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.miskell AT opus.co DOT nz>
>>>> Subject: [Bacula-users] bscan, file retention, and pruning
>>>> To: bacula-users<bacula-users AT lists.sourceforge DOT net>
>>>> Message-ID:<4CE45109.4010301 AT opus.co DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users