Backup Central

We are attempting to restore a single file from a backup set, and the
restore is failing. We have done restores previously without a problem.
The odd line in the output is the "Error: Read error on Record Header
/dev/nst0: Success". What does that mean? This is with bacula-1.32d.

I'm running further tests now.

Greg

kiev-dir: Start Restore Job RestoreFiles.2004-02-05_11.22.50
kiev-sd: RestoreFiles.2004-02-05_11.22.50 Warning: Wrong Volume mounted
on device /dev/nst0: Wanted Set1Tape12 have Set1Tape15
kiev-sd: 3301 Issuing autochanger "loaded" command.
kiev-sd: 3302 Issuing autochanger "unload" command.
kiev-sd: 3303 Issuing autochanger "load slot 12" command.
kiev-sd: 3304 Autochanger "load slot 12" status is OK.
kiev-sd: Ready to read from volume "Set1Tape12" on device /dev/nst0.
kiev-sd: Forward spacing to file:block 17:7833.
kiev-sd: RestoreFiles.2004-02-05_11.22.50 Error: block.c:248 Expected
block-id BB01 or BB02, got . Buffer discarded.
kiev-sd: RestoreFiles.2004-02-05_11.22.50 Error: block.c:248 Expected
block-id BB01 or BB02, got . Buffer discarded.
kiev-sd: RestoreFiles.2004-02-05_11.22.50 Error: Read error on Record
Header /dev/nst0: Success
kiev-dir: RestoreFiles.2004-02-05_11.22.50 Error: Bacula 1.32d
(02Nov03): 05-Feb-2004 11:31
JobId: 702
Job: RestoreFiles.2004-02-05_11.22.50
Client: nara-fd
Start time: 05-Feb-2004 11:22
End time: 05-Feb-2004 11:31
Files Restored: 0
Bytes Restored: 0
Rate: 0.0 KB/s
Non-fatal FD Errors: 0
FD termination status: OK
SD termination status: Error
Termination: *** Restore Error ***

Gregory Brauer wrote:
kiev-sd: Forward spacing to file:block 17:7833.

The problem is definitely related to this line. If I do a
restore and in the process bacula tries to forward space to
##:0, it works. If the number after the ":" is non-zero it
fails. Which bacula setting turns off block seeks?

Random access = No ?

I don't think I have ever seen bacula try to do a block seek
before, even when restoring single files.

Greg

Hello,

The real problem is that Bacula read a block from the tape and got
garbage (a . instead of BB02 in the block identification field). The
read error: success printed after that is an artifact from unwinding an
error condition in a low level subroutine (i.e. a minor bug).

Concerning your next email: Bacula *is* quite capable of forward spacing
files as well as blocks and does this more often than not when restoring
a single file.

I have two suggestions for resolving your problem:

- Upgrade to 1.32f-4 because if I am not mistaken I turned off fast
block rejection in a prior release which could create similar problems.
The ChangeLog would verify if it occurred before or after your version.

- If that doesn't solve your problem, try restoring all the files from
the job that contains the one you want. That will prevent Bacula from
doing the block forward spacing, and you will see whether or not it is a
bug or a bad tape that is returning a bad block of data.

Regards, Kern

On Thu, 2004-02-05 at 20:48, Gregory Brauer wrote:
We are attempting to restore a single file from a backup set, and the
restore is failing. We have done restores previously without a problem.
The odd line in the output is the "Error: Read error on Record Header
/dev/nst0: Success". What does that mean? This is with bacula-1.32d.

I'm running further tests now.

Greg



