Editing controller files for DITA (#4037) (#4040)

Configuring automation execution modular compliance chapter 17

https://issues.redhat.com/browse/AAP-46737

Affects titles/controller-admin-guide

Author: EMcWhinn

downstream/assemblies/platform/assembly-ag-controller-backup-and-restore.adoc

@@ -4,7 +4,7 @@
 
 = Backup and restore
 
-You can backup and restore your system using the {PlatformNameShort} setup playbook. 
+You can backup and restore your system by using the {PlatformNameShort} setup playbook. 
 
 For more information, see the link:{URLControllerAdminGuide}/index#controller-backup-restore-clustered-environments[Backup and restore clustered environments] section.
 
@@ -18,7 +18,7 @@ Backup and restore functionality only works with the PostgreSQL versions support
 For more information, see link:{URLPlanningGuide}/platform-system-requirements[System requirements] in _{TitlePlanningGuide}_.
 ====
 
-The {PlatformNameShort} setup playbook is invoked as `setup.sh` from the path where you unpacked the platform installer tarball. 
+The {PlatformNameShort} setup playbook is invoked as `setup.sh` from the path where you unpacked the platform installer tar file. 
 It uses the same inventory file used by the install playbook. 
 The setup script takes the following arguments for backing up and restoring:
 
@@ -56,6 +56,9 @@ setup.sh -i <inventory file>
 ----
 
 include::platform/con-controller-backup-restore-playbooks.adoc[leveloffset=+1]
+
 include::platform/ref-controller-backup-restore-considerations.adoc[leveloffset=+1]
+
 include::platform/ref-controller-backup-restore-clustered-environments.adoc[leveloffset=+1]
+
 include::platform/con-controller-restore-different-cluster.adoc[leveloffset=+2]

downstream/modules/platform/con-controller-backup-restore-playbooks.adoc

@@ -16,7 +16,7 @@ These playbooks serve to backup and restore.
 ** Manual projects
 * The restore backup restores the backed up files and data to a freshly installed and working second instance of {ControllerName}.
 
-When restoring your system, the installer checks to see that the backup file exists before beginning the restoration. 
+When restoring your system, installation program checks to see that the backup file exists before beginning the restoration. 
 If the backup file is not available, your restoration fails.
 
 [NOTE]

downstream/modules/platform/ref-controller-backup-restore-clustered-environments.adoc

@@ -8,12 +8,12 @@ The procedure for backup and restore for a clustered environment is similar to a
 
 [NOTE]
 ====
-For more information on installing clustered environments, see the xref:controller-cluster-install[Install and configure] section.
+For more information about installing clustered environments, see the xref:controller-cluster-install[Install and configure] section.
 ====
 
 * If restoring to a new cluster, ensure that the old cluster is shut down before proceeding because they can conflict with each other when accessing the database.
 * Per-node backups are only restored to nodes bearing the same hostname as the backup.
-* When restoring to an existing cluster, the restore contains the following:
+* When restoring to an existing cluster, the restore has the following:
 
 ** A dump of the PostgreSQL database
 ** UI artifacts, included in the database dump

downstream/modules/platform/ref-controller-backup-restore-considerations.adoc

@@ -20,7 +20,7 @@ The {PlatformNameShort} database backups are staged on each node at `/var/backup
 Version:: You must always use the most recent minor version of a release to backup or restore your {PlatformNameShort} installation version. 
 For example, if the current platform version you are on is 2.0.x, only use the latest 2.0 installer.
 
-File path:: When using `setup.sh` in order to do a restore from the default restore file path, `/var/lib/awx`, `-r` is still required in order to do the restore, but it no longer accepts an argument. 
+File path:: When using `setup.sh` to do a restore from the default restore file path, `/var/lib/awx`, `-r` is still required to do the restore, but it no longer accepts an argument. 
 If a non-default restore file path is needed, you must provide this as an extra_var (`root@localhost:~# ./setup.sh -e 'restore_backup_file=/path/to/nondefault/backup.tar.gz' -r`).
 
 Directory:: If the backup file is placed in the same directory as the `setup.sh` installer, the restore playbook automatically locates the restore files.