Timeshift mounts unclean partitions to back up onto? And observations.

[kyrian666]

Already filed at Ubuntu, but forgot to check for upstream code.

https://bugs.launchpad.net/ubuntu/+source/timeshift/+bug/1953409

So, I had an absolute horror of a time which badly broke my system in a number of ways. Tracing things back it appears to originate with Timeshift. Although I can't readily say which version because things were that broken (I might be able to dig it up if essential).

The crux of it seems to be that timeshift seeks to mount a filesystem to perform backups to, even if it is corrupted. This causes all sorts of "fun things" to happen.

To which I have the following observations/suggestions:

• Timeshift should not mount and attempt to back up to corrupted filesystems.
• Timeshift should ensure that its behaviour does not cause updatedb to be run on the filesystem it has mounted. Perhaps by a filter being added to updatedb, I don't know?
• Because I think mounting filesystems silently like that is the unintuitive behaviour that lead to it. Updatedb is just doing what it says on the tin.
  /var/log/kern.log:Jan 10 20:47:09 marius kernel: [ 363.671082] EXT4-fs error (device dm-4): ext4_lookup:1703: inode #7086099: comm updatedb.mlocat: deleted inode referenced: 7119161
  /var/log/kern.log.1:Jan 9 14:00:02 marius kernel: [ 379.513273] EXT4-fs error (device dm-4): ext4_lookup:1703: inode #5505033: comm timeshift: deleted inode referenced: 9178184
• Also, use of corrupted filesystems exacerbates corruption, furthermore (I think?) the use of hard links by timeshift for space saving makes the fsck problems to fix it again exponentially worse due to 'duplicate reference' errors etc.

And the following indirectly related suggestions for documentation etc:

• Shouldn't documentation be abundandly clear timeshift WILL NOT guard against hardware failures? (RTFM?).
• Lack of NFS support put me in this situation. Understandable but what remote protocols (if any) Will work? iSCSI? Some documentation on that would be good?
• An rsync type backup to a subdirectory should not preclude the partition from being used for anything else, but timeshift's behaviour appears to indicate it does preclude that?
• I find timeshift's (IIRC) default exclusion of /home frankly bizarre and unintuitive? Perhaps there should be an install-time dialogue to ask if you want this to happen?

PS. Apologies this is a bit rough and ready (and indeed probably warrants multiple bugs), but I wanted to finally get this bug filed today as I'd been dealing with the partition that was victim to this issue again (thankfully the fsck didn't take as long as I feared to get through manually, but data loss is still a possibility, TBC). As you can tell from the timestamps below it's already taken me a long time to get to it, and I'm only doing it now way past bed time when already tired.

PPS. The partition that timeshift was backing up to at the time was, IIRC, not in use for anything else and not mounted by any other means, which is why this points to timeshift having mounted it, and hence updatedb having tried to traverse it, and further corrupted it, or at very least complained it was mounted and was corrupt.