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.
> > Any ideas how to restore this file? This is a kind of desaster
> > situation because at the moment I NEED this backup. So of course
> > it would be nice to know how to avoid this problem for future backups.
> >
> This is not normal behavior. Some how the volume big-0147 got
> corrupted (bacula bug? / kernel bug? / bad hardware? / other software?
> / unclean shutdown?) . I am not sure a corrupted volume is
> recoverable, especially one with compression on.
Maybe the volume got corrupted. But even if I try to restore an older
backup the same happens. I do a full backup once a week and an
daily incremental backup. The database dump file in question will be
backed up every day by the incremental backup.
None of those backups for the last 30 days works.
> > But I would also be lucky about a way how to completely restore
> > this file (I guess all relevant data is available in the backups files,
> > but the restore process does not handle it well).
> >
> > Any help possible?
> > Thanks and regards
> >
> Do you have a bootstrap file for the job?
I guess not. I only keep the bootstrap files of the most recent job.
> BTW, are you using a 32 bit OS? I have not had bacula on 32 bits since
> late 2004 at work. However I did have 32 bits at home till 2005. What
> version of bacula are you using? Are you using concurrent jobs?
Version: 2.4.3 (10 October 2008) x86_64-pc-linux-gnu gentoo
So no 32 bit OS. And not concurrent jobs. At least I did not modify
any default behaviour, so "grep -i concurrent /etc/bacula/bacula*.conf"
results in no output. I guess the default behaviour is to run
only one single job.
But maybe one can explain what exactly those error messages mean?
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).
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?
Thanks and regards
-stefan-
------------------------------------------------------------------------------
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
|
