Timeshift CLI for Automated System Snapshots on elementary OS
Elementary OS has earned a reputation for being one of the most approachable Linux distributions available, particularly for users who have just migrated away from macOS or Windows. The Pantheon desktop environment is clean, the AppCentre is curated, and the out-of-the-box experience rarely requires command line tinkering. Yet there are moments when the terminal becomes unavoidable, especially when dealing with system-level tasks like backups and recovery. Timeshift is the de facto tool for creating and restoring system snapshots, and while a graphical front end exists, the Timeshift CLI offers more flexibility for automation, remote administration, and integration with scripts.
Australians running elementary OS on older hardware in places like Brisbane, Adelaide, or Hobart often have to deal with harsh summer temperatures, sudden power outages during storm season, and the occasional botched configuration after a manual driver install. Having a reliable snapshot strategy is not a luxury in these conditions; it is a practical safeguard. The CLI variant of Timeshift is particularly useful for headless setups, for users who manage their machine over SSH from another room or from a remote site, and for anyone who wants snapshots to happen quietly in the background without ever clicking a button.
Understanding what Timeshift does and how the CLI differs
Timeshift creates incremental snapshots of the system partition using either the RSYNC or BTRFS method. The RSYNC approach works on any file system, including the default ext4 installation of elementary OS, and stores changes as ordinary files on a designated partition or external drive. BTRFS snapshots, on the other hand, are near-instantaneous and consume almost no additional disk space because they leverage the copy-on-write nature of the file system itself. Both methods capture the operating system, installed applications, and configuration files, but they exclude user data by default, which keeps snapshots small and focused on recoverability.
The graphical Timeshift application wraps these underlying features in a tidy GTK interface that suits the Pantheon aesthetic. The CLI, invoked simply as timeshift in a terminal, exposes the same capabilities through a set of flags and subcommands. Power users in cities like Melbourne and Sydney often prefer the CLI because it can be scripted, scheduled with cron or systemd, and combined with other maintenance tasks in a single routine. It also runs cleanly over an SSH session, which is helpful when managing a home server or a media centre tucked away in a study nook.
The CLI is not a stripped-down version of the tool. It supports the same snapshot levels (hourly, daily, weekly, monthly, boot), the same restore options, and the same exclusion lists. The main trade-off is that you have to remember a few command patterns, but those patterns are stable, well-documented, and easy to drop into a shell script for repeat use. The CLI also produces output that is friendly to log files, which is handy for users who keep a maintenance journal or who pipe results into a monitoring script that emails them a weekly summary.
Installing Timeshift on elementary OS
Elementary OS is based on Ubuntu, which means Timeshift is available directly from the Ubuntu repositories under the same package name. The simplest installation path is through the command line using apt, which avoids the slight delay that can occur when the AppCentre indexes new software. Open a terminal from the Applications menu or by pressing Super and typing "Terminal", then run the following commands.
sudo apt update
sudo apt install timeshift
The package is signed and maintained by Tony George, the same developer behind the graphical build. There is no need to add a PPA unless you specifically want a newer release than what Ubuntu provides. If you do want the latest version, the official Launchpad PPA is teejee2008/timeshift, and it can be added with sudo add-apt-repository ppa:teejee2008/timeshift followed by another update and install cycle. Once installed, the CLI binary lives at /usr/bin/timeshift and is immediately available to any user with sudo privileges.
Once the installation completes, you can verify the binary is available by running timeshift --version. If the command returns a version string, the CLI is ready to use. No additional service needs to be started, because Timeshift operates on demand and through whatever scheduler you choose to drive it. Users who prefer to keep their system minimal can remove the GTK dependencies at a later stage, although the standard package is small enough that this is rarely worth the effort.
Creating your first snapshot from the terminal
Before you start creating snapshots, you need to tell Timeshift where to store them. Plug in an external USB drive, identify its device label with lsblk, and then run a setup command. The interactive setup wizard is launched with sudo timeshift --setup, and it walks you through the snapshot type, location, and schedule preferences. If you prefer a non-interactive configuration for a script, the same outcome can be achieved by writing the configuration file directly under /etc/timeshift/timeshift.json.
For most elementary OS installations, RSYNC is the safest choice because the default file system is ext4. Select the partition you want to back up, and Timeshift will ask whether to include the home directory. Most users answer no here, because personal files are better protected by a separate backup solution that handles versioning differently. After the setup completes, the very first snapshot can be taken with a single command.
sudo timeshift --create --comments "Initial baseline snapshot"
The first run takes a while because it copies the full system state. Subsequent snapshots are incremental and typically complete in a few minutes, depending on how much the system has changed since the last capture. You can list existing snapshots with sudo timeshift --list, which prints a tidy table showing the snapshot name, timestamp, and the tags you assigned. A well-commented history makes it easy to pick the right restore point later, especially if you tend to forget which kernel update or driver change you were testing three weeks ago.
Automating snapshots with cron or systemd timers
Manual snapshots are useful, but the real value comes from letting the system handle them automatically. Timeshift does not install a scheduler by default, so you need to wire one up yourself. The most common approach in Australia is to use cron, which has been part of Unix-like systems for decades and is therefore well understood by anyone who has ever administered a Linux box at a small business in Perth or a community centre in Canberra.
Open the root crontab with sudo crontab -e and add a line that runs Timeshift at a time of day when the machine is likely to be idle. A reasonable schedule for a desktop user is one daily snapshot at lunchtime, one weekly snapshot on Sunday morning, and a monthly snapshot on the first of the month. Timeshift will automatically prune older snapshots according to the schedule levels you selected during setup, so you do not need to manage retention manually.
0 13 * * * /usr/bin/timeshift --create --scripted --quiet
0 9 * * 0 /usr/bin/timeshift --create --scripted --comments "weekly" --quiet
For users who prefer systemd timers over cron, the same effect can be achieved with a small service and timer unit pair placed under /etc/systemd/system/. The systemd approach has the advantage of being more transparent to systemctl list-timers, and it integrates nicely with the journal for troubleshooting. Whichever scheduler you choose, remember to test the automation by waiting for a scheduled run or by triggering the timer manually with sudo systemctl start timeshift-snapshot.service if you go the systemd route. It is also worth glancing at /var/log/timeshift or journalctl -u timeshift-snapshot after the first few runs to confirm the jobs are firing on time.
If your machine spends most of its time on battery or you simply want to reduce wear on the storage, you might also consider pairing snapshot automation with the power saver guide for Pantheon. Snapshots do consume I/O, and suspending them during low-battery stretches keeps the workflow tidy. Australians juggling peak energy tariffs and a mix of grid and solar power often find that thoughtful scheduling makes the laptop both calmer and cheaper to run.
Restoring from a snapshot and managing storage
Restoring a system from a Timeshift snapshot is the moment you realise the effort was worthwhile. The process can be performed either from the running system or from a live USB environment, and the CLI handles both scenarios. From the running system, you can dry-run a restore first to see exactly which files will be replaced, then commit the action with a follow-up command.
sudo timeshift --restore
The command will warn you that the operation is destructive and ask you to confirm. You can bypass the prompt with --yes if you are confident, but most users prefer the safety net. If the system refuses to boot after a bad update, boot from an elementary OS live USB, install Timeshift into the live environment with sudo apt install timeshift, and then point it at the partition containing your snapshots. The CLI will detect them automatically, and you can roll back to any point in time with the same command.
Storage management is a quiet but important part of the workflow. Timeshift keeps snapshots in the location you specified during setup, and it enforces retention rules based on the schedule levels you enabled. You can free space immediately by deleting a specific snapshot with sudo timeshift --delete --snapshot <name>, or by removing all snapshots with sudo timeshift --delete-all. On machines with limited disk space, such as older laptops still common in Australian households, it is sensible to keep the external drive unplugged when not in use and to plug it in only when the scheduled snapshot is about to run.
A good habit is to occasionally boot from the live USB, browse the snapshot contents manually, and confirm that the configuration files you care about are present and recent. Snapshots are only as valuable as the last successful verification, and a quick check every few months is enough to catch any silent failures before they matter.
Run sudo timeshift --check on your machine tonight to confirm that the binary can read your current configuration and that the snapshot location is reachable, then schedule your first automated capture for tomorrow lunchtime during a break in your day.
