Hi Jim, One more comment about this script.
A DiskToCatalog job is run as one of the verify jobs. The thing is, (and this is the part you commented at the end of your OP), it is NOT verifying the data I am restoring to /tmp/bacula-auto_restores/.... The RunScripts in the Catalog job in my Community edition environment are customized, and I keep a few dumps around in the dump directory. So what happens with this verify job - and the reason they are successful on my Community system - is that it is verifying the original files which still exist in the dump directory. In my Enterprise test environments, I left the default Catalog job's RunScripts which delete the bacula.sql file at the end of the job, and so, this verify job fails because it is trying to verify files which have been deleted and no longer exist in the place they where backed up from. So, what I am trying to say is that currently, this DiskToCatalog test in my script will only make sense in the scenario where the auto-restore job restores to "where = /" (the original location) which is not what we would normally want to do on a live filesystem - but would be perfectly OK to do in the case of the catalog dump. Hope this helps! Best regards, Bill -- Bill Arlofski http://www.revpol.com/bacula -- Not responsible for anything below this line -- ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
