Bind-mount confuses Timeshift; cannot find device root

[Redsandro]

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

System:

• Linux Distribution Name and Version: Linux Mint 19.2
• Desktop: Cinnamon
• Application Version v19.01 / 19.01.0.2+tina