Website backup and restore checklist: plan recovery

A useful website backup plan explains what can be recovered, how far back you can go and who will carry out the recovery. Before accepting “backups included”, ask for a list of covered systems, retained recovery points and a safe demonstration that the agreed website can be restored. A successful backup notification alone does not answer those questions.

This website backup and restore checklist helps a business agree recovery requirements with its website supplier or hosting provider. The right arrangement depends on what the website stores and how the business uses it. A five-page service website, an editorial site and an online shop can have very different recovery needs.

1. List what the website depends on

Start with the pieces needed to run the site, rather than the name of a backup product. Include page content, images, code, configuration and any database. Then list connected services separately: a form destination, booking system, payment provider or customer relationship management system may hold information outside the website's hosting account.

A copy of the visible pages does not necessarily include those other records. For example, WordPress explains that a typical full backup needs both website files and the database. Downloading its files alone does not capture the database. The files and database should also represent a compatible point in the site's history, particularly around updates.

For a site built from a code repository, ask what else is needed to rebuild and publish it. GitHub's backup guidance distinguishes the data included in different backup methods. A repository copy is useful, but it should not be assumed to contain every uploaded asset, external record, account setting or deployment requirement.

Use a small coverage table to make these boundaries visible. This is a planning worksheet, not a claim that every website needs every row. Replace the examples with the systems your business actually uses and record the responsible owner for each one.

2. Agree acceptable data loss and downtime

Two plain-language questions make the plan more useful: how much recent information could the business afford to lose, and how long could the relevant service be unavailable? Answer them for the business process, not just for the homepage. A static brochure page and a system accepting paid orders may deserve different answers.

These questions correspond to the recovery point objective, or RPO, and recovery time objective, or RTO. AWS defines these recovery objectives in terms of an acceptable data-loss window and maximum acceptable service interruption. Treat them as agreed planning targets. They are not evidence that a particular supplier can meet them under every incident.

For example, a daily recovery point can leave a gap containing changes made after the latest successful backup. Its existence says nothing by itself about how quickly someone can locate it, obtain access, restore it and verify the result. Ask the supplier to connect the proposed schedule and recovery process to your stated targets.

Avoid selecting “no data loss” or “instant recovery” simply because those phrases sound reassuring. Explain which information cannot be recreated and which business activities can temporarily use an alternative route. Then agree a feasible arrangement, its cost and any limitations. Record the hours during which recovery help is available, including how an incident outside those hours will be handled.

3. Keep usable recovery points for long enough

Backup frequency and retention answer different questions. Frequency concerns how often a new recovery point is created. Retention concerns how long older points remain available. A frequent backup that repeatedly replaces the only copy may offer little help when an unwanted change is discovered several days later.

Ask how many versions are retained, how their dates are identified and what happens when storage limits or a subscription change are reached. Include the time your team might need to notice a problem. If nobody reviews content for several weeks, a very short retention window may expire before an accidental deletion is discovered.

Clarify how the recovery copies are separated from the live environment and who can modify or delete them. A copy affected by the same mistaken account action or security incident may not provide the independence you expected. Discuss access controls and protection with the responsible provider rather than assuming that a second folder or automatic synchronisation is sufficient.

Keep the plan practical: identify the recovery location and responsible account owner without putting passwords, secret keys or customer records in a shared brief. Record where authorised access instructions are maintained. Also agree who receives failure notifications and what they do when a scheduled backup does not complete.

4. Distinguish rollback, selective recovery and full restore

Different problems call for different recovery methods. A deployment rollback returns the published site to an earlier version. Selective recovery retrieves a particular file, page or record. A full restore reconstructs the covered environment from a recovery set. Ask which of these methods your arrangement supports and what each one changes.

For example, Cloudflare Pages documents rollback to a previous successful production deployment. That is useful for a problem introduced by a deployment. It does not establish that a separate booking platform or external customer database will also return to that moment. Confirm each dependency's behaviour rather than treating “rollback” as a universal undo button.

Before restoring older data, identify changes made since that recovery point. A complete database restore may replace valid newer information along with the unwanted change. Decide whether those later records can be preserved, reconciled or recovered separately. The person authorising recovery should understand that trade-off before a destructive operation begins.

Record the decision path in ordinary language: who assesses the issue, who approves the chosen recovery point and who performs the work. Include a way to keep the current state available for investigation when appropriate. The recovery plan should explain how the team chooses a method, not encourage a business owner to experiment on the live site.

5. Demonstrate a restore in a safe environment

Ask for a coordinated restore test before relying on the plan. AWS recommends periodic recovery testing to check that backup data can be recovered and used. The practical question is whether the agreed recovery set produces a usable site, not whether an archive file exists.

Use an isolated test destination agreed with the technical owner. Keep restored customer information access-controlled and prevent test copies from sending real notifications, accepting payments or overwriting live integrations. The responsible team should decide what data is appropriate for the test and how it will be removed afterwards.

Review the restored pages, images, navigation and necessary configuration. Check a representative business journey using coordinated test arrangements. A page rendering correctly does not prove that its connected service is configured correctly. Where a dependency cannot safely be exercised, record that limitation instead of marking the whole journey as demonstrated.

Keep a short test record: the recovery point used, covered systems, destination, start and finish times, checks performed and unresolved issues. Measure the stages that matter to your agreed recovery objective, including access and verification. Repeat the relevant checks after material changes to the site, hosting or recovery arrangement, with a review frequency agreed for your circumstances.

6. Work through one realistic recovery decision

Consider a hypothetical consultancy with a small service website. Its pages are published from a repository, and enquiries are retained in a separate system. On Tuesday afternoon, the team discovers that a Monday deployment removed a service page. A new enquiry arrived on Tuesday morning.

The first question is whether the problem affects only the published pages or also the enquiry system. If a previous deployment contains the missing page, the team can assess a deployment rollback without assuming it must restore the separate enquiry records. It checks what other website changes would also be reverted and whether retrieving the single page is a better option.

In an isolated preview, the responsible supplier demonstrates the proposed version and verifies the agreed links and form configuration. The business owner reviews the affected changes and authorises the live recovery through its established process. The enquiry system's newer record is considered separately because its storage and recovery arrangements are separate.

This example describes a decision method, not a reported client result or a promise of recovery time. For an online shop with orders stored in the website database, the same decision would need to account for orders created after the proposed recovery point. The useful lesson is to map where information lives before choosing what to restore.

7. Put recovery responsibilities in the agreement

Finish with a short checklist that both sides can answer. Keep it with the website handover materials and revisit it when the site changes. It should remain understandable to the person who would need to report an incident, even if that person did not commission the original project.

• We know which website components and external systems are covered.
• We have agreed recovery objectives, backup frequency and retention.
• We know who checks failures and who can obtain authorised recovery access.
• We understand the supported recovery methods and the risk to newer data.
• We have a dated restore-test record with its limitations and next actions.
• We have agreed responsibility, availability and any separate recovery charges.

Add unresolved requirements to the website project brief. If recovery planning accompanies a replacement site, use the redesign checklist for the wider transition. A clear recovery agreement reduces guesswork when an incident occurs; it should describe what has been arranged and demonstrated.

Digital Studio's website service starts at EUR 2,190 for a one-off build of up to five pages using supplied content, with responsive design, SEO foundations, one lead form and launch on your domain. Backup arrangements, restore testing and ongoing recovery support need to be discussed and explicitly scoped for your project. Describe your website and recovery requirements so responsibilities and any additional work can be agreed before the build starts.