[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] [Bacula-users] Storage daemons dies on restore
On Wednesday 23 July 2008 20:54:33 Andrea Venturoli wrote:
> Kern Sibbald ha scritto:
> >> However, this does not seem to solve my problem completely.
> >> Here's, from director's output, what happens:
> >> 22-Jul 18:07 xxxxx-sd JobId 5506: End of file 30 on device "DDS-5"
> >> (/dev/nsa0), Volume "Ext81"
> >> 22-Jul 18:07 xxxxx-sd JobId 5506: End of Volume at file 30 on device
> >> "DDS-5" (/dev/nsa0), Volume "Ext81"
> >> 22-Jul 18:09 xxxxx-sd JobId 5506: Warning: acquire.c:271 Wrong Volume
> >> mounted on device "DDS-5" (/dev/nsa0): Wanted Ext82 have Ext81
> >> 22-Jul 18:09 xxxxx-sd JobId 5506: Ready to read from volume "Ext81" on
> >> device "DDS-5" (/dev/nsa0).
> >> 22-Jul 18:09 xxxxx-sd JobId 5506: Forward spacing Volume "Ext81" to
> >> file:block 29:0.
> >> 22-Jul 18:15 xxxxx-fd JobId 5506: Error: Uncompression error on file ...
> >> ERR=Zlib data error
> >> The the job obviously terminates with a *** Restore Error ***
> >> Just to be clear: I was not asked to go and change the tape in the
> >> drive.
> > What Volume was it reading? Ext82 or Ext81. If it was re-reading Ext81
> > then we have a serious problem, and it is not suprising that it got the
> > uncompression error. If it was reading Ext82, which is what it wanted,
> > then it implies a problem with the drive and you should check your kernel
> > logs for SCSI errors ...
> > If this is not an autochanger, I recommend that you also apply the
> > 2.4.1-mount.patch, which you can find in the Source Forge Bacula patches
> > section.
> > Please let me know.
> This is not an autochanger, but a DDS-5/DAT72 unit, which I believe to
> have no hardware problems.
> I applied the mentioned patch, but the behaviour is still the same.
> Bacula needed "Ext81": this was already mounted in the drive and got
> read up to its end.
> Then it needed "Ext82" and should have asked for me to unmount the
> former and mount the latter.
> Alas, it did not do that: it it didn't ask or wait for any physical
> intervention, but read Ext81 again instead.
> Of course it is not surprising it got the uncompression error at this
There is clearly a problem with manual tape changes, and though this case
sounds straight forward to test, it is not easy to automate the testing and
is also the kind of problem that takes a lot of time to fix. As a
consequence, I recommend you fall back to 2.2.8 until we are sure it is
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.