Backups: present, complete, tested

"We have a backup" is one of the sentences that most often turns out untrue in an emergency. Not because anyone lied — but because "backup" can mean three different things, and only one of them helps. A backup only counts when it is present (it is created regularly), complete (it holds everything needed to restore) and tested (someone has restored from it before). It almost always fails at the third point — and that is the only one that counts in an emergency.

What a complete backup includes

The WordPress documentation puts it plainly: a backup has two parts, the database and the files, and a full restore needs both.

• The database holds all content — pages, posts, settings, users, form entries. Without it the website is empty.
• The files are WordPress itself, the theme, the plugins, the configuration file and above all the uploads folder with every image and document. Without them the design and every image are missing.

A backup with only one of the two parts is not a backup. That happens more often than you would think — when a provider offers "backups" and means only the database, or when someone copied the files and forgot the database. And the configuration file with the credentials is sometimes left out because it holds sensitive data. Without it, restoring becomes laborious.

Where the backup has to live

Not only on the same server as the website. This is the most important rule and the one broken most often. A backup in the same directory helps in exactly one case: when you deleted something by accident. It does not help with a server failure, a suspended or lost hosting account, an attack with server access — the backups are hit as well — or with ransomware.

Germany's Federal Office for Information Security (BSI) recommends the 3-2-1 rule: three current versions, on two different media, one of them in another location. The WordPress documentation says the same more practically: several recent backups in different places, such as one at the host, one in cloud storage and one on your own computer.

For a business website the minimum is: one automatic backup on the server and one automatic copy somewhere else.

How often, and how long to keep them

How often depends on how much work you are prepared to lose. The WordPress documentation suggests weekly for small sites with few changes and daily for active ones. For a shop with ongoing orders, daily is rather too little.

Always additionally before a WordPress update, a theme or plugin update, installing a new plugin and larger rebuilds. That is where a backup is actually needed most often — not after an attack, but after an update that broke something.

How long to keep them is the question hardly anyone considers, and it has a concrete reason: attacks are often discovered late. IBM measures in its annual data breach report an average of 181 days in 2025 before a breach is even noticed. Keeping only the last three days can mean three already compromised backups in an emergency.

A proven working value for business websites is 30 days, better longer. The split: only a few days on the server, the long retention in the second location — storage is cheaper there and does not get in the way of operations.

Where it fails: the restore test

A backup nobody has ever restored from is a guess. The BSI turns this into a basic requirement of its IT baseline protection: it must be tested regularly whether the backed-up data can be restored correctly and in reasonable time.

What goes wrong in practice:

• The file is damaged and will not unpack.
• The backup has been running with an error for months that nobody saw, because nobody reads the messages.
• The uploads folder was excluded because it was "too big".
• The database is there, the configuration file is missing.
• Everything is complete — but nobody knows how to restore it, and in an emergency there is no time to learn.

The honest test: restore the backup on a test environment, open the home page, log into the back end, look at a few subpages, submit a form, check that the images are there. If that works, you have a backup.

The quick test in between: check that the latest backup exists, when it was created and how large it is. A backup that suddenly has a tenth of its usual size is an alarm.

What you need in an emergency

An emergency is not a good time to go looking for things. These details belong somewhere reachable independently of the website:

• access to the host — customer number, login, contact person
• access to the domain registrar, if that is someone else
• access to where the backups are stored
• credentials for the database and file access
• a short guide to the order in which things are restored
• who calls whom

It sounds bureaucratic. It is the difference between two hours and two days.

The order of a restore

In broad strokes — the details are usually done by someone who knows them:

1. Put the website into maintenance mode or take it offline, so no further damage is done.
2. Back up the broken state first. It sounds absurd and it matters: if the restore goes wrong, the broken state is better than none — and after an attack it may be needed to find out what happened.
3. Restore the files.
4. Restore the database.
5. Check the credentials in the configuration file.
6. Check: home page, most important subpages, forms, images, back end.
7. After an attack, change every password.

And then ask why it happened. A restore without looking for the cause means the same thing happens again soon — especially after an attack, where the hole is still open.

What host backups do and don't do

Almost every host advertises backups. That is good, and it does not replace a solution of your own. Three questions:

• How far back do they go? Often seven or fourteen days — too few for an attack discovered late.
• Can you restore yourself, or do you have to ask? If it goes through a ticket, it can take a while at the weekend.
• Can you get single things back or only the whole state?

And the fundamental objection: the backup sits with the same provider as the website. If something goes fundamentally wrong there, both are affected. Host backups are a convenience; your own backup in another place is the safeguard.

Five questions you can answer today

1. When was the latest backup created?
2. Where is it?
3. Does it contain the database and the files?
4. How far back do the backups go?
5. When did someone last restore from one?

If you cannot answer one of them, that is the first task. And a practical look: the last five backups should be about the same size and grow with the content. A sudden drop means something was not included.

What to do

1. Establish the current state — the five questions above.
2. Get a copy off site. If you change only one thing, change this.
3. Extend the retention to at least 30 days.
4. Run a restore test. Once — afterwards you know whether you have a backup or a hope.
5. Make the check part of ongoing maintenance: monthly, whether the backup runs and is complete, and now and then whether it can be restored.
6. Put together the emergency file — access and order, outside the website.

Of all the points in ongoing maintenance, this is the only one where a lapse does not lead to a worse website but to none at all. Everything else can be caught up on. Lost data cannot.

Sources

• WordPress Advanced Administration, WordPress backups — database and files, frequency, copies in several places: developer.wordpress.org
• BSI, proposals for business continuity strategies (guidance on standard 200-4) — the 3-2-1 rule: bsi.bund.de
• BSI, IT baseline protection module CON.3 backup concept — CON.3.A15 regular testing of backups: bsi.bund.de
• IBM, Cost of a Data Breach Report 2025 — 181 days on average until discovery: ibm.com