Timeshift: System Restore Tool for Linux

I've probably spent way too much time thinking about Linux backup over the years. But thankfully, I found a setup that works really well for me in 2018 or so, used it for the last few years, and I wrote up a detailed blog post about it just a month ago:

https://amontalenti.com/2024/06/19/backups-restic-rclone

The tools I use on Linux for backup are restic + rclone, storing my restic repo on a speedy USB3 SSD. For offsite, I use rclone to incrementally upload the entire restic repository to Backblaze B2.

The net effect: I have something akin to Time Machine (macOS) or Arq (macOS + Windows), but on my Linux laptop, without needing to use ZFS or btrfs everywhere.

Using restic + some shell scripting, I get full support for de-duplicated, encrypted, snapshot-based backups across all my "simpler" source filesystems. Namely: across ext4, exFAT, and (occasionally) FAT32, which is where my data is usually stored. And pushing the whole restic repo offsite to cloud storage via rclone + Backblaze completes the "3-2-1" setup straightforwardly.

I prefer using openSUSE, which is tightly integrated with snapper[0], making it simple to recover from a botched update. I've only ever had to use it when an update broke my graphics drivers, but when you need it, it's invaluable.

Snapper on openSUSE is integrated with both zypper (package manager) and YaST (system configuration tool) [1], so you get automatic snapshots before and after destructive actions. Also, openSUSE defaults to btrfs, so the snapshots are filesystem-native.

[0]: http://snapper.io/

[1]: https://en.opensuse.org/Portal:Snapper

I adore Timeshift. It has made my time on Linux so much more trouble free.

I have used Linux for 10+ years but over the I have spent hours, days and weeks trying to undo or fix little issues I introduce by tinkering around with things. Often I seem to break things at the worst times, right as I am starting to work on some new project or something that is time sensitive.

Now, I can just roll back to an earlier stable version if I don't want to spend the time right then on troubleshooting.

I've enabled this on all my family members machines and teach them to just roll back when Linux goes funky.

This reminds me of the default behavior of NixOS. Whenever you make a change in the configuration for NixOS and rebuild it, it takes a snapshot of the system configurations and lets you restore after a reboot if you screw something up.

Similarly, it doesn't do anything in regards to user files.

> similar to the System Restore feature in Windows and the Time Machine tool in Mac OS

This makes no sense! System Restore is a useless wart that just wastes time making "restore points" at every app/driver install and can rarely (if ever) produce a working system when used to "restore" anything. It does not back up user data at all. Time Machine is a whole-system backup solution that seems to work quite well and does back up user data.

To me the quoted statement might as well read "a tool similar to knitting needles (in hobby shops) and dremels (in machine shops)"

Reading their description further, it seems like they are implementing something similar to TimeMachine (within the confines of what linux makes possible), and not at all like "System Restore". This seems sane as this implements something that is actually useful. They, sadly, seem to gloss over what the consequences are of using non-btrfs FS with this tool, only mentioning that btrfs is needed for byte-exact snapshots. They do not mention what sort of byte-inexactness ext4 users should expect...

ZFS Snapshots + Sanoid and Syncoid to manage and trigger them is what people should be doing. Unfortunately, booting from ZFS volumes seems to be some form of black art unless things have changed over the last couple of years.

The license conflict and OpenZFS always having to chase kernel releases often resulting in delayed releases for new kernels means I cannot confidently use them with rolling release distros on the boot drive. If I muck something up, the data drives will be offline for a few minutes till I fix the problem. Doing the same with the boot drive is pain I can live without.

Hmm, this doesn't appear to be what I hoped it was:

> Timeshift is similar to applications like rsnapshot, BackInTime and TimeVault but with different goals. It is designed to protect only system files and settings. User files such as documents, pictures and music are excluded.

On the other hand, a quick search looking for "that zfs based time machine thing" did reveal a new (to me) project that looks very interesting:

https://github.com/kimono-koans/httm

My system is different and simpler:

The root partition / and the home partition /home are different.

There's a /home/etc/ folder with a very small set of configuration files I want to save, everything else is nuked on reinstall.

When I do a reinstall, the root partition is formatted, the /home partition is not.

This allows me to test different distros and not be tied to any particular distro or any particular backup tool, if I test a distro and I don't like it, then it is very easy to change it.

Timeshift saved my system so many times over the past 6-7 years. Botched upgrades, experimenting with desktop environments, destroying configuration defaults, it works and does what it says on the tin.

I've found Debian Stable to be extremely stable, especially in recent years, I honestly don't think about system restore as much as I worry about a drive crashing or a laptop getting stolen. I assumed Linux Mint LTS was similarly stable.

Folks who have run into issues, what was the root cause?

I use a series of scripts to make daily Borg backups to a local repository: https://github.com/gchamon/borg-automated-backups

Currently the local folder is a samba mount so it's off-site.

