Backups Done Right

A backup you have never restored is a theory. Most people find out which side of that line they are on at the worst possible moment: a hacked WordPress site, a plugin update that empties a database table, a hosting account closed after a billing mix-up, or a folder deleted in the belief that it was the staging copy.

This guide builds a routine that works on shared hosting, a VPS or a managed plan, then shows you how to prove that it works. The procedure is the same everywhere. Only the tools change. You will decide what to copy, how often, where the copies live, how to automate the job, and how to restore into a test area.

None of it needs special skill. It needs an afternoon, a storage account that is separate from your hosting account, and the discipline to do one restore in daylight, before an emergency makes you do it in the dark.

What to back up

A website is two things that must stay in step: files and a database. The files are themes, plugins, uploaded images, configuration such as wp-config.php or .env, and any custom code. The database holds the posts, orders, users and settings. A copy of one without the other is rarely useful. Uploads from last Tuesday with a database from last month give you images that no page refers to.

Then there is everything around the site that nobody thinks of until it is gone. Mailboxes hosted with the site. A written list of your DNS records (a zone export takes a minute). The settings of external services: the payment gateway keys, the newsletter list, the analytics property. Put these in a plain text file and keep it with the backups.

Leave out what can be rebuilt cheaply: cache directories, log files, and the node_modules folder of a project you can reinstall. Smaller backups run faster and cost less to store, and a fast backup is one that actually gets run.

How often

Choose the frequency by asking how much work you can bear to lose and redo. That figure has a name, the recovery point, and it is set by the gap between copies. The second number is how long you can be offline while you restore, which depends on how well you have practised.

A shop deserves particular care. If the database is restored to this morning's copy, any order placed since then exists only in the payment provider's records and in a customer's inbox. Frequent database dumps are cheap, because the database is usually small next to the uploads folder.

Where the copies go

Follow the 3-2-1 idea: three copies of the data, on two kinds of storage, with one copy off-site. The live site counts as one copy. A practical version for a small site is your host's daily backup, a weekly copy to cloud storage under a separate account, and a monthly download to your own computer or an external drive.

"Separate account" is the part people skip. If the backups sit in a storage bucket that your hosting login can also delete, then whoever steals that login (or whichever script goes wrong) can remove the site and its backups in one go.

Setting it up, step by step

The exact buttons differ by host, but the sequence does not. This version assumes a typical shared or VPS account with shell access. If you only have a control panel, use its backup screen for steps 2 and 3 and skip the commands.

1. Create a storage location that is not on the web server: a bucket or folder at a different provider, with its own login and its own two-factor authentication.
2. Switch on your host's built-in daily backup and note how many days it keeps and where it stores them. If it keeps them on the same server, treat it as one convenience copy, not a safeguard.
3. Dump the database with a proper tool. For MySQL or MariaDB:

mysqldump --single-transaction --routines --no-tablespaces \
  -u dbuser -p dbname | gzip > /home/user/backups/db-$(date +%F).sql.gz

The --single-transaction flag takes a consistent snapshot of InnoDB tables without locking the site. Copying the raw database files while the server is running does not give you that, and the result may not start.

4. Archive the files, leaving out what you can rebuild:

tar --exclude='wp-content/cache' -czf /home/user/backups/files-$(date +%F).tar.gz \
  -C /home/user/public_html .

5. Encrypt anything that leaves your control, for example with gpg --symmetric --cipher-algo AES256 file, and store the passphrase in your password manager, not next to the backup.
6. Copy the result off the server with rsync -av /home/user/backups/ [email protected]:site1/, or with your cloud provider's command line tool.
7. Schedule the whole thing with cron, for instance 30 2 * * * /home/user/bin/backup.sh, which runs at 02:30 every night. The cron helper will check the syntax for you.
8. Make the script tell you when it fails. Cron can email the output, and a non-zero exit code should be loud, not buried.

On WordPress without shell access, a backup plugin that writes to external storage does the same job. Choose one whose output you can open without the plugin installed, and keep a note of which plugin made the files.

Retention: how long to keep what

Problems are often noticed late. A defaced page nobody visits, a product catalogue that lost 200 images, malware that sat unnoticed for three weeks. If you only keep the last seven days, every copy you hold may already contain the damage.

A workable scheme is fourteen daily copies, eight weekly copies and twelve monthly copies, trimmed to what you can afford. The sums are small: for a 2 GB site that is about 34 copies, roughly 70 GB at worst, and far less with incremental or deduplicating tools.

Test the restore

This is the step that turns a theory into a backup. Do it once now, then again every quarter or after any major change to the site.

1. Create an empty staging area: a subdomain such as restore-test.example.com, or a local copy on your own machine.
2. Download the latest backup from the off-site location, not from the server, so you test the real path.
3. Unpack the files with tar -xzf files-2026-10-04.tar.gz -C /path/to/staging.
4. Create an empty database and load the dump: gunzip -c db-2026-10-04.sql.gz | mysql -u dbuser -p stagingdb.
5. Edit the configuration so the staging copy points at the staging database, and change the site URL if the application stores one.
6. Open the staging site. Check the newest post or order, the images, and the admin login.
7. Time the whole process and write the steps down, including where the passphrase lives.

Verifying it

Do a ten-minute review once a month. Look at the size of the newest database dump: it should be close to the previous one, and a file of a few hundred bytes means the dump failed. Run gunzip -t db-2026-10-04.sql.gz to test the archive, and ls -lh on the backup folder to see that a file appeared for each day. Open the off-site storage and confirm the newest file is there and dated correctly. If the backup script emails you, check that the email still arrives.

Common failures

• Backups that silently produce empty database files because the password changed.
• Backups stored on the same server, so a disk failure or a hacked account takes both.
• Backups that depend on a plugin which has since been removed, leaving files nobody can read.
• Backups with no one responsible for checking them.
• Backups that include malware, because nobody looked for it before the copy that mattered was overwritten.
• An encrypted archive whose passphrase was kept only on the server that died.

Loose ends

Is my host's backup enough?

It is a good first layer, but it lives with the same company and often the same account. If the account is suspended or compromised, you may lose both. Keep one copy elsewhere.

Can I just copy the database folder?

Not while the database is running. Use mysqldump or a tool that takes a consistent snapshot.

How big will this get?

Uploads dominate. Incremental tools such as rsync with hard links, or dedicated backup programs that deduplicate, store each unchanged file once.

Do I need to back up email?

If your mailboxes live with the site, yes. If they are with a dedicated mail provider, check what that provider keeps and for how long.

The checklist

• Files and database both included, plus a note of DNS records and external service settings.
• Frequency matched to how much work you can afford to lose.
• At least three copies, on two kinds of storage, one off-site under a separate login.
• Database dumped with a proper tool, never copied live.
• Copies that leave your control are encrypted, and the passphrase is stored elsewhere.
• Automated with cron or the host's scheduler, with a failure alert.
• Retention covers at least a year in thinning steps.
• One full restore tested, timed and written down, repeated every quarter.
• A named person who looks at the backups every month.

If something has already gone wrong, the troubleshooting guide covers what to check first, and the casebook has a few stories of what recovery looks like when the backups were, or were not, in order.