There is a sentence we repeat internally whenever backups come up: a backup is only real once it has been restored somewhere. Until that moment it is a file you hope is complete, produced by a job you hope ran, sitting on storage you hope is healthy. Hope is not a strategy we are comfortable selling, so our backup routine is built to replace each of those hopes with something we have actually watched work.
This article walks through that routine: how the schedule works, why we keep backups in daily, weekly, and monthly tiers, and the part we consider most important, the restore drills. None of it is glamorous. All of it is the difference between an incident that costs an hour and an incident that costs a business its history.
The schedule nobody has to remember
Backups on our platform run on an automatic schedule. Nobody triggers them, nobody has to remember them, and no client is ever asked to think about them. This matters more than it sounds. Any routine that depends on a person remembering to do it will eventually meet a vacation, a busy week, or a handover, and that is exactly when it fails. So the schedule is part of the hosting platform itself, the same way TLS certificates renew themselves and security patches roll out across the sites we host. It runs whether the week is calm or chaotic, and our monitoring raises an incident if a scheduled backup ever fails to appear, because a silently missing backup is the most dangerous kind.
Every backup covers the pieces a site actually needs in order to come back: the database, the uploaded files, and the configuration that ties them together. A database dump without the files is a site full of broken images. Files without the database are a folder of orphans. We treat them as one unit because a restore treats them as one unit.
Why retention comes in tiers
We keep daily, weekly, and monthly backups, and the reason is that different problems are discovered on different timelines.
Yesterday's mistake is the easy case. An editor deletes the wrong page, an import goes sideways, a bulk update touches more content than intended. Someone notices quickly, and the most recent daily backup contains everything from before the mistake. This is the scenario most people picture when they think about backups, and it is the least demanding one.
The harder case is the problem nobody noticed for weeks. A form that quietly stopped saving submissions. Content that was overwritten during a cleanup and only missed when someone went looking for it. By the time a problem like that surfaces, every daily backup already contains it. This is what the weekly and monthly tiers are for: they let us reach back past the point where the damage began and recover what was true before it. Retention tiers are not about hoarding data. They are about matching how long it realistically takes to discover that something went wrong.
A green checkmark is not proof
Every backup system in the world will happily show you a green checkmark. The job ran, the file exists, the size looks plausible. We watch those signals too, and they are useful for catching a job that failed outright. But a checkmark cannot tell you whether the database dump will actually import, whether the file archive is complete, or whether the snapshot happened to capture a site mid-update in a way that will not come back cleanly.
The only test that answers those questions is a restore. There is no shortcut, no clever verification that substitutes for it, and every team that operates backups seriously arrives at the same conclusion sooner or later. We would rather arrive at it on a quiet afternoon than during an outage. So instead of trusting the checkmark, we rehearse.
What a restore drill looks like
A restore drill is exactly what it sounds like. We take a real backup of a real site and bring it back to life in an isolated environment, the same way we would if the original had been lost. The database is loaded, the files are put in place, the configuration is applied, and then a person, not a script, opens the site and checks it. Do the pages render, can you log in, is recent content present, do uploaded files open.
Two things come out of a drill besides confidence. The first is a number: how long a restore actually takes, from decision to working site. When a real incident happens, that number is the honest answer to the only question a client asks, which is when will we be back. The second is friction found in peacetime. A step missing from the runbook, a credential only one person had, an archive that takes longer to fetch than expected. Every one of those is cheap to fix on a normal day and expensive to discover under pressure, which is the entire point of rehearsing.
Because we run the same production stack locally that our servers run, the environment a backup is rehearsed into behaves like the environment it would be restored into. A drill that passes is evidence, not an approximation.
Restores as an everyday tool
Something we learned along the way: when restores are routine, they stop being an emergency-only skill. We regularly pull copies of production databases, scrubbed of personal data, into development environments as a normal part of building features, which means the restore path gets exercised constantly rather than once in a while. The same machinery powers our handover packages: any client can ask for a complete export of their site that restores with a single command, as a standard part of how we work rather than a negotiation. We can offer that calmly because restoring is something we do all the time, not something we dust off in a crisis.
What this means for you as a site owner
If you own a website, ours or anyone else's, the useful takeaway is a short list of questions. Are backups automatic, or does someone have to remember them? Do they cover the files and the database together? How far back can you reach, and does that match how long it might take to notice a quiet problem? And the question that matters most: when was a backup last actually restored, and how long did it take?
Whoever looks after your site should be able to answer all of these without checking. We built our routine so that we can, and we would encourage you to expect the same wherever your site lives. A backup you have watched come back to life is worth more than any dashboard full of green.