>>>>> On Mon, 20 Sep 2010 09:54:24 +1200, Craig Miskell said:
> 
>       I recently had to bscan a tape.  The job was in the database (the Job 
> Retention
> period hadn't yet passed), but the file/path records were not (the File
> Retention period *had* passed).
> 
> For this client, there were two Filesets in the database due to a change a few
> months back.  The job on the scanned tape was originally run using fileset 1,
> but bscan changed the record in the Job table to fileset 2.
> 
> I've not yet run exhaustive tests because it takes 3-4 hours to read the tape
> and insert the data into the database.  Before I go down that path: should I 
> be
> expecting this behaviour from bscan?  If not, I should be able to fix it and
> supply a patch (you know, good old community involvement in bug fixes.... :)),
> but I would like to know I'm not wasting my time first.

I think it is difficult.  Can it reliably pick the correct one (in the case
where the job record was deleted as well)?  If the job record still exists,
which fields (if any) should be updated?


> I'm running Bacula 5.0.0 on Debian Etch (yes, I know, that's old.  I'm working
> on it in between bscanning tapes :))
> 
> Side question: is bscan the correct operation in this case, where File 
> Retention
> has passed but Job Retention hasn't?  Given, of course, that I want to restore
> selected files, not the entire fileset.

It is the only way if you want to use the restore command.  OTOH, you could
use bextract to read the volume directly, but it doesn't support all of the
options (e.g. decryption).

__Martin

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users