What Should a Website Backup Actually Recover?

A backup job can finish successfully while recovery remains untested. The success report does not show that the copy can bring back the parts of your website the business needs. Even a restored homepage tells you little about whether staff can sign in, find customer records or open uploaded documents.

Start with the work. What would you need to do on the website after losing it? Then ask your provider to show what would have to come back for that work to be possible.

A booking and its attachment belong together

Imagine a booking website that stores appointments in a database and customer documents as uploaded files. This is a hypothetical example, but the problem is easy to picture: you recover the appointment, click its attachment and find that the document is missing.

You have the booking details. You still cannot do the job that needs the document.

For a typical WordPress website, the WordPress backup guidance explains that both the database and files matter and should be kept as a consistent set. Other websites can be built differently. Ask where your records and uploads actually live rather than assuming a backup of one folder covers them.

The website software, its settings and the access needed to restore and use it also matter. So do connected services. The Australian Signals Directorate's system management guidance calls for recovering data, applications and settings to a common point and identifying dependencies beforehand. For an owner, that means asking whether the pieces will work together, and who has the access to put them back.

How much recent work could be missing?

A restored copy represents a point in the website's past. A booking made after that point may be absent, even when the restoration works exactly as intended.

Ask your provider to name the point they could recover to and explain how old that information would be when you needed it. Then consider what the missing work would mean. Could staff reconstruct it from another record? Would customers need to be contacted? The acceptable answer depends on what your website does.

There is also the time spent getting back to work. Copying data back is only part of it. Someone needs to restore the other pieces and check that the important tasks work. AWS's recovery testing guidance recommends testing separately, checking that restored data is accessible and usable, and measuring its age and the time needed to restore and validate it against the business's needs.

Ask how long those steps took in the test. That gives you something concrete to discuss. It is not a promise of how long a whole future incident will last, including finding the problem and deciding what to do.

The payment may still have happened

Return to the booking example. Suppose the customer paid a deposit through an outside payment service. Restoring an older website copy does not undo that payment or prove that the website's records agree with the payment service.

If the booking itself is held in an outside booking service, it may not be in the website backup at all. Ask which system holds the record your staff should rely on, what that service can recover and how someone will check the records against each other. Restoring your website cannot turn back everything connected to it.

Ask to see a safe restoration

The useful next step is a planned restoration by authorised people in an isolated environment. Agree who will do it and what they will check. The restored copy needs to protect personal and business information, stay out of public view and leave live records untouched.

It must also be prevented from sending real emails, taking payments, triggering automatic requests to other services or creating live bookings. Controlled test accounts and test connections can help where available. If a service cannot safely be used in the test, record that limit and check its role separately.

In our hypothetical example, the provider would restore a consistent copy, sign in with controlled access, open the chosen booking and its attachment, and compare them with what should exist at that recovery point. That is much more useful than a screenshot of the homepage.

There is a historical reminder of why this matters in GitLab's account of its January 2017 database outage. Expected database backups were unavailable and failure emails had been rejected; recovery relied on another snapshot. The loss affected GitLab.com database information, not repository data or self-managed customers. It illustrates the gap between having backup arrangements and having a usable way back.

Use the result to decide what needs changing

Ask for a short record of what was restored and from which point, which tasks were checked and what happened. It should also state how old the restored information was, how long restoration and checks took, what access and connected services were needed, and what failed or remained untested.

A successful booking check demonstrates that task under those test conditions. It does not prove every record is intact, every feature works or every future recovery will take the same time. An isolated copy also does not by itself establish that a recovered website is secure or free of an attack.

Put that result beside what your business needs. You may have enough evidence that the agreed cover fits. You may find a specific gap, such as missing uploads or unavailable account access. Or the test may leave an important task unanswered and need to go further.

If you are discussing website maintenance with LINK-V, bring the tasks your staff and customers would need after recovery. What should be covered, and any restoration testing, can then be agreed for your website.