November 2026 • Guide

This page rests on guidance from the UK National Cyber Security Centre (NCSC), two vendor descriptions of the rule and its variant, a Microsoft definition of RPO and RTO, and the text of the GDPR. Statements about our own service come from our product page and were checked on 7 November 2026. We could not fetch a current statement of the rule from CISA, so we cite the NCSC instead.

The 3-2-1 backup rule is a simple test for a website backup strategy: keep at least three copies of your data, on two different devices, with one copy off-site. The NCSC describes the rule in these terms and adds that a cloud copy can serve as the off-site copy. It is a rule of thumb, not a standard, and it does not promise that a restore will work.

This page explains the rule, what a web server must cover, RPO and RTO in plain words, and why restore testing matters more than the backup schedule. It also collects website backup best practices that you can apply on any server. It then maps the backups of our Managed Web Server to the rule, point by point. In short: we provide the first backup copy on separate storage and the restore tools. The off-site copy and the restore tests are your part.

What the 3-2-1 backup rule says

  • 3 copies of your data. The live data counts as one copy, so you need two more.
  • 2 different devices or storage types. A failure of one device must not take out every copy.
  • 1 copy off-site. A fire, a flood, theft or a provider-wide incident must not reach every copy.

The rule was popularised by the professional photographer Peter Krogh in his 2005 book about digital asset management for photographers, according to a glossary entry from the backup vendor Barracuda. That entry does not say he invented the idea. The NCSC states the same three numbers in a 2019 blog post.

The NCSC also points out a limit of the 3-2-1 backup rule: it does not require any copy to be offline. For that reason the NCSC gives separate advice to keep at least one backup disconnected from the systems it protects, so that one incident cannot reach all backups at once.

The 3-2-1-1-0 variant

Some backup vendors extend the rule to 3-2-1-1-0. The backup storage vendor Object First, in an August 2025 post about its work with Veeam, describes the extra "1" as one copy that is immutable or air-gapped, and the "0" as backups verified to have zero errors. This is that vendor's description of a variant, not an official standard. We mention it because both extra ideas, immutability and verification, also appear in NCSC guidance.

What to back up on a web server

A good website backup strategy starts with a list of what the website needs in order to run. The NCSC guide for small organisations names the website and email among the data a business should copy. On a web server the list is longer:

What Why it matters Common mistake
Website files Code, themes, plugins, uploads and media. Uploads cannot be rebuilt from a code repository. Backing up only the code folder and forgetting user uploads.
Databases Orders, users, posts and settings usually live in the database, not in files. Copying the raw database files while the database is running, which can give an inconsistent copy. Use a proper dump or a database-aware backup tool.
Email Mailboxes hold business records. Mail may run on a different server than the website. Assuming that a website backup also contains mail.
DNS zones Without the records, a restored site may not be reachable or mail may stop working. Keeping the zone only in the control panel of the current provider.
Configuration Web server settings, PHP versions, cron jobs, certificates and their private keys. Having to recall settings from memory during an outage.
Secrets and keys Application keys, API tokens and the encryption keys for the backups themselves. Storing the backup key next to the backup.

Write this list down once per site. It becomes the checklist for your restore test later.

RPO and RTO in plain words

Two numbers shape every website backup strategy: they decide how often and how fast you need to back up. Microsoft's training material defines the recovery point objective (RPO) as the point in time to which data must be recovered, which equals the most data loss you accept. It defines the recovery time objective (RTO) as the longest time you can take to bring things back online after a failure. In one sentence: RPO is how much data you can afford to lose, and RTO is how long you can afford to be down.

  • A nightly backup means that, in the worst case, you lose up to one day of changes. That is an RPO of about 24 hours.
  • A brochure site that changes once a month can live with that. A shop that takes orders all day cannot, and needs more frequent database backups.
  • RTO is not a setting. It is a measurement. You only know it after you have timed a real restore.

Website backup best practices: retention, encryption, off-site copies and immutability

Retention

Retention is how many past versions you keep and for how long. Keeping old versions matters because a restore can only go back as far as the oldest copy you kept. A website backup strategy must allow for slow discovery. A site that was hacked three weeks ago and noticed today needs a backup from before the hack. How long to keep versions is a policy decision for your business. There is no single correct number, and we do not give one.

Encryption

A backup holds the same personal data as the live site. Article 32 of the GDPR lists pseudonymisation and encryption of personal data as example security measures. Encrypt backups that leave your control, and keep the key somewhere other than the backup itself. If you lose the key, you lose the backup.

Off-site

Off-site means a different failure domain: another building, and for provider-level risks, another provider and another account. The NCSC accepts a cloud copy as the off-site copy. It also advises protecting online backup accounts with 2-step verification.

Immutability

Ransomware and attackers with stolen credentials try to delete backups first. The NCSC describes access controls that let a backup client only create or append backups, so that malware with that limited access cannot overwrite earlier ones. The NCSC compares this to traditional write-once storage. If you back up to a remote server, give the backup account the fewest rights that still allow it to write.

