Troy Daniels schrieb: > > 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.
Ok, that makes sense now. I found verify.c and verify_vol.c in src/filed. > I run my VolumeToCatalog verify jobs with my backup server specified as > the client to minimise Network impact for this reason. So the Client option doesn't have to be the same as the client name that was used for the backup? I've never thought about this. > > 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...) I interpret the traffic to the fd wrong, given the fact that the verify code is there. > 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. Yes, that would make things clearer. Now I've to find out what was going wrong with the two verify jobs of my full backups from last weekend (mail from yesterday). The inc/diff verify jobs before were ok and the verify job of the inc backup from this night too. Is there a way to rerun the verify job of the full backup (sunday) after the next verify job (last night)? 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
