Hi,
28.02.2008 12:49, Damian Brasher wrote:
> Hi List
>
> I have had some fairly regular job failures that I have pinpointed to be
> caused by tape status type error mismatches. The most common is that the
> tape status does not match that of the catalogue in a number of ways.
>
> The first is that if the catalogue reports the volume status to be
> error, used or full and I manually change the status of the volume using
> *update -> Volume parameters -> Volume status -> Pool -> PoolName -> Append
>
> How can I be sure that the volume/tape has been updated as well as the
> catalogue?
You can't. That's because this sort of tape status *only* exists in
the catalogue. There's no volume status on the volume itself.
> How can I read the status of a volume/tape without referring to the
> catalogue, to see the true tape status?
The true and only volume status is the one in the catalog.
> The second mismatch issue involves the catalogue reporting a different
> file count than the volume actually contains, this is a typical error:
>
> 27-Feb 23:05 backup-sd JobId 514: Error: Bacula cannot write on tape
> Volume "Wednesday1" because:
> The number of files mismatch! Volume=103 Catalog=0
>
> How can I avoid an error like this halting a job?
These errors indicate a serious problem writing to the volumes, or
reading it.
In the catalog, Bacula notes the number of file marks for each tape.
When mounting to append, it seeks to the end of the tape. If the file
position is different to what is in the catalog, it produces this error.
Most often we see file count mismatches where the volume # of files is
a only a bit off compared to the one in the catalog. This typically
occurs when the SD or DIR crashes during job execution.
If you see this regularly, and with a file count of 0, chances are
that either your tapes are damaged, your tape drive's firmware or the
driver is broken, or you've got a serious bug in your Bacula environment.
You need to fix the underlying problem. The first step to do so is to
run the btape tests and tweak the configuration until they all run
without failure.
The needed storage settings are highly system dependent, so it might
help if you reported the operating system, tape and SCSI hardware
you're using - perhaps someone runs a similar setup and can help with
their configuration.
> The third mismatch is reported by the status of the storage daemon by
> user intervention. Often when I manually unmount a volume the storage
> daemon reports back the the device is BLOCKED due to user intervention.
This is not an error, this is just the status you get when manually
unmounting.
> I'm not 100% sure but this error the causes a job to fail,
Unless you've got some timeouts set, this should not cause jobs to end
in error, they should only be stalled.
> even when I
> use a script to automatically umount then mount just before the job starts.
What is the bconsole output from these scripts?
> Is there a way to eliminate old BLOCKED messages so they do not prevent
> a legitimate job?
No, it's not the messages blocking the jobs, it's the status you
actively set (i.e. unmounting) that causes the block. The only cure is
to not unmount, or mount again.
> Here is a cut down copy of my bacula-dir.conf
>
> Director {
> Name = backup-dir
> DIRport = 9101
> QueryFile = "/etc/bacula/query.sql"
> WorkingDirectory = "/var/bacula/working"
> PidDirectory = "/var/run"
> Maximum Concurrent Jobs = 1
> Password = "******"
> Messages = Daemon
> }
>
> Job {
> Name = "holly"
> Type = Backup
> Level = Full Client = holly
> FileSet = "holly"
> Storage = LTO-2
> Pool = Default
> RunBeforeJob = "/etc/bacula/scripts/runbefore.sh"
> Write Bootstrap = "/var/lib/bacula/holly.bsr"
> Schedule = "WeeklyCycle"
> Messages = Standard
> Priority = 7
> Max Start Delay = 22h
> Max Run Time = 30m
This might cause jobs to be cancelled when no tape is mounted.
> }
>
> FileSet {
I suggest you re-check with btape and ensure the hardware is
configured correctly.
Then you'll have to re-think your timeouts and procedures regarding
unmounting etc. Normally, there's no need to unmount a tape unless you
want to change it, and if you change it it should be easy to ensure
the tape is mounted afterwards. As an alternative to unmounting,
releasing might also help.
Arno
--
Arno Lehmann
IT-Service Lehmann
www.its-lehmann.de
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
