LUDOC-11 misc: unify header and add vim footer

[doc/manual.git] / BackupAndRestore.xml

diff --git a/BackupAndRestore.xml b/BackupAndRestore.xml
index fe280c9..30f97c7 100644 (file)
--- a/BackupAndRestore.xml
+++ b/BackupAndRestore.xml
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='utf-8'?>
 <chapter xmlns="http://docbook.org/ns/docbook"
 <?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
   <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


@@ -20,12 +20,12 @@ xml:id="backupandrestore">
     </listitem>
     <listitem>
       <para>
     </listitem>
     <listitem>
       <para>

-        <xref linkend="dbdoclet.backup_target_filesystem"/>
+        <xref linkend="backup_fs_level"/>

       </para>
     </listitem>
     <listitem>
       <para>
       </para>
     </listitem>
     <listitem>
       <para>

-        <xref linkend="dbdoclet.restore_target_filesystem"/>
+        <xref linkend="backup_fs_level.restore"/>

       </para>
     </listitem>
     <listitem>
       </para>
     </listitem>
     <listitem>


@@ -172,7 +172,7 @@ xml:id="backupandrestore">
           <listitem>
             <para>Verify that the Lustre file system (source) and the replica
             file system (target) are identical 
           <listitem>
             <para>Verify that the Lustre file system (source) and the replica
             file system (target) are identical 

-            <emphasis>before</emphasis>registering the changelog user. If the
+            <emphasis>before</emphasis> registering the changelog user. If the

             file systems are discrepant, use a utility, e.g. regular 
             <literal>rsync</literal>(not 
             <literal>lustre_rsync</literal>), to make them identical.</para>
             file systems are discrepant, use a utility, e.g. regular 
             <literal>rsync</literal>(not 
             <literal>lustre_rsync</literal>), to make them identical.</para>


@@ -426,19 +426,6 @@ Changelog records consumed: 42</screen>
       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>
       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. 
-      <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.hpdd.intel.com/browse/LU-957">LU-957</link>),
-      and file-level backup is supported (see 
-      <xref linkend="dbdoclet.backup_target_filesystem"/>).</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>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


@@ -452,11 +439,8 @@ Changelog records consumed: 42</screen>
     <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 
     <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>
     <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>


@@ -474,7 +458,7 @@ Changelog records consumed: 42</screen>
     backup device, and is still much better than not having any backup at all.
     </para>
   </section>
     backup device, and is still much better than not having any backup at all.
     </para>
   </section>

-  <section xml:id="dbdoclet.backup_target_filesystem">
+  <section xml:id="backup_fs_level">

     <title>
     <indexterm>
       <primary>backup</primary>
     <title>
     <indexterm>
       <primary>backup</primary>


@@ -483,10 +467,10 @@ Changelog records consumed: 42</screen>
     <indexterm>
       <primary>backup</primary>
       <secondary>MDT file system</secondary>
     <indexterm>
       <primary>backup</primary>
       <secondary>MDT file system</secondary>

-    </indexterm>Backing Up an OST or MDT (ldiskfs File System Level)</title>
+    </indexterm>Backing Up an OST or MDT (Backend File System Level)</title>

     <para>This procedure provides an alternative to backup or migrate the data
     of an OST or MDT at the file level. At the file-level, unused space is
     <para>This procedure provides an alternative to backup or migrate the data
     of an OST or MDT at the file level. At the file-level, unused space is

-    omitted from the backed up and the process may be completed quicker with
+    omitted from the backup and the process may be completed quicker with a

     smaller total backup size. Backing up a single OST device is not
     necessarily the best way to perform backups of the Lustre file system,
     since the files stored in the backup are not usable without metadata stored
     smaller total backup size. Backing up a single OST device is not
     necessarily the best way to perform backups of the Lustre file system,
     since the files stored in the backup are not usable without metadata stored


