>>>>>>> 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. Cheers, Dan ------------------------------------------------------------------------------ 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