]> git.sur5r.net Git - bacula/docs/commitdiff
Add bootstrap example to bscan usage
authorKern Sibbald <kern@sibbald.com>
Sat, 16 Jul 2011 06:44:28 +0000 (08:44 +0200)
committerKern Sibbald <kern@sibbald.com>
Sat, 16 Jul 2011 06:44:44 +0000 (08:44 +0200)
docs/manuals/en/utility/progs.tex

index 3231d6cd2e0425327a01352c41fceffd2cb4d333..90c9db662b2e019bb9e2127da933989e4465ca2f 100644 (file)
@@ -461,7 +461,7 @@ from your catalog so that the records on the Volume are no longer in the
 catalog, or for Volumes that you have archived.  Note, if you scan in
 Volumes that were previously purged, you will be able to do restores from
 those Volumes.  However, unless you modify the Job and File retention times
-for the Jobs that were added by scanning, the next time you run any Job
+for the Jobs that were added by scanning, the next time you run any backup Job
 with the same name, the records will be pruned again.  Since it takes a
 long time to scan Volumes this can be very frustrating.
 
@@ -572,18 +572,28 @@ Since there is a limit on the command line length (511 bytes) accepted
 by {\bf bscan}, if you have too many Volumes, you will need to manually
 create a bootstrap file.  See the \ilink{Bootstrap}{BootstrapChapter}
 chapter of this manual for more details, in particular the section
-entitled \ilink{Bootstrap for bscan}{bscanBootstrap}.
+entitled \ilink{Bootstrap for bscan}{bscanBootstrap}. Basically, the
+.bsr file for the above example might look like:
+
+\footnotesize
+\begin{verbatim}
+Volume=Vol001
+Volume=Vol002
+Volume=Vol003
+\end{verbatim}
+\normalsize
 
 You should, always try to specify the tapes in the order they are written.
-However, bscan can handle scanning tapes that are not sequential.  Any
+If you do not, any Jobs that span a volume may not be fully or properly
+restored. However, bscan can handle scanning tapes that are not sequential.  Any
 incomplete records at the end of the tape will simply be ignored in that
 case.  If you are simply repairing an existing catalog, this may be OK, but
 if you are creating a new catalog from scratch, it will leave your database
 in an incorrect state.  If you do not specify all necessary Volumes on a
 single bscan command, bscan will not be able to correctly restore the
 records that span two volumes.  In other words, it is much better to
-specify two or three volumes on a single bscan command rather than run
-bscan two or three times, each with a single volume.
+specify two or three volumes on a single bscan command (or in a .bsr file)
+rather than run bscan two or three times, each with a single volume.
 
 
 Note, the restoration process using bscan is not identical to the original