Hello,

On 5/20/2006 11:32 PM, John Goerzen wrote:
On 2006-05-19, John Goerzen <[EMAIL PROTECTED]> wrote:

I did an update volume and set yesterday's volume to used... then it
said it was waiting for mount.  I ran mount for the second time
(remember I had already done that earlier), and then the backups
started using one of the available volumes.


Still haven't heard a theory on why that happened, so if anyone has an
idea, please do chime in ;-)

Don't know, but I have experienced similar things, but not always: Only when a pool was full, I manually purged a volume, and then issued a mount command it sometimes takes two mount commands to continue the running jobs. This might also be timing related, though - I assume it is possible that the DIR still works with the catalog, and I'm too impatient...

In the meantime, another odd problem.  I set volume use duration to 21h
to make sure that the volume would be set to used in time for the next
backup, to try to prevent this from happening again.

Well, it worked, but it didn't help the backup start on time.

We had three labeled, but otherwise completely unused, tapes in the
pool.  Two were in the changer, and Bacula knew this.  Yet for some
inexplicable reason, it decided it wanted the tape that wasn't in the
changer!  (All three were showing Appendable).  I finally set that tape
Destroyed (or Deactivated or whatever that option was), ran mount again,
and then things worked.

I am concerned about the unpredictability of the tape handling here,
alas.

I can't say I experience unpredictable tape handling here, so it would be good do see more detailed information from you: If possible, use a pool with a very limited number of volumes (the three you talk about seems ok), collect all the tape status information before you start a job (i.e. use 'list' and 'llist' commands on the pool and the volumes in it) and in case of unpredictable behaviour, and of course make sure your catalog is in a consistent state (i.e. don't modify the catalog database unless you know how to fix it :-)

It is very important to keep in mind that the volume metadata is individual for each volume, so that, after modifying retention times, you have to apply these changes to the existing volumes, too. Also, the retention period begins after the last write to a volume, so for example your backup job takes 3.5 hours, 21 hours of retention are too long to ensure availability after 24 hours.

Arno

Thanks,

-- John



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

--
IT-Service Lehmann                    [EMAIL PROTECTED]
Arno Lehmann                  http://www.its-lehmann.de


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to