How to set up automatic backups on a VPS

On a VPS, backups are entirely your responsibility unless you have specifically purchased a managed plan or an add-on that covers them — there is no control panel quietly doing this in the background the way there is on shared hosting. This guide builds a simple backup that covers both your files and your database, scheduled to run on its own, copied somewhere other than the server it is protecting.

A simple backup script

This script archives your website files and dumps your database to a single directory, each named with the date:

sudo nano /usr/local/bin/backup.sh

#!/bin/bash
set -e

DATE=$(date +%F)
BACKUP_DIR=/var/backups/site
mkdir -p "$BACKUP_DIR"

tar -czf "$BACKUP_DIR/files-$DATE.tar.gz" /var/www/example.com

mysqldump -u appuser -p'a-strong-password-here' appdb | gzip > "$BACKUP_DIR/db-$DATE.sql.gz"

find "$BACKUP_DIR" -type f -mtime +14 -delete

The last line removes anything older than 14 days from local storage, so the backup directory itself does not grow forever — adjust the number of days to whatever you can afford in disk space.

Make it executable:

sudo chmod +x /usr/local/bin/backup.sh
sudo chmod 700 /usr/local/bin/backup.sh

Schedule it with cron

sudo crontab -e

0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

That runs the script at 3am every day. See setting up a cron job on a VPS if the five-field schedule syntax is unfamiliar. Redirecting output to a log file, as above, means a failure produces something you can actually go back and read rather than a silent, unnoticed skip.

Copy the backup off the server

This is the step that actually makes it a backup rather than just an archive. From a second machine — another server, or your own computer — pull the backup directory down with rsync over SSH:

rsync -avz -e ssh yourname@203.0.113.10:/var/backups/site/ /local/backup/path/

Schedule that command with cron on the receiving end, so it runs automatically after the VPS has finished generating the day's backup — leave enough of a gap between the two schedules for the backup script to finish first. Transferring files to a server with SCP and SFTP covers the underlying tools in more detail if you would rather push instead of pull, or move files manually as a one-off.

Test that a restore actually works

An untested backup is a hope, not a plan. Periodically restore a copy somewhere other than the live server and confirm it genuinely works:

tar -xzf files-2026-08-26.tar.gz -C /tmp/restore-test
gunzip -c db-2026-08-26.sql.gz | mysql -u appuser -p appdb_test

Check the extracted files look complete and the database import finishes without errors. Doing this once, when the backup is first set up, and then again every few months, is enough to catch a script that has silently stopped working — a corrupted dump, or a path that no longer exists after the site was moved — long before you actually need to rely on it.

What this script does not cover

• Off-site redundancy beyond one location. Consider keeping backups in more than one place if the data is genuinely critical.
• Point-in-time recovery. A daily backup can lose up to a day of data if something happens shortly before the next run. If that gap is not acceptable, look at your database engine's own binary logging or replication features.
• Encryption of the archive itself, if the backup destination is not somewhere you fully trust — gpg can encrypt the files before they leave the server if this matters for your data.

If backups and their management are something you would rather not own yourself, that is exactly the kind of task a managed VPS plan is meant to cover — see managed versus unmanaged VPS, or contact us to check what is included on your plan.