Guide

Back up a Linux server with rsync, start to finish.

One tool that's been on every Linux box since the 90s, one SSH key, one cron line. This is the whole stack — and it's more durable than most backup products.

Step 1: set up key-based SSH

Unattended backups need authentication without prompts. Generate a key on the server being backed up (no passphrase for cron use, or use an agent), and install the public half on your storage account:

# on the server you're backing up
ssh-keygen -t ed25519 -f ~/.ssh/rsyncit -N ""
ssh-copy-id -i ~/.ssh/rsyncit.pub usr1042@usr1042.rsyncit.com

# test — should log in with no password prompt
ssh -i ~/.ssh/rsyncit usr1042@usr1042.rsyncit.com

On RSYNCIT you can include your public key when ordering and skip the copy step — credentials arrive cron-ready.

Step 2: the rsync command, flag by flag

rsync -avz --delete \
  -e "ssh -i /root/.ssh/rsyncit" \
  --exclude-from=/etc/backup-excludes.txt \
  /etc /home /var/www /srv \
  usr1042@usr1042.rsyncit.com:daily/
  • -a (archive) — recursive, preserves permissions, ownership, timestamps, symlinks. The flag that makes a copy a backup.
  • -v — verbose file list, invaluable in logs.
  • -z — compress in transit; helps on slower uplinks, skip it on fast links with mostly-compressed data (media, dumps in .gz).
  • --delete — remove files on the destination that no longer exist at the source, so the backup mirrors reality. Powerful and dangerous: a fat-fingered source path can empty the destination, so test with --dry-run first, always.
  • --exclude-from — a file of patterns you don't want: caches, tmp, sockets, lost+found.

A sensible starting exclude file: /proc, /sys, /dev, /run, /tmp, *.tmp, cache directories for your stack.

Step 3: databases need a dump first

rsync copies files; a live database's files are a moving target and restore inconsistently. Dump first, then let rsync carry the dump: mysqldump --all-databases | gzip > /srv/db-dumps/nightly.sql.gz (or pg_dumpall) in the same script, ordered before the rsync line. The dump is a regular file — rsync moves it like everything else.

Step 4: schedule and log it

# /etc/cron.d/offsite-backup — 02:15 nightly
15 2 * * * root /usr/local/bin/offsite-backup.sh >> /var/log/offsite-backup.log 2>&1

Wrap the rsync in a small script that exits non-zero on failure, and alert on it — a backup that silently stopped in March is the one you discover in July. Check $?, or grep the log for rsync error. For systemd timers and locking against overlapping runs, see the automation guide.

One more habit: restore something monthly. rsync usr1042@usr1042.rsyncit.com:daily/etc/fstab /tmp/restore-test/ takes ten seconds and turns "we have backups" into "we have restores."

Where this simple setup falls short

A single mirrored copy protects against hardware loss, not against yesterday's mistake — --delete faithfully propagates deletions and ransomware-encrypted files alike. The fix is history: hardlink snapshots with --link-dest give you dated restore points that cost only the changed bytes. That's the next guide, and it's the difference between a mirror and a real backup strategy.

Need the other end of that rsync command?

Flat $6.95/TB per month, unmetered uploads, and a hostname that speaks rsync natively.

See pricing

TL;DR

  • ed25519 key, no passphrase, cron-ready
  • -avz --delete + excludes
  • Dump databases before rsync runs
  • Log, alert on failure, test restores
  • Add --link-dest history next