<?xml version='1.0' encoding='utf-8'?>
<chapter xmlns="http://docbook.org/ns/docbook"
-xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US"
-xml:id="backupandrestore">
+ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US"
+ xml:id="backupandrestore">
<title xml:id="backupandrestore.title">Backing Up and Restoring a File
System</title>
<para>This chapter describes how to backup and restore at the file
<itemizedlist>
<listitem>
<para>
- <xref linkend="dbdoclet.backup_file"/>
+ <xref linkend="backup_file"/>
</para>
</listitem>
<listitem>
<para>
- <xref linkend="dbdoclet.backup_device"/>
+ <xref linkend="backup_device"/>
</para>
</listitem>
<listitem>
</listitem>
<listitem>
<para>
- <xref linkend="dbdoclet.backup_lvm_snapshot"/>
+ <xref linkend="backup_lvm_snapshot"/>
</para>
</listitem>
</itemizedlist>
<para>It is <emphasis>strongly</emphasis> recommended that sites perform
periodic device-level backup of the MDT(s)
- (<xref linkend="dbdoclet.backup_device"/>),
+ (<xref linkend="backup_device"/>),
for example twice a week with alternate backups going to a separate
device, even if there is not enough capacity to do a full backup of all
of the filesystem data. Even if there are separate file-level backups of
it is needed), and only needs good linear read/write performance. While
the device-level MDT backup is not useful for restoring individual files,
it is most efficient to handle the case of MDT failure or corruption.</para>
- <section xml:id="dbdoclet.backup_file">
+ <section xml:id="backup_file">
<title>
<indexterm>
<primary>backup</primary>
<literal>lustre_rsync</literal> is run, the user must specify a set of
parameters for the program to use. These parameters are described in
the following table and in
- <xref linkend="dbdoclet.50438219_63667" />. On subsequent runs, these
+ <xref linkend="lustre_rsync" />. On subsequent runs, these
parameters are stored in the the status file, and only the name of the
status file needs to be passed to
<literal>lustre_rsync</literal>.</para>
</section>
</section>
</section>
- <section xml:id="dbdoclet.backup_device">
+ <section xml:id="backup_device">
<title>
<indexterm>
<primary>backup</primary>
expensive storage than the actual MDT device(s) since it only needs to
have good streaming read/write speed instead of high random IOPS.</para>
</note>
- <warning condition='l23'>
- <para>In Lustre software release 2.0 through 2.2, the only successful
- way to backup and restore an MDT is to do a device-level backup as is
- described in this section. File-level restore of an MDT is not possible
- before Lustre software release 2.3, as the Object Index (OI) file cannot
- be rebuilt after restore without the OI Scrub functionality.
- Since Lustre 2.3, Object Index files are automatically rebuilt at first
- mount after a restore is detected (see
- <link xl:href="http://jira.whamcloud.com/browse/LU-957">LU-957</link>),
- and file-level backup is supported (see
- <xref linkend="backup_fs_level"/>).</para>
- </warning>
<para>If hardware replacement is the reason for the backup or if a spare
storage device is available, it is possible to do a raw copy of the MDT or
OST from one block device to the other, as long as the new device is at
<para>Even in the face of hardware errors, the <literal>ldiskfs</literal>
file system is very robust and it may be possible
to recover the file system data after running
- <literal>e2fsck -fy /dev/{newdev}</literal> on the new device, along with
- <literal>ll_recover_lost_found_objs</literal> for OST devices.</para>
- <para condition="l26">With Lustre software version 2.6 and later, there is
- no longer a need to run
- <literal>ll_recover_lost_found_objs</literal> on the OSTs, since the
+ <literal>e2fsck -fy /dev/{newdev}</literal> on the new device.</para>
+ <para>With Lustre software version 2.6 and later, the
<literal>LFSCK</literal> scanning will automatically move objects from
<literal>lost+found</literal> back into its correct location on the OST
after directory corruption.</para>
it is the preferred method for migration of OST devices, especially when it
is desirable to reformat the underlying file system with different
configuration options or to reduce fragmentation.</para>
- <note><para>
- <emphasis role="bold">Prior to Lustre software release 2.3</emphasis>, the
- only successful way to perform an MDT backup and restore was to do a
- device-level backup as described in
- <xref linkend="dbdoclet.backup_device" />. The ability to do MDT
- file-level backups is not available for Lustre software release 2.0
- through 2.2, because restoration of the Object Index (OI) file does not
- return the MDT to a functioning state.</para>
- <para><emphasis role="bold">Since Lustre software release 2.3</emphasis>,
- Object Index files are automatically rebuilt at first mount after a
- restore is detected (see
- <link xl:href="http://jira.whamcloud.com/browse/LU-957">LU-957</link>),
- so file-level MDT restore is supported.</para></note>
+ <note>
+ <para>Since Lustre stores internal metadata that maps FIDs to local
+ inode numbers via the Object Index file, they need to be rebuilt at
+ first mount after a restore is detected so that file-level MDT backup
+ and restore is supported. The OI Scrub rebuilds these automatically
+ at first mount after a restore is detected, which may affect MDT
+ performance after mount until the rebuild is completed. Progress can
+ be monitored via <literal>lctl get_param osd-*.*.oi_scrub</literal>
+ on the MDS or OSS node where the target filesystem was restored.
+ </para>
+ </note>
<section xml:id="backup_fs_level.index_objects" condition="l2B">
<title>
<indexterm>
before the unmount of the target (MDT or OST) in order to be able to
restore the file system successfully. To enable index backup on the
target, execute the following command on the target server:</para>
- <screen># lctl set_param osd-zfs.${fsname}-${target}.index_backup=1</screen>
+ <screen># lctl set_param osd-*.${fsname}-${target}.index_backup=1</screen>
<para><replaceable>${target}</replaceable> is composed of the target type
(MDT or OST) plus the target index, such as <literal>MDT0000</literal>,
<literal>OST0001</literal>, and so on.</para>
<primary>backup</primary>
<secondary>OST and MDT</secondary>
</indexterm>Backing Up an OST or MDT</title>
- <para>For Lustre software release 2.3 and newer with MDT file-level backup
- support, substitute <literal>mdt</literal> for <literal>ost</literal>
+ <para>The below examples show backing up an OST filesystem. When backing
+ up an MDT, substitute <literal>mdt</literal> for <literal>ost</literal>
in the instructions below.</para>
<orderedlist>
<listitem>
will be immediately although there may be I/O errors reading
from files that are present on the MDT but not the OSTs, and files that
were created after the MDT backup will not be accessible or visible. See
- <xref linkend="dbdoclet.lfsckadmin" />for details on using LFSCK.</para>
+ <xref linkend="lfsckadmin" />for details on using LFSCK.</para>
</section>
- <section xml:id="dbdoclet.backup_lvm_snapshot">
+ <section xml:id="backup_lvm_snapshot">
<title>
<indexterm>
<primary>backup</primary>
</section>
</section>
</chapter>
+<!--
+ vim:expandtab:shiftwidth=2:tabstop=8:
+ -->
git://git.whamcloud.com / doc / manual.git / blobdiff