Website Backups and the 3-2-1 Rule: A Practical Guide

Every other security measure on your site can fail: a plugin flaw, a stolen password, a bad update, a deleted database, a hardware fault. A good backup is what turns any of these from a crisis into an inconvenience. Yet many site owners discover during an emergency that they have no backup, or one that is out of date, incomplete or impossible to restore.

The 3-2-1 rule

The 3-2-1 rule is a simple, long-standing guideline for backup design:

• 3 copies of your data: the live data plus two backups.
• 2 different types of storage or media, so one kind of failure does not wipe everything out.
• 1 copy off-site, in a different location and under a different account from the live site.

For a website, that might look like: the live site on your hosting account, a daily backup stored by the host or the control panel, and a second copy sent to independent cloud storage that your hosting login cannot delete. Some people extend the rule to 3-2-1-1-0: one copy offline or immutable (cannot be changed), and zero errors confirmed through restore testing.

What to back up

1. Files: the website code, themes, plugins and uploaded media.
2. Databases: posts, users, orders and settings. For WordPress this is the most important and most frequently changing part.
3. Configuration: wp-config.php, .htaccess, server and cron settings.
4. Email: mailboxes and their content, if you host business email with the site.
5. DNS records and domain settings: export or record them, so you can rebuild if needed.
6. Documentation: a short list of what is installed, where, and how to restore.

How often

Decide this by asking: how much work can I afford to lose? That is your recovery point objective.

Type of site	Suggested frequency
Brochure site that changes rarely	Weekly full backup, plus a backup before any change
Blog or content site	Daily database and files
Online shop or membership site	Several database backups a day, or continuous, plus daily files

Keep several generations, not just the latest. Malware or a bad update may go unnoticed for days, and if you only keep yesterday's copy, you may only have infected backups. A common pattern is daily copies for a week or two, weekly copies for a month or two, and a few monthly copies.

Where to store copies

• On the same server: convenient and fast to restore, but lost together with the server in a hardware failure, a hack or an account deletion. Treat this as the first copy only.
• Remote storage: object storage, another hosting account or another provider, accessed with credentials that are separate from your site login.
• Your own computer or NAS: a decent extra copy for small sites, if you keep it in a safe place and update it.
• Immutable or versioned storage: protects against ransomware and accidental deletion because old versions cannot be overwritten.

Encrypt backups that leave your server, especially if they contain customer data or personal information, and store the encryption key separately.

Testing the restore

The knowledge base has guides for restoring in Plesk.

A backup is only proven when you have restored from it. At least twice a year, and after any major change in setup:

1. Restore the latest backup to a staging area or a test domain, not the live site.
2. Check that the home page, images, forms, logins and key plugins work.
3. Confirm the database is complete: recent posts or orders are present.
4. Time the process, so you know how long recovery really takes.
5. Write the steps down, so anyone on your team can do it under pressure.

Common backup mistakes

• Relying only on the host's backups with no copy elsewhere.
• Backing up files but not the database, or the other way round.
• Keeping backup credentials stored on the website, where an intruder could delete them too.
• Never checking the logs, so failures go unnoticed for months.
• Storing backup archives inside the public web folder, where anyone who guesses the file name can download them.
• Backups so large and slow that they fail or time out; exclude cache folders and old logs.

Backups and privacy

Backups contain the same personal data as your live site, so they fall under the same obligations. Keep them secure, limit access, and delete old ones on a schedule consistent with your retention policy. If a customer asks you to erase their data, remember that older backups may still contain it; document how long backups are kept so you can explain it.

A worked example for a small business site

Take a WordPress site for a small agency. The owner configures the control panel to take a nightly backup of files and database, kept for two weeks. A backup plugin sends a weekly encrypted archive to separate cloud storage under a different login, keeping the last eight. Once a month the owner downloads one archive to an external drive stored in the office. That gives three copies, on at least two kinds of storage, with two off the server, for very little effort or cost.

Twice a year the owner restores the latest archive onto a test subdomain and opens the main pages, submits the contact form, and logs in. The whole exercise takes under an hour and has already caught a plugin that had silently stopped including the database in its export. That kind of failure is exactly why restore testing matters, and why a log message saying "backup complete" is not enough proof.

Backups you can rely on

Zebra Hosting Cloud hosting plans run on Plesk, which has tools to create and schedule backups and to restore them. Use them, then add an independent off-site copy to complete the 3-2-1 rule. See the security page for how we think about protecting your data.