From: Kern Sibbald <kern@sibbald.com>
Date: Fri, 9 Sep 2005 09:30:19 +0000 (+0000)
Subject: updates
X-Git-Tag: Release-1.38.0~121
X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=5380d366a30a2043ab9390fe49a186a17a8e227e;p=bacula%2Fdocs

updates
---

diff --git a/docs/manual/dirdconf.tex b/docs/manual/dirdconf.tex
index 17f56f7d..a9c516aa 100644
--- a/docs/manual/dirdconf.tex
+++ b/docs/manual/dirdconf.tex
@@ -444,7 +444,7 @@ catalog  database, it looks for a previous Job with:
    different FileSet.  
 \item The Job was a FULL backup.  
 \item The Job terminated normally (i.e. did not fail or was not  canceled).  
-   \end{itemize}
+\end{itemize}
 
 If all the above conditions do not hold, the Director will  upgrade the
 Differential to a Full save. Otherwise, the  Differential backup will be
@@ -473,17 +473,28 @@ in the catalog after doing another Full save.  However, to remove deleted
 files from the catalog during a Differential backup is quite a time consuming
 process  and not currently implemented in Bacula. 
 
-As noted above, if you move a directory rather than copy it, the files in it do
-not
-have their modification time (st\_mtime) or their attribute change time
-(st\_ctime) 
-changed. As a consequence, those files will probably not be backed up by an
-Incremental
-or Differential backup which depend solely on these time stamps. If you move a
-directory,
-and which it to be properly backed up, it is generally preferable to copy it
-then
-delete the original.
+As noted above, if you move a directory rather than copy it, the
+files in it do not have their modification time (st\_mtime) or
+their attribute change time (st\_ctime) changed.  As a
+consequence, those files will probably not be backed up by an
+Incremental or Differential backup which depend solely on these
+time stamps.  If you move a directory, and which it to be
+properly backed up, it is generally preferable to copy it then
+delete the original.  
+
+Every once and a while, someone asks why we need Differential
+backups as long as Incremental backups pickup all changed files.
+There are possibly many answers to this question, but the one
+that is the most important for me is that it effectively combines
+all the Incremental and Differential backups since the last Full 
+backup into a single Differential backup. This has two effects:
+1. It gives some redundancy. 2. More importantly, it reduces the
+number of Volumes that are needed to do a restore effectively
+eliminating the need to read all the volumes on which the
+preceding Incremental and Differential backups since the last
+Full are done.
+
+
 \end{description}
 
 For a {\bf Restore} Job, no level needs to be specified.  
diff --git a/docs/manual/supportedchangers.tex b/docs/manual/supportedchangers.tex
index d37219fd..aa645363 100644
--- a/docs/manual/supportedchangers.tex
+++ b/docs/manual/supportedchangers.tex
@@ -35,6 +35,7 @@ Slot).
  \hline {z/VM } & {IBM } & {?? } & {IBM Tape Manager } & {-} & {??  } \\
  \hline {z/VM } & {IBM } & {?? } & {native tape } & {-} & {??  } \\
  \hline {Linux } & {Exabyte } & {VXA2 } & {VXA PacketLoader 1x10 2U } & {10} & {80/160GB  } \\
+ \hline {- } & {Exabyte } & {LTO } & {Magnum 1x7 LTO Tape Auotloader } & {7} & {200/400GB  } \\
  \hline {Linux Gentoo 1.4 } & {Exabyte } & {AIT-2 } & {215A } & {15 (2 drives)} & {50GB  } \\
  \hline {Linux } & {HP } & {DDS-4 } & {SureStore DAT-40X6 } & {6 } & {40GB  } \\
  \hline {Linux } & {HP } & {Ultrium-2/LTO } & {MSL 6000/ 60030/ 5052 } & {28 } & {200/400GB  } \\