On 11/19/2010 4:02 PM, Bob Hetzel wrote: > > > On 11/18/2010 11:00 PM, Dan Langille wrote: >> On 11/18/2010 4:20 PM, Bob Hetzel wrote: >>>> From: Craig Miskell<craig.misk...@opus.co.nz> >>>> Subject: [Bacula-users] bscan, file retention, and pruning >>>> To: bacula-users<bacula-users@lists.sourceforge.net> >>>> Message-ID:<4ce45109.4010...@opus.co.nz> >>>> Content-Type: text/plain; charset=ISO-8859-1 >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Hi, >>>> So I have just seen a case where an old tape with a job that had it's file >>>> records pruned by the File Retention was bscan'd to get the records back >>>> into >>>> the database. >>>> >>>> The operator then tried to run a restore, but had managed to leave the tape >>>> drive in an inconsistent state (unmounted, with the tape in it, so mtx >>>> had a >>>> hernia), and the Restore job failed. That's unfortunate, but it happens, >>>> and >>>> isn't the real problem. When the job failed and finished, the File >>>> Retention >>>> period kicked in, and the bscan'd records were purged. >>>> >>>> This is somewhat annoying, and means we have to bscan again (4 hours+). >>>> In the >>>> general case of a bscan and a single successful restore, it's pretty >>>> much ok. >>>> But in case of a failure of the restore, or if we find we have to do >>>> more than >>>> one restore (the user decides they need more files after the first >>>> batch), this >>>> is a real pain. >>>> >>>> The somewhat crude approach is to raise File Retention on the client to >>>> a big >>>> enough period to cover back to when the tape was written, while going >>>> through >>>> the bscan/restore process, and setting it back to normal afterwards. >>>> >>>> Is there a better way? I'm thinking of something like marking the job as >>>> not-pruneable after the bscan and while doing restores, but I'm open to any >>>> suggestions. >>>> >>>> Thanks, >> >>> What you've hit on is something I've noted too... I'm thinking it would be >>> a nice tweak/enhancement to bacula if the pruning function was disabled on >>> restore jobs. Another case that could trigger it might be just restoring >>> from your oldest backup. >>> >>> I've no idea how simple this change might be, though. It seems rather >>> counter intuitive for bacula to try to prune something at the end of a >>> restore job (successful or failed) so it may be a bigger project than >>> adding a simple if statement... Has anybody dug into that part of the code? >> >> Do not set auto prune on. >> >> Instead, use an Admin job to do your pruning for you. >> > > Interesting idea... Do you have a good prune script?
No need as far as I know. I do not recall details. I seem to recall reading details when learning about Job Type = Admin. I suggest starting there. -- Dan Langille - http://langille.org/ ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
