I have what is admittedly probably a rather obscure corner case: backing up from a mounted Time Machine backup on Linux. (I do this to make an off-site backup without having to run restic on the individual machines.) This uses the fuse filesystem tmfs on top of sparsebundlefs. Rather surprisingly, it works. However, I noticed that restic was always rereading all the data (rather slowly, due to the many layers of abstraction!), even when nothing had changed since the parent snapshot.
A bit of further digging showed that this is because tmfs returns different inode numbers each time the filesystem is mounted, which causes IsNewer in internal/restic.go to return True. Removing the node.Inode != uint64(inode) check in that function solves the problem: backups are now quick when nothing has changed.
I’m concerned, however, that this might cause problems when restoring, as restic might erroneously treat some different files as hard links, if their inode numbers happen to have collided.
Is there a better way to work around this issue? (Other than fixing tmfs to produce stable inode numbers, which is beyond my current abilities.)
Not sure about the thing you’re really asking here, but I just have to chime in that your entire backup infrastructure is depending on TM doing its job correctly. I would highly recommend against that, and instead recommend that you run restic on each of those machines, so that you have two different software backing up your data.
If there’s an issue with TM, and that’s something you are in many cases unlikely to notice, your only backup of the data will contain the errors.
That may indeed happen, I’m not sure how well restic handles the case where two different files have the same inode. I’m also not sure if you can get into this situation, even with unstable inodes: You’re restoring one particular snapshot, which was the state of the system at one point in time. And usually the fuse fs implementation needs to make sure that within one mounted fs there are no colliding inodes. So there should be no colliding inodes within one snapshot in the repo.
Don’t use restore, but use the restic fuse mount to copy files out. For one, the program doing the copying would need to restore hard links (which e.g. rsync doesn’t do by default), so you’re in control. And second, for the fuse mount (which needs to show several snapshots at once) the inodes exposed in the fs do not correspond to the inodes the files had at backup time.
Thank you. I’m aware that this introduces a single point of failure, and agree that it would be better to have two independent backups. However, there’s a trade-off with convenience which I think makes this approach worthwhile for these particular machines. (Most of the important data eventually ends up elsewhere, where it will be backed up directly by restic.)
Thank you Alexander. Good point about uniqueness of inodes within a snapshot. I’ll check that this really is the case here! Also, thanks for the restore-via-mount hint.