I've been following this thread with some interest, but with little to contribute directly. However, the thread does bring up some questions that I've had about the concept of pruning the bacula database.
It seems to me that the database should only be pruned when files are added (ie., when a backup succeeds), not merely because a volume was accessed for reading. In other realms, such as the algorithm that bacula employs to decide which volume to use, bacula tries very hard to keep data on the backup media (and in the catalog) for as long as possible. The idea that accessing a volume (ie., doing a restore) can prune records seems to be inconsistent with the philosophy of keeping the data whenever possible. In our environment, it's pretty common that a request to restore files from directory "X" is then followed by another request to restore files from directory "Y", when the user realizes that they didn't get all the files they needed. If the first restore caused the database records for a multi-TB backup that spans 3 or 4 tapes to be pruned, then the second restore will be extremely slow and painful. It seems that the disk space resource to store a large database catalog is much "cheaper" than the time resource for a system administrator to bscan tapes or the time resource for an end user to wait for a restore. What are the settings required to configure bacula so that the catalog retention period is the same as the data retention? In other words, as long as the data exists on the backup media, the database catalog records exist as well? Obviously, the database size may expand a great deal. I know very, very little about databases, but would there be significant performance or database stability advantages to moving the old records into distinct tables? In other words, instead of pruning database records (while the data still exists on the backup media), move those records to a separate table or separate database? This would keep the "hot" database of the most current records at a smaller size, while letting the database of older records grow. That distinction could give system administrators & DBAs the choice of what physical disks are used to store each database, etc. Does anyone know the practical database size limits for MySQL and Postgres? Would typical bacula installations (if there is such a thing) be in danger of reaching those limits if database records were retained as long as the data itself? Thanks, Mark ---- Mark Bergman [EMAIL PROTECTED] System Administrator Section of Biomedical Image Analysis 215-662-7310 Department of Radiology, University of Pennsylvania http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=mark.bergman%40.uphs.upenn.edu ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
