openstack
/
operations-guide
Code Issues Proposed changes

Merge "Copyedit ops backup chapter"

This commit is contained in:
Jenkins 2014-03-18 00:29:25 +00:00 committed by Gerrit Code Review
parent 4c2a267237 e593438033
commit 1bffa8a6f5
1 changed files with 23 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
doc/openstack-ops/ch_ops_backup_recovery.xml
View File

@ -13,7 +13,7 @@
<?dbhtml stop-chunking?>
<title>Backup and Recovery</title>
<para>Standard backup best practices apply when creating your
OpenStack backup policy. For example, how often to backup your
OpenStack back up policy. For example, how often to backup your
data is closely related to how quickly you need to recover
from data loss.</para>
<note>
@ -21,12 +21,12 @@
focus on a highly available deployment. The
<citetitle><link
xlink:href="http://docs.openstack.org/high-availability-guide/content/"
>OpenStack High Availability Guide offers
>OpenStack High Availability Guide</link></citetitle> 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>
downtime and data loss.
</para></note>
<para>Other backup considerations include:</para>
<itemizedlist>
@ -53,14 +53,14 @@
files and databases that the various OpenStack components
need to run. This chapter does not describe how to back up
objects inside Object Storage or data contained inside
Block Storage. Generally these areas are left for the user
Block Storage. Generally these areas are left for users
to back up on their own.</para>
</section>
<section xml:id="database_backups">
<title>Database Backups</title>
<para>The example OpenStack architecture designates the Cloud
Controller as the MySQL server. This MySQL server hosts
the databases for Nova, Glance, Cinder, and Keystone. With
<para>The example OpenStack architecture designates the cloud
controller as the MySQL server. This MySQL server hosts
the databases for nova, glance, cinder, and keystone. With
all of these databases in one place, it's very easy to
create a database backup:</para>
@ -81,29 +81,29 @@ filename="${backup_dir}/mysql-`hostname`-`eval date +%Y%m%d`.sql.gz"
/usr/bin/mysqldump --opt --all-databases | gzip &gt; $filename
# Delete backups older than 7 days
find $backup_dir -ctime +7 -type f -delete</programlisting>
<para>This script dumps the entire MySQL database and delete
any backups older than 7 days.</para>
<para>This script dumps the entire MySQL database and deletes
any backups older than seven days.</para>
</section>
<section xml:id="file_system_backups">
<title>File System Backups</title>
<para>This section discusses which files and directories should be backed up regularly, organized by service.</para>
<section xml:id="compute">
<title>Compute</title>
<para>The <code>/etc/nova</code> directory on both the
<para>The <filename>/etc/nova</filename> directory on both the
cloud controller and compute nodes should be regularly
backed up.</para>
<para>
<code>/var/log/nova</code> does not need backed up if
<code>/var/log/nova</code> does not need to be backed up if
you have all logs going to a central area. It is
highly recommended to use a central logging server or
backup the log directory.</para>
back up the log directory.</para>
<para>
<code>/var/lib/nova</code> is another important
directory to backup. The exception to this is the
directory to back up. The exception to this is the
<code>/var/lib/nova/instances</code> subdirectory
on compute nodes. This subdirectory contains the KVM
images of running instances. You would only want to
back up this directory if you need to maintain backup
images of running instances. You would want to
back up this directory only if you need to maintain backup
copies of all instances. Under most circumstances, you
do not need to do this, but this can vary from cloud
to cloud and your service levels. Also be aware that
@ -116,12 +116,12 @@ find $backup_dir -ctime +7 -type f -delete</programlisting>
<para>
<code>/etc/glance</code> and
<code>/var/log/glance</code> follow the same rules
at the nova counterparts.</para>
as their nova counterparts.</para>
<para>
<code>/var/lib/glance</code> should also be backed up.
Take special notice of
<code>/var/lib/glance/images</code>. If you are
using a file-based back-end of Glance,
using a file-based backend of glance,
<code>/var/lib/glance/images</code> is where the
images are stored and care should be taken.</para>
<para>There are two ways to ensure stability with this
@ -140,7 +140,7 @@ find $backup_dir -ctime +7 -type f -delete</programlisting>
<code>/var/log/keystone</code> follow the same
rules as other components.</para>
<para>
<code>/var/lib/keystone</code>, while should not
<code>/var/lib/keystone</code>, although it should not
contain any data being used, can also be backed up
just in case.</para>
</section>
@ -158,13 +158,13 @@ find $backup_dir -ctime +7 -type f -delete</programlisting>
<title>Object Storage</title>
<para>
<code>/etc/swift</code> is very important to have
backed up. This directory contains the Swift
backed up. This directory contains the swift
configuration files as well as the ring files and ring
<glossterm>builder file</glossterm>s, which if
lost render the data on your cluster inaccessible. A
best practice is to copy the builder files to all
storage nodes along with the ring files. Multiple
backups copies are spread throughout your storage
backup copies are spread throughout your storage
cluster.</para>
</section>
</section>
@ -181,10 +181,10 @@ find $backup_dir -ctime +7 -type f -delete</programlisting>
# stop nova-novncproxy
# stop nova-objectstore
# stop nova-scheduler</programlisting>
<para>Now you can import a previously backed up
<para>Now you can import a previously backed-up
database:</para>
<programlisting language="bash"><?db-font-size 65%?><prompt>#</prompt> mysql nova &lt; nova.sql</programlisting>
<para>As well as restore backed up nova directories:</para>
<para>You can also restore backed-up nova directories:</para>
<programlisting language="bash"><?db-font-size 65%?><prompt>#</prompt> mv /etc/nova{,.orig}
# cp -a /path/to/backup/nova /etc/</programlisting>
<para>Once the files are restored, start everything back
@ -203,7 +203,7 @@ find $backup_dir -ctime +7 -type f -delete</programlisting>
<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
service, and appropriate file system locations, you can be assured
you can handle any event requiring recovery.</para>
</section>
</chapter>