It may look odd for backups to appear this late in a security series. But a backup is not a device that prevents incidents; it is the device that keeps an incident from becoming a loss. The earlier parts were about closing doors. This one is about what you lose when a door is opened anyway.
Three ways to lose a site that has backups
The same situation recurs in real consultations: “yes, we have backups” — and then the backups turn out to be unusable.
The first line is especially common. WordPress consists of files and a database, and the two are a pair. Images and themes live in files; posts, settings and enquiry records live in the database. With only one half, a restore does not get you halfway.
The third line matters just as much. If the server itself fails or the account is locked, backups stored on that server become unreachable at the same moment. At least one copy has to live outside the site.
A backup setup that fits a founder’s budget
The industry rule of thumb is “three copies, two media, one off-site”. For a small site, that translates cleanly into four lines.
Retention is the underrated one. Keep only seven days and, if you discover a compromise ten days late, there is no clean point left to return to. Quiet problems are discovered late by definition, so keep a month or more where you can.
The restore drill — about an hour
Hence the title. “A backup file exists” and “this file can bring the site back” are two different claims, and the only way to verify the second is to do it.
Do not drill on the live site. Restore into your host’s staging environment or a local copy. One run tells you a surprising amount: how long a restore actually takes, where the credentials you will need are kept, and above all whether the archive is intact.
Afterwards, write down the elapsed time and the steps. During a real incident you will not be calm, and what you need then is not knowledge but a list you can follow.
What a backup does not do for you
One honest caveat to close on. A backup is a rollback, not a repair. If whatever allowed the compromise is still there, the restored site is reachable by the same route. A restore therefore always needs a cause-finding step after it — which is the subject of the final part of this series.
More on operational routines including backups lives in the development workflow archive, and reviewing backup coverage and restorability is part of our optimization program.
Next part
The next part is about visible trust: SSL is definitely enabled, yet the padlock refuses to appear. The cause is usually a single line, and there is a reliable way to find it.