kiev-dir: Start Restore Job RestoreFiles.2004-02-05_11.22.50
kiev-sd: RestoreFiles.2004-02-05_11.22.50 Warning: Wrong Volume mounted
on device /dev/nst0: Wanted Set1Tape12 have Set1Tape15
kiev-sd: 3301 Issuing autochanger "loaded" command.
kiev-sd: 3302 Issuing autochanger "unload" command.
kiev-sd: 3303 Issuing autochanger "load slot 12" command.
kiev-sd: 3304 Autochanger "load slot 12" status is OK.
kiev-sd: Ready to read from volume "Set1Tape12" on device /dev/nst0.
kiev-sd: Forward spacing to file:block 17:7833.
kiev-sd: RestoreFiles.2004-02-05_11.22.50 Error: block.c:248 Expected
block-id BB01 or BB02, got . Buffer discarded.
kiev-sd: RestoreFiles.2004-02-05_11.22.50 Error: block.c:248 Expected
block-id BB01 or BB02, got . Buffer discarded.
kiev-sd: RestoreFiles.2004-02-05_11.22.50 Error: Read error on Record
Header /dev/nst0: Success
kiev-dir: RestoreFiles.2004-02-05_11.22.50 Error: Bacula 1.32d
(02Nov03): 05-Feb-2004 11:31
JobId: 702
Job: RestoreFiles.2004-02-05_11.22.50
Client: nara-fd
Start time: 05-Feb-2004 11:22
End time: 05-Feb-2004 11:31
Files Restored: 0
Bytes Restored: 0
Rate: 0.0 KB/s
Non-fatal FD Errors: 0
FD termination status: OK
SD termination status: Error
Termination: *** Restore Error ***



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users



RE: [Bacula-users] incremental restore question From: Dan Langille <dan < at > la...> - 2004-02-06 01:53

On Thu, 5 Feb 2004, Stuart McGraw wrote:

I can think of several reasons why you would want a file
system restored to *exactly* the state it was in at the
time of the last backup...

All would agree that achieving the solution is a good thing. I can only
go by what Kern said: it is not easy.

If it was easy, it would be done. Someone needs to sit down and create
the algorithm.



RE: [Bacula-users] incremental restore question From: Stuart McGraw <smcg4191 < at > fr...> - 2004-02-06 01:34

I can think of several reasons why you would want a file
system restored to *exactly* the state it was in at the
time of the last backup...

- The file system is near capacity and restoring deleted
files can result in a full file system before all the
files are restored. I have experienced this and it was
nor pleasant.
- In some cases the presence of a file can affect the behavior
of the system. The files in the /etc/xinetd.d directory on
a linux system for example.
- It is common to have processes that receive data in files,
process the data, then delete the files. Injecting the
data a second time could have deleterious effects.
- The simple action of deleting files can represent significant
work -- is this file obsolete? Is it redundant? Is it bad?
Is it in the wrong location? Just having to redo this work
can be a significant loss of time (the avoidance of which is
the real purpose of backups, yes?) I have seen cases where
several people-days were spent cleaning up a file system. I
would not want to be the one to tell them that the work had
to be repeated because the backups had "helpfully" restored
everything.

Backups have several purposes but one of them is to get things
back as they were, as quickly as possible, after a failure.
Restoring deleted files does not contribute to this goal.

Volker Sauer wrote:
Alan Brown wrote:
Will I end
up with files A and C, or files A, B, and C?

A, B and C.

This is common answer virtually to ANY backup system, as far as I know.

Given that Bacula uses a database to track changes, why not record
deletions to the incremental update so that during restores, B would be
deleted?

Why? I don't think that this is very smart. A backup is primarily for
restoring files not for deleting them.
The only reason I can imagine is to restore a complete user-directory
*exactly* like it was before it got delete while using full- and
incremenatial jobs for the restore. Then you'd have files which where
deleted during the period the incremenatial backups ran beneatch the
restored files of the user. But I don't thnik, that this is really bad.

Kern Sibbald wrote:
I have two suggestions for resolving your problem:

- Upgrade to 1.32f-4 because if I am not mistaken I turned off fast
block rejection in a prior release which could create similar problems.
The ChangeLog would verify if it occurred before or after your version.

- If that doesn't solve your problem, try restoring all the files from
the job that contains the one you want. That will prevent Bacula from
doing the block forward spacing, and you will see whether or not it is a
bug or a bad tape that is returning a bad block of data.

1.32f-4 *appears* to fix the problem. It is no longer trying to
do a block seek.

Thanks!

Greg

I'm very pleased to hear that the problem is fixed. I assure you,
however, that if you read back a single file, version 1.32f-4 will very
likely do forward spacing to a non-zero block number depending on the
block number where the data is located. It doesn't do "seeks" as such,
it does forward spacing.

