How to Set Up Automatic Backups (and Actually Test the Restore)

A backup is a claim: "if this server disappeared tonight, we would be running again by tomorrow." Most backup setups have never been asked to prove it. This guide sets up backups that run without you and then makes you do the one thing that turns a claim into a fact.

What "backed up" means: 3-2-1

Three copies of the data, on two different kinds of storage, one of them somewhere else. For a web server:

1. The live data on the server.
2. A backup on the server or its provider's storage (fast to restore from).
3. A backup somewhere unrelated — another provider, object storage, a NAS at the office — that a compromise or billing failure at the first provider cannot touch.

A backup that lives only on the same disk as the site is a copy, not a backup. RAID is not a backup either; see RAID levels explained.

What to back up

• Site files — including uploads, which are usually the only irreplaceable part. Code is in git; uploads are not.
• Databases — dumped with a consistent snapshot, not copied as raw files while running.
• Mail — mailboxes, if the server hosts them.
• Configuration — /etc, the panel's config, certificates, cron jobs. Restoring a site is fast; recreating a server's configuration from memory is not.

How often

Daily is the baseline; the question is how much you can afford to lose. A store taking orders loses money for every hour between backups — hourly database dumps are cheap. A brochure site changes monthly; daily is generous. Keep at least 14 daily copies, plus a few weekly ones going back a couple of months, because the malware you find today may have arrived three weeks ago.

Plesk

Backup & Restore on the subscription (or server-wide under Tools & Settings):

1. Schedule → daily, 02:00, full backup weekly and incremental in between.
2. Store in: the server, and remote storage — Plesk supports FTP, SFTP, Amazon S3, Google Drive, Dropbox, Microsoft OneDrive and any S3-compatible bucket. Configure one under Remote Storage Settings.
3. Number of backups to keep: 14.
4. Notify on errors with your email.

Restoring is a click on the backup; you can restore the whole subscription or pick files, a database or a mailbox from inside it. Plesk backups and restore walks through both.

Command line

A script that dumps the databases and syncs everything to a remote destination, run from cron:

#!/bin/bash
set -euo pipefail
DEST=/backup/$(date +%F)
mkdir -p "$DEST"

# databases, one file each, consistent snapshot
for db in $(mysql -N -e "SHOW DATABASES" | grep -vE '^(information_schema|performance_schema|mysql|sys)$'); do
  mysqldump --single-transaction --quick --routines "$db" | gzip > "$DEST/$db.sql.gz"
done

# files and config
tar -czf "$DEST/www.tar.gz" /var/www
tar -czf "$DEST/etc.tar.gz" /etc

# off-site: an S3-compatible bucket via rclone (configured with `rclone config`)
rclone sync /backup remote:server-backups --transfers 4

# keep 14 days locally
find /backup -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +

set -euo pipefail makes the script stop and exit non-zero on any error, so cron's failure notification actually fires — see knowing when cron jobs fail. For deduplicated, encrypted, versioned backups with the same effort, restic is the better tool: backing up with rsync and restic.

Protect the backups from the thing you are backing up against

If a server is compromised, the attacker can read whatever credentials it holds — including the ones to the backup bucket. Two defences: give the server a key that can write but not delete (S3 bucket policies allow this; restic's --append-only REST server does too), and enable object lock / versioning on the bucket so that even a delete keeps the old version for 30 days. Ransomware that deletes backups first is not hypothetical.

The restore test

This is the step. Once a quarter, on a spare VPS or a local VM:

1. Take yesterday's backup from the off-site copy — not the local one.
2. Restore the files and import the database into a fresh install.
3. Point a hosts-file entry at it and load the site. Log in. Open the last order.
4. Time it, and write down every step you had to remember. That list is your recovery runbook.

If any step fails or takes hours of guesswork, you have found out now rather than at 3 a.m. with a customer waiting. Fix it, and test again next quarter.

What VPSPioneer does

Every shared and reseller subscription is backed up daily with 14 copies held on separate storage, restorable from Plesk; every managed VPS gets nightly backups with 14-day off-site retention, and we restore-test the backup system itself monthly. Your own off-site copy on top of that is still the right idea — it is the "1" in 3-2-1, and it is yours regardless of provider.