Timeshift for Linux is an application that provides functionality similar to the System Restore feature in Windows and the Time Machine tool in Mac OS. Timeshift protects your system by taking incremental snapshots of the file system at regular intervals. These snapshots can be restored at a later date to undo all changes to the system.(Timeshift GitHub)
When exploring a new distro, it’s always helpful to have the option to undo changes, especially after installing or configuring something substantial that significantly alters your system. For example, installing NVIDIA drivers modifies multiple components of your system, and simply uninstalling the drivers doesn’t always revert everything to the exact state it was in before driver's installation.
Snapshots ≠ Backups
It’s important to note that, although snapshots are sometimes referred to as backups—even Debian documentation lists Timeshift as a backup tool - BackupAndRecovery-Debian Wiki—I somewhat disagree with this classification.
The maintainers of Timeshift also make this distinction clear:
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. This ensures that your files remain unchanged when you restore your system to an earlier date. (Source)
If you need a true backup tool, you should look elsewhere or manually back up periodically just some important data to cloud storage or physical media/storage device.
While many people use snapshots as backup tools—and they work 90% of the time—in the other 10%, they can fail. Holding onto snapshots for too long, especially as the system changes significantly, can lead to problems. This isn't an issue specific to Timeshift, but it can happen if, for example, you take a snapshot, then make major modifications to your storage setup (such as reconfiguring LVM, partitions, changing filesystems). In such cases, it’s best to delete old snapshots and create a fresh one after successful modifications.
I think that probability to encounter such issues with Timeshift is quite low, but in my experience with VMware snapshots, I ran into trouble for precisely this reason.
After taking a snapshot of a Virtual Machine (VM), a logical volume has been extended and additional RAID storage has been added to this VM.The snapshot afterward has not been deleted and then a write-intensive task has been launched, which eventually has triggered an I/O error on the added RAID storage. It was a bit of a "situationship" since the RAID was specifically set up to ensure data integrity. Fortunately, no data was lost, but the Virtual Machine got crazy, caught between the restrictive snapshot (designed to allow a full rollback in VMware) and the newly evolved storage configuration—especially with the repetitive write process on the RAID system.
For more details about Snaphshots vs Backups, you can read this thread on Reddit. And I proceed with timeshift installation, because I need exactly a snapshot tool, not a backup tool.
Timeshift GUI - a little drawback
Timeshift has a graphical user interface, which, for some, may be a strong advantage, while for others, it might be less appealing (I, for example, prefer terminal or command line interfaces).
The timeshift package depends on lib-gtk-3.0 (Debian -- details of package timeshift in Bookworm). lib-gtk is the GTK graphical user interface library, and this dependency makes timeshift a suboptimal solution for machines primarily used as servers. However, I use it on my personal PC, and although I can’t recall any other package in my setup that uses GTK, this tool’s reliability outweighs the drawback of having GTK installed. But if this is a concern for you, you may want to consider a different tool for snaphots. Here’s the original response (a bit dated) from the creator of Timeshift:
Timeshift has dependencies on GTK3 libraries so you must have that installed even if you have not installed a desktop. During installation it will install all dependencies it requires.
Separating the codebase into 2 separate packages (with and without Gtk dependencies) involves a lot of work.
I’m not sure if the current maintainers of Timeshift have plans to separate Timeshift into GUI-only and CLI/TUI-only versions, or if this might have already been done. I haven’t found any information on it.
Preparing "storage device" for Timeshift
My system is partitioned with LVM, and I have a volume group that holds all my system’s logical volumes (called wonderland-vg). First, I want to check if there’s any free space in this volume group. If not, I’ll need to expand it.
Most tutorials and guides focus on how to configure Timeshift where to store snapshots via the GUI. However, my system currently doesn’t have a DE nor even a display server (technically, I am on headless server, that means that I cannot use mouse). Timeshift’s approach to snapshot destinations is based on storage devices (timeshift’s config file expecting UUID) rather than directories, which makes sense—storing snapshots on the external storage device is useful in case the system breaks. So first, I’ll prepare a separate logical partition—a logical volume—for my future snapshots.
#these commands give me stats about my volume group
$ sudo vgdisplay
$ sudo vgs
I have around 160 GB free in wonderland-vg volume group, so I do not need to expand it:
I proceed with creation of new logical volume and mounting it to /timeshift directory:
# create logical volume with name timeshift in volume group wonderland-vg
$ sudo lvcreate -L 20G -n timeshift wonderland-vg
#verify creation
$ sudo lvdisplay
# create a filesystem (all my system is ext4, choose any you use
$ sudo mkfs.ext4 /dev/wonderland-vg/timeshift
Installing Timeshift
Installation of timeshift in Debian is quite straightforward: just run sudo apt install timeshift.
Oh my, that’s quite a lot of dependencies!
My current Debian setup is very close to a server setup, so I have very few things installed. Surprisingly, it doesn’t seem to pull in the display server Xorg, which is actually pretty good, especially for people using Wayland. However, there are still quite of some X11 packages installed.
Configuring Timeshift
The configuration of timeshift with command line is done mostly via configuration file. In /etc/timeshift/, you can find the default config - default.json. If you had already tried to create a snapshot with sudo timeshift --create, you will find in that directory also timeshift.json file. If you want to have control over the choice of storage device where your snapshots will be stored before launching timeshift --create for the first time, you have to modify /etc/timeshift/default.json. If you want to change the storage device where timeshift already have placed some snapshot(s), you have to modify /etc/timeshift/timeshift.json.
In order to point timeshift to use a specific storage device, you have to provide its UUID. If you run sudo blkid, you’ll see the UUIDs of all your storage devices and can pick one where you are willing to place your snapshots.
If you are with the setup that you have control over your mouse, the task becomes quite simple - run sudo blkid, identify storage device (it can be a logical volume, there is no requirement for storage to be physical partition, it can be logical partition as well!). Then you copy corresponding UUID and you will have to paste it into timeshift configuration file (/etc/timeshift/default.json or /etc/timeshift/timeshift.json) in the field "backup_device_uuid" (between backquotes).
NB! If you are on headless server and you cannot just easily select a text from terminal, here is the workaround:
# /dev/mapper/wonderland--vg-timeshift is a logical volume where I want to store my snapshots
# with this command I extract UUID and store it into a temporary file
$ sudo blkid -s UUID -o value /dev/mapper/wonderland--vg-timeshift > /tmp/uuid-snapshots.txt
# Then, I open the `timeshift` configuration file to modify.
# I do it before running timeshift for the first time, so I have only `default.json` as a config file
$ sudo vim.tiny /etc/timeshift/default.json
{
"backup_device_uuid" : "|",
...
}
# I place a cursor between backquotes (where | is)
# in normal vim mode, I type:
:r /tmp/uuid-snapshots.txt
# this command will place the content of file where your coursor is, if needed, modify it a bit, so it is placed correctly
# Save the file!
NB! IF you run sudo timeshift --create for the first time after installation **it will not prompt you to select the storage, but instead it will pick one on its own. In my experience, it selects the first physical partition of a disk where your OS resides (for example, /dev/sdb1); the problem that often it's a /boot partition, so it's definitely not the best place to store snapshots. In this case, interrupt the execution (Ctrl +C) and go to modify/etc/timeshift/timeshift.json (it should be created after the first launch) - either manually provide the correct UUID of the desirable storage or remove automatically set UUIDs (backup_device_uuid and parent_device_uuid fields). Once you’ve done that, restart the command, and it should prompt you to select the storage. However, timeshift has already placed its directory to the storage (which he picked by itself) after the first launch. It may have sense to go and wipe /timeshift directory from there after configuring timeshift to store snapshots on desirable storage device**.
I think the GUI would give more comprehensive control over device selection.
If using Timeshift's GUI is not an option, you can schedule backups using cron jobs or changing false to true in configuration file for schedule_monthly, schedule_weekly, schedule_daily, schedule_hourly (NB! I did not test it!). I don't enable automatic snapshots because, as I mentioned, they’re not true backups, and I don’t need constant snapshotting. I’ll take snapshots manually when necessary (e.g., before major system updates or modifications).
If you're planning to set up automatic snapshots, you should also check the configuration file for the snapshot retention policy.
For instance, if you schedule snapshots to run daily, even if they’re incremental, there’s no point in keeping all of them indefinitely (because they occupy storage's space). You need to pay particular attention to the values of these fields in the configuration file: count_monthly, count_weekly, count_daily, count_hourly.
Keep in mind that manually deleting snapshots via command line is a bad idea. Snapshots are incremental: only the first snapshot contains a "full" snapshot, while subsequent snapshots are just deltas (differences) from that first snapshot. If you manually delete the first (or "parent") snapshot, the others become unusable. However, if you use the retention policies and Timeshift commands, like sudo timeshift --delete --snapshot '<name/timestamp from sudo timeshift --list>', your snapshots will be managed correctly.
Another configuration field to check is exclude. By default all user's home directory is excluded from snapshotting.
NB! If you’re experimenting with different Desktop Environments, browsers, terminal emulators, or shells, remember that anything related to the customization, display stuff typically has configuration files in your $HOME (/home/your_username) directory—often in $HOME/.config. If your /home directory is excluded from snapshotting (field exclude in /etc/timeshift/timeshift.json), when you install for instance KDE -> sudo timeshift --restore -> install GNOME, all of KDE’s config files will remain in $HOME and $HOME/.config. If you do many experiments withs such things, it will inevitably lead to clutter of $HOME directory over time (remember, that ls is not sufficient to see all content, try at least ls -a).
Testing Timeshift
I’ve already created a couple of backups, and since they’re incremental, only the first one was large and took more time to create. Let’s see if this tool can handle reverting a kernel version update and restore the system from "incremental" snapshot (not the first, complete one).
To see how timeshift organizes its stuff/files/snapshots, you can mount the storage device which is used by timeshift with:
# create a directory - mounting point
$ sudo mkdir /timeshift
# mount there newly created logical partition
$ sudo mount /dev/wonderland-vg/timeshift /timeshift
# to see what is inside
$ ls -a /timeshift
This is directory structure that was created automatically by timeshift for itself:
My system's kernel version before kernel upgrade from bookworm-backports repo:
My system's kernel version after kernel upgrade from bookworm-backports repo:
I have 2 snapshots and I will be using the latest one.
$ sudo timeshift --list
$ sudo timeshift --restore --snapshot <timestamp/name form the list>
Timeshift will ask me whether I want to reinstall GRUB. Since the change to my system was a kernel upgrade, I confirm. Then, I’m asked where GRUB should be installed.
After the system state and settings are retrieved from the snapshot and ready for rollback, the system reboots.
NB: If you use BTRFS, don't miss the opportunity to take advantage of its excellent restore capabilities—they are fully supported in Timeshift:
It is strongly recommended to use BTRFS snapshots on systems that are installed on BTRFS partition. BTRFS snapshots are perfect byte-for-byte copies of the system. Nothing is excluded. BTRFS snapshots can be created and restored in seconds, and have very low overhead in terms of disk space.(Timeshift GitHub)
My system's kernel version after restore:
UPD on testing:
I’ve noticed that sometimes when I do a rollback using timeshift restore and then reboot, the restored system’s wireless network interface (Wi-Fi) ends up down. NetworkManager can’t resolve it—it’s not just the Wi-Fi gets disconnected, but the entire wireless interface disappearing (ip a does not list it at all). However, doing a clean reboot after the restore fixes this issue without any problem.
Summarizing:
Timeshift's Pros:
🦄 Continuously maintained and widely-used snapshotting tool
🦄 Easy management via command line
🦄 Incremental snapshots
🦄 Clearly separates snapshots from backups
🦄 Has an active community
Timeshift's Cons:
🫏 No-GUI (CLI-only) installation is not possible
🫏 Brings many dependencies related to the Xorg display server, which may not be the best for server setups or systems with Wayland
🫏 Limited guides on CLI-only usage, even though it's possible
🫏 Storage destination is bound by UUID, which may be confusing
🫏 Limited identifiers in storage selection when creating the first snapshot, making it harder to choose the correct storage device
Top comments (0)