In 1.32f-4 the default is that Bacula does *not* print positioning
information. If you want to see when it is doing positioning, you must
add a -v option to the command line on the Storage daemon. Then you
will see more detail on what is going on internally. It will not print
huge volumes of information, and this is the way I normally run the
daemons.

Best regards, Kern

Please let me know once you are sure it works ...

On Wed, 2004-02-11 at 06:45, Gregory Brauer wrote:
Kern Sibbald wrote:
I have two suggestions for resolving your problem:

- Upgrade to 1.32f-4 because if I am not mistaken I turned off fast
block rejection in a prior release which could create similar problems.
The ChangeLog would verify if it occurred before or after your version.

- If that doesn't solve your problem, try restoring all the files from
the job that contains the one you want. That will prevent Bacula from
doing the block forward spacing, and you will see whether or not it is a
bug or a bad tape that is returning a bad block of data.

1.32f-4 *appears* to fix the problem. It is no longer trying to
do a block seek.

Thanks!

Greg


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

Kern Sibbald wrote:
I'm very pleased to hear that the problem is fixed. I assure you,
however, that if you read back a single file, version 1.32f-4 will very
likely do forward spacing to a non-zero block number depending on the
block number where the data is located. It doesn't do "seeks" as such,
it does forward spacing.

Well, I have done some test restores from several files that I am
sure would have to be somewhere in the middle of a tape file,
and bacula 1.32f-4 has always moved to block 0 of the tape file and
started the read from there. This is fine... it works and is
reasonably fast, so I'm not complaining.

Greg

Hi,
I am using bacula 1.32f4 on freebsd 4.9-stable (with patches and
everything), and backing up to hard disk.

I used zip compression, and when trying to restore a file i got this
error :
Error: Uncompression error on file xxx ERR=Zlib data error

any idea what can be the cause?

Thanks

Hello,

I have no idea what that means as it is in the bowels of zlib.
It seems that something similar occurred once because of a change of
version of zlib (totally unbelievable and irresponsible of the authors
IMO), but it could also mean that you have a bad disk, or FreeBSD
pthreads has struck again, or less likely that there is a Bacula bug ...

Regards, Kern

On Mon, 2004-03-08 at 18:59, FireWire BSD wrote:
Hi,
I am using bacula 1.32f4 on freebsd 4.9-stable (with patches and
everything), and backing up to hard disk.

I used zip compression, and when trying to restore a file i got this
error :
Error: Uncompression error on file xxx ERR=Zlib data error

any idea what can be the cause?

Thanks



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

Hi,

I had same problem again with premature end of file for the zlib so
the last files couldn't be restored.
i will stop using zip compression and see what's going on.

thanks

On Wed, 2004-03-10 at 10:46, Kern Sibbald wrote:
Hello,

I have no idea what that means as it is in the bowels of zlib.
It seems that something similar occurred once because of a change of
version of zlib (totally unbelievable and irresponsible of the authors
IMO), but it could also mean that you have a bad disk, or FreeBSD
pthreads has struck again, or less likely that there is a Bacula bug ...

Regards, Kern

On Mon, 2004-03-08 at 18:59, FireWire BSD wrote:
Hi,
I am using bacula 1.32f4 on freebsd 4.9-stable (with patches and
everything), and backing up to hard disk.

I used zip compression, and when trying to restore a file i got this
error :
Error: Uncompression error on file xxx ERR=Zlib data error

any idea what can be the cause?

Thanks



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

Gregory Brauer wrote:
Kern Sibbald wrote:

I'm very pleased to hear that the problem is fixed. I assure you,
however, that if you read back a single file, version 1.32f-4 will very
likely do forward spacing to a non-zero block number depending on the
block number where the data is located. It doesn't do "seeks" as such,
it does forward spacing.


Well, I have done some test restores from several files that I am
sure would have to be somewhere in the middle of a tape file,
and bacula 1.32f-4 has always moved to block 0 of the tape file and
started the read from there. This is fine... it works and is
reasonably fast, so I'm not complaining.

