Bacula-users

Re: [Bacula-users] Is a Verify Job reliable on Windows ?

2010-01-08 15:52:28
Subject: Re: [Bacula-users] Is a Verify Job reliable on Windows ?
From: Martin Simmons <martin AT lispworks DOT com>
To: bacula-users AT lists.sourceforge DOT net
Date: Fri, 8 Jan 2010 20:48:56 GMT
>>>>> On Thu, 7 Jan 2010 21:29:55 +0100, Guillaume Laurès said:
> 
> Hello fellow bacula users,
> 
> I ran on a small issue today, using a Verify Job for the first time.
> I backed up 6000+ files, around 55 Gb (a Windows whole drive). Then I  
> changed the letter of the drive, and restored all the files on a new  
> partition under the original letter. Restore went okay, except for a  
> minor a file number discrepancy (mark * "trap" ?).
> I need to wipe the original partition, and I don't remember if the  
> restore job does a SHA1 check after restore against the Catalog, so I  
> wanted to do one by myself before erasing the original data.
> Strangely enough running a Verify Job shows SHA1 differences for  
> around 50 files :-(
> The oddity is that when I check-summed an original big zip file  
> against the restored one with the file checksum utility from  
> Microsoft, I found the very same SHA1 sig for both files. Note that  
> this one is far from being equal to either one Bacula reports for this  
> zip file... Some very small text files containing SHA1/MD5 cheksums  
> where reported incorrect too, whereas they are indeed identical.
> 
> Setup :
> - server is Ubuntu 8.04.3 LTS backup, with 3.0.3 installed from  
> sources, virtualized in ESXi 3.5 (yes, I ran btape tests for several  
> hours, ran fine albeit slower than drive official speed)
> - client is Windows 2003 Server 32bit, with 3.0.3a installed from the  
> sourceforge binary
> - device is DLT-7000 with hardware compression turned off.
> 
> Fileset used to backup :
> FileSet {
>    Name = "Donnees serveur"
>    Include {
>      Options {
>        Signature = SHA1
>        Compression = GZIP6
>      }
>      File = "E:/"
>    }
> }
> 
> The one used for the Verify Job (w/ Type = Disk to Catalog) just adds  
> "Verify = pinsug1" in the options under Compression.
> 
> Any idea why Bacula thinks it's wrong whereas it's not ?

I think the checksum includes everything returned by the BackupRead function
on Windows, so possible something is slightly different in the meta data.

__Martin

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
<Prev in Thread] Current Thread [Next in Thread>