104 lines
6.0 KiB
XML
104 lines
6.0 KiB
XML
<?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 [--incremental] <replaceable>VOLUME</replaceable></userinput></screen>
|
|
<para>Where <replaceable>VOLUME</replaceable> is the name or ID of the volume,
|
|
and <option>incremental</option> is a flag that indicates whether an
|
|
incremental backup should be performed.</para>
|
|
<para>Without the <option>incremental</option> flag, a full backup is
|
|
created by default. With the <option>incremental</option> flag, an
|
|
incremental backup is created.</para>
|
|
<note><para>The <option>incremental</option> flag is only available for
|
|
block storage API v2. You have to specify [--os-volume-api-version 2]
|
|
in the <command>cinder</command> command-line interface to use this
|
|
parameter.</para></note>
|
|
<para>The incremental backup is based on a parent backup which is an
|
|
existing backup with the latest timestamp. The parent backup can be a full
|
|
backup or an incremental backup depending on the timestamp.</para>
|
|
<note><para>The first backup of a volume has to be a full backup. Attempting
|
|
to do an incremental backup without any existing backups will fail.
|
|
</para></note>
|
|
<para>A new configure option <option>backup_swift_block_size</option>
|
|
is introduced into <filename>cinder.conf</filename> for the default Swift
|
|
backup driver. This is the size in bytes that changes are tracked for
|
|
incremental backups. The existing <option>backup_swift_object_size
|
|
</option> option, the size in bytes of Swift backup objects, has to be a
|
|
multiple of <option>backup_swift_block_size</option>. The default is 32768
|
|
for <option>backup_swift_block_size</option>, and the default is 52428800
|
|
for <option>backup_swift_object_size</option>.
|
|
</para>
|
|
<para>This command also returns a backup ID. Use this backup ID when restoring the volume:</para>
|
|
<screen><prompt>$</prompt> <userinput>cinder backup-restore <replaceable>BACKUP_ID</replaceable></userinput></screen>
|
|
<para>When restoring from a full backup, it is a full restore.</para>
|
|
<para>When restoring from an incremental backup, a list of backups is
|
|
built based on the IDs of the parent backups. A full restore is
|
|
performed based on the full backup first, then restore is done based
|
|
on the incremental backup, laying on top of it in order.</para>
|
|
<para>Because volume backups are dependent on the Block Storage database, you must also back up
|
|
your Block Storage database regularly to ensure data recovery.</para>
|
|
<note>
|
|
<para>Alternatively, you can export and save the metadata of selected volume backups. Doing so
|
|
precludes the need to back up the entire Block Storage database. This is useful if you need
|
|
only a small subset of volumes to survive a catastrophic database failure.</para>
|
|
<para>If you specify a UUID encryption key when setting up the volume specifications, the
|
|
backup metadata ensures that the key will remain valid when you back up and restore
|
|
the volume.</para>
|
|
<para>For more information about how to export and import volume backup metadata, see <xref
|
|
linkend="volume-backup-restore-export-import"/>.</para>
|
|
</note>
|
|
<para>By default, the swift object store is used for the backup repository.</para>
|
|
<para>
|
|
If instead you want to use an NFS export as the backup repository,
|
|
add the following configuration options to the
|
|
<literal>[DEFAULT]</literal> section of the
|
|
<filename>cinder.conf</filename> file and restart the Block
|
|
Storage services:
|
|
</para>
|
|
<programlisting language="ini">backup_driver = cinder.backup.drivers.nfs
|
|
backup_share = <replaceable>HOST</replaceable>:<replaceable>EXPORT_PATH</replaceable></programlisting>
|
|
<para>
|
|
For the <option>backup_share</option> option, replace
|
|
<replaceable>HOST</replaceable> with the DNS resolvable host name or
|
|
the IP address of the storage server for the NFS share, and
|
|
<replaceable>EXPORT_PATH</replaceable> with the path to that
|
|
share. If your environment requires that non-default mount
|
|
options be specified for the share, set these as follows:
|
|
</para>
|
|
<programlisting language="ini">backup_mount_options = <replaceable>MOUNT_OPTIONS</replaceable></programlisting>
|
|
<para>
|
|
<replaceable>MOUNT_OPTIONS</replaceable> is a comma-separated
|
|
string of NFS mount options as detailed in the NFS man page.
|
|
</para>
|
|
<para>There are several other options whose default values may be overriden as appropriate for your environment:
|
|
</para>
|
|
<programlisting language="ini">backup_compression_algorithm = zlib
|
|
backup_sha_block_size_bytes = 32768
|
|
backup_file_size = 1999994880</programlisting>
|
|
<para>
|
|
The option <option>backup_compression_algorithm</option> can be
|
|
set to <literal>bz2</literal> or <literal>None</literal>. The
|
|
latter can be a useful setting when the server providing the share
|
|
for the backup repository itself performs deduplication or
|
|
compression on the backup data.
|
|
</para>
|
|
<para>
|
|
The option <option>backup_file_size</option> must be a multiple of
|
|
<option>backup_sha_block_size_bytes</option>. It is effectively
|
|
the maximum file size to be used, given your environment, to hold
|
|
backup data. Volumes larger than this will be stored in multiple
|
|
files in the backup repository. The
|
|
<option>backup_sha_block_size_bytes</option> option determines the size
|
|
of blocks from the cinder volume being backed up on which digital
|
|
signatures are calculated in order to enable incremental
|
|
backup capability.
|
|
</para>
|
|
</section>
|