Should send snapshots to folder, not partition

[DonEdwards]

At present, timeshift apparently must be configured to send backups to a partition, by device name, e.g. /dev/sda4

man mount mentions that device names are unstable, particularly for removable media, and that other approaches should be used. (I use the LABEL= option a lot.) Offsite backup, of course, requires removable media.

I am currently experimenting with using a symlink - /dev/sda4 (/home) has a symlink to /mnt/backups/timeshift. (/mnt/backups is currently /dev/sdc2, which is on an SSD connected via USB.) This appears to work BUT... very slowly. Perhaps aggravated by the fact that /dev/sda4 is an ext4 partition while /mnt/backups is a btrfs partition and the timeshift folder there has compression turned on. The snapshot currently in progress is estimated to complete in another 878 hours... yes I really mean over a month.

I've also tried keeping minimal snapshots on /dev/sda4 and backing them up to the removable device using backintime... but that seems like redundant processing and inherently slower than the symlink approach should be. (Considerably faster than it appears to be.)

[ACR-Jeff]

It has always been recommended to backup to a separate drive then a system drive. The reason is due to if your system drive crashes, data lose or boot issues, You won't lose your snapshot and will still have access to a snapshot on a separate drive. Giving you the ability to restore the snapshot their after any system issues.

[Mr-Dead]

Hello.

I second OP's feature request, which, I believe, can be expounded out into multiple discussions.

First, the apparent limitation of destination. Timeshift has traditionally offered only block device as a destination. Whether or not this limitation is technical is beyond my scope of knowledge, so correct me please. However, it would be convenient for users such as OP if Timeshift offered a more robust filer to set directories as destinations.

Second, OP makes a good argument against Timeshift's current usage of device names. They are not stable nor persistent, especially when users perform snapshots onto external media, as recommended.

I administer an LVM over LUKS data drive that houses a backup partition. The Disk column, which contains the radio button, uses a naming scheme that is not persistent. The first screenshot illustrates normal conditions.

This second screenshot illustrates conditions where I unlocked my thumbdrive prior to unlocking my data drive.

The predominance of this naming scheme is confusing, because Timeshift still mounts the correct partition regardless of its "dm" designation. This means Timeshift probably already relies on Label and/or UUID to identify the correct partition. If true, it is curious to me why the nonpersistent designators dominate the Label and exclude the UUID altogether. Both cryptsetup, man -P'less -p LUKS\ EXTENSION' cryptsetup, and lvm, man -P'less -p VALID\ NAMES' lvm, have recommended naming schemes that should align with both users' expectations and software design. A setup like the NAME column for lsblk would satisfy all of my recommendations for my LVM over LUKS. Yet, I'm not at liberty to say it would satisfy everyones setup. But it would be a good start, I think.

Thank you, devs, for the maintenance of this fine product.

[DonEdwards]

ACR-Jeff, in explaining why the program forces you to choose a partition, comes really close to explaining why it should let you choose a folder. A brief summary - more detail later - is that the current causes the undesired behavior (backups to a system partition) to happen accidentally and with adverse side effects.

In partial response to Mr-Dead: I looked at the config file and determined that Timeshift stores several identifiers for the partition, but also stores - and actually uses - the folder where that partition is mounted. We're really choosing a folder, but the configuration process hides that fact from us in order to limit what folders we are allowed to choose. (And incidentally failing to stop us from choosing a partition we probably shouldn't, such as where /home is mounted.)

Now the detailed version...

Suppose you have a system with a fairly small system partition, and you have a backup drive mounted at /mnt/backups. Set up Timeshift to do its snapshots on that partition, and also set up Backintime to put its snapshots at /mnt/backups/here. (backintime will then create /mnt/backups/here/backintime/{stuff} .) Set up scheduled nightly backups.

Now dismount your backup drive. And go to bed.

Scheduled stuff happens.

Backintime will observe that its target location, /mnt/backups/here, does not exist, and will therefore fail.

Timeshift will observe that its target location, /mnt/backups, DOES exist - it's a folder on the system partition - and contains no snapshots. It will create the directories it likes, and do one or more snapshots. To the system partition. Which risks filling up the system partition to the point that it can cause system failure. And also makes it impossible to mount the backup device, until you go in and manually clean out that folder.