WIP

Author: AnnaSjerling

modules/ROOT/pages/clustering/disaster-recovery.adoc

@@ -7,8 +7,8 @@ A database can become unavailable due to issues on different system levels.
 For example, a data center failover may lead to the loss of multiple servers, which may cause a set of databases to become unavailable.
 
 This section contains a step-by-step guide on how to recover *unavailable databases* that are incapable of serving writes, while possibly still being able to serve reads.
+The guide recovers the unavailable databases and make them fully operational, with minimal impact on the other databases in the cluster.
 However, if a database is not performing as expected for other reasons, this section cannot help.
-By following the steps outlined here, you can recover the unavailable databases and make them fully operational, with minimal impact on the other databases in the cluster.
 
 [CAUTION]
 ====
@@ -62,7 +62,7 @@ See xref:clustering/setup/routing.adoc#clustering-routing[Server-side routing] f
 
 ==== State
 ====
-The Neo4j process is started on all _offline_ servers.
+The Neo4j process is started on all servers which are not _lost_.
 ====
 
 ==== Path to correct state
@@ -117,14 +117,14 @@ This causes downtime for all databases in the cluster until the processes are st
 . On each server, run `bin/neo4j-admin database info system` and compare the `lastCommittedTransaction` to find out which server has the most up-to-date copy of the `system` database.
 . On the most up-to-date server, run `bin/neo4j-admin database dump system --to-path=[path-to-dump]` to take a dump of the current `system` database and store it in an accessible location.
 . For every _lost_ server, add a new *unconstrained* one according to xref:clustering/servers.adoc#cluster-add-server[Add a server to the cluster].
-It is important that the new servers are unconstrained, or deallocating servers might be blocked even though enough servers were added.
+It is important that the new servers are unconstrained, or deallocating servers in the next step of this guide might be blocked, even though enough servers were added.
 +
 [NOTE]
 =====
 While recommended, it is not strictly necessary to add new servers in this step.
 There is also an option to change the `system` database mode (`server.cluster.system_database_mode`) on secondary allocations to make them primary allocations for the new `system` database.
 The amount of primary allocations needed is defined by `dbms.cluster.minimum_initial_system_primaries_count`, see the xref:configuration/configuration-settings.adoc#config_dbms.cluster.minimum_initial_system_primaries_count[Configuration settings] for more information.
-Not replacing servers can cause cluster overload when databases are moved from lost servers to available ones in the next step of this guide.
+Be aware that not replacing servers can cause cluster overload when databases are moved from lost servers to available ones in the next step of this guide.
 =====
 +
 . On each server, run `bin/neo4j-admin database load system --from-path=[path-to-dump] --overwrite-destination=true` to load the current `system` database dump.
@@ -143,8 +143,8 @@ All servers in the cluster's view are available and enabled.
 
 A lost server will still be in the `system` database's view of the cluster, but in an unavailable state.
 According to the view of the cluster, these lost servers are still hosting the databases they had before they became lost.
-Therefore, removing lost servers is not as easy as informing the `system` database that they are lost.
-It also includes moving requested allocations on the lost servers onto servers which are actually in the cluster, so that those databases' topologies are still satisfied.
+Therefore, informing the cluster of servers which are lost is not enough.
+The databases hosted on the lost servers also need to be moved onto servers which are actually in the cluster.
 
 ==== Example verification
 The cluster's view of servers can be seen by listing the servers, see xref:clustering/servers.adoc#_listing_servers[Listing servers] for more information.
@@ -157,7 +157,7 @@ SHOW SERVERS;
 
 ==== Path to correct state
 The following steps can be used to remove lost servers and add new ones to the cluster.
-They include moving any potential database allocations from lost servers to available servers in the cluster.
+That includes moving any potential database allocations from lost servers to available servers in the cluster.
 These steps might also recreate some databases, since a database which has lost a majority of its primary allocations cannot be moved from one server to another.
 
 .Guide