The backup tab says success and nothing else
Automatic backups are real, and they are the reason most sites survive a bad day. A nightly job copies the files and the database, the hosting panel shows a green label with a timestamp, and for a small business that is already better than nothing. Building the site with AI makes the copy easier still: the result is a repository, a database and a handful of configuration values, small enough to duplicate in minutes.
What the label cannot tell you is whether that copy can become a working website again. A backup is a file. A website is that file plus a database plus DNS records plus the environment the software ran in. The first is stored; the rest are assumed. The distance between “the copy exists” and “the site came back from the copy” is where a week disappears.
You cannot find out by looking at the dashboard. No panel reports a successful restore, because no restore was attempted. The green label is a record of the copy, not of the recovery, and the two are only ever compared once something has already gone wrong.
What breaks the first time you restore
The most common failure is a partial copy. Panels often back up files and database separately, on different schedules, and a restore can hand you Tuesday’s files with Sunday’s data. The site loads, it shows the wrong content, and orders or enquiries are recorded against versions of the catalogue you changed last month. Nothing in the interface flags the mismatch.
The second failure is everything the copy does not contain. DNS records live with your domain registrar, not on your host. Mail authentication, redirect rules, environment variables, API keys and the schedules of your automations live wherever they were configured. A restore that brings back the pages but not the addresses pointing at them produces a working website nobody can reach.
The third is that the environment has moved on. The archive was taken on a version your current plan no longer offers, a database password changed when the card was replaced, or the site now lives on a domain bought two renewals ago. The files unpack and the application refuses to start.
And sometimes the account itself is gone. A compromised admin panel, an expired card that took the hosting with it, or a colleague who closed the provider account can remove the backup along with the site. A copy stored under the same credentials as the thing it protects protects nothing.
Run the drill somewhere else, and time it
Restoring over the live site proves almost nothing. It tells you the archive unpacks, and if the archive is wrong you have just replaced a working website with a broken one. The useful test restores into a separate location: another directory on the same hosting, a staging subdomain, or a fresh environment on a different provider entirely.
Then open it the way a visitor would. Load the homepage and two or three inner pages, check that images appear, submit the contact form and confirm the message reaches a real mailbox, log into the admin area, and compare the newest content with what you published this week. Each check answers a different question: is the data current, is the media complete, do the integrations still authenticate, can a person still get in.
Give the drill a fixed slot — twice a year for a site that hardly changes, every quarter for one that publishes often — and write down how long it took. That duration is the only number you will actually need when something fails on a Monday morning: “we can be back the same morning” is a plan, and “we have never tried” is not one.
What has to be inside the copy
Files and database are the minimum, not the whole. Alongside them, keep a one-page inventory of everything that lives outside the code: the DNS zone and mail authentication records, how TLS is handled, which domains are registered where, which services the site talks to, and who can log in to what. This document is the part no build tool produces, because none of it sits in the repository — and it is the part you need first when the account is the thing that failed.
Keep a second copy somewhere the site cannot reach. A separate provider, separate credentials, retained long enough to catch a problem you did not notice on the same day it happened. A backup that shares an account with the live site survives hardware failure and very little else: the same compromised password, the same closed account and the same accidental deletion take both at once.
Retention is a decision, not a default. Keep enough history to cover the moment you noticed the damage, which is usually days after it was done — a corrupted export overwrites last month’s files, and the mistake only becomes visible when someone reads the site. Ask what the oldest useful copy would have to be, and keep copies older than your deploy schedule, not just newer than it.
Automation keeps the copy; people prove it
Scheduled backups, off-site copies and alerting on failed runs are all scriptable, and they should be. An AI assistant is genuinely useful here: it can watch the job, notice that a run stopped producing archives, and unpack yesterday’s copy into a test location on a fixed day each week. These are the boring parts of reliability, and automating them removes the most common reason backups quietly stop.
What automation cannot do is judge the restored result. Whether the current price list is present, whether last month’s campaign page survived, whether the form still delivers to the mailbox the sales team reads — that is a short checklist only your team can write, because it encodes what the business actually depends on. An AI-built site makes this sharper: the pages can be regenerated quickly, the specific content, integrations and decisions cannot.
So treat the checklist as the deliverable. Five to ten statements that must be true on the restored site, checked once per drill, updated when the business changes. It costs nothing to write and it is the difference between a backup you have and a backup you can use.
The restore test belongs next to the launch checklist
A backup becomes real at the moment someone restores it. Until then it is a hypothesis stored by a provider you did not audit, under credentials you have not tested, covering a system whose pieces live in four different places. The gap between those two states is closed by one unglamorous afternoon of work, repeated twice a year.
Add the drill to the same list that already holds the mobile check, the form test and the analytics review, and give it an owner. Sites fail in ordinary ways — a bad deploy, a replaced card, a stolen login — and the businesses that come back quickly are not the ones with better hosting. They are the ones that had opened the copy before they needed it.
Related service: Websites and web applications