Update disaster-recovery.adoc

Author: NataliaIvakina

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

@@ -30,7 +30,7 @@ In this guide the following terms are used:
 
 * An _offline_ server is a server that is not running but may be restartable.
 * A _lost_ server, however, is a server that is currently not running and cannot be restarted.
-* A _write-available_ database is able to serve writes, while a _write unavailable_ database is not.
+* A _write-available_ database is able to serve writes, while a _write-unavailable_ database is not.
 ====
 
 There are four steps to recovering a cluster from a disaster:
@@ -92,7 +92,7 @@ The `system` database contains the view of the cluster.
 This includes which servers and databases are present, where they live and how they are configured.
 During a disaster, the view of the cluster might need to change to reflect a new reality, such as removing lost servers.
 Databases might also need to be recreated to regain write availability.
-Because both of these steps are executed by modifying the `system` database, making the `system` database write-enabled is a vital first step during disaster recovery.
+Because both of these steps are executed by modifying the `system` database, making the `system` database write-available is a vital first step during disaster recovery.
 
 ==== Verifying the state
 
@@ -175,7 +175,7 @@ SHOW SERVERS;
 ==== Path to correct state
 Use the following steps to remove lost servers and add new ones to the cluster.
 To remove lost servers, any allocations they were hosting must be moved to available servers in the cluster.
-This is done in two different ways:
+This is done in two different steps:
 
 * Any allocations that cannot move by themselves require the database to be recreated so that they are forced to move.
 * Any allocations that can move will be instructed to do so by deallocating the server.
@@ -288,7 +288,7 @@ Recreations might fail for different reasons, but one example is that the checks
 .Guide
 [%collapsible]
 ====
-. Identify all write unavailable databases by running `CALL dbms.cluster.statusCheck([])` as described in the xref:clustering/disaster-recovery.adoc#example-verification[Example verification] part of this disaster recovery step.
+. Identify all write-unavailable databases by running `CALL dbms.cluster.statusCheck([])` as described in the xref:clustering/disaster-recovery.adoc#example-verification[Example verification] part of this disaster recovery step.
 Filter out all databases desired to be stopped, so that they are not recreated unnecessarily.
 . Recreate every database that is not write-available and has not been recreated previously.
 See xref:clustering/databases.adoc#recreate-databases[Recreate databases] for more information.