Hi, Ralf Gross wrote: > Hi, > > I need a clarification on how a VolumeToCatalog verify job works. Until now I > thought this type of verify would read the attributes from tape (Volume) and > compares it with the attributes in the db (Catalog). >
Technically true, but I believe it's the file daemon that does the comparison (it has all the decryption/md5/checksum code, etc for them) - so the data is fed to the client to compare. I run my VolumeToCatalog verify jobs with my backup server specified as the client to minimise Network impact for this reason. > But I see high network traffic between bacula-dir and bacula-fd on the client. > The level 200 debug output during a VolumeToCatalog job on the client shows > that the attributes are read from disk. > Not sure where in the following it's specifically saying it's getting it from the disk, I read it as reporting the attributes of the file on tape. (which has a path that also happens to be on the disk...) Running something like 'lsof' during a verify will confirm this for sure, however as I mentioned above my verifies run thru my backup servers FD without issue, and it sure doesn't have the 400+Gb of files that exist on the fileserver on it. > bacula-fd: > > VU0EM003: job.c:232 <dird: verify level=volume > VU0EM003: job.c:248 Executing verify command. > VU0EM003: pythonlib.c:237 No startup module. > VU0EM003: job.c:1513 bfiled>dird: 2000 OK verify > VU0EM003: job.c:1669 VolSessId=1 VolsessT=1186423732 SF=0 EF=0 > VU0EM003: job.c:1670 JobId=429 vol=DummyVolume > VU0EM003: job.c:1677 >stored: read open session = DummyVolume 1 1186423732 0 > 0 0 0 > VU0EM003: job.c:1683 bfiled<stored: 3000 OK open ticket = 1 > VU0EM003: job.c:1688 bfiled: got Ticket=1 > VU0EM003: job.c:1745 3000 OK bootstrap > VU0EM003: job.c:1702 >stored: read data 1 > VU0EM003: job.c:1745 3000 OK data > > VU0EM003: verify_vol.c:102 Got hdr: FilInx=1 Stream=1. > VU0EM003: verify_vol.c:115 Got stream data, len=77 > VU0EM003: verify_vol.c:149 Got Attr: FilInx=1 type=3 > VU0EM003: verify_vol.c:168 Attr=GgB MY5T Int B A A A QVg BAA CQ BGs+ze BF3Inr > BGNyXj A A C > VU0EM003: verify_vol.c:197 send ATTR inx=1 fname=/bin/umount > VU0EM003: verify_vol.c:207 bfiled>bdird: attribs len=84: msg=1 1 pinsug5 > /bin/umount > > > <--- > http://www.bacula.org/rel-manual/Configuring_Director.html#JobResource > VolumeToCatalog > This level causes Bacula to read the file attribute data > written to the Volume from the last Job. The file attribute data are compared > to the values saved in the Catalog database and any differences are reported. > This is similar to the Catalog level except that instead of comparing the disk > file attributes to the catalog database, the attribute data written to the > Volume is read and compared to the catalog database. Although the attribute > data including the signatures (MD5 or SHA1) are compared, the actual file data > is not compared (it is not in the catalog). > > DiskToCatalog > This level causes Bacula to read the files as they currently are > on disk, and to compare the current file attributes with the attributes saved > in the catalog from the last backup for the job specified on the VerifyJob > directive. This level differs from the Catalog level described above by the > fact that it doesn't compare against a previous Verify job but against a > previous backup. When you run this level, you must supply the verify options > on > your Include statements. Those options determine what attribute fields are > compared. > This command can be very useful if you have disk problems because it will > compare the current state of your disk against the last successful backup, > which may be several jobs. > ---> > I guess a manual update might be in order to highlight this behaviour. Cheers, Troy Daniels. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
