Backup Central

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:1
396 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.

Andrew

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.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

I thought I had fixed this by upgrading to Bacula 5 (as part of Fedora 13 upgrade) and reverting bacula-sd.conf settings to defaults. I can perform reboots, stop & restart bacula-sd, and Bacula is able to append. However the other day the system locked up (due to an unrelated issue) & I had to reboot the hard way with the power switch. After that I am back to MTEOM tape positioning errors:-
08-Jul 01:06 bacula-sd JobId 315: Error: Unable to position to end of data on device "SLR7" (/dev/nst0): ERR=dev.c:956 ioctl MT
EOM error on "SLR7" (/dev/nst0). ERR=Input/output error.

If I try to position at the end of this tape I get an I/O error:-
[root@localhost dev]# mt -f /dev/nst0 eod
/dev/nst0: Input/output error
But if I use the previous week's tape, which did not have any errors, mt -f /dev/nst0 eod successfully positions the tape.

It looks as if Bacula writes the EOM marker when it is shut down nicely, not when it completes the backup job; if it is shut down brutally it doesn't get written and so the end of the medium can't be found. Is this how Bacula really works? If it is, how can I get round it, or is it a bug?

For the record, my (default) bacula-sd.conf settings are:-
   Hardware End of Medium = Yes
   Fast Forward Space File = Yes
   Use MTIOCGET = Yes
   BSF at EOM = No
   Two EOF = No
   Backward Space Record = Yes
   Backward Space File = Yes
   Forward Space Record = Yes
   Forward Space File = Yes
and my tape driver options are
The options set: buffer-writes async-writes read-ahead can-bsr