This problem is back (or perhaps it was never really gone). I had the
hard drive on the bacula server fail and am trying to restore my
catalog from tape. It is trying to forward space to a particular
block, and as before any time a restore tries to forward space to
a block number other than "0", the restore fails. Is there any way
I can turn off forward spacing so that bacula will only tried to
read starting at the beginning of the tape file?

I'm also wondering why it is trying to forward space at all, since
I am doing a full restore of an entire job that backed up only
a single file (/var/bacula/bacula.sql). What would be in the
first tape block that it is skipping?

This is with bacula-1.32f-5.

chetroketl-dir: Start Restore Job RestoreFiles.2004-04-21_21.05.05
chetroketl-sd: Ready to read from volume "Backup2Set2Tape15" on device /dev/nst0.
chetroketl-sd: Forward spacing to file:block 27:1.
chetroketl-sd: RestoreFiles.2004-04-21_21.05.05 Error: block.c:248 Expected
block-id BB01 or BB02, got ileI. Buffer discarded.
chetroketl-sd: RestoreFiles.2004-04-21_21.05.05 Error: block.c:248 Expected
block-id BB01 or BB02, got ileI. Buffer discarded.
chetroketl-sd: RestoreFiles.2004-04-21_21.05.05 Error: Read error on Record
Header /dev/nst0: Success
chetroketl-dir: RestoreFiles.2004-04-21_21.05.05 Error: Bacula 1.32f-5
(09Mar04): 21-Apr-2004 21:06
JobId: 25
Job: RestoreFiles.2004-04-21_21.05.05
Client: chetroketl-fd
Start time: 21-Apr-2004 21:05
End time: 21-Apr-2004 21:06
Files Restored: 0
Bytes Restored: 0
Rate: 0.0 KB/s
FD Errors: 0
FD termination status: OK
SD termination status: Error
Termination: *** Restore Error ***

Thanks.

Greg

Gregory Brauer wrote:
This is with bacula-1.32f-5.

More info:

This also happens with bacula-sqlite-1.32f-4, which is the
version I had thought had fixed the problem previously... it
turns out I just had several very lucky spot-checks at that
time.

bextract restores the files fine, so the tape is ok.

Just FYI, I didn't mention that the database I am using to
try and restore my bacula.sql file from is a temporary database
built with bscan from the tape that I know holds the backup of my
full database.

Greg

Hello,

On Thu, 2004-04-22 at 06:24, Gregory Brauer wrote:
Gregory Brauer wrote:
Kern Sibbald wrote:

I'm very pleased to hear that the problem is fixed. I assure you,
however, that if you read back a single file, version 1.32f-4 will very
likely do forward spacing to a non-zero block number depending on the
block number where the data is located. It doesn't do "seeks" as such,
it does forward spacing.


Well, I have done some test restores from several files that I am
sure would have to be somewhere in the middle of a tape file,
and bacula 1.32f-4 has always moved to block 0 of the tape file and
started the read from there. This is fine... it works and is
reasonably fast, so I'm not complaining.

This problem is back (or perhaps it was never really gone). I had the
hard drive on the bacula server fail and am trying to restore my
catalog from tape. It is trying to forward space to a particular
block, and as before any time a restore tries to forward space to
a block number other than "0", the restore fails. Is there any way
I can turn off forward spacing so that bacula will only tried to
read starting at the beginning of the tape file?

I'm also wondering why it is trying to forward space at all, since
I am doing a full restore of an entire job that backed up only
a single file (/var/bacula/bacula.sql). What would be in the
first tape block that it is skipping?

Bacula is trying to forward space to file 27 block 1, so if that is not
correct, there is something seriously fouled up in your catalog. You
didn't explain how you generated this restore file, so perhaps you were
running through code that is not well testing and there is a bug.

If your tape drive passes the 1.34.x btape "test" command, there is no
reason why forward spacing will not work. I recommend you try it. You
can download the package and build it (use 1.34.1) but not install it
and just run btape (or copy it to your binary directory). If it fails
the "test" command seeking then that is where your problem lies. You
will need to correct the problem. You need to use version 1.34.x for
this as I added new seek tests.

As for turning off seeking -- that is not something I am going to do.
However, you can force it off by running restore to the point that it
asks you to run the job. Then in another command window edit the bsr
file (restore.bsr), which will be in your working directory. In that
file, remove all occurrences of VolFile and VolBlock not changing
anything else. Then let the job start and Bacula will read from the
beginning of the tape. If you want Bacula to read to the end of the
tape, you can also remove the Count line.

I'd be interested to hear the outcome of this.

Best regards, Kern


This is with bacula-1.32f-5.


chetroketl-dir: Start Restore Job RestoreFiles.2004-04-21_21.05.05
chetroketl-sd: Ready to read from volume "Backup2Set2Tape15" on device /dev/nst0.
chetroketl-sd: Forward spacing to file:block 27:1.
chetroketl-sd: RestoreFiles.2004-04-21_21.05.05 Error: block.c:248 Expected
block-id BB01 or BB02, got ileI. Buffer discarded.
chetroketl-sd: RestoreFiles.2004-04-21_21.05.05 Error: block.c:248 Expected
block-id BB01 or BB02, got ileI. Buffer discarded.
chetroketl-sd: RestoreFiles.2004-04-21_21.05.05 Error: Read error on Record
Header /dev/nst0: Success
chetroketl-dir: RestoreFiles.2004-04-21_21.05.05 Error: Bacula 1.32f-5
(09Mar04): 21-Apr-2004 21:06
JobId: 25
Job: RestoreFiles.2004-04-21_21.05.05
Client: chetroketl-fd
Start time: 21-Apr-2004 21:05
End time: 21-Apr-2004 21:06
Files Restored: 0
Bytes Restored: 0
Rate: 0.0 KB/s
FD Errors: 0
FD termination status: OK
SD termination status: Error
Termination: *** Restore Error ***


Thanks.

Greg


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

On Thu, 2004-04-22 at 06:55, Gregory Brauer wrote:
Gregory Brauer wrote:
This is with bacula-1.32f-5.


More info:

This also happens with bacula-sqlite-1.32f-4, which is the
version I had thought had fixed the problem previously... it
turns out I just had several very lucky spot-checks at that
time.

bextract restores the files fine, so the tape is ok.

Just FYI, I didn't mention that the database I am using to
try and restore my bacula.sql file from is a temporary database
built with bscan from the tape that I know holds the backup of my
full database.

Oh, a database built from bscan well, that is a totally different story.

This is definitely not as well tested as the main restore command from a
current catalog. Though I have carefully tested this, and it is part of
the regression testing, it is possible that there is a problem in some
case bscanning in the tape positioning information.

If there is anything else unusual in the slightest, please let me know.
It helps isolate the problem. I'll take a closer look at the bscan
code and perhaps expand the regression testing.

In the mean time, you know how to turn off the positioning code.

Best regards, Kern

Kern Sibbald wrote:
Bacula is trying to forward space to file 27 block 1, so if that is not
correct, there is something seriously fouled up in your catalog. You
didn't explain how you generated this restore file, so perhaps you were
running through code that is not well testing and there is a bug.

