>>>>> On Wed, 02 Jun 2010 19:11:29 -0400, AndyW said:
>
> I invariably get errors of the following kind when I try to append to a
> previously written tape following a reboot:-
>
> 31-May 23:48 bacula-dir JobId 234: Start Backup JobId 234,
> Job=BackupHomeDir.2010-05-31_23.48.54_04
> 31-May 23:48 bacula-dir JobId 234: Using Device "SLR7"
> 31-May 23:49 bacula-sd JobId 234: Volume "Week3-Tape001" previously written,
> moving to end of data.
> 31-May 23:52 bacula-sd JobId 234: Error: Unable to position to end of data on
> device "SLR7" (/dev/nst0): ERR=dev.c:1396 ioctl MTFSF error on "SLR7"
> (/dev/nst0). ERR=Input/output error.
>
> 31-May 23:52 bacula-sd JobId 234: Marking Volume "Week3-Tape001" in Error in
> Catalog.
> 31-May 23:56 bacula-sd JobId 234: Job BackupHomeDir.2010-05-31_23.48.54_04
> waiting. Cannot find any appendable volum
> es.
>
> I can write to a newly initialised tape without problem, and can append so
> long as the PC is not rebooted - even after stopping & restarting Bacula.
> Tapes are new, the btape test program runs 100% successfully and I can read
> from the tapes even after they are in error.
>
> Tape device is Tandberg SLR7. Driver options (set using mt) are:
> buffer-writes async-writes read-ahead two-fms can-bsr. Device settings in
> bacula-sd.conf are:
> Block Positioning = no
> Hardware End of Medium = No # defaut is Yes
> Backward Space Record = no
> Backward Space File = no
> Fast Forward Space File = No # This line required if above HEOM is set to
> "No"
> BSF at EOM = Yes # Default is no
> Two EOF = Yes # Minimum Block Size = 512
>
>
> My backup schedule is weekly full, followed by nightly incremental. Bacula
> version is 3.0.3. OS is Fedora 12 (kernel 2.6.32.12-115.fc12.x86_64).
>
> I have seen numerous postings about this on this forum & elsewhere - one post
> here had recommended settings which seemed to fix the problem for a few days
> before it resumed. I have tried numerous combinations of driver and Bacula
> settings but always get this error (or a similar one with "MTEOF"). It seems
> the tape is either writing a marker it shouldn't, or *not* writing something
> it should, when the system is rebooted. How do I correct the tape drive
> behaviour and/or configure Bacula to handle it?
>
> Any ideas gratefully received.
Firstly, do you really need to use two eofs?
Also, when are you setting the two-fms driver options?
Can you verify the options periodically? The following is supposed to do that:
mt -f /dev/nst0 stsetoptions 0
grep st0 /var/log/messages
It is possible that the bad tape was somehow written without the two-fms
driver option, e.g. if something in the system cleared it. Perhaps the
setting doesn't persist when you insert a new tape?
You could try to find out how many eofs are on a tape by temporarily switching
off two-fms and counting the number of files on the tape. E.g. (completely
untested)
Unmount the drive from Bacula.
mt -f /dev/nst0 rewind
mt -f /dev/nst0 stclearoptions two-fms
dd if=/dev/nst0 of=/dev/null
Repeat the dd command until it either gets an error or shows several zero
length files.
If dd reports more than one zero length file and no errors, then this
technique is probably not going to work.
If it gets an error without reporting any zero length files then you probably
have a tape with only one eof at the end.
If it gets an error after reporting a single zero length file then you
probably have a tape with two eofs at the end.
Try this with a good tape and a bad tape to see if they are different.
__Martin
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
