Bacula-users

Re: [Bacula-users] restoring big files spanning multiple volumes?

2009-03-18 14:39:52
Subject: Re: [Bacula-users] restoring big files spanning multiple volumes?
From: Martin Simmons <martin AT lispworks DOT com>
To: palme AT kapott DOT org
Date: Wed, 18 Mar 2009 18:29:48 GMT
>>>>> On Wed, 18 Mar 2009 16:35:03 +0100, Stefan Palme said:
> 
> Hi, 
> 
> On Wed, 2009-03-18 at 09:24 -0400, John Drescher wrote:
> > > I have a setup where I backup some files into a "File" storage
> > > (i.e. not on tape). I have set the maximum volume size to something
> > > around 2 GB to avoid some problems when transfering them later via
> > > FTP, storing them on other file systems etc.
> > >
> > > One of the files to be backuped has around 3.5 GB. In all my backups
> > > this file (obviously) spans two volumes.
> > >
> > That is generally not a problem. I have restored dozens of times in
> > this situation without ever seeing this error.
> 
> So did I, but I thought maybe the combination "one file backed up on
> multiple volumes" and "compression on" may cause the problem.

It is somewhat unlikely, because compression is done by the FD but the
checksums are computed (and checked) by the SD.

Do you run multiple concurrent jobs?


> But maybe one can explain what exactly those error messages mean?

Each Bacula block contains a checksum of the other bytes in the block,
computed just before the block is written to the media.  Bacula computes the
checksum again from the bytes just after it reads them from the media and the
error means that it got a different checksum.


> Especially I am interested in the fact that the error message 
> "Block checksum mismatch in block=5105 len=64512..." prints two
> different values for "block" - block=48729 when doing restore from
> the bacula console, block=5105 when using bextract...
> 
> Maybe it is also interesting, that the checksum error occurs on the
> FIRST volume (-0146) when using bextract, but on the SECOND
> volume (-0147) when using the bacula console (at least this is my
> interpretation of the error messages).

Yes, it is strange, because restore and bextract use the same code to read the
blocks.

Does restore always get the same block and incorrect checksum for that job?
Likewise for bextract?

Does bls -j also give errors?  What about bls -k?


> A question about this one: "Error: attribs.c:421 File size of restored
> file ./var/lib/postgresql/backup/database.dump not correct. Original
> 3682990713, restored 309133312.".
> Why not all data has been restored? Is it because the restore process
> has been canceled because of the previous checksum error? Or is there
> not enough data to restore everything?

Yes, if some data is missing then the file will not be restored correctly.
The problem will be worse for compressed backups.

__Martin

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users