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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
