Server backup strategy: backups using the 3-2-1 rule

In short: A resilient server backup strategy follows the 3-2-1 rule: three copies, two types of storage, one copy off-site. For backups to survive an attack, at least one copy needs protection against deletion by the server itself. And only a successful restoration test shows that the backup works in an emergency.

What the 3-2-1 rule means

The 3-2-1 rule is a simple principle for data backup that has proved its worth for years:

• 3 copies: the original data and two backups.
• 2 types of storage: for example local disk and object storage, or server storage and tape.
• 1 copy off-site: at a different location, with a different provider or offline.

For web servers this means specifically: a backup on the same hard disk as the website does not count as an independent copy. If the server fails or is compromised, both are lost. For management, the key question is therefore not “Do we have backups?” but “Can we restore operations from a copy that the incident did not reach?”

A server backup strategy that survives an attack

Attackers know that backups undo their work. Anyone with access to a server therefore often also looks for backups in order to delete or encrypt them. A modern strategy therefore often extends the 3-2-1 rule to 3-2-1-1-0: one additional copy offline or immutable, and zero errors in the restoration test.

Three principles make backups resilient:

• Pull instead of push: A separate backup system fetches the data from the web server. The web server itself has no credentials with which it could delete backups.
• Immutability: Object storage with a retention lock, or snapshots that cannot be deleted for a set time.
• Separate access: The backup account is not the same as the hosting customer account and has its own second factor.

What has to be backed up

With web servers, often only the web root is backed up. Important parts are then missing for a complete restoration.

Example: backing up database and files

The following example shows the basic building blocks of a daily backup. In practice, a backup tool with encryption, deduplication and retention rules handles the transfer off-site.

#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"

# Back up the database consistently; credentials from a protected file, not in the command
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

# Application files and configuration
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d

# Checksums for later verification
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"

The file .backup-my.cnf contains the credentials of a database user who may only read, and has the permissions 0600. --single-transaction ensures a consistent state for InnoDB tables without stopping the shop.

Then a separate system transfers the backup off-site. It is important that this step is monitored: a backup job that has been failing silently for days otherwise gets noticed only in an emergency. A daily report on success, size and duration is enough, as long as someone reads it and follows up deviations.

If you also use backups or snapshots from your hosting provider, clarify in writing how long they are retained, whether you can restore yourself and whether the backups are preserved if the account is terminated or suspended. These copies are a good complement but do not replace your own independent backup.

Retention: why older states matter after PHP2Shell

After an attack, the most recent backup is not the most valuable one; the most recent clean one is. With PHP2Shell, according to media reports, a first attack attempt was observed on 17 October 2026, and the patches appeared on 21 October 2026. Anyone who retains only seven days may no longer have a state that lies safely before the possible break-in.

A proven scheme combines several periods, for example daily backups for a few weeks, weekly ones for a few months and monthly ones for a year. The exact periods depend on your protection needs and on deletion obligations under data protection law.

Also important: a backup from the time after a break-in can contain webshells or modified files. After an incident, never restore blindly; compare files with a clean state and check them before the website goes back online. Pointers on what to look for are under Signs of compromise. A patch does not remove planted malware, and a backup does not do so by itself either.

Testing and documenting restoration

A backup without a test is an assumption. Only restoration shows whether all parts are present, whether the key works and how long the process actually takes.

• Regularly restore a complete backup in a test environment, including database and configuration.
• Check whether the website then works completely: login, orders, forms, emails.
• Measure the duration and record which steps were manual. Compare the result with the longest time your business can manage without a website.
• Store the restoration guide where it is reachable even if the server has failed, for example in the IT emergency plan.

How does PHP SOS help?

• We check your existing backups for completeness, retention, separation from the server and protection against deletion.
• We set up a 3-2-1 backup with an immutable copy and test restoration together with you.
• After an incident, we identify the last clean state and restore it on a patched system as part of malware removal.
• In the security maintenance contract, we monitor the backups continuously and carry out regular restoration tests.

Frequently asked questions

Sources

• BSI IT-Grundschutz
• BSI: data backup
• php.net: security announcements on PHP2Shell