Theorem as to a possible mechanism:
If the catalog DB is empty when it runs, bscan creates new Clients and
Filesets as it encounters them. However, it does not guarantee that
they have the same ClientIds or FileSetIDs, and when scanning later jobs
- probably especially if you have to scan jobs in multiple batches
because there are too many Volumes to fit in the commandline at once -
if the FileSetId for the job appears to match an already existing
FileSetId, bscan assumes that the job is associated with the FileSet
*now* corresponding to that ID, even if it earlier allocated a different
ID to that FileSet. Ditto, possibly, with ClientIDs.
PARTIAL workaround:
If you have to drop the DB, restart Bacula before bscanning anything.
This at least makes reasonably sure the CLIENTS get their old ClientIds
back, assuming ClientIds previously reflected their order in the
Director config file. However, this does not store the FileSet IDs into
the DB, so it's only a partial solution.
I'm testing now to see whether workably correct results can be obtained
by dropping DB, restarting Bacula, then bscanning 5.2.1 backup volumes
FIRST followed by 5.0.3 volumes.
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org
Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater
It's not the years, it's the mileage.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
