Added instructions on volume backup and export
This patch adds two sections: one for volume backup, and the other for exporting volume metadata. The feature in focus here is the volume metadata export, which makes volume backups portable across cloud services and also recoverable even in the event of cinder database failure. Partially implements: https://blueprints.launchpad.net/cinder/+spec/cinder-backup-recover-api Partially implements: https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support Change-Id: I0ffa0c7ab9b9ecd3449e93390099e8d0001c8efd
This commit is contained in:
parent
fb98f857ea
commit
29d7064fe9
@ -125,6 +125,8 @@
|
||||
<xi:include href="section_backup-block-storage-disks.xml"/>
|
||||
<xi:include href="section_volume-migration.xml"/>
|
||||
<xi:include href="section_glusterfs_removal.xml"/>
|
||||
<xi:include href="section_volume-backups.xml"/>
|
||||
<xi:include href="section_volume-backups-export-import.xml"/>
|
||||
</section>
|
||||
<section xml:id="troubleshooting-cinder-install">
|
||||
<title>Troubleshoot your installation</title>
|
||||
|
@ -0,0 +1,41 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
||||
xml:id="volume-backup-restore-export-import">
|
||||
<title>Export and import backup metadata</title>
|
||||
<para>A volume backup can only be restored on the same Block
|
||||
Storage service. This is because restoring a volume from a backup
|
||||
requires metadata available on the database used by the Block
|
||||
Storage service.</para>
|
||||
<note><para>For information on how to back up and restore a
|
||||
volume, see <xref linkend="volume-backup-restore"/>.</para></note>
|
||||
<para>You can, however, export the metadata of a volume backup. To
|
||||
do so, run this command as an OpenStack <literal>admin</literal>
|
||||
user (presumably, after creating a volume backup):
|
||||
</para>
|
||||
<screen><prompt>$</prompt> <userinput>cinder backup-export <replaceable>backup_ID</replaceable></userinput></screen>
|
||||
<para>Where <replaceable>backup_ID</replaceable> is the volume
|
||||
backup's ID. This command should return the backup's corresponding
|
||||
database information as encoded string metadata.</para>
|
||||
<para>Exporting and storing this encoded string metadata allows
|
||||
you to completely restore the backup, even in the event of a
|
||||
catastrophic database failure. This will preclude the need to
|
||||
back up the entire Block Storage database, particularly if you
|
||||
only need to keep complete backups of a small subset of
|
||||
volumes.</para>
|
||||
<para>In addition, having a volume backup and its backup metadata also
|
||||
provides volume portability. Specifically, backing up a volume and
|
||||
exporting its metadata will allow you to restore the volume on a
|
||||
completely different Block Storage database, or even on a different
|
||||
cloud service. To do so, first import the backup metadata to the Block
|
||||
Storage database and then restore the backup. </para>
|
||||
<para>To import backup metadata, run the following command as an
|
||||
OpenStack <literal>admin</literal>:</para>
|
||||
<screen><prompt>$</prompt> <userinput>cinder backup-import <replaceable>metadata</replaceable></userinput></screen>
|
||||
<para>Where <replaceable>metadata</replaceable> is the backup
|
||||
metadata exported earlier.</para>
|
||||
<para>Once you have imported the backup metadata into a Block Storage
|
||||
database, restore the volume (<xref
|
||||
linkend="volume-backup-restore"/>).</para>
|
||||
</section>
|
31
doc/admin-guide-cloud/section_volume-backups.xml
Normal file
31
doc/admin-guide-cloud/section_volume-backups.xml
Normal file
@ -0,0 +1,31 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
||||
xml:id="volume-backup-restore">
|
||||
<title>Back up and restore volumes</title>
|
||||
<para>The <command>cinder</command> command-line interface
|
||||
provides the tools for creating a volume backup. You can restore
|
||||
a volume from a backup as long as the backup's associated database
|
||||
information (or backup metadata) is intact in the Block Storage
|
||||
database.
|
||||
</para>
|
||||
<para>Run this command to create a backup of a volume:</para>
|
||||
<screen><prompt>$</prompt> <userinput>cinder backup-create <replaceable>VOLUME</replaceable></userinput></screen>
|
||||
<para>Where <replaceable>VOLUME</replaceable> is the name or ID of
|
||||
the volume.</para>
|
||||
<para>The previous command will also return a backup ID. Use this
|
||||
backup ID when restoring the volume, as in:</para>
|
||||
<screen><prompt>$</prompt> <userinput>cinder backup-restore <replaceable>backup_ID</replaceable></userinput></screen>
|
||||
<para>As mentioned earlier, volume backups are dependent on the
|
||||
Block Storage database. Because of this, we recommend that you
|
||||
also back up your Block Storage database regularly in order to
|
||||
ensure data recovery.</para>
|
||||
<note><para>Alternatively, you can export and save the metadata of
|
||||
selected volume backups. Doing so will preclude the need to
|
||||
back up the entire Block Storage database. This is particularly
|
||||
useful if you only need a small subset of volumes to survive a
|
||||
catastrophic database failure.</para>
|
||||
<para>For more information on how to export and import volume
|
||||
backup metadata, see <xref linkend="volume-backup-restore-export-import"/>.</para></note>
|
||||
</section>
|
Loading…
Reference in New Issue
Block a user