The only tip I'd have for people using Borg is to verify your backups frequently. It can get corrupted without much warning. Also if you want quick and somewhat easy monitoring of backups being created you can use webmin to watch for the modifications in the backup folder and send an email if there isn't a backup being sent in a while. Similarly, you can regularly scan the Borg repo and send email in case of failures for manual investigation.

This is low tech, at least lower tech than elastic stack or promstack, but it gets the job done.

A bit of a side note and a bit of old man reveal, it would be nifty to have the backup system write the snapshots to cd/dvd/bluray disk.

I remember working in a company that had a robot WORM system. It would grab a disc, it would be processed, take it out, place it among the archives. If a restore as needed the robot would find the backup, and read off the data.

I never worked directly on the system, and I seem to remember there was a window that the system could keep track of (naturally) but older disks were stored off site somewhere for however long that window was.

(Everything was replicated to a fully 100% duplicate system geographically highly separated from the production system.

I just switched from windows to Mint and the first thing it asked me was to configure backups and snapshots and stuff. Pretty cool!

My first "real" experience with Linux was with Wubi (Ubuntu packaged as a Windows program). I think it was based on Ubuntu version 6 or 8.

I also tried to update it, when the graphical shell displayed a message saying that update is available. Of course, it bricked the system.

I've switched from Ubuntu to Mint to Debian to Fedora to Arch to Manjaro for personal use and had to support a much wider variety of distributions professionally. My experience so far has been that upgrades inevitably damage the system. Most don't survive even a single upgrade. Arch-like systems survive several major package upgrades, but also start falling apart with time. Every few years enough problems accumulate that merit either a complete overhaul or just starting from scratch.

With this lesson learned, I don't try to work with backups for my own systems. When the inevitable happens, I try to push forward to the next iteration, and if some things to be lost, then so be it. To complement this, I try to make the personal data as small and as simple to replicate and to modify moving forward as possible. I.e. I would rule against using filesystem snapshots in favor of storing the file contents. I wouldn't use symbolic links (in that kind of data) because they can either break or not be supported in the archive tool. I wouldn't rely on file ownership or permissions (god forbid ACLs!) Try to remove as much of a "formatting" information as possible... so I end up with either text files or images.

This is not to discourage someone from building automated systems that can preserve much richer assembly of data. And for some data my approach would simply be impossible due to requirements. But, on a personal level... I think it's less of a software problem and more of a strategy about how not to accumulate data that's easy to lose.

The highly awaited Linux Mint 22.0 release marks a very exciting chapter for one of the most popular Ubuntu-based distributions. This new version is not meant to be some kind of regular update; it's an LTS version with promises of updates and support all the way to 2029. Both experienced Linux users and newcomers will find a lot in this version worthy of attention to detail in changes and new features. Let's break down what's new and what makes this release stand out.

https://www.geeksmatrix.com/2024/07/linux-mint-220-whats-new...

Timeshift does not work for me because I encrypted my ssd, decrypt on boot, but linux sees every file twice, once encrypted and once decrypted, thinking that my storage is full, and thus timeshift refuses to make backups due to no storage. At least thats as far as I'm understanding it atm

I use BackInTime, which works in a similar way but is much more configurable. I have hourly backups of all my code for the past day, then a single daily for the past week, etc.

Saved my ass a few times.

Nice UI :-)

Random notes/suggestions

- rsync is not a snapthot tool, so while in most of the cases we can rsync a live volume issueless on a desktop it's not a good idea doing so

- zfs support in 2024 is a must, btrfs honestly is the proof of how NOT to manage storage, like stratis

- it seems not much a backup tool, witch is perfectly fine but since the target seems to be end users not too much IT literate it should be stated clear...

I'd like some sort of a comparison with Duplicity/Déjà Dup that seems to be the default on Gnome/Cinnamon.

Can timeshift work with ext4 filesystems?

I know it won't have the atomicity of a CoW fs, but I'd be fine with that, as the important files on my systems aren't often modified, especially during a backup - I'd configure it to disable the systemd timers while the backup process is running.

Can someone recommend a solution that works well with immutable distros such as Project Bluefin or Fedora Kinoite/Silverblue? We just need to backup maybe the etc and dotfiles. Also great if it can backup NixOS too.

I've just got a simple script that uses rclone for most of my home directory to my NAS. For nearly everything else, I don't mind if I have to start mostly from scratch.

> Creates filesystem snapshots using rsync+hardlinks

Sounds like it works similarly to git fork on GitHub? That is, if no files have changed, the snapshot doesn't take up any extra room?

Magical thing about timeshift is that you can use it straight from your live CD. It will find root, backups, and restore it together with a boot partition.

Has the btrfs sub volume quota bug been fixed yet? I always had issues when using it

Isn't timeshift what apple calls their snapshot/backup thingy?

Don't forget Atpik. great for migrating a system to a new distro.

oh this brings back memories, i found a script that did this about 15 years ago. it kept three versions of backups using rsync and hard-links to avoid duplication.

Yet another solution that is wholly unnecessary in NixOS. Nice idea, though, since you can too easily screw up every other Linux.