Restore testing is the real test

Among website backup best practices, this one comes first: a backup that has never been restored is an assumption. The NCSC guide for small organisations says to learn how to restore your backup and to check that it contains all your important data. The NCSC blog adds that backups should be regularly tested. Article 32 of the GDPR also lists regular testing of security measures, and the ability to restore access to personal data after an incident, among its example measures.

A practical restore test takes less than an hour per site:

  1. Restore the latest backup to a different location, never over the live site.
  2. Open the restored site. Log in as an administrator. Place a test order or submit a form.
  3. Compare a few database figures with the live site, such as the number of posts, users or orders.
  4. Check that uploads and images open.
  5. Write down how long it took. This is your measured RTO.
  6. Repeat after any major change, and at least on a fixed schedule such as every quarter.

How our backups map to the 3-2-1 backup rule

The table uses only what our product page documents for the Managed Web Server. Where the page is silent, the table says so.

3-2-1 element What is documented for our Managed Web Server Who provides it
Copy 1: live data Storage on Ceph with three synchronous copies on separate drives. This protects against drive failure. It is not a backup, because a deleted or corrupted file is changed on all copies. Included
Copy 2: backup Nightly incremental backups, included in every plan, stored on a separate storage array. Included
Two different devices The backups are on a separate storage array from the live data. Whether a second array in the same provider counts as a different storage type is your own risk decision. Partly
Copy 3: off-site Not provided by default. The panel can send backups to an SFTP or local destination. You choose and run the off-site destination, for example a server at another provider. You add it
Encryption GPG AES-256 encryption is available in the panel. It is off by default. You switch it on
Scheduling and retention Scheduled backups and retention settings exist in the panel (you can keep from 1 to 1000 backups). The default retention of the nightly managed backup is not stated on our product page. You set it
Restore One-click restore, and restore dry runs in the panel. Included
Restore testing The panel can verify a backup: it checks SHA-256 values, decrypts it and test-restores databases into scratch databases, and verification is on by default. Running restore tests on your own sites and recording the result is a task for the customer. You do it
Immutable copy (3-2-1-1-0) Not stated on our product page. Not stated
Email backup Email is a separate add-on on its own Mailcow server. A full-server backup in the panel includes every mailbox's mail by default. How the mail server itself is backed up is not described on our product page. Not stated

Our managed service includes backup administration, which covers the nightly backups. Your sites and application code remain under your control, so decisions such as retention, the off-site destination and the restore schedule are yours.

Where PFHW fits, and where it does not

PFHW fits if you want the first backup copy to be automatic, on separate storage, with a restore you can start from the panel. The scheduled backups, retention settings, encryption option, SFTP destination and dry runs let an agency or freelancer build a setup that follows the 3-2-1 backup rule, once an off-site copy is added.

  • Off-site copy. It is not part of the default package. You must add a destination at another provider or location. That also means you pay for and monitor that destination.
  • Encryption is off by default. Switch it on, and store the key separately from the backups.
  • Retention default. We do not state it on the product page. Set a value that matches your own policy and test that older versions can be restored.
  • Immutability. We do not state that backups are immutable. If you need an immutable copy, plan it at the off-site destination.
  • Mail. Mail runs on a separate server. Check separately how mail is backed up before you rely on it.
  • Restore tests. Nobody can do these for you. They are the only proof that the rest works.

If you cannot accept that the off-site copy is your task, choose a provider that includes one, and ask the provider how that copy is stored and tested. Ask for the retention period in writing.

Frequently asked questions

What are website backup best practices in short?

Follow the 3-2-1 backup rule, encrypt backups that leave your control, keep several versions, keep one copy offline or append-only, and test a restore on a schedule. Write down how long a restore takes.

Is a RAID array or a replicated storage system a backup?

No. RAID and replication protect against hardware failure. If a file is deleted, encrypted by malware or corrupted, the change is copied to every replica. A backup is a separate, versioned copy that you can go back to.

Does the 3-2-1 backup rule protect against ransomware?

Only partly. The NCSC notes that the rule does not require any copy to be offline, so malware that reaches all connected copies can still destroy them. Keep one copy offline or with append-only access, and test restores.

How often should I back up a website?

As often as your RPO requires. A nightly backup limits the loss to about one day of changes. If you cannot accept losing a day of orders or comments, back up the database more often than the files.

Where should the off-site copy be stored?

In a different failure domain, which is the third copy in the 3-2-1 backup rule: another site, and for provider-level risks another provider with separate login credentials. The NCSC accepts a cloud copy as the off-site copy.

Should backups be encrypted?

Yes, if they leave your control or contain personal data. Article 32 of the GDPR names encryption as an example measure. Keep the key apart from the backup. In our panel the GPG AES-256 option is off by default, so you must enable it.

Related resources

Sources

Request a demo