the system administrator or person building {\bf Bacula}. In our testing
SQLite has performed very well, and for the functions that we use, it has
never encountered any errors except that it does not appear to handle
-databases larger than 2GBytes.
+databases larger than 2GBytes. That said, we would not recommend it for
+serious production use.
The Bacula SQL code has been written in a manner that will allow it to be
easily modified to support any of the current SQL database systems on the
\end{longtable}
-The {\bf JobMedia} table contains one entry for each volume written for the
-current Job. If the Job spans 3 tapes, there will be three JobMedia records,
-each containing the information to find all the files for the given JobId on
-the tape.
+The {\bf JobMedia} table contains one entry at the following: start of
+the job, start of each new tape file, start of each new tape, end of the
+job. Since by default, a new tape file is written every 2GB, in general,
+you will have more than 2 JobMedia records per Job. The number can be
+varied by changing the "Maximum File Size" specified in the Device
+resource. This record allows Bacula to efficiently position close to
+(within 2GB) any given file in a backup. For restoring a full Job,
+these records are not very important, but if you want to retrieve
+a single file that was written near the end of a 100GB backup, the
+JobMedia records can speed it up by orders of magnitude by permitting
+forward spacing files and blocks rather than reading the whole 100GB
+backup.
+
+
\