Re: Compare backup with actual data on client

Am 16.02.2025 um 19:36 schrieb Rob Gerber:

Hi Rob!

> Verify jobs of type DiskToCatalog don't need any volumes or tapes. They 
> only reference the catalog for file dates/times/sizes /hashes and check 
> the information found against the filesystem. Please note that the means 
> of this verification might be configurable with a fileset option, so 
> perhaps the statistics verified could be different from what I state 
> above depending on your configuration or on the defaults.It is possible 
> that verify job could have checked just sizes and dates, and filesystem 
> level corruption wouldn't have changed either of those. You would need 
> to check the manual to determine the defaults for the verify job, and 
> inspect your fileset resource in the bacula-dir.conf file to see if any 
> special verify option was set.

So far, I haven't defined any verify options in my fileset definitions 
whatsoever. I guess, I should change that in order to be better prepared 
for similar incidents in the future?

> If I understand correctly, the original copies of the library files you 
> restored verified as good during the DiskToCatalog job, yet on restoring 
> them to the correct location your problem cleared and you were able to 
> ssh into the system again.
 > [...]

Yes, that's correct.
However, that not the only symptom I experienced. On the system there is 
also PHP script which is run by a cron job every 10 minutes and that 
script gave me the error message "[...]libcrypto.so.1.1: undefined 
symbol: , version OPENSSL_1_1_0". Which, BTW, was the information that 
pushed me into the ultimately correct direction. And of course also this 
error message went away once I restored the two library files in the 
correct location.



Regards

Sebastian