Apply suggestions from code review

Author: NataliaIvakina

modules/ROOT/pages/clustering/multi-region-deployment/geo-redundant-deployment.adoc

@@ -103,23 +103,25 @@ Your writes will be fast, because they are within the DC.
 
 If a DC goes down, you retain write availability for the `system` database, which makes restoring write availability to the user databases easier.
 
-However, if the DC with primaries goes down, you lose write availability for the user databases.
+However, if the DC with primaries goes down, the user databases will become write-unavailable.
 Though read availability may remain via the secondaries.
 
 ==== Recovering from the loss of a data center
 
 If you lose the DC with primaries in, the user databases will go write-unavailable, though the secondaries should continue to provide read availability.
 Because of the third DC, the `system` database remains write-available, so you will be able to get the user databases back to write-available without process downtime.
 
-However, if you need to use the `recreateDatabase()` procedure, it will involve downtime for the user database.
+However, if you need to use the xref:database-administration/standard-databases/recreate-database.adoc[`dbms.recreateDatabase()` procedure], it will involve downtime for the user database.
 
 Example recovery steps::
 
 . Mark missing servers as not present by cordoning them.
 For each `Unavailable` server, run `CALL dbms.cluster.cordonServer("unavailable-server-id")` on one of the available servers.
 
 . Recreate each user database, letting it select the existing xref:database-administration/standard-databases/recreate-database.adoc#seed-servers[servers as seeders].
-You need to accept a smaller topology that fits in the remaining data center.
+You need to accept a smaller topology that will fit in the remaining data center.
+
+For detailed scenarios, see the xref:clustering/multi-region-deployment/disaster-recovery.adoc[Disaster recovery guide].
 
 
 [[cluster-anti-patterns]]