Why don't you create a bootstrap file so that all Volumes can be scanned in one bscan execution. Any time you use multiple bscan executions you are likely to have problems especially due to jobs spanning volumes.
Kern On 11/04/2011 01:07 AM, Phil Stracchino wrote: > 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. > > ------------------------------------------------------------------------------ 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
