Johannes Meixner

Problem summary as far as I see it: What should ReaR do when UUIDs in restored files like /etc/fstab do not exist on the recreated system? Cf. https://github.com/rear/rear/issues/2785#issuecomment-1091773765 (excerpt): ```...

Whether or not there is a cron job doesn't actually matter here i.e. it doesn't matter how "rear mkrescue" got launched. The issue is that there can be inconsistencies between...

I got distracted by other things and now weekend is almost there... My primary intent is not to let ReaR automatically fix such inconsistencies but to only detect them which...

I think it is no bug in ReaR that things in the recovery system must be consistent with what there is in the backup. In some cases we may avoid...

I am currently working on some initial simple attempt to at least be able to detect when something went wrong or looks wrong with UUIDs. An initial pull request will...

@pcahyna yes, we must make it very clear to the user that he is responsible to keep his backup in sync with his ReaR recovery system and that he can...

I used the term "external backup" in a sloppy way when I basically meant that the backup is made outside of ReaR. Regarding TSM backup via "rear mkbackup": I guess...

With https://github.com/rear/rear/pull/2795 merged we have code that might be also used to solve this issue here. While https://github.com/rear/rear/pull/2795 detects when restored basic system files do not match the recreated system...

Yes, this issue will (of course) not be done for the (already delayed) ReaR 2.7. After the ReaR 2.7 release I intend to have a look - as time permits.

Regarding how to do a basic check that a backup via "rear mkbackuponly" is consistent with a "rear mkrescue" that had been done before: I noticed right now during "rear...