Hi Rob, please find my response inline. Bottom line here is for me that according to your statements I am doing it the right way - I stil have this problem.
Does someone have another idea ? (I am not going to start and say “why does the FD actually compute the checksum/hash independently of the the data being stored? I think that must be what it does, otherwise I see no explanation why the hash wouldn’t match the stored data for busy log files. Wouldn’t it be more consistent to compute the hash over the exact data that is being actually read in (or written out) for the backup volume?” There obviously must be a good reason to do it in a non-atomic way, I just can’t see what reason that would be.) ATB, JC > On 10. Nov 2023, at 17:00, Rob Gerber <r...@craeon.net> wrote: > > What level of verify job are you running (data or the other one, can't recall > name), and are you using accurate mode? Level: Data Accurate: no I am using yes on Type Backup Level Incremental, it never occurred to me to also set Accurate yes for the verify jobs. > I got verify failures in the past when I was verifying old jobs with the > verify option that isn't data, or when I verified with level=data and > accurate=yes. The message I got was similar to yours - verify failure and no > files listed as bad. > > The verify job type I can't recall is only for verifying the most recent job. > It checks file consistency and catalog information on the volume to be sure > it is the most recent. Obviously a backup that isn't the most recent in the > chain will have outdated catalog information, so that level of verify will > fail. The verify jobs are run right after the backup jobs (all backup jobs run first, then all verify jobs run). So the verify should always look into the latest backup job. > The gotcha here is that a data level verify ran with accurate=yes is > equivalent to the other type of verify - it will then check volume catalog > entries in addition to file integrity. OK I see, I do not use accurate=yes with the verify jobs and that seems to be what I really also want it to be. > For any job which you cannot be certain is the most recent job, I recommend > level=data and accurate=no. Must specify jobid and run for each job. > > Alternative is to run the other type of verify after each backup job, or at > least while that job is the newest and most recent job. > > Robert Gerber > 402-237-8692 > r...@craeon.net <mailto:r...@craeon.net> > On Fri, Nov 10, 2023, 7:41 AM Justin Case <jus7inc...@gmail.com > <mailto:jus7inc...@gmail.com>> wrote: > Hi there, > > I am doing a verify for each backup job. The verify happens no immediately > after the backup, but on the same day for sure. > > For some hosts I do have verify differences, and for FDs version 9.x I get > reports on which files that, so I am able to exclude them from the fileset. > > However, FDs version 11.x and 13.x do not report the files that are > generating the differences (and an according bug report is open for 8 months > already: > https://gitlab.bacula.org/bacula-community-edition/bacula-community/-/issues/2670 > > <https://gitlab.bacula.org/bacula-community-edition/bacula-community/-/issues/2670>). > > I would like to exclude the files that are generating differences on machines > runnid FD 11.x and 13.x, too, but I have no good idea how to determine which > files that are. (Using FD 9.x is not an option for these machines, as either > not available, not supported, or the machines have "special needs” regarding > connection directions, i.e. due to firewalls the default connection > initiation directions do not work - an this can be remediated using FD 11.x > and higher) > > Does someone have an idea how I could efficiently determine, which files are > generating the verify differences? > > ATB > JC > > _______________________________________________ > 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>
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
