Site backups: test a restore before you need one

Hosting or the last developer told you the backups are on. The day a bad update, a deleted order, a hacked plugin, or a dead server arrives, someone finally opens the copy. They often find only the database, or only the uploaded files, or an archive that lived on the server that just died. The newest useful copy can be three weeks old, the storage password can be missing, and a first restore can take the rest of the day.

A backup nobody has restored is a file with a hopeful name. It is not a way to get the site back.

1. What you actually find in the archive

The shop keeps product photos. The clinic keeps PDFs of invoices. The office keeps a database of orders and leads, and a nightly job often copies only one of those.

A database dump does not include the uploaded photos and PDFs. A copy of the files folder does not include the orders and leads. A snapshot of the web server does not include a database on another machine, and it does not include files in a separate storage account.

"Backups run" is a schedule, not an inventory. The line tells you the job started. It does not tell you how many days of copies you can still pick from, where the newest one sits, whether the database and the files were taken at the same moment, or who holds the key when the archive is encrypted. Those are four separate answers, and each one decides whether a restore works. Ask for them in writing while nothing is broken; on the day of an incident the same questions only get you a ticket in a queue.

Place matters as much as contents. If the only copy sits on the same server, a dead disk takes the site and the backup together. If the storage login belongs to a developer who has left, the company can see the job name and still cannot open the files.

2. Why the green email is not a restore

Someone set the job up once. The panel sent a "backup completed" message, and the team stopped looking. That message means the task ran.

The person who knew the password, the bucket name, and which folder holds the uploads often leaves. The note they meant to write never appears. The next person inherits a green tick and a login they cannot find.

A hosting snapshot covers the machine the panel knows about. It skips a database server you pay for separately, and it skips the storage where the site keeps photos, so each of those needs its own line or it is not backed up.

A backup that has never been restored has never been tested. The first attempt is when you learn that the database was never inside, or that the archive was written by a tool the company stopped paying for three versions ago and nothing opens it now, or that nobody ever timed the run. Then nobody can say whether the site comes back before the working day ends or after it, and the restore turns into an afternoon of guessing. None of that appears in a completion email.

3. What to write down before the next incident

You do not need to read the backup software to start. Ask the person who still has access, and keep the answers in a place the company owns.

Ask the host, not only the person who set the job up. Retention decides whether you restore or reinstall: a host that keeps a single copy cannot bring back last month's orders. Location decides whether the copy survives the machine it protects, and a copy on the host's own machine usually dies with that machine. Encryption needs one specific answer: who holds the key. If the host encrypts and keeps the key, the host can open the archive and you cannot move it to another provider. Also ask which tool writes the archive and which tool opens it.

• Who can start a restore, and how many hours they expect it to take.
• What is copied: the database of orders and leads, the uploaded photos and PDFs, and the settings. Passwords stay in a separate safe place, not in the same archive and not in a chat.
• Where the copy lives: another provider, or at least another server. A backup that exists only on the same server does not count.
• How often the job runs, and how many days back you can still choose a copy.
• Whether the database and the files are taken together, or as two jobs that can drift apart.
• Whether the archive is encrypted, and who holds the key. A copy only the host can open does not move to another provider.
• Which tool writes the archive, which tool opens it, and how to download the raw file without the host's panel.
• One person who runs the restore, and a second person who has already watched it once.

If an answer is "we think so", write "not checked". That line is more useful than a green tick nobody has opened.

Once a quarter, restore onto a separate test environment, not onto the live site. Open a few real pages and one recent order or lead. Write down how long it took, because that number is how long the next incident will take.

A real restore has a start time and a stop time. Use a separate environment that can hold a copy of the site without touching customer orders, note when you started, and note when the pages were usable again. Then compare what matters: a few real pages, one recent order or lead, the files behind it, and the settings that send mail. Run it with two people, because the person who writes the page and the person who later follows it are rarely the same. What you learn is more than the duration. It is which of your notes were wrong, which access was already gone, and which step nobody had written down.

How often you repeat it follows the data, not the calendar. A brochure site whose pages can be rebuilt from the repository needs no more than the quarterly pass. A shop in season, a clinic whose appointments sit in one database, or an office that sends invoices from stored records should not go a quarter without practice, because every week without a proved restore is a week of records nobody can rebuild. Ask what disappears if the copy turns out to be a month old, and how long the business can work without it.

Do not treat the live site as the test. The copy you open must not take orders from customers, and a separate environment is how you prove the archive before anyone edits the live site, which is the same gap as patching a live site with nowhere to test. Whether a restore has been proved belongs on the technical audit checklist.

4. What one session produces

One session is an inventory plus one test restore, not a new hosting contract. You leave with a single page: what is copied, where it lives, how to restore it, and who has access.

The next person who inherits this system needs that page more than a history of the tool. On it: what is copied, when the job runs, where the copy lives, which tool opens it, who has access, and the restore steps in the order you ran them. The page costs less than any failure above, and it is the only part of this work that survives a change of host, a change of developer, or a change of role inside the company. Without it, the knowledge sits in one person's memory and ends there.

That is ordinary maintenance on the system you already run. Services cover that pass, and selected work keeps each result next to the operation that produced it. Nobody on the team has watched a restore happen yet, and nobody wrote down what is copied; the Laravel handover and support service produces that page and one restore you can see. If you want the page written, send what the host claims is backed up and who still has the login. Anything that carries a password stays on your side.