A website backup is only useful if you can restore it and check that it works. Before relying on your host's backup, find out what it stores, who can restore it and how much activity would be lost between two copies. Rehearse the recovery in a separate environment, without replacing the live site or triggering real operations.
The promise of a daily backup is reassuring until you need it. Then questions appear that were never answered: whether it includes the database, whether it keeps the photographs, and whether access depends on an account nobody knows how to recover. Continuity starts before the incident, while you can still check it calmly.
What does "our host makes backups" actually mean?
Ask them to describe what is included and how recovery works in concrete terms. "Backups included" may refer to a service with conditions you have never read. You need to know what is copied, how long it stays available and who can request or carry out the restore. A commercial name is not a substitute for those answers.
The business guide from INCIBE, Spain's national cybersecurity institute, recommends identifying critical information and checking recovery regularly. It also covers protecting and retaining backups. INCIBE backup guide (in Spanish), 2018 edition, accessed on 10 October 2026. It is used here as a current good-practice reference, not as recent news.
Imagine a cookery school that updates workshop dates in WordPress and receives sign-ups through an external service. The host may store the website while the sign-ups live in another application. If you restore the site, you have not automatically restored every operation of the business. You need to draw that boundary before designing the test.
In WordPress, the official documentation distinguishes between the site files and the database. A recovery strategy must consider both. WordPress backups, accessed on 10 October 2026. Saving only a folder can leave out information needed to rebuild the pages and their settings.
Which parts of the business do not fit in a file backup?
Besides the content, the school in the example depends on the domain, the notification email and the account that receives sign-ups. List those connections and who is responsible for each. It is not an inventory to publish: it exists so that a recovery does not end in a page that is visible but cannot handle requests.
Think in terms of concrete tasks. The person who changes a date must be able to save it; whoever signs up must receive the right confirmation; the team must be able to find the request. Restoring the appearance and restoring the function are different tests. A nice screenshot of the home page does not verify the sign-up journey.
Avoid storing passwords in the continuity document. Note where they are managed and which procedure recovers access. If the only person who knows a key is unavailable, the plan must include a legitimate alternative. Sharing every password with the whole team is not a suitable alternative.
It is also worth identifying what will not be copied and why. There may be temporary data you do not need to keep, or records that require a different policy. The choice should reflect function, sensitivity and how long the data stays useful. Copying everything without criteria can multiply information that nobody controls afterwards.
In the school's rehearsal, a fictitious sign-up and a test workshop date would be enough. You do not need student names or payment histories to demonstrate how the website behaves. Choose a minimal case that exercises the critical functions and avoid moving personal data into an unnecessary environment.
How do you rehearse a recovery without disturbing the live website?
Agree on a separate environment and an observable goal. Do not restore on top of the live site to find out whether the backup works. The test should let you review the result without replacing current content or sending confirmations to real people. Preparing the rehearsal environment is part of the recovery.
Before opening the copy, check which actions it might run on start-up. A form, a scheduled task or an integration can contact real services. The technical owner should limit those outputs in a controlled way during the test, keep data protected and make sure the rehearsal environment does not appear as another public website of the business.
The sequence in the example could be: restore the agreed copy, confirm that the workshops appear, test an internal edit and send a fictitious sign-up to a test destination. Each step needs an expected result. If one piece does not work, keep the incident to find out what is missing; do not declare the test complete because you reached the home page.
| Check | Result to look for | Reason to stop and review |
|---|---|---|
| Content | Workshops and pages from the chosen date | Essential information is missing |
| Files | Required photographs and documents | Missing links or resources |
| Administration | Legitimate access and a test edit | Dependence on an unknown account |
| Form | Fictitious operation to a test destination | It sends to a real person |
| Environment | Limited access and agreed isolation | Another copy of the business is exposed |
The table does not aim to cover every system. It must be adapted to what sustains your activity. A shop with orders needs a different validation; an informational website may have a simpler journey. The test is designed around the relevant operations, without adding complexity that gives no information.
What decisions do you need to make about time and data loss?
Ask how much work you would be willing to rebuild and for how long you can operate another way. These are business decisions before they are technical parameters. A school that receives requests all the time may need a different manual fallback from a studio whose website mainly works as a catalogue.
Two concepts help explain this: the recovery point objective, or RPO, describes the tolerable data loss, measured in time; the recovery time objective, or RTO, expresses the desired recovery time. They are design goals, not results guaranteed by writing two numbers in a document. AWS reference on recovery objectives, accessed on 10 October 2026.
For the cookery school, consider a hypothetical example: if a date changes after the last backup, that change will need to be identified and put back. If requests arrive on an external platform, they may be checkable there. You need to know where each piece of information lives to know what would have to be rebuilt and what remains available.
The rehearsal lets you compare expectations with reality. Record how long it took to restore and validate the journey you tested, without automatically extrapolating it to any incident. A small restore does not show what would happen with a wider outage, a locked account or a damaged backup. The evidence has a specific scope.
What should be documented after the test?
Keep the date of the backup, the procedure used, the functions verified and the failures found. Add who reviewed the result and what is still pending. The document should allow the rehearsal to be repeated, not depend on the memory of whoever did it. An honest record is more useful than a box ticked without explanation.
Define when to check again. A significant change to forms, services or hosting may justify another test. You do not need to repeat everything for each text correction; identify what changes the dependencies. Recovery goes out of date when the system changes and nobody updates the procedure.
Ask the provider for the current service conditions: access to backups, retention and recovery. Do not assume an old screenshot still describes your plan. If part of the process depends on support, note the channel and the minimum information they will ask for, without storing access details insecurely.
How have we approached it at meiika?
Our website and custom systems services let us talk through the journey your business needs. To discuss continuity, explain what you would be unable to do if the website failed. We do not present this guide as a restore carried out for a client, nor do we promise a recovery time.
You can provide a description of the hosting and the connections without sending complete backups or keys. The first goal is to understand the dependencies. After that, we can define which review or test makes sense for the project.