Yes, the documentation seems to indicate that the "Verify" mode was mainly designed to verify integrity on tape rather than on disk. I can see the point for "VolumeToCatalog" that only the last backup is used. For "DiskToCatalog" I may want to be able to compare with a less recent backup and also want to include JobIDs from Full, Differential and Incremental backups in the run.
This is why I think a feature request is the best choice. A "verify" command could handle "DiskToCatalog", "VolumeToCatalog" and "Catalog" levels although the main use case would be "DiskToCatalog". Holger > Looking at the docs > (https://www.bacula.org/9.6.x-manuals/en/main/Configuring_Director.html#SECTION002130000000000000000 > <https://www.bacula.org/9.6.x-manuals/en/main/Configuring_Director.html#SECTION002130000000000000000>), > it says that DiskToCatalog only operates on the last backup: > > *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 *VolumeToCatalog* 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. > > Note, the current implementation (1.32c) does not identify files > that have been deleted. > > > On Wed, Dec 2, 2020 at 3:38 PM Holger Jakob > <ja...@dsi.uni-stuttgart.de <mailto:ja...@dsi.uni-stuttgart.de>> wrote: > > Having seen no response so far I guess Verify jobs are not used > very often. Is this behavior of Verify just a bug or result of an > incomplete implementation? Or should this be turned into a feature > request? I really think a new "verify" command similar to the > "restore" command may be the right approach. > > I am stuck with a data recovery task that requires me to do an > data integrity scan rather than a restore (no access to tapes). > "DiskToCatalog" is the right choice for me but I need more than > just a diff against the last run job. > > Holger > >> Hi all, >> >> I am trying to run a verify that compares the md5 checksums in the >> catalog with the files on disk. Although I am using DiskToCatalog, the >> verify job seems to only compare with the last backup job. If that last >> job was not a Full backup then, apparently, only the changed files are >> verified. I need bacula to track back to the last Full backup and apply >> the Differential and Incremental jobs up to the current date. This is >> what is usually done when you run a Restore job with the "restore" >> command for a certain date. Is something like this supported for a >> Verify job, or am I missing something in my Job definition? >> >> Job { >> Name = "HOST_BACKUP_VERIFY" >> Type = Verify >> Level = DiskToCatalog >> Client = host-fd >> Verify Job = "HOST_BACKUP" >> FileSet = "HOST_DATA" >> Max Start Delay = 12h >> Storage = PV-124T >> Messages = Standard >> Pool = Default >> Full Backup Pool = Full >> Priority = 10 >> } >> >> list jobs shows me: >> >> | 35412 | HOST_BACKUP | 2020-11-23 01:55:03 | B | I >> | 0 | 0 | A | >> | 35387 | HOST_BACKUP_VERIFY | 2020-11-20 20:10:29 | V | d | >> 21791 | 7772025165 | D | >> | 35388 | HOST_BACKUP | 2020-11-20 20:19:11 | B | I >> | 47 | 45156890 | T | >> | 35389 | HOST_BACKUP_VERIFY | 2020-11-20 20:34:11 | V | d | >> 21791 | 7772090423 | D | >> | 35390 | HOST_BACKUP_VERIFY | 2020-11-20 20:46:23 | V | d | >> 21791 | 7772127788 | D | >> | 35391 | HOST_BACKUP | 2020-11-20 20:55:37 | B | F | >> 21712 | 7772157306 | T | >> | 35392 | HOST_BACKUP_VERIFY | 2020-11-20 21:09:17 | V | d | >> 21791 | 7772194578 | D | >> >> Only Job 35392 is showing me the few files that got changed. 35387 was >> basically returning the whole file structure claiming that those are all >> new files. >> >> Any suggestion how to use Verify? >> >> Or is there a method to extract the checksums from the catalog DB? >> >> Thanks >> Holger > > -- > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > <mailto:Bacula-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/bacula-users > <https://lists.sourceforge.net/lists/listinfo/bacula-users> > > > > -- > Jonathan Hankins > > Homewood City Schools > > W: 205-877-4548 > > This e-mail is intended only for the recipient and may contain confidential > or proprietary information. If you are not the intended recipient, the > review, distribution, duplication or retention of this message and its > attachments is prohibited. Please notify the sender of this error immediately > by reply e-mail, and permanently delete this message and its attachments in > any form in which they may have been preserved. --
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