@@ -495,36 +479,81 @@ Changelog records consumed: 42</screen>
     is desirable to reformat the underlying file system with different
     configuration options or to reduce fragmentation.</para>
     <note>
     is desirable to reformat the underlying file system with different
     configuration options or to reduce fragmentation.</para>
     <note>

-      <para>Prior to Lustre software release 2.3, the only successful way to
-      perform an MDT backup and restore is to do a device-level backup as is
-      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. 
-      <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.hpdd.intel.com/browse/LU-957">LU-957</link>),
-      so file-level MDT restore is supported.</para>
+      <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>
     </note>

-    <para>For Lustre software release 2.3 and newer with MDT file-level backup
-    support, substitute 
-    <literal>mdt</literal> for 
-    <literal>ost</literal> in the instructions below.</para>
-    <orderedlist>
-      <listitem>
-        <para>
-          <emphasis role="bold">Make a mountpoint for the file
-          system.</emphasis>
-        </para>
-        <screen>[oss]# mkdir -p /mnt/ost</screen>
-      </listitem>
-      <listitem>
-        <para>
-          <emphasis role="bold">Mount the file system.</emphasis>
-        </para>
+    <section xml:id="backup_fs_level.index_objects" condition="l2B">
+      <title>
+        <indexterm>
+          <primary>backup</primary>
+          <secondary>index objects</secondary>
+        </indexterm>Backing Up an OST or MDT (Backend File System Level)</title>
+      <para>Prior to Lustre software release 2.11.0, we can only do the backend
+        file system level backup and restore process for ldiskfs-based systems.
+        The ability to perform a zfs-based MDT/OST file system level backup and
+        restore is introduced beginning in Lustre software release 2.11.0.
+        Differing from an ldiskfs-based system, index objects must be backed up
+        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-*.${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>
+      <note><para>The index_backup is also valid for an ldiskfs-based system,
+        that will be used when migrating data between ldiskfs-based and
+        zfs-based systems as described in <xref linkend="migrate_backends"/>.
+      </para></note>
+    </section>
+    <section xml:id="backup_fs_level.ost_mdt">
+      <title>
+        <indexterm>
+          <primary>backup</primary>
+          <secondary>OST and MDT</secondary>
+        </indexterm>Backing Up an OST or MDT</title>
+      <para>If backing up an MDT, substitute <literal>mdt</literal> for
+        <literal>ost</literal> in the instructions below.</para>
+      <orderedlist>
+        <listitem>
+          <para><emphasis role="bold">Umount the target</emphasis></para>
+        </listitem>
+        <listitem>
+          <para><emphasis role="bold">Make a mountpoint for the file system.
+          </emphasis></para>
+          <screen>[oss]# mkdir -p /mnt/ost</screen>
+        </listitem>
+        <listitem>
+          <para><emphasis role="bold">Mount the file system.</emphasis></para>
+        <para>For ldiskfs-based systems:</para>

         <screen>[oss]# mount -t ldiskfs /dev/<emphasis>{ostdev}</emphasis> /mnt/ost</screen>
         <screen>[oss]# mount -t ldiskfs /dev/<emphasis>{ostdev}</emphasis> /mnt/ost</screen>

+        <para>For zfs-based systems:</para>
+        <orderedlist>
+          <listitem>
+            <para>Import the pool for the target if it is exported. For example:
+              <screen>[oss]# zpool import lustre-ost [-d ${ostdev_dir}]</screen>
+            </para>
+          </listitem>
+          <listitem>
+            <para>Enable the <literal>canmount</literal> property on the target
+              filesystem. For example:
+              <screen>[oss]# zfs set canmount=on ${fsname}-ost/ost</screen>
+              You also can specify the mountpoint property. By default, it will
+              be: <literal>/${fsname}-ost/ost</literal>
+            </para>
+          </listitem>
+          <listitem>
+            <para>Mount the target as 'zfs'. For example:
+              <screen>[oss]# zfs mount ${fsname}-ost/ost</screen>
+            </para>
+          </listitem>
+        </orderedlist>

       </listitem>
       <listitem>
         <para>
       </listitem>
       <listitem>
         <para>


@@ -539,13 +568,12 @@ Changelog records consumed: 42</screen>
         </para>
         <screen>[oss]# getfattr -R -d -m '.*' -e hex -P . &gt; ea-$(date +%Y%m%d).bak</screen>
         <note>
         </para>
         <screen>[oss]# getfattr -R -d -m '.*' -e hex -P . &gt; ea-$(date +%Y%m%d).bak</screen>
         <note>

-          <para>If the 
-          <literal>tar(1)</literal> command supports the 
-          <literal>--xattr</literal> option, the 
+          <para>If the <literal>tar(1)</literal> command supports the 
+          <literal>--xattr</literal> option (see below), the 

           <literal>getfattr</literal> step may be unnecessary as long as tar
           <literal>getfattr</literal> step may be unnecessary as long as tar

-          does a backup of the 
-          <literal>trusted.*</literal> attributes. However, completing this step
-          is not harmful and can serve as an added safety measure.</para>
+          correctly backs up the <literal>trusted.*</literal> attributes.
+         However, completing this step is not harmful and can serve as an
+         added safety measure.</para>

         </note>
         <note>
           <para>In most distributions, the 
         </note>
         <note>
           <para>In most distributions, the 


@@ -562,10 +590,12 @@ Changelog records consumed: 42</screen>
           <literal>ea-$date.bak</literal> file has properly backed up the EA
           data on the OST.</emphasis>
         </para>
           <literal>ea-$date.bak</literal> file has properly backed up the EA
           data on the OST.</emphasis>
         </para>

-        <para>Without this attribute data, the restore process may be missing
-        extra data that can be very useful in case of later file system
-        corruption. Look at this file with more or a text editor. Each object
-        file should have a corresponding item similar to this:</para>
+        <para>Without this attribute data, the MDT restore process will fail
+        and result in an unusable filesystem.  The OST restore process may be
+        missing extra data that can be very useful in case of later file system
+        corruption. Look at this file with <literal>more</literal> or a text
+        editor. Each object file should have a corresponding item similar to
+        this:</para>

         <screen>[oss]# file: O/0/d0/100992
 trusted.fid= \
 0x0d822200000000004a8a73e500000000808a0100000000000000000000000000</screen>
         <screen>[oss]# file: O/0/d0/100992
 trusted.fid= \
 0x0d822200000000004a8a73e500000000808a0100000000000000000000000000</screen>


@@ -574,24 +604,22 @@ trusted.fid= \
         <para>
           <emphasis role="bold">Back up all file system data.</emphasis>
         </para>
         <para>
           <emphasis role="bold">Back up all file system data.</emphasis>
         </para>

-        <screen>[oss]# tar czvf {backup file}.tgz [--xattrs] --sparse .</screen>
+        <screen>[oss]# tar czvf {backup file}.tgz [--xattrs] [--xattrs-include="trusted.*" --sparse .</screen>

         <note>
           <para>The tar 
         <note>
           <para>The tar 

-          <literal>--sparse</literal> option is vital for backing up an MDT. In
-          order to have 
-          <literal>--sparse</literal> behave correctly, and complete the backup
-          of and MDT in finite time, the version of tar must be specified.
-          Correctly functioning versions of tar include the Lustre software
-          enhanced version of tar at 
-          <link xmlns:xlink="http://www.w3.org/1999/xlink"
-          xlink:href="https://wiki.hpdd.intel.com/display/PUB/Lustre+Tools#LustreTools-lustre-tar" />,
-          the tar from a Red Hat Enterprise Linux distribution (version 6.3 or
-          more recent) and the GNU tar version 1.25 or more recent.</para>
+          <literal>--sparse</literal> option is vital for backing up an MDT.
+          Very old versions of tar may not support the
+          <literal>--sparse</literal> option correctly, which may cause the
+          MDT backup to take a long time.  Known-working versions include
+          the tar from Red Hat Enterprise Linux distribution (RHEL version
+         6.3 or newer) or GNU tar version 1.25 and newer.</para>

         </note>
         <warning>
         </note>
         <warning>

-          <para>The tar 
-          <literal>--xattrs</literal> option is only available in GNU tar
-          distributions from Red Hat or Intel.</para>
+          <para>The tar <literal>--xattrs</literal> option is only available
+          in GNU tar version 1.27 or later or in RHEL 6.3 or newer.  The
+          <literal>--xattrs-include="trusted.*"</literal> option is
+          <emphasis>required</emphasis> for correct restoration of the xattrs
+          when using GNU tar 1.27 or RHEL 7 and newer.</para>

         </warning>
       </listitem>
       <listitem>
         </warning>
       </listitem>
       <listitem>


@@ -615,8 +643,9 @@ trusted.fid= \
         </note>
       </listitem>
     </orderedlist>
         </note>
       </listitem>
     </orderedlist>

+    </section>

   </section>
   </section>

-  <section xml:id="dbdoclet.restore_target_filesystem">
+  <section xml:id="backup_fs_level.restore">

     <title>
     <indexterm>
       <primary>backup</primary>
     <title>
     <indexterm>
       <primary>backup</primary>


@@ -627,15 +656,38 @@ trusted.fid= \
     <orderedlist>
       <listitem>
         <para>Format the new device.</para>
     <orderedlist>
       <listitem>
         <para>Format the new device.</para>

-        <screen>[oss]# mkfs.lustre --ost --index {<emphasis>OST index</emphasis>} {<emphasis>other options</emphasis>} /dev/<emphasis>{newdev}</emphasis></screen>
+        <screen>[oss]# mkfs.lustre --ost --index {<emphasis>OST index</emphasis>}
+--replace --fstype=${fstype} {<emphasis>other options</emphasis>} /dev/<emphasis>{newdev}</emphasis></screen>

       </listitem>
       <listitem>
       </listitem>
       <listitem>

-        <para>Set the file system label.</para>
+        <para>Set the file system label (<emphasis role="bold">ldiskfs-based
+          systems only</emphasis>).</para>

         <screen>[oss]# e2label {fsname}-OST{index in hex} /mnt/ost</screen>
       </listitem>
       <listitem>
         <para>Mount the file system.</para>
         <screen>[oss]# e2label {fsname}-OST{index in hex} /mnt/ost</screen>
       </listitem>
       <listitem>
         <para>Mount the file system.</para>

+        <para>For ldiskfs-based systems:</para>

         <screen>[oss]# mount -t ldiskfs /dev/<emphasis>{newdev}</emphasis> /mnt/ost</screen>
         <screen>[oss]# mount -t ldiskfs /dev/<emphasis>{newdev}</emphasis> /mnt/ost</screen>

+        <para>For zfs-based systems:</para>
+        <orderedlist>
+          <listitem>
+            <para>Import the pool for the target if it is exported. For example:
+            </para>
+            <screen>[oss]# zpool import lustre-ost [-d ${ostdev_dir}]</screen>
+          </listitem>
+          <listitem>
+            <para>Enable the canmount property on the target filesystem. For
+              example:</para>
+            <screen>[oss]# zfs set canmount=on ${fsname}-ost/ost</screen>
+            <para>You also can specify the <literal>mountpoint</literal>
+              property. By default, it will be:
+              <literal>/${fsname}-ost/ost</literal></para>
+          </listitem>
+          <listitem>
+            <para>Mount the target as 'zfs'. For example:</para>
+            <screen>[oss]# zfs mount ${fsname}-ost/ost</screen>
+          </listitem>
+        </orderedlist>

       </listitem>
       <listitem>
         <para>Change to the new file system mount point.</para>
       </listitem>
       <listitem>
         <para>Change to the new file system mount point.</para>


@@ -643,10 +695,20 @@ trusted.fid= \
       </listitem>
       <listitem>
         <para>Restore the file system backup.</para>
       </listitem>
       <listitem>
         <para>Restore the file system backup.</para>

-        <screen>[oss]# tar xzvpf <emphasis>{backup file}</emphasis> [--xattrs] --sparse</screen>
+        <screen>[oss]# tar xzvpf <emphasis>{backup file}</emphasis> [--xattrs] [--xattrs-include="trusted.*"] --sparse</screen>
+        <warning>
+          <para>The tar <literal>--xattrs</literal> option is only available
+         in GNU tar version 1.27 or later or in RHEL 6.3 or newer.  The
+         <literal>--xattrs-include="trusted.*"</literal> option is
+         <emphasis>required</emphasis> for correct restoration of the
+         MDT xattrs when using GNU tar 1.27 or RHEL 7 and newer.  Otherwise,
+         the <literal>setfattr</literal> step below should be used.
+         </para>
+        </warning>

       </listitem>
       <listitem>
       </listitem>
       <listitem>

-        <para>Restore the file system extended attributes.</para>
+        <para>If not using a version of tar that supports direct xattr
+       backups, restore the file system extended attributes.</para>

         <screen>[oss]# setfattr --restore=ea-${date}.bak</screen>
         <note>
           <para>If 
         <screen>[oss]# setfattr --restore=ea-${date}.bak</screen>
         <note>
           <para>If 


@@ -660,25 +722,61 @@ trusted.fid= \
 0x0d822200000000004a8a73e500000000808a0100000000000000000000000000</screen>
       </listitem>
       <listitem>
 0x0d822200000000004a8a73e500000000808a0100000000000000000000000000</screen>
       </listitem>
       <listitem>

+        <para>Remove old OI and LFSCK files.</para>
+        <screen>[oss]# rm -rf oi.16* lfsck_* LFSCK</screen>
+      </listitem>
+      <listitem>
+        <para>Remove old CATALOGS.</para>
+        <screen>[oss]# rm -f CATALOGS</screen>
+        <note>
+        <para>This is optional for the MDT side only. The CATALOGS record the
+       llog file handlers that are used for recovering cross-server updates.
+       Before OI scrub rebuilds the OI mappings for the llog files, the
+       related recovery will get a failure if it runs faster than the
+       background OI scrub.  This will result in a failure of the whole mount
+       process. OI scrub is an online tool, therefore, a mount failure means
+       that the OI scrub will be stopped.  Removing the old CATALOGS will
+       avoid this potential trouble.  The side-effect of removing old
+       CATALOGS is that the recovery for related cross-server updates will
+       be aborted. However, this can be handled by LFSCK after the system
+       mount is up.</para>
+        </note>
+      </listitem>
+      <listitem>

         <para>Change directory out of the file system.</para>
         <screen>[oss]# cd -</screen>
       </listitem>
       <listitem>
         <para>Unmount the new file system.</para>
         <screen>[oss]# umount /mnt/ost</screen>
         <para>Change directory out of the file system.</para>
         <screen>[oss]# cd -</screen>
       </listitem>
       <listitem>
         <para>Unmount the new file system.</para>
         <screen>[oss]# umount /mnt/ost</screen>

+        <note><para>If the restored system has a different NID from the backup
+          system, please change the NID. For detail, please refer to
+          <xref linkend="lustremaint.changingservernid" />.  For example:</para>
+          <screen>[oss]# mount -t lustre -o nosvc ${fsname}-ost/ost /mnt/ost
+[oss]# lctl replace_nids ${fsname}-OSTxxxx $new_nids
+[oss]# umount /mnt/ost</screen></note>
+      </listitem>
+      <listitem>
+        <para>Mount the target as <literal>lustre</literal>.</para>
+        <para>Usually, we will use the <literal>-o abort_recov</literal> option
+          to skip unnecessary recovery. For example:</para>
+        <screen>[oss]# mount -t lustre -o abort_recov #{fsname}-ost/ost /mnt/ost</screen>
+        <para>Lustre can detect the restore automatically when mounting the
+          target, and then trigger OI scrub to rebuild the OIs and index objects
+          asynchronously in the background. You can check the OI scrub status
+          with the following command:</para>
+        <screen>[oss]# lctl get_param -n osd-${fstype}.${fsname}-${target}.oi_scrub</screen>

       </listitem>
     </orderedlist>
       </listitem>
     </orderedlist>

-    <para condition='l23'>If the file system was used between the time the backup was made and
-    when it was restored, then the online 
-    <literal>LFSCK</literal> tool (part of Lustre code after version 2.3) 
-    will automatically be
-    run to ensure the file system is coherent. If all of the device file
-    systems were backed up at the same time after the entire Lustre file system
-    was stopped, this step is unnecessary. In either case, the file system 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>
+    <para>If the file system was used between the time the backup was made and
+      when it was restored, then the online <literal>LFSCK</literal> tool will
+      automatically be run to ensure the filesystem is coherent. If all of the
+      device filesystems were backed up at the same time after Lustre was
+      was stopped, this step is unnecessary. In either case, the filesystem
+      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>

   </section>
   <section xml:id="dbdoclet.backup_lvm_snapshot">
     <title>
   </section>
   <section xml:id="dbdoclet.backup_lvm_snapshot">
     <title>


@@ -957,4 +1055,47 @@ fstab  passwds
       </note>
     </section>
   </section>
       </note>
     </section>
   </section>

+  <section xml:id="migrate_backends" condition="l2B">
+      <title>
+          <indexterm>
+              <primary>backup</primary>
+              <secondary>ZFS ZPL</secondary>
+          </indexterm>Migration Between ZFS and ldiskfs Target Filesystems
+      </title>
+      <para>Beginning with Lustre 2.11.0, it is possible to migrate between
+        ZFS and ldiskfs backends.  For migrating OSTs, it is best to use
+        <literal>lfs find</literal>/<literal>lfs_migrate</literal> to empty out
+        an OST while the filesystem is in use and then reformat it with the new
+        fstype. For instructions on removing the OST, please see
+        <xref linkend="lustremaint.remove_ost"/>.</para>
+      <section remap="h3" xml:id="migrate_backends.zfs2ldiskfs">
+        <title>
+          <indexterm>
+            <primary>backup</primary>
+            <secondary>ZFS to ldiskfs</secondary>
+          </indexterm>Migrate from a ZFS to an ldiskfs based filesystem</title>
+        <para>The first step of the process is to make a ZFS backend backup
+          using <literal>tar</literal> as described in
+          <xref linkend="backup_fs_level"/>.</para>
+        <para>Next, restore the backup to an ldiskfs-based system as described
+          in <xref linkend="backup_fs_level.restore"/>.</para>
+      </section>
+      <section remap="h3" xml:id="migrate_backends.ldiskfs2zfs">
+        <title>
+          <indexterm>
+            <primary>backup</primary>
+            <secondary>ZFS to ldiskfs</secondary>
+          </indexterm>Migrate from an ldiskfs to a ZFS based filesystem</title>
+        <para>The first step of the process is to make an ldiskfs backend backup
+          using <literal>tar</literal> as described in
+          <xref linkend="backup_fs_level"/>.</para>
+        <para><emphasis role="strong">Caution:</emphasis>For a migration from
+          ldiskfs to zfs, it is required to enable index_backup before the
+          unmount of the target.  This is an additional step for a regular
+          ldiskfs-based backup/restore and easy to be missed.</para>
+        <para>Next, restore the backup to an ldiskfs-based system as described
+          in <xref linkend="backup_fs_level.restore"/>.</para>
+      </section>
+  </section>

 </chapter>
 </chapter>

+<!--vim:expandtab:shiftwidth=2:tabstop=8:-->