\begin{enumerate}
\item It cannot restore access control lists (ACL) that have been
backed up along with the file data.
-\item It cannot restore Win32 non-portable streams (typically default).
\item It cannot restore encrypted files.
\item The command line length is relatively limited,
which means that you cannot enter a huge number of volumes. If you need to
was written when you saved it (default bacula-dir.conf file).
The {\bf bscan} program can be used to re-create a database (catalog)
-records from the backup information written to one or more Volumes.
-This is normally
-needed only if one or more Volumes have been pruned or purged from your
-catalog so that the records on the Volume are no longer in the catalog, or
-for Volumes that you have archived.
-
-With some care, it can also be used to synchronize your existing catalog with
-a Volume. Although we have never seen a case of bscan damaging a
-catalog, since bscan modifies your catalog, we recommend that
-you do a simple ASCII backup of your database before running {\bf bscan} just
-to be sure. See \ilink{Compacting Your Database}{CompactingMySQL} for
+records from the backup information written to one or more Volumes. This
+is normally needed only if one or more Volumes have been pruned or purged
+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
+with the same name, the records will be pruned again. Since it takes a
+long time to scan Volumes this can be very frustrating.
+
+With some care, {\bf bscan} can also be used to synchronize your existing
+catalog with a Volume. Although we have never seen a case of bscan
+damaging a catalog, since bscan modifies your catalog, we recommend that
+you do a simple ASCII backup of your database before running {\bf bscan}
+just to be sure. See \ilink{Compacting Your Database}{CompactingMySQL} for
the details of making a copy of your database.
{\bf bscan} can also be useful in a disaster recovery situation, after the
rewind rewind the tape
scan read() tape block by block to EOT and report
scanblocks Bacula read block by block to EOT and report
+ speed report drive speed
status print tape status
test General test Bacula tape functions
weof write an EOF on the tape
note for labeling tapes, we recommend that you use the {\bf label} command in
the {\bf Console} program since it will never overwrite a valid Bacula tape.
+\subsubsection*{Testing your Tape Drive}
+\label{sec:btapespeed}
+
+To determine the best configuration of your tape drive, you can run the new
+\texttt{speed} command available in the \texttt{btape} program.
+
+This command can have the following arguments:
+\begin{itemize}
+\item[\texttt{file\_size=n}] Specify the Maximum File Size for this test
+ (between 1 and 5GB). This counter is in GB.
+\item[\texttt{nb\_file=n}] Specify the number of file to be written. The amount
+ of data should be greater than your memory ($file\_size*nb\_file$).
+\item[\texttt{skip\_zero}] This flag permits to skip tests with constant
+ data.
+\item[\texttt{skip\_random}] This flag permits to skip tests with random
+ data.
+\item[\texttt{skip\_raw}] This flag permits to skip tests with raw access.
+\item[\texttt{skip\_block}] This flag permits to skip tests with Bacula block
+ access.
+\end{itemize}
+
+\begin{verbatim}
+*speed file_size=3 skip_raw
+btape.c:1078 Test with zero data and bacula block structure.
+btape.c:956 Begin writing 3 files of 3.221 GB with blocks of 129024 bytes.
+++++++++++++++++++++++++++++++++++++++++++
+btape.c:604 Wrote 1 EOF to "Drive-0" (/dev/nst0)
+btape.c:406 Volume bytes=3.221 GB. Write rate = 44.128 MB/s
+...
+btape.c:383 Total Volume bytes=9.664 GB. Total Write rate = 43.531 MB/s
+
+btape.c:1090 Test with random data, should give the minimum throughput.
+btape.c:956 Begin writing 3 files of 3.221 GB with blocks of 129024 bytes.
++++++++++++++++++++++++++++++++++++++++++++
+btape.c:604 Wrote 1 EOF to "Drive-0" (/dev/nst0)
+btape.c:406 Volume bytes=3.221 GB. Write rate = 7.271 MB/s
++++++++++++++++++++++++++++++++++++++++++++
+...
+btape.c:383 Total Volume bytes=9.664 GB. Total Write rate = 7.365 MB/s
+
+\end{verbatim}
+
+When using compression, the random test will give your the minimum throughput
+of your drive . The test using constant string will give you the maximum speed
+of your hardware chain. (cpu, memory, scsi card, cable, drive, tape).
+
+You can change the block size in the Storage Daemon configuration file.
+
\section{Other Programs}
\index[general]{Programs!Other}
\index[general]{Other Programs}
running with a non-English language setting, you might try adding
a LANG=''en\_US'' immediately before the bsmtp call.
+In general, {\bf bsmtp} attempts to cleanup email addresses that you
+specify in the from, copy, mailhost, and recipient fields, by adding
+the necessary \lt{} and \gt{} characters around the address part. However,
+if you include a {\bf display-name} (see RFC 5332), some SMTP servers
+such as Exchange may not accept the message if the {\bf display-name} is
+also included in \lt{} and \gt{}. As mentioned above, you must test, and
+if you run into this situation, you may manually add the \lt{} and \gt{}
+to the Bacula {\bf mailcommand} or {\bf operatorcommand} and when
+{\bf bsmtp} is formatting an address if it already contains a \lt{} or
+\gt{} character, it will leave the address unchanged.
+
\section{dbcheck}
\label{dbcheck}
\index[general]{Dbcheck}
\footnotesize
\begin{verbatim}
-Usage: dbcheck [-c config] [-C catalog name] [-d debug_level]
-<working-directory> <bacula-database> <user> <password> [<dbhost>]
+Usage: dbcheck [-c config ] [-B] [-C catalog name] [-d debug_level]
+ <working-directory> <bacula-database> <user> <password> [<dbhost>] [<dbport>]
-b batch mode
-C catalog name in the director conf file
- -c director conf filename
- -dnn set debug level to nn
+ -c Director conf filename
+ -B print catalog configuration and exit
+ -d <nn> set debug level to <nn>
+ -dt print timestamp in debug output
-f fix inconsistencies
-v verbose
-? print this message
\end{verbatim}
\normalsize
+If the \textbf{-B} option is specified, dbcheck will print out catalog
+information in a simple text based format. This is useful to backup it in a
+secure way.
+
+\begin{verbatim}
+ $ dbcheck -B
+ catalog=MyCatalog
+ db_type=SQLite
+ db_name=regress
+ db_driver=
+ db_user=regress
+ db_password=
+ db_address=
+ db_port=0
+ db_socket=
+\end{verbatim} %$
+
If the {\bf -c} option is given with the Director's conf file, there is no
need to enter any of the command line arguments, in particular the working
directory as dbcheck will read them from the file.
regardless of their age.
\end{itemize}
+
+If you are using Mysql, dbcheck will ask you if you want to create temporary
+indexes to speed up orphaned Path and Filename elimination.
+
+Mostly for PostgreSQL users, we provide a pure SQL script dbcheck replacement
+in \url{examples/database/dbcheck.sql} that works with global queries instead
+of many small queries like dbcheck. Execution instructions are at the top of
+the script and you will need to type \texttt{COMMIT} at the end to validate
+modifications.
+
+If you are using bweb or brestore, don't eliminate orphaned Path, else you will
+have to rebuild \texttt{brestore\_pathvisibility} and
+\texttt{brestore\_pathhierarchy} indexes.
+
By the way, I personally run dbcheck only where I have messed up
my database due to a bug in developing Bacula code, so normally
you should never need to run dbcheck in spite of the
projects / bacula / docs / blobdiff