Timeshift: Backup on another device

Hey there,
I have used timeshift for years but I always found it a bit weird to make the backup on the same disk as the one I use. I know, technically timeshift is not a full backup system, so I do backups in another way on an external disk as well.
But I would like to have the backups from timeshift on a second internal disk and I am not sure if I understand the UI correctly.

Those are my disks:

nvme1n1 is the one I use, 0n1 is my second one. I want to save the timeshift data from 1n1 on 0n1.

Is it enough to just change the disk in that menu here?

If I do so, I get the message “Select BTRFS system disk with root subvolume @”. Do I need to make a @volume on disk 0n1 as well or does that tell me that I am not allowed to do it on a different disk?

Sorry if that topic came across a bit confused
I am thankful for any meaningful explanation :slight_smile:

timeshift can do two things, but they are not the same… :point_down:

  1. make backups via rsync
  2. make btrfs snapshots

The latter is not a backup solution, but rather a “rollback” feature. The former is a backup solution, but only if you store the backups on another physical medium than your system drive.

Best is to change the type of backup to rsync, and then you simply point it at a partition — preferably on another drive, and preferably an empty one, so that you have enough space — that it must store the backups on.

The filesystem on the target drive is not important, provided that it is a Linux-native filesystem, because it must be able to store the POSIX permissions and file ownership — so no ntfs, vfat, exfat or anything like that. But ext4, xfs, btrfs and the likes are all fine.

Hi, thank you for your good explanation
Is it possible to do both of them at the same time?
If I understand that right, then activating rsync would mean that I don’t have my important rollback function anymore? I used that several times after doing something stupid in the kernel

You are using btrfs, so one thing that should be added to Aragorn’s input above:

If you save the btrfs snapshots on another drive (instead of using rsync) they will take up the same space as the data you “backup” from your drive (so rsync makes more sense to use then).
If you save it on the SAME drive it won’t take up much space, because it is a snapshot on a CoW filesystem (only when you start changing things on your running system the data will actually be created, or rather, the NEW data is added to the drive while the old stays in the snapshot).

I am also not sure how grub will deal with snapshots on other partitions, if it finds them and adds them so you can revert from grub directly.

Since you are doing backups to other drives another way (good job and good practice btw!) I would recommend you keep using snapshots and save those snapshots on the same drive to save space AND be able to boot directly into a snapshot from grub.

1 Like

You could try:

:footprints:

1 Like

Not at the same time, but you can switch between both methods. So, you could first make a btrfs snapshot, and then switch to rsync and tell timeshift to store the backup on a different device.

If he uses @andreas85 app to make the snapshots on another drive, he can still use timeshift to manage the “local” ones.

The reason local snapshots is sooooo good is because of how you so easily can boot right back into them from grub (read only) and then restore that snapshot to your root and reboot.

1 Like

Indeed, that would work perfectly well. :wink: :+1:

With Mint, I started moving Timeshift rsync backups to my storage disks - and it seemed quite good.

However, after a few disasters - waiting so long for the restorations and reading about INSTANT snapshots, my last install just over a year ago was BTRFS with some short term snapshots (3 hourly, and a daily) and back-in-time continues the rsync backups to my storage disk.

Neither one appears to have any impact on system performance unless I collect too many BTRFS snapshots and need to delete a few to free up space.

The beauty is the speed of the snapshots and the simple select and reboot to restore.

Maybe in another year or two I can report any issues it brings, but so far it’s proved bulletproof…

Personally, I use btrfs on all of my filesystems except for /boot (which is ext4) and /boot/efi (which is of course vfat). However, I do not use btrfs snapshots. I maintain a different strategy, which wouldn’t work very well with how timeshift makes btrfs snapshots.

The thing is that I maintain several separate partitions — basically, everything that can be split off from the root filesystem is indeed split off — and that includes the tried-and-tested (but in modern GNU/Linux distributions less easy to implement) method of splitting off /usr and mounting it read-only.

If I were to start all over again, then I’d still be doing that, but then I’d probably opt for a single btrfs filesystem with dedicated subvolumes and subvolume quotas, but when I installed Manjaro now over 4 years ago, I wasn’t all that familiar with btrfs yet.

So, my partition layout is currently like this… :point_down:

[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] >   lsblk -o NAME,FSTYPE,MOUNTPOINT
NAME    FSTYPE MOUNTPOINT
sda                         # 1TB SSD (SATA3)
├─sda1  vfat   /boot/efi    # mounted read-only
├─sda2  ext4   /boot        # mounted read-only
├─sda3  btrfs  /
├─sda4  btrfs  /usr         # mounted read-only
├─sda5  btrfs  /usr/local   # mounted read-only
├─sda6  btrfs  /opt         # mounted read-only
├─sda7  btrfs               # my old /var, which was too small - not mounted
├─sda8  btrfs  /srv
├─sda9  btrfs  /home
├─sda10 swap                # disabled
└─sda11 btrfs  /var
sdb                         # 750 GB older spinning rust drive (SATA2)
├─sdb1  swap                # disabled
└─sdb2  btrfs               # my backups
sr0   

I LOVE this discussion.

My sollution is this.

I have a rpi running UrBackup ALSO using btrfs as backup storage.
This means UrBackup can make snapshots as backups (it creates a local snapshot and pulls files from there, then deletes it), I can restore per file/directory, download as zip etc on everything.
The incremental backups every 5 hours makes sure everything is backed up to date and since they are snapshots, well, only changed files are transfered in the backup AND the space it takes up is minimal. I have 260 incremental backups at this moment, every single little file changed. :slight_smile:
This is my ransomware protection 1. (also backs up my whole OTHER file server, but that’s beside the point here)
I use this method to backup my /home, file-disk, /etc & /root (I just realized, why do I backup root? must be some old testing I did a long time ago)


I also use clonezilla to make backups on my whole drive (because I still have dual boot with win11, for... reasons...) AND partitions (boot, root, home). This I have to do manually, use ventoy and run clonezilla > backup. This is all on me to keep updated. I save those backups to a partition that I NEVER mount (ransomware protection 2) unless I need to clear up old backups. This is in case of complete disk failure.

Timeshift makes snapshots every day, saves 7 days then deletes. I save 4 weekly, and 2 monthly.
I have all original hooks active so before an update, a snapshot is made (this has saved me more times than I would like to admit, I like to tinker… xD)

Because I make the clonezilla partition backups I prefer to NOT have home on same btrfs filesystem, because if I restore that partition, the home would be included.
So this is my lsblk:

NAME        FSTYPE MOUNTPOINT
sda                
├─sda1      vfat                   # windows boot
├─sda2                             # windows "who tf knows what this is" partition
├─sda3      ntfs                   # windows
├─sda4      ntfs                   # another windows "who tf knows what this is" partition
├─sda5      vfat   /boot/efi
├─sda6      swap   [SWAP]
├─sda7      btrfs  /var/log
│                  /var/cache
│                  /
└─sda8      btrfs  /home
# and a bunch of other drives not relevant.

I have also found that with btrfs, it’s a good idea to run a btrfs scrub every once in a while, and especially on machines that stay up 24/7. :wink:

Yeah, systemd timer recomended from me.

1 Like

Hello people,
Thank you for all of your comments. It was nice to read through them and btrfs scrub is already my personal highlight.

I am not that experienced in dealing with all of these tools, even though I used Linux for ages. It seems a bit like I should actually let my btrfs snapshots untouched for the sake of my systems integrity (I used it several times to save me from disaster and dont want to mess it up).

Maybe I should generally search for a different backup tool and let timeshift mind its business?

Great idea.