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-runfirst, 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 pricingTL;DR
- ed25519 key, no passphrase, cron-ready
-avz --delete+ excludes- Dump databases before rsync runs
- Log, alert on failure, test restores
- Add
--link-desthistory next