I generated the restore file using the CLI, choosing latest backup
for a machine, and then doing a "mark var" in the file selector, to
select the whole job, which is really just the one file,
/var/log/bacula.sql. The problem isn't specific to this particular
job... it just seems most of the time (read "whenever I am testing
and don't really care if the restore works or not") I get lucky and
bacula will be looking to forward space to an even tape file boundary
(<file>:0) and it will work fine, whereas other times (when I have
actually lost data and need the restore to work) bacula seems to
always choose a block other than the start block on the tape file
boundary, and it fails to forward space to that block.

If your tape drive passes the 1.34.x btape "test" command, there is no
reason why forward spacing will not work. I recommend you try it. You
can download the package and build it (use 1.34.1) but not install it
and just run btape (or copy it to your binary directory). If it fails
the "test" command seeking then that is where your problem lies. You
will need to correct the problem. You need to use version 1.34.x for
this as I added new seek tests.

I have run the btape test (from 1.32f-#) several times on AIT-1, AIT-2,
and AIT-3 drives, and it passes, except for a section where it
fails and recommends that I add "Backward Space Record = No", which I
do and then it passes the test completely. Despite passing this test,
I see these read failures consistently any time I try to do a restore
and bacula decides to skip to somewhere in the middle of a tape file.

I will try the 1.34.x btape test tomorrow and report back. I forgot
to mention, I am running RedHat 9, with the latest update kernel.

As for turning off seeking -- that is not something I am going to do.
However, you can force it off by running restore to the point that it
asks you to run the job. Then in another command window edit the bsr
file (restore.bsr), which will be in your working directory. In that
file, remove all occurrences of VolFile and VolBlock not changing
anything else. Then let the job start and Bacula will read from the
beginning of the tape. If you want Bacula to read to the end of the
tape, you can also remove the Count line.

I will try this too. Is there any way to tweak the restore.bsr file
to start at the beginning of the tape file it was going to skip to
anyway, without skipping to a particular block? Maybe this will be
obvious once I take a look at one.

Thanks for the response.

Greg

Hello,

OK, thanks for the additional information. In checking my regression
script, it had a bscan regression only for disk files and not for tape.
:-(

In adding a bscan tape test, I found that there is some problem in
restoring after a bscan. This does not occur when doing a restore from
the original catalog, so for the moment (i.e. in my tests), the problem
seems to be isolated to bscan (hopefully). The file positions *are*
correctly put in the catalog, but there seems to be a problem with the
block positioning as reconstructed by bscan.

Even though the problem seems to be in bscan, I recommend you do the
1.34.x btape "test" command in any case as it might show up a problem
that needs correcting.

To allow Bacula to position to a file but not block positioning, just
delete all VolBlock lines in the bsr file and leave the VolFile lines.
It should be pretty obvious.

Please send me a copy of your restore.bsr file as it is now. That way,
when you get a corrected copy of bscan, you can send me the corrected
restore.bsr file and I can verify that it has been fixed.

Best regards, Kern

On Thu, 2004-04-22 at 10:21, Gregory Brauer wrote:
Kern Sibbald wrote:
Bacula is trying to forward space to file 27 block 1, so if that is not
correct, there is something seriously fouled up in your catalog. You
didn't explain how you generated this restore file, so perhaps you were
running through code that is not well testing and there is a bug.

I generated the restore file using the CLI, choosing latest backup
for a machine, and then doing a "mark var" in the file selector, to
select the whole job, which is really just the one file,
/var/log/bacula.sql. The problem isn't specific to this particular
job... it just seems most of the time (read "whenever I am testing
and don't really care if the restore works or not") I get lucky and
bacula will be looking to forward space to an even tape file boundary
(<file>:0) and it will work fine, whereas other times (when I have
actually lost data and need the restore to work) bacula seems to
always choose a block other than the start block on the tape file
boundary, and it fails to forward space to that block.

If your tape drive passes the 1.34.x btape "test" command, there is no
reason why forward spacing will not work. I recommend you try it. You
can download the package and build it (use 1.34.1) but not install it
and just run btape (or copy it to your binary directory). If it fails
the "test" command seeking then that is where your problem lies. You
will need to correct the problem. You need to use version 1.34.x for
this as I added new seek tests.

I have run the btape test (from 1.32f-#) several times on AIT-1, AIT-2,
and AIT-3 drives, and it passes, except for a section where it
fails and recommends that I add "Backward Space Record = No", which I
do and then it passes the test completely. Despite passing this test,
I see these read failures consistently any time I try to do a restore
and bacula decides to skip to somewhere in the middle of a tape file.

I will try the 1.34.x btape test tomorrow and report back. I forgot
to mention, I am running RedHat 9, with the latest update kernel.

As for turning off seeking -- that is not something I am going to do.
However, you can force it off by running restore to the point that it
asks you to run the job. Then in another command window edit the bsr
file (restore.bsr), which will be in your working directory. In that
file, remove all occurrences of VolFile and VolBlock not changing
anything else. Then let the job start and Bacula will read from the
beginning of the tape. If you want Bacula to read to the end of the
tape, you can also remove the Count line.

I will try this too. Is there any way to tweak the restore.bsr file
to start at the beginning of the tape file it was going to skip to
anyway, without skipping to a particular block? Maybe this will be
obvious once I take a look at one.

Thanks for the response.

Greg


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users