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
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
