Further refinements

docs/modules/storage/pages/persistence.adoc

@@ -7,7 +7,9 @@
 
 == Why Persist Data
 
-Data in Hazelcast is usually stored in-memory (RAM) so that it's faster to access. However, data in RAM is volatile, meaning that when a member shuts down, its data is lost. In-memory partition backups are the primary method for data resilience in Hazelcast but additionally persisting data to disk can be useful in certain situations. When you persist data on disk, members can load it upon a restart instead of relying on other active members sending it over the network. In the case of cluster-wide failure - e.g. due to data centre power outage - where we cannot rely on receiving the data from other active members, persistence means that we can recover data that would otherwise be irreversibly lost.
+Data in Hazelcast is usually stored in-memory (RAM) so that it's faster to access. However, data in RAM is volatile, meaning that when a member shuts down, its data is lost. In-memory partition backups are the primary method for data resilience in Hazelcast, but additionally persisting data to disk can reduce downtime and data loss in certain scenarios.
+
+When you persist data on disk, members can load it on restart, instead of waiting for other active members to send it over the network. In a cluster-wide failure - e.g. due to a data center power outage - there are no active members to receive data from, so persistence means that we can recover data that would otherwise be lost.
 
 Clusters can use persisted data for the following scenarios:
 
@@ -17,11 +19,11 @@ Clusters can use persisted data for the following scenarios:
 +
 [IMPORTANT]
 ====
-In order for persistence to function correctly for planned cluster shutdowns you must first put the cluster into `PASSIVE` state before shutting down members. A list of methods for gracefully shutting down a cluster can be found in the xref:maintain-cluster:shutdown.adoc[shutdown] docs.
+In order for persistence to function correctly for planned cluster shutdowns you must first put the cluster into `PASSIVE` state before shutting down members. A list of methods for gracefully shutting down a cluster can be found in the xref:maintain-cluster:shutdown.adoc[shutdown] documentation.
 ====
-** **Unplanned**: A cluster is restarted after all its members crash at the same time due an event such as a power outage. Note that some data loss is expected unless `fsync` is set to `true`. For more information, see xref:storage:configuring-persistence.adoc#data-structures[Data structure options].
+** **Unplanned**: A cluster is restarted after all its members crash at the same time due to an event such as a power outage. Note that some data loss is expected unless `fsync` is set to `true`. For more information, see xref:storage:configuring-persistence.adoc#data-structures[Data structure options].
 
-- **Accelerating single member restarts**: 
+- **Single member restarts**: 
 
 ** **Planned**: During a rolling restart each cluster member is restarted one by one for scenarios such as installing an operating system patch or new hardware. xref:maintain-cluster:rolling-upgrades.adoc[Rolling upgrades] are an example of a rolling restart.
 ** **Unplanned**: A single member may crash or terminate unexpectedly at any time, using persistence allows faster recovery by using the data on disk where possible. In some cases a member can recover entirely using the data on disk removing the need to transfer data over the network.