Back up files with rsync

rsync copies files between machines over SSH and sends only what has changed since the last run. That makes it ideal for keeping a second copy of your site files. This guide sets up a pull backup, where a backup machine fetches files from the VPS.

Before you begin

• Two machines with SSH access: your VPS (Ubuntu 24.04), and a backup machine such as your home computer, a Linux machine, or a second server.
• SSH key login from the backup machine to the VPS. Password-free keys are needed for scheduled backups later.
• A user on the VPS that can read the site files, such as deploy, and a site folder such as /var/www/example.com.
• rsync installed on both machines. macOS includes it; Windows users can run it inside WSL.

Step 1: Install and check rsync

On the VPS, install rsync and print its version. Most Ubuntu images already have it, so the install may do nothing.

sudo apt update
sudo apt install -y rsync
rsync --version

rsync  version 3.2.7  protocol version 31

Step 2: Create a destination folder on the backup machine

Run this on the backup machine. The folder will hold one copy of the site.

mkdir -p ~/backups/example.com

Step 3: Run a dry run

Run the command from the backup machine. It pulls the files from the VPS. The flags mean:

• -a (archive) keeps permissions, timestamps, symbolic links and folder structure.
• -v shows each file as it goes, and -z compresses data on the wire.
• -n (dry run) shows what would change without copying anything.
• -e ssh tells rsync to use SSH as the transport.

The trailing slash on the source matters. With it, rsync copies the contents of the folder. Without it, rsync would copy the folder itself into the destination.

rsync -avzn -e ssh deploy@203.0.113.10:/var/www/example.com/ ~/backups/example.com/

sending incremental file list
index.html
css/site.css
images/logo.png

sent 412 bytes  received 9,845 bytes  total size is 52,310  speedup is 4.85

Each listed path is a file that would be copied. Replace 203.0.113.10 and deploy with your real address and user.

Step 4: Run the real sync

When the dry run looks right, repeat the command without -n. The first run copies everything. Later runs copy only changes.

rsync -avz -e ssh deploy@203.0.113.10:/var/www/example.com/ ~/backups/example.com/

Step 5: Decide whether to mirror deletions

By default, rsync never deletes anything on the destination. Files you remove from the site stay in the backup, which is a useful safety net. The --delete option makes the backup an exact mirror, removing files that no longer exist on the server. You can also exclude folders you do not need, such as caches:

rsync -avz --delete --exclude 'cache/' -e ssh deploy@203.0.113.10:/var/www/example.com/ ~/backups/example.com/

Step 6: Verify the copy

Run the dry run again. When the backup is current, rsync lists no files and reports a tiny transfer, which means both sides already match:

rsync -avzn -e ssh deploy@203.0.113.10:/var/www/example.com/ ~/backups/example.com/
du -sh ~/backups/example.com

sent 96 bytes  received 22 bytes  total size is 52,310  speedup is 436.75

41M     /home/alex/backups/example.com

Troubleshooting

• Permission denied on some files: the user on the VPS cannot read them. Check ownership with ls -l /var/www/example.com, or use --rsync-path="sudo rsync" if that user has passwordless sudo for rsync.
• Host key verification failed: this is the first connection to that server. Connect once with ssh deploy@203.0.113.10, check the fingerprint, and accept it.
• rsync: command not found on the VPS: install it with sudo apt install -y rsync.
• Transfer interrupted on large files: add --partial so rsync keeps partly copied files and resumes them on the next run.

Next steps

Once the manual copy works, schedule it with the cron guide so it runs every night. Then make sure the copies restore properly using the restore testing guide, since a backup that cannot be restored does not protect you.