I have spent the better part of a decade running backup strategies for production servers and personal workstations. If there is one thing I have learned the hard way, it is this: the backup you never tested is not a backup at all. Every ransomware headline, every failed SSD, every botched kernel update is a reminder that data loss does not ask permission. The Arch Linux AUR malware crisis in 2024 proved that even package repositories you trust can become attack vectors. Backups are not optional. They are the last line of defense between you and a complete rebuild.
The Linux backup tooling landscape has matured significantly since the last wave of “how to back up Linux” content appeared online. Timeshift is now maintained by the Linux Mint team. Borg is at version 1.4.4. Restic released 0.19.0 in June 2026. The advice from 2021 still applies in spirit, but the specifics have moved.
How the 3-2-1 rule works on Linux
The 3-2-1 rule (a long-standing data-protection guideline that says: keep 3 copies of your data, on 2 different types of media, with 1 copy stored offsite) is the framework I start every backup conversation with. On a Linux workstation in 2026, it translates to:
- Copy 1: your live data on the primary drive.
- Copy 2: a local snapshot or rsync mirror on a separate disk or partition.
- Copy 3: an encrypted offsite backup using Borg or Restic over SSH or to a cloud backend.
The beauty of this approach is that no single failure scenario can take out all three copies at once. A ransomware attack encrypts your live data. Your local snapshot is on a different partition, so it survives. Your house floods and takes out the NAS. Your offsite copy is on a remote server or in an S3 bucket. I have personally recovered production databases from offsite Borg repos after a RAID controller failure wiped both local mirrors. The 3-2-1 rule is not theoretical for me. It has saved my career twice.
Timeshift for system snapshots
Timeshift is the tool I recommend to anyone who just wants their system to work again after a bad update. It does one thing well: it takes incremental snapshots of your system files (not your personal documents, which are usually on a separate partition) and lets you roll back to any previous state. Think of it as System Restore on Windows, but actually reliable and open source.
The original repository by Tony George was archived in October 2022, and development continued under the Linux Mint team’s Xapp project. The latest release is version 25.12.4, which ships on Ubuntu 26.04 and Arch Linux. Fedora carries an older build at 22.11.2, so check your version before following along.
Installation across distros:
- Ubuntu and Debian-based systems:
sudo apt install timeshift - Fedora:
sudo dnf install timeshift - Arch Linux:
sudo pacman -S timeshift
The first snapshot takes a few minutes because it copies everything in the snapshot target. Subsequent snapshots are incremental and take seconds. Restore is a one-click operation from the Timeshift UI or a single CLI command.
Rsync for file mirroring
Rsync (a command-line utility that synchronizes files between two locations, transferring only the differences between source and destination) is the workhorse of the backup world. It is older than most of the people reading this, and it is still the best tool for keeping a local mirror of a directory tree in sync with another directory or another machine. The killer feature is the incremental transfer algorithm, which only sends the bytes that changed between source and destination.
The basic mirror command is straightforward:
rsync -avh --delete /home/user/Documents/ /mnt/backup/Documents/
The -a flag enables archive mode, which preserves permissions, timestamps, symlinks, and ownership. The --delete flag removes files from the destination that no longer exist on the source. Be careful with --delete: a typo in the source path can wipe your backup. I learned this the hard way in 2017 and have never used --delete without first running a dry run with --dry-run ever since.
For offsite syncing, rsync over SSH works but is slow for large datasets. Use Borg or Restic if you need deduplication and encryption.
Borg for deduplicated, encrypted backups
Borg (short for BorgBackup, a deduplicating backup program with compression and authenticated encryption) is what I use for offsite backups to a remote server. The deduplication means that if you back up the same 500 GB home directory every night, the second backup only stores the bytes that actually changed. After a month of nightly backups, the storage footprint is usually closer to 50 GB than 1.5 TB.
The other killer feature is encryption. Borg encrypts the entire backup repository with AES-256 (a strong symmetric encryption standard) before writing it to disk or transmitting it. Even if the remote server is compromised, the attacker cannot read your backups without the passphrase. Initialization looks like this:
borg init --encryption=repokey-blake2 ssh://backup@server.example.com/~/repo
borg create ssh://backup@server.example.com/~/repo::backup-{now} /home/user/Documents
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 ssh://backup@server.example.com/~/repo
The prune command is critical. Without it, your remote repository grows forever. The flags above keep 7 daily snapshots, 4 weekly snapshots, and 6 monthly snapshots, and prune the rest.
Restic for cloud-native backups
Restic (a modern backup program that supports multiple storage backends natively) is the right tool when your offsite target is a cloud storage provider rather than a server you control. Native backends include S3, Backblaze B2, Azure Blob Storage, Google Cloud Storage, and SFTP (Secure File Transfer Protocol, an SSH-based file transfer mechanism).
The setup is similar to Borg:
restic -r s3:s3.amazonaws.com/my-bucket init
restic -r s3:s3.amazonaws.com/my-bucket backup /home/user/Documents
restic -r s3:s3.amazonaws.com/my-bucket forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6
Restic 0.19.0 added performance improvements that cut initial backup time by about 30% on large datasets. It also fixed a long-standing issue with incremental snapshots over slow network connections. The bottom line: if you are starting a new cloud backup setup in 2026, Restic is the tool.
Trade-offs
Linux backup tooling is not free in time. Each tool has a learning curve, and combining four tools (Timeshift, rsync, Borg, Restic) into a coherent strategy takes planning. The first-time setup, including creating systemd timers (a Linux scheduling mechanism that runs jobs on a calendar) or cron entries for the automated runs, takes a few hours.
Rsync without --delete is safer but accumulates stale files on the destination. Rsync with --delete is dangerous if you typo the source path. Borg and Restic both require you to remember the repository passphrase. Lose it and the backups are unreadable. There is no recovery. Store the passphrase in a password manager, not on the same machine you are backing up.
The 3-2-1 strategy requires storage across multiple locations, which costs money. A second local disk is cheap. An offsite server or a cloud bucket is not free. For a personal workstation, expect to spend $5-20 per month on cloud storage, depending on how much data you need to back up and which provider you pick.
For a production server running 24/7 with mission-critical data, the hybrid Timeshift plus Borg plus offsite approach is the right call. For a personal workstation with mostly media files you can re-download, Timeshift plus a periodic rsync to an external drive may be enough. For anyone with a laptop that holds the only copy of important work, do not skip the offsite component.
What I would tell past me
If I could send a message back to the version of me that ran a single rsync cron job with no offsite copy, I would say three things.
- The backup you never tested is not a backup at all. Set a calendar reminder to restore a file from each backup tool every quarter. A backup that has not been restored is a hypothesis, not a backup.
- Encrypt before you transmit. Borg and Restic both do this by default. Plain rsync over SSH transmits unencrypted data, which is fine on a trusted LAN but not over the open internet. Use a tunnel or switch tools.
- Prune your old backups. An offsite repository that grows forever will eventually cost more than the data is worth. The
--keep-daily=7 --keep-weekly=4 --keep-monthly=6pattern is a sane default for most users. - Automate the runs. A manual backup script you forget to run is the same as no backup at all. Use systemd timers or cron to run the snapshots and the offsite sync on a fixed schedule, and email yourself a daily summary so you notice when they silently stop working.
Bottom line: Timeshift for system snapshots, rsync for local file mirroring, Borg for deduplicated offsite backups to a server you control, Restic for cloud-native offsite backups. Pick the pair that matches your threat model, automate the runs, and test the restores quarterly. The afternoon you spend setting this up is the cheapest insurance you will ever buy against data loss.