Menu
▾
▴
Re: [Bacula-users] DDS-4 restore error
|
From: Kern S. <ke...@si...> - 2004-02-21 23:09:27
|
Hello Jason,
Thanks sounds like enough info to keep me busy for the time being.
Thanks, I'll work on fixing it.
Best regards, Kern
On Sat, 2004-02-21 at 22:28, JML wrote:
> Kern,
>
> mt status and tapeinfo output are attached. Default blocksize was
> originally 512 bytes. I ran the following test on my machine:
>
> - set defblksize to 512
> - started bacula, labelled tape, ran job
> - job completes with the following in log
> SD termination status: OK
> Termination: Backup OK
> - restore attempts with blocksize set to 0 or 512 result in the familiar
> "Volume data error! Wanted block-id BB02, got . Buffer discarded."
>
> This is redhat 9 with a 2.4.20 kernel. I can also send you the large debug
> logs for the director and storage daemon off-list if you'ld like em.
>
> thanks,
>
> Jason
>
>
> On Sat, 21 Feb 2004, Kern Sibbald wrote:
>
> > On Fri, 2004-02-20 at 20:05, JML wrote:
> > > sorry, my mistake- a default block size was still set. It might be
> > > clearer, however, if that tip moved from section 17.7 to 17.6 in the docs.
> >
> > Good idea. I copied it so it appears in both places.
> >
> > >
> > > By the way, should I be concerned that bacula wrote to tape without
> > > reporting errors in spite of the incorrect block size?
> >
> > Yes, Bacula should report all errors. If it is not, and I don't see how
> > that can happen, there is a serious "bug" in Bacula. Please give me the
> > details so that I can reproduce it here (I imagine it is your default
> > block size, but I'd like to have the details anyway).
> >
> > Best regards, Kern
> >
> > > In other words, any
> > > chance that it would write a tape that was later unreadable, even if the
> > > setting were corrected after the fact? I'm thinking of the sysadmin who
> > > forgets to script the mt commands for startup, or the newbie who never
> > > tests restores until they're needed. :)
> > >
> > > regards,
> > >
> > > Jason
> > >
> > >
> > > On Thu, 19 Feb 2004, Kern Sibbald wrote:
> > >
> > > > Hello,
> > > >
> > > > Before running the btape "test", run the mt command recommended in the
> > > > manual that sets your SCSI driver parameters.
> > > >
> > > > Then please send me the full output from the latest btape 1.33.3-16Feb04
> > > > "test" command, and I'll look at it. Also please send me your
> > > > bacula-sd.conf (I know you sent it before, but it is buried somewhere
> > > > long ago ...).
> > > >
> > > > Best regards, Kern
> > > >
> > > > On Wed, 2004-02-18 at 22:19, JML wrote:
> > > > > Hi Kern,
> > > > >
> > > > > a quick update since my previous post below- the new btape in 1.33.3
> > > > > reports the same problem with our DDS-4. Any thoughts on what I should try
> > > > > next?
> > > > >
> > > > > thanks,
> > > > >
> > > > > Jason
> > > > >
> > > > >
> > > > > On Fri, 13 Feb 2004, JML wrote:
> > > > >
> > > > > > Yes, the problem seems odd for so mainstream a drive as this. I followed
> > > > > > your suggestions on tape cleaning and alternate tapes, but they check out
> > > > > > okay. I can even write and read tar archives from the device with no
> > > > > > problem.
> > > > > >
> > > > > > In case they offer any clues, I've attached the results from tapeinfo, mt
> > > > > > status, and the CVS version btape, which does catch an error now BTW. It
> > > > > > also seems odd that tapeinfo reports "Medium Type: Not Loaded" when it is
> > > > > > loaded.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > Jason
> > > > > >
> > > > > >
> > > > > > On Fri, 13 Feb 2004, Kern Sibbald wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > Fast block rejection is still turned off in 1.33. In fact, it should
> > > > > > > cause problems only if using multiple concurrent jobs, so I doubt it is
> > > > > > > the problem here. With a Sony DDS-4 you should be having no problems.
> > > > > > > I'd recommend that you remove the:
> > > > > > >
> > > > > > > Fast Forward Space File = no
> > > > > > > Backward Space Record = No
> > > > > > >
> > > > > > > as they just cripple your excellent drive. It may be that you have a
> > > > > > > bad tape, or a dirty drive, so I would recommend you run a cleaning tape
> > > > > > > at least once, then as I suggested in a previous email, download the
> > > > > > > latest CVS code and rebuild btape. It now has a tape block read back
> > > > > > > test as well as a positioning test, so maybe something will show up.
> > > > > > >
> > > > > > > Best regards, Kern
> > > > > > >
> > > > > > >
> > > > > > > On Fri, 2004-02-13 at 05:35, JML wrote:
> > > > > > > > Hello again,
> > > > > > > >
> > > > > > > > I have a separate issue with restoring from a DDS-4 changer (specifically
> > > > > > > > a Sony TSL-S11000). System is RedHat 9. Changer ops and backup work fine,
> > > > > > > > then I get the following during a restore job:
> > > > > > > >
> > > > > > > > nail-sd: Ready to read from volume "foo-06" on device /dev/nst0.
> > > > > > > > nail-sd: Forward spacing to file:block 0:1.
> > > > > > > > nail-sd: RestoreFiles.2004-02-12_16.36.23 Error: block.c:248 Expected
> > > > > > > > block-id BB01 or BB02, got . Buffer discarded.
> > > > > > > > nail-sd: RestoreFiles.2004-02-12_16.36.23 Error: block.c:248 Expected
> > > > > > > > block-id BB01 or BB02, got . Buffer discarded.
> > > > > > > > nail-sd: RestoreFiles.2004-02-12_16.36.23 Error: Read error on Record
> > > > > > > > Header /dev/nst0: Success
> > > > > > > > nail-fd: RestoreFiles.2004-02-12_16.36.23 Error: bnet.c:374 Write error
> > > > > > > > sending to Storage daemon:nail:9103: ERR=Broken pipe
> > > > > > > > nail-dir: RestoreFiles.2004-02-12_16.36.23 Error: Bacula 1.33 (30Jan04):
> > > > > > > > 12-Feb-2004 16:38
> > > > > > > > JobId: 35
> > > > > > > > Job: RestoreFiles.2004-02-12_16.36.23
> > > > > > > > Client: nail-fd
> > > > > > > > Start time: 12-Feb-2004 16:36
> > > > > > > > End time: 12-Feb-2004 16:38
> > > > > > > > Files Restored: 0
> > > > > > > > Bytes Restored: 0
> > > > > > > > Rate: 0.0 KB/s
> > > > > > > > FD Errors: 1
> > > > > > > > FD termination status: Error
> > > > > > > > SD termination status: Error
> > > > > > > > Termination: *** Restore Error ***
> > > > > > > >
> > > > > > > > Seems to make no difference whether I "mark *" or only restore a subset of
> > > > > > > > the job. I also followed the instructions pertaining to mt stoptions.
> > > > > > > >
> > > > > > > > btape's test gives a clean bill of health on this drive, though after
> > > > > > > > advising that I set the last two options in my Device declaration below:
> > > > > > > >
> > > > > > > > Device {
> > > > > > > > Name = DDS-4 #
> > > > > > > > Media Type = DDS-4
> > > > > > > > Archive Device = /dev/nst0
> > > > > > > > Autochanger = Yes
> > > > > > > > Changer Command = "/usr/local/bacula/etc/mtx-changer %c %o %S %a"
> > > > > > > > Changer Device = /dev/sg1
> > > > > > > > LabelMedia = No
> > > > > > > > AutomaticMount = yes; # when device opened, read it
> > > > > > > > AlwaysOpen = yes;
> > > > > > > > Fast Forward Space File = no
> > > > > > > > Backward Space Record = No
> > > > > > > > }
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > All of this sounds similar to a thread from last week when the advice was
> > > > > > > > to upgrade to 1.32f-4, which had fast block rejection disabled. Is this
> > > > > > > > disabled already in the 1.33 beta, or is there an easy way to do so?
> > > > > > > >
> > > > > > > > best,
> > > > > > > >
> > > > > > > > Jason
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -------------------------------------------------------
> > > > > > > > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > > > > > > > Build and deploy apps & Web services for Linux with
> > > > > > > > a free DVD software kit from IBM. Click Now!
> > > > > > > > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > > > > > > > _______________________________________________
> > > > > > > > Bacula-users mailing list
> > > > > > > > Bac...@li...
> > > > > > > > https://lists.sourceforge.net/lists/listinfo/bacula-users
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
|