Backups don't need to be complicated. There's a whole industry built around implementing backup systems with NAS devices, RAID arrays, and software with snazzy GUI frontends. But my favorite solution to backups was introduced thirty years ago and comes bundled with Linux, macOS, and WSL for free. I'm talking about rsync — the reliable command-line tool that can efficiently handle most backup scenarios with one line.
Setting up rsync is pretty easy, and will certainly take you less time than configuring a RAID array (which is redundancy, not a proper backup). With rsync, you'll get a separate copy of your data that you can restore from. There's no UI or web-based control panel, but it still comes with all the essentials: fast incremental transfers, secure sync over SSH, support for snapshots, and it's easy to automate.
How rsync actually works
And what makes it so good
Rsync, as the name implies, is a synchronization tool. It mirrors the contents from a source directory to a destination directory, effectively keeping the two in sync. But the real power behind rsync is in how it performs the synchronization process.
Rather than copying files every run, rsync checks to see what the differences are between the source and destination paths. In other words, it will transfer all the new files that exist at the source but not at the destination, delete those in the destination that no longer exist in the source (this behavior is optional), and it will also transfer the changes of any modified files. That last part is crucial: rsync uses a delta-transfer algorithm to only transfer the changed blocks of a file. This saves a lot of bandwidth and time by only sending the bits of data that have actually changed.
The other great thing about rsync is its speed. I have a few hundred thousand files on my system, and it's able to scan all of them and compare them to the destination directory to assess any changed data in just a few seconds. It scales very well with big file sizes and directories with an extreme number of files in them.
To implement an infallible backup strategy, you should have three copies of your data, one of which is offsite (i.e., the 3-2-1 rule). The way this would work with rsync is two different commands — one to sync your source directory (your main files that you work directly on) with a local destination directory, and a separate command that syncs the data with an offsite directory. Since rsync works over SSH, your remote backup could be a Raspberry Pi, a rented VPS, your friend's server, or anywhere else you have SSH access. The main thing is to keep it separate from the other two copies.
Ready to sync your files?
Here's the command to get started
The command below is enough to cover the majority of backup scenarios. Here's how you can keep your source directory in sync with a local destination directory:
rsync -avhP --delete /source/directory/ /destination/directory/There are a lot of flags you can use with rsync, but these are the most common and are probably enough for most backup jobs. Here's what each one means:
-
-a— Archive mode. Makes the transfer recursive, and preserves file permissions, timestamps, symbolic links, and ownership. -
-v— Verbose. This lets you see every file that's being transferred. -
-h— Human-readable. Just puts the bytes in more digestible units like KB, MB, and GB. -
-P— Shows the progress of file transfers and also keeps partially transferred files (in case of interruption, this allows you to resume where the transfer left off). -
--delete— This flag deletes files from the destination that no longer exist in the source.
Remote syncs over SSH
For remote transfers, you include the -e ssh option and specify the username and hostname (or IP address). Everything else stays the same:
rsync -avhP --delete -e ssh /source/directory/ user@hostname:/destination/directory/Since rsync tunnels all traffic through SSH, your files are encrypted in transit. If you want to run the command without being prompted for a password (ideal if you're automating backups), you can set up SSH key authentication.
Snapshot backups with version history
If you want to configure snapshot backups, you can utilize rsync's --link-dest option:
rsync -avh --delete \
--link-dest=/backup/snapshots/latest \
/home/user/ /backup/snapshots/$(date +%Y-%m-%d)/That command tells rsync to create a new, timestamped destination directory, but hardlink previously synced files to it first, and only transfer the changes. This way, you don't consume any additional space but have browseable snapshots of any time rsync ran.
You'll also need to update the latest symlink after each run, so the next backup knows what to compare against:
ln -snf /backup/snapshots/$(date +%Y-%m-%d) /backup/snapshots/latestWhen rsync isn't the answer
It's a great tool but it's not for everyone
While rsync is effective in most situations, there are a few where it's not. It's not good for deduplication, so if you have a lot of files that have overlapping data (like VM images), Borg or Restic will handle transfers much more efficiently with content-defined chunking. Another weak point is encryption at rest. You need to couple rsync with an encrypted file system (I use gocryptfs) so that destination files are encrypted on the device and not just in transit.
Despite rsync being relatively straightforward, some people simply aren't comfortable in the terminal or prefer robust GUI applications. For them, rsync will be a tough sell. The advantages of rsync's simplicity and control far outweigh any of its shortcomings, and for the majority of people it's the only backup tool they'll need.
Your backup is one command away
With just one rsync command, you have a far more reliable backup than many people ever get around to setting up. Start by pointing rsync to a local destination directory or remote server, and add the line to cron for automation. Consider using snapshots if you don't plan to oversee every backup. That way you'll still be able to recover old versions of files.
