diff --git a/doc/openstack-ops/ch_ops_backup_recovery.xml b/doc/openstack-ops/ch_ops_backup_recovery.xml
index 9bea4b52..07489541 100644
--- a/doc/openstack-ops/ch_ops_backup_recovery.xml
+++ b/doc/openstack-ops/ch_ops_backup_recovery.xml
@@ -16,12 +16,18 @@
OpenStack backup policy. For example, how often to backup your
data is closely related to how quickly you need to recover
from data loss.</para>
- <note><para>If you cannot have any data loss at
- all, you should also focus on high availability deployment
- methodologies at all layers - from your hardware capability
- to your control infrastructure segregation. Running multiple services
- storing your back-end data decreases the risk that there will
- be a data loss event in the event one fails.</para></note>
+ <note>
+ <para>If you cannot have any data loss at all, you should also
+ focus on a highly available deployment. The
+ <citetitle><link
+ xlink:href="http://docs.openstack.org/high-availability-guide/content/"
+ >OpenStack High Availability Guide offers
+ suggestions for elimination of a single point of
+ failure that could cause system downtime. While it
+ is not a completely prescriptive document, it
+ offers methods and techniques for avoiding
+ downtime and data loss.</link></citetitle>
+ </para></note>
<para>Other backup considerations include:</para>
<itemizedlist>
<listitem>
@@ -192,4 +198,12 @@ find $backup_dir -ctime +7 -type f -delete</programlisting>
<para>Other services follow the same process, with their
respective directories and databases.</para>
</section>
+ <section xml:id="ops-backup-recovery-summary">
+ <title>Summary</title>
+ <para>Backup and subsequent recovery is one of the first tasks system
+ administrators learn. However, each system has different
+ items that need attention. By taking care of your database, image
+ service and appropriate file system locations, you can be assured
+ you can handle any event requiring recovery.</para>
+ </section>
</chapter>