Bind-mount confuses Timeshift; cannot find device root (original) (raw)

Describe the bug

Timeshift 'lost' my snapshots by looking in the wrong location.

Backups should be stored at LVM /dev/mapper/mint--vg-data which is mounted in fstab at /media/redsandro. This is the only 1 TB VG, easily identifiable in Timeshift as /dev/dm-5.

This config used to work correctly. However, for some reason, an unrelated and pre-existing bind-mount from /var/www to dm-5/luks-www has become the target for timeshift to write to.

In stead of reading/writing dm-5/timeshift, Timeshift now reads/writes from dm-5/luks-www/timeshift (bind-mounted to /var/www) as you can see in the logs. Here is a diff from before and after traveling. Some identical lines removed for brevity:

-2019-11-30 +2019-12-19

(...) SnapshotRepo: unlock_and_mount_devices() device=/dev/dm-5 SnapshotRepo: unlock_and_mount_device() device=/dev/dm-5 Device: get_mounted_filesystems_using_mtab(): 6 SnapshotRepo: load_snapshots() -loading snapshots from '/media/redsandro/timeshift/snapshots': 9 found SnapshotRepo: unlock_and_mount_device(): exit Selected snapshot device: /dev/dm-5 Free space: 1.2 TB SnapshotRepo: check_status() SnapshotRepo: available() is_available: ok SnapshotRepo: has_snapshots() SnapshotRepo: has_space() Device: get_disk_space_using_df(): 1 (...) +no snapshots +mkdir: /var/www/timeshift/snapshots Daily snapshots are enabled -Last daily snapshot is 16 hours old +Last daily snapshot not found (...) -SnapshotRepo: load_snapshots() -loading snapshots from '/media/redsandro/timeshift/snapshots': 9 found +Creating new snapshot...(RSYNC) +Saving to device: /dev/dm-5, mounted at path: /var/www

The issue boils down to this: Under certain circumstances, Timeshift wrongly resolves the root of the target filesystem to a subdirectory of that file system.

A workaround is to stop using bind-mounts, but I have a whole lot of them for development purposes and they are a legal Linux construct, so I'll stop using Timeshift for now in stead.

Additionally, because the wrongly identified target is now also part of the source in the form of a bind-mount from /var/www, the source data is infinite and the target will fill up indefinitely. This is a different issue however. A workaround is to blacklist /var/www, but I would like to include it in my backup.

Screenshots

image

System: