>>>>> On Mon, 22 Sep 2014 17:42:19 -0400, Dan Ragle said:
>
> >>>>>>> On Thu, 18 Sep 2014 20:44:51 -0400, Dan Ragle said:
> >>>
> >>> Think I'm missing something in my setup here, but don't know what.
> >>>
> >>> I'm running director and sd version 7.0.5 on a CentOS box, and backing
> >>> up (among others) a Windows Vista Home Premium client (which is running
> >>> 5.2.10). I'm finding that the incremental saves for the Windows client
> >>> ALWAYS include all the empty directories and zero-byte files, whether
> >>> they've changed or not.
> >>>
> >>> Looking at the bat/brestore console, I can see for example that a
> >>> certain zero-byte file is listed in every incremental backup, and that
> >>> it has the same date and Chksum in every entry.
> >>>
> >>> I'm using accurate mode backups, with accurate=pinsmc1:
> >>>
> >>> FileSet {
> >>> Name = Windows
> >>> Include {
> >>> Options {
> >>> compression=GZIP
> >>> signature=SHA1
> >>> accurate=pinsmc1
> >>> checkfilechanges=yes
> >>> }
> >>> ...
> >>>
> >>> with the includes and excludes pretty normal (a few * wildcards in the
> >>> excludes, but nothing fancy). I'm also backing up a few Linux clients
> >>> and a MacOS client with the same director and not noticing this behavior
> >>> with those (two of the linux clients are 7.0.5, and the other one as
> >>> well as the Mac client is 5.2.6).
> >>>
> >>> Anything obvious jumping out at anybody? I can provide more info if
> >>> needed, but figured I'd start with some basics.
> >>
> >> You could try setting the debug level to 100 in the client (setdebug
> >> client=Windows level=100 trace=1) to see what it is comparing.
> >>
> >> You could also look at the lstat column for those files in the file table
> >> to
> >> see what differs (see .bvfs_decode_lstat at
> >> http://www.bacula.org/7.0.x-manuals/en/main/New_Features_in_7_0_0.html#SECTION003129000000000000000).
> >>
> >> __Martin
> >>
> >
> > Thanks, Martin. I'll try the setdebug on tonight's backup and see what
> > comes of it.
> >
> > In the meantime, I'm not sure if the .bvfs commands will shed any new
> > light on the issue, since the file simply shows the same lstat on each
> > backup:
> >
> > * .bvfs_versions client=joshua-fd pathid=19570 fnid=36065 jobid=76
> > 19570 36065 503052 16 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Full_0016 0
> > 19570 36065 561670 22 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Inc_0022 0
> > 19570 36065 587296 28 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Inc_0028 0
> > 19570 36065 590294 34 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Inc_0034 0
> > 19570 36065 595122 40 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Inc_0040 0
> > 19570 36065 605010 46 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Inc_0046 0
> > 19570 36065 606812 52 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Inc_0052 0
> > 19570 36065 609242 60 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Inc_0058 0
> > 19570 36065 614435 66 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Inc_0063 0
> > 19570 36065 615289 70 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Inc_0067 0
> > 19570 36065 617073 76 A A IH/ B A A A A A A BJ7e3Q BJ7e3Q
> > BJ7e3Q A A MwUJerN1ZDJwRrMXpKcXmVly9OL8 Inc_0073 0
> >
> > * bvfs_decode_lstat lstat="A A IH/ B A A A A A A BJ7e3Q BJ7e3Q BJ7e3Q A A"
> > st_nlink=1
> > st_mode=33279
> > st_uid=0
> > st_gid=0
> > st_size=0
> > st_blocks=0
> > st_ino=0
> > st_ctime=1240329680
> > st_mtime=1240329680
> > st_mtime=1240329680
> > st_dev=0
> > LinkFI=0
> >
>
> Ok, so presumably it's the SHA1 chksum that it doesn't like:
>
> joshua-fd: filed/accurate.c:236-0 add
> fname=<C:/Users/Dan/Perl/from_linux/comments/block/block_ip.txt> lstat=A
> A IH/ B A A A A A A BJ7e3Q BJ7e3Q BJ7e3Q A A M delta_seq=0
> chksum=wUJerN1ZDJwRrMXpKcXmVly9OL8
>
> ...
>
> joshua-fd: filed/accurate.c:82-0 lookup
> <C:/Users/Dan/Perl/from_linux/comments/block/block_ip.txt> ok
> joshua-fd: filed/verify.c:297-0 === digest_file
> joshua-fd: filed/accurate.c:453-0
> C:/Users/Dan/Perl/from_linux/comments/block/block_ip.txt SHA1
> chksum diff. Cat: wUJerN1ZDJwRrMXpKcXmVly9OL8 File:
> 2jmj7l5rSw0yVb/vlWAYkK/YBwk
> joshua-fd: findlib/bfile.c:529-0 === NO plugin
> joshua-fd: findlib/bfile.c:621-0 Read
> CreateFileW=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy21\Users\Dan\Perl\from_linux\comments\block\block_ip.txt
>
> So I guess I'll just try it with MD5's for that client on my next
> scheduled full backup and see what happens after that.
It looks like a bug: the chksum in the catalog is based on the data returned
by the Win32 function BackupRead, but the accurate code doesn't call this when
st_size=0, so it will always be different.
See also http://bugs.bacula.org/view.php?id=1804.
__Martin
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
