LUDOC-504 nodemap: servers must be in a trusted+admin group

[doc/manual.git] / BackupAndRestore.xml

diff --git a/BackupAndRestore.xml b/BackupAndRestore.xml
index 30f97c7..8e8fcf8 100644 (file)
--- a/BackupAndRestore.xml
+++ b/BackupAndRestore.xml
@@ -10,12 +10,12 @@
   <itemizedlist>
     <listitem>
       <para>
   <itemizedlist>
     <listitem>
       <para>

-        <xref linkend="dbdoclet.backup_file"/>
+        <xref linkend="backup_file"/>

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

-        <xref linkend="dbdoclet.backup_device"/>
+        <xref linkend="backup_device"/>

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


@@ -30,13 +30,13 @@
     </listitem>
     <listitem>
       <para>
     </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)
       </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
   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


@@ -52,7 +52,7 @@
   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>
   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>
     <title>
     <indexterm>
       <primary>backup</primary>


@@ -152,7 +152,7 @@
         <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 
         <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>
         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>


@@ -403,7 +403,7 @@ Changelog records consumed: 42</screen>
       </section>
     </section>
   </section>
       </section>
     </section>
   </section>

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

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


@@ -518,8 +518,9 @@ Changelog records consumed: 42</screen>
           <primary>backup</primary>
           <secondary>OST and MDT</secondary>
         </indexterm>Backing Up an OST or MDT</title>
           <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>
+      <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>
           <para><emphasis role="bold">Umount the target</emphasis></para>
       <orderedlist>
         <listitem>
           <para><emphasis role="bold">Umount the target</emphasis></para>


@@ -776,9 +777,9 @@ trusted.fid= \
       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 
       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>

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

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


@@ -1098,4 +1099,6 @@ fstab  passwds
       </section>
   </section>
 </chapter>
       </section>
   </section>
 </chapter>

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