rsync copies files to another server or to storage, preserving ownership and permissions, and transfers only what has changed. That makes it well suited to keeping an up-to-date copy of your data somewhere other than the server itself.
The basic command
Over SSH, which is the usual case:
rsync -avz --progress -e ssh /path/on/source/ [email protected]:/backups/
If the destination is mounted locally — Backup Stor mounted over SMB, for example — no SSH is needed:
rsync -avz /path/on/source/ /mnt/backup/
See How to connect to Backup Stor from Linux for connection details.
The options that matter
-a— archive mode. This is the one to remember: it preserves permissions, ownership, timestamps, symbolic links and recurses into directories, replacing half a dozen individual flags.-v— show what is being transferred.-z— compress during transfer. Worth it for text and code, pointless for already-compressed archives and video.--progress— show progress for each file, useful for large transfers.--delete— remove files at the destination that no longer exist at the source, producing an exact mirror. Powerful and dangerous: see the warning below.-nor--dry-run— show what would happen without doing it. Use this first, every time.
The trailing slash on the source path changes the meaning.
/path/source/copies the contents of the directory into the destination;/path/sourcecopies the directory itself, producing/backups/source/. Getting this wrong produces an unexpected nesting rather than an error, and with--deleteit can remove the wrong files.
Resuming after an interruption
If the connection drops, run exactly the same command again. rsync compares both sides and continues from where it stopped rather than starting over — which is the main reason to prefer it over scp for anything large.
Scheduling it with cron
Open your crontab:
crontab -e
Add a line — this example runs every night at 03:20:
SHELL=/bin/bash 20 3 * * * rsync -az /path/on/source/ /mnt/backup/ >> /var/log/rsync.log 2>&1
Points worth noting:
- Do not use
* * * * *. That runs every minute, and a run that has not finished when the next starts leads to overlapping jobs competing for disk and network. Choose a real interval — nightly is right for most backups. - Drop
-vand--progressin scheduled jobs, or the log fills with a line per file. - Redirect the output to a log, as above. Without it you have no way of knowing whether the job has been failing.
- Use key authentication for SSH transfers — a scheduled job cannot type a password. See Setting up SSH key access to Backup Stor.
For the schedule syntax, see Cron style schedules in KeyHelp.
An rsync copy is not a full backup
A plain rsync gives you a mirror of the current state. That protects you against losing the server, but not against your own mistakes: a file deleted or encrypted today is deleted or encrypted in the copy at the next run, and the previous version is gone.
For real protection, keep more than one point in time. The simplest approach is a dated destination directory:
rsync -az --link-dest=/backups/latest /path/on/source/ /backups/$(date +%F)/ ln -sfn /backups/$(date +%F) /backups/latest
--link-dest hard-links files that have not changed, so each dated copy looks complete while occupying only the space of what actually differs. Combine this with removing directories older than a chosen number of days.
Databases need separate treatment
Copying the files of a running database produces an unusable copy. Dump the database first and let rsync copy the dump — see How to repair MySQL databases and tables for the dump commands.
Check that it works
Run the job by hand once and confirm the files arrive. Then, a few days later, check that the log shows successful runs and that recent files are present at the destination — and try restoring something. A backup nobody has ever restored from is an assumption, not a backup.
If a transfer fails or the copy is not what you expected, open a ticket from your client area with the command you used.
