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.misk...@opus.co.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@lists.sourceforge.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
