Sebastian,
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.
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.
I don't know for sure why this could have happened but maybe the issue
wasn't disk-related. Maybe if you'd had console access to the server a
restart of the sshd service or the system itself would have cleared your
issue. If sshd was in some sort of unresponsive state that didn't outright
terminate the sshd process, maybe replacing the library files triggered a
restart of the sshd service, OR maybe it caused sshd to crash, and THEN
systemd restarted the sshd service.
I'm speculating here without reviewing the manual or using anything other
than my memory, so please verify everything I've said here with another
source before trusting it. The manual (while confusing and huge) should
have some specifics about disktocatalog verification, and about the verify
fileset option.
Robert Gerber
402-237-8692
r...@craeon.net
On Sun, Feb 16, 2025, 12:12 PM Sebastian Suchanek <bac...@suchanek.de>
wrote:
> Am 14.02.2025 um 20:25 schrieb Bill Arlofski via Bacula-users:
> > On 2/14/25 12:14 PM, Sebastian Suchanek wrote:
>
> Hi Bill!
>
> >> [...]
> >> Is there any way to do such a comparison and get a list of files where
> >> the backuped data differs from the current filesystem? (So that I can
> >> manually check which files are *not* supposed to have changed since the
> >> last backup and restore them, while leaving files that have been changed
> >> on purpose untouched.) And, if yes, how can I do that?
> >> [...]
> >
> > Sounds like you are looking for Bacula's `Verify` job with level
> `DiskToCatalog`.
> > [...]
> Thanks for your answer. It helped, however a bit indirectly. ;-)
>
> Concerning the underlying problem, given the error messages I got, I
> suspected "libcrypto.so.1.1" and/or "libssl.so.1.1" to be either
> corrupted or missing. Even before posting my original question here on
> the mailing list, I tried to restore those two files from the backup,
> but didn't have success. (I'll get back to that in a minute.)
>
> Following your hint, I created the following Bacula job and ran it:
>
> --------------------- 8< ---------------------
>
> Job {
> Name = "VerifyFiles"
> Type = Verify
> Level = DiskToCatalog
> Client = ClientInQuestion
> FileSet = "Fileset from Backup"
> Storage = LTO-Drive
> Messages = Standard
> Pool = LTO1
> }
>
> --------------------- 8< ---------------------
>
> The job resulted in showing up some unsuspicious files like logfiles as
> being different, but *none* of the two files mentioned above. However,
> it did reveal that I messed up the restore attempt I mentioned earlier
> and accidentaly restored the two files in the wrong directory. So I
> re-ran the restore operation, this time making sure that the files went
> to the correct location. Et voilà, the system is now perfectly working
> again. So obviously at least one of the two files were the root cause of
> the original problem.
> Now I'm wondering: why didn't the file(s) show up during the verify job
> run? (BTW, for the verify job run, now tapes were loaded, so obviously
> at least the "full" content of the files on the system in question were
> not checked.) What did I do wrong?
>
>
> Regards
>
> Sebastian
>
>
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> 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
