View Issue Details

IDProjectCategoryView StatusLast Update
0000882bareos-coredirectorpublic2023-12-13 14:09
ReporterInt Assigned Tobruno-at-bareos  
Status closedResolutionwon't fix 
Product Version17.2.4-rc1 
Summary0000882: Verify Job is run with level Full instead of VolumeToCatalog
DescriptionWhen running a scheduled verify job it is executed with level Full although it is configured with level VolumeToCatalog in both job and jobdef definitions.

Because of that the job fail with error:

07-Dec 23:59 bareos-dir JobId 166: Fatal error: verify.c:86 Unimplemented Verify level 70(F)
07-Dec 23:59 bareos-dir JobId 166: Error: Bareos bareos-dir 17.2.4 (21Sep17):
  Build: x86_64-redhat-linux-gnu redhat CentOS Linux release 7.4.1708 (Core)
  JobId: 166
  Job: backup_verify-igms08-fd.2017-12-07_23.59.00_24
  FileSet: LinuxAll
  Verify Level: Full
  Client: igms07-fd
  Verify JobId: 0
  Verify Job: backup-igms08-fd
  Start time: 07-Dec-2017 23:59:00
  End time: 07-Dec-2017 23:59:00
  Files Examined: 0
  Non-fatal FD errors: 1
  FD termination status:
  Termination: *** Verify Error ***

When running the verify job manually through webui "Jobs->Run" it is executed correctly with level VolumeToCatalog

Additional InformationJob {
  Name = "backup_verify-igms08-fd"
  Pool = Backup_Intego
  Client = "igms07-fd" #use the client on the backup server itself for maximum performance
  FileSet = "LinuxAll"
  Schedule = "WeeklyCycleAfterBackup"
  Level = VolumeToCatalog
  JobDefs = "DefaultVerifyJobSettings"

  Verify Job = "backup-igms08-fd"

JobDefs {
  Name = "DefaultVerifyJobSettings"
  Type = Verify
  Level = VolumeToCatalog
  Storage = Tape
  Messages = Standard
  Priority = 12
  Accurate = yes

TagsNo tags attached.




2017-12-11 11:22

reporter   ~0002836

This happened because the job level was overwritten by the schedule.

Perhaps it would make sense to ignore job level overides with level full/differential/incremental for verify jobs, because these levels don't make sense in combination with a verfiy job?


2023-12-13 14:09

manager   ~0005633

You may propose a PR to modify the behavior, but it has few chances to be successful as the "supreme" order is the command run.

Issue History

Date Modified Username Field Change
2017-12-08 09:21 Int New Issue
2017-12-11 11:22 Int Note Added: 0002836
2023-12-13 14:09 bruno-at-bareos Assigned To => bruno-at-bareos
2023-12-13 14:09 bruno-at-bareos Status new => closed
2023-12-13 14:09 bruno-at-bareos Resolution open => won't fix
2023-12-13 14:09 bruno-at-bareos Note Added: 0005633