Update the note

Author: NataliaIvakina

modules/ROOT/pages/backup-restore/planning.adoc

@@ -183,16 +183,17 @@ Backing up a database in a clustered environment is not essentially different fr
 Use `SHOW DATABASE <database>` to learn which servers are hosting the database you want to back up.
 See xref:clustering/monitoring/show-databases-monitoring.adoc#show-databases-monitoring-listing-single[Listing a single database] for more information.
 
-However, _restoring_ a database in a cluster is different since it is not known in advance how a database is going to be allocated to the servers in a cluster.
-This method relies on the seed already existing on one of the servers.
+Restoring from the command line involves putting a copy of the database on disk on each server that will need it.
+That can be awkward to achieve.
 The recommended way to restore a database in a cluster is to xref::database-administration/standard-databases/seed-from-uri.adoc[seed from URI].
 
 [IMPORTANT]
 ====
-When backing up a clustered database, be aware that the xref:clustering/introduction.adoc#clustering-introduction-operational[cluster topology] metadata is not included in the backup.
-The cluster topology is stored in the `system` database and describes how the copies of a database should be spread across the servers in a cluster.
+By default, a database backup includes only the database contents.
+If you choose to include metadata, the backup also stores the role-based access control (RBAC) settings associated with the database.
 
-Because this metadata is excluded from backups, restoring to a new cluster environment requires manual reconfiguration of servers modes and database allocations. 
+When restoring, you have the flexibility to define the target topology (how many primaries and secondaries are desired for the database), which may differ from the topology at backup time.
+The database will then be allocated across the available servers according to that topology. 
 ====
 
 [[backup-planning-databases]]