Re: [Bacula-users] bscan, file retention, and pruning
2010-11-18 08:10:46
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
|
|
|