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).
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. 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. ---> If VolumeToCatalog reads the attributes from disk, where is the difference to DiskToCatalog? Ralf ------------------------------------------------------------------------- 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
