Bacula-users

Re: [Bacula-users] bscan, file retention, and pruning

2010-11-18 08:10:46
Subject: Re: [Bacula-users] bscan, file retention, and pruning
From: Kleber Leal <kleber.leal AT gmail DOT com>
To: bacula-users <bacula-users AT lists.sourceforge DOT net>
Date: Thu, 18 Nov 2010 10:03:43 -0300
Maybe this can help you:
http://www.bacula.org/5.0.x-manuals/en/utility/utility/Volume_Utility_Tools.html#SECTION00274000000000000000

copy/paste
An interesting aspect of restoring a catalog backup using bscan is that the backup was made while Bacula was running and writing to a tape. At the point the backup of the catalog is made, the tape Bacula is writing to will have say 10 files on it, but after the catalog backup is made, there will be 11 files on the tape Bacula is writing. This there is a difference between what is contained in the backed up catalog and what is actually on the tape. If after restoring a catalog, you attempt to write on the same tape that was used to backup the catalog, Bacula will detect the difference in the number of files registered in the catalog compared to what is on the tape, and will mark the tape in error.

Kleber

2010/11/17 Craig Miskell <craig.miskell AT opus.co DOT nz>
-----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,

- --
Craig Miskell
Senior Systems Administrator
Opus International Consultants
Phone: +64 4 471 7209
I think we agree, the past is over
- -George W Bush

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkzkUQkACgkQmDveRtxWqna+BwCgmIKDzOVuuqLoNqe4Gzu12Ky9
ptIAn3R/CfmMMBe+L2m3V+DuY1vrk2p0
=wdLG
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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

------------------------------------------------------------------------------
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