The short answer
- It is not the backup that counts but the restore: test periodically whether you can actually put a recovery point back.
- The strategy: daily, automatic, in a place other than your site itself, and kept for weeks.
- The timeline to a disaster is made of small, harmless-looking postponements. Recognise them.
- Structural maintenance turns the Friday-afternoon disaster into a non-event.
The neglect timeline
This is how it goes wrong. Not with a bang, but in steps that each look harmless on their own.
- Site goes live. Everyone happy. Backups are on, the hosting says.
- First updates postponed. Busy quarter. Next month will do.
- A plugin is abandoned. Nobody notices; it still works.
- Odd spike in traffic. Probably a bot. No time to look.
- Friday afternoon, quarter past four. Site down. Where is the backup again, and does it work?
Why the restore is the real backup
Backups fail quietly. A tick in the hosting panel says something is being written, not that it is complete, not that the database is included, and not that the file is readable on the day everything depends on it.
So the restore test is the core of any serious strategy: periodically put a backup back on a test location and check that the site works. Only then do you know something, instead of hoping it.
It is an hour of work each time. Put it in the calendar, because nobody does it spontaneously.
Hope is no strategy. A tested restore is.
The strategy in four rules
Rule one: daily and automatic, because by hand means forgotten. Rule two: keep the copies in a place other than the site itself; a backup next to the house that burns down burns with it.
Rule three: keep several generations. Malware or a mistake can run along unnoticed for weeks, and then you want to go back further than yesterday.
Rule four: write down who restores and how, in one findable place. In a panic nobody searches well.
Breaking the timeline
Look again at the timeline above. Every step felt defensible on its own; together they form the shortest route to an offline site and a ruined weekend. The pattern is called postponement, and it is the most expensive habit in website management.
Structural maintenance breaks the pattern: updates at fixed moments and tested, monitoring that beeps before customers notice anything, and yes, that periodic restore test.
Attacks are faster and more automated this year than ever, especially on outdated plugins. Reactive management runs behind them by definition. Boring and arranged in advance wins.
Frequently asked questions
My hosting says backups are included. That is enough, surely?
It is a start, not a strategy. Ask on: how often, how long kept, is the database included, and can you restore yourself. And test the answer, because that is what it all turns on.
How often should I do a restore test?
Periodically, at a fixed rhythm that fits how important your site is. In our maintenance contracts the test is standard work, not an option.
What does good maintenance cost?
Less than one serious outage, and that is precisely the point. After a short technical intake you get a fixed monthly price on paper.
When was your last restore tested?
If you do not know, the answer is too long ago. Tell us what is running; we show what well-arranged maintenance means for your site.