A backup claim should produce four kinds of evidence: what was captured, how long copies are retained, where they are stored and controlled, and a record of restoration testing. Without those receipts, an enabled setting or a completed copy can be mistaken for an independently available copy or a tested restore.
The right coverage and test scope vary by platform, how often the site changes, the consequences of loss, and the business’s own risk tolerance. This article does not prescribe one frequency, retention period, recovery target, or disaster-recovery promise.
It also does not decide who is responsible for ongoing website management, which host to buy, what belongs in project handover, who owns a domain, or what a maintenance plan should cost. It owns the narrower question: what should a backup claim be able to prove?
A backup file and a recovery plan are different things
A backup is a captured copy. Recovery is the ability to use a suitable copy, with the needed access and instructions, to restore the relevant site state. A provider can run an automatic job and still leave important questions unanswered: does it include the database as well as files, does it retain the time period the business needs, can an authorized person request a restore, and has anyone tested the process without damaging the live site?
For a typical WordPress site, WordPress’s own documentation distinguishes the database from site files and says both are needed for a full restore. That is a useful example of why “downloaded the website” may not be enough. Other platforms have different export, restore, and ownership limits. Ask the provider about the actual system instead of assuming a WordPress answer applies everywhere.
The capture / retention / location / restore checklist
Use one row for each website or material component. Leave a blank where the claim cannot yet be evidenced.
| Evidence area | What the backup claim should answer | Evidence to request or record | Boundary to make explicit |
|---|---|---|---|
| Capture | What is included: application files, database, uploads, configuration, content, media, deployment material, or another defined set? | Backup inventory or job definition with the last successful run. | A copy of one layer does not prove every dependent layer is included. |
| Frequency | What trigger or schedule creates copies, and what change period could be lost between copies? | Schedule, policy, or provider setting; date of the latest completed copy. | The appropriate interval depends on how the system and business change; this article sets no universal cadence. |
| Retention | How many versions or what time window remains available? | Provider retention setting and a list or screenshot of available recovery points where appropriate. | Retention is not the same as a promise that every historical state can be recovered. |
| Storage location | Where do the copies reside, and is the storage distinct from the system whose failure is being considered? | Named storage/provider, account owner, and whether another location exists. | A second copy can reduce one risk without making a recovery guaranteed. |
| Access and control | Who can view, request, download, or restore a copy, and how is access recovered if a relationship ends? | Account-role or documented request path; business-controlled recovery contact where appropriate. | Access should follow actual ownership and security practices; do not share credentials in a checklist. |
| Restore testing | Has a defined copy been restored in an appropriate environment, and what did the test include? | Date, tested copy, environment, responsible party, steps performed, and result. | A test can establish only the scope it exercised; it does not prove every future incident will be simple. |
| Dependencies and exclusions | Which external services, secrets, email settings, DNS, integrations, licenses, or data stores are not restored by this copy? | Dependency inventory and explicit exclusions. | Do not assume a website backup recreates third-party accounts, licenses, delivery services, or business records. |
| Latest successful test | What is the most recent evidence that the documented recovery path worked? | Dated test record, observations, exceptions, and next corrective action. | “Last job succeeded” is not a substitute for a restore result. |
The point of the table is not bureaucratic paperwork. It turns a broad claim into a set of checkable facts before an outage, accidental deletion, or vendor transition makes the gaps expensive.
Check the copy against the system you actually run
Start by naming the site type. A hosted site builder may offer platform-level recovery but limited export. A content-management system may have a database, uploaded media, themes, plugins, and configuration that must line up. A custom application may use a source repository, deployment service, managed database, object storage, environment configuration, and third-party integrations. A static page may have fewer moving parts but still depend on its domain, host account, source files, and deployment path.
Do not extrapolate from another business’s setup. The useful evidence is a current inventory of your material components and a record of which recovery method covers each one.
Test restoration without converting the test into an outage
A restore test should have a defined purpose. It might verify that a selected backup opens, that a database and files can be reassembled in a non-production environment, that a page renders, or that a documented person can request the provider’s restore process. Test only with authorization and a plan that protects the live system.
Record the copy used, the time it represents, the environment, the person or provider who ran the test, the components checked, the result, and anything that was missing. If a test exposes a gap, the honest outcome is a repair question—not a claim that the system is protected because a file exists.
Ask the provider questions that produce receipts
- What exactly is captured, and which important components are excluded?
- What starts a backup, and what is the latest successful capture date?
- How long are recovery points retained, and where are they stored?
- Who controls the account and can request or perform a restore?
- Which third-party systems, licenses, data, or credentials fall outside this backup?
- When was the last restore test, in what environment, and what did it prove?
- If the provider relationship ends, what evidence and access does the business retain?
For the broader choice of which party owns the infrastructure and incident role, read Best Web Hosting for a Small Business. If the business is moving providers, How to Change Web Designers Without Losing Your Website, Domain, Email, or Leads covers the wider dependency inventory and transition sequence.
What the evidence can—and cannot—say
A good evidence record can show that a defined copy exists and that a defined restoration test succeeded under stated conditions. It cannot honestly promise no data loss, a particular recovery time, uninterrupted business operation, or that every outside dependency will return exactly as it was. Those outcomes depend on the system, the incident, access, provider terms, and work performed when recovery is needed.
That is still valuable. It lets a business replace hope with an inspectable recovery posture: what exists, who controls it, what it covers, what it excludes, and when it was last proven.
Sources
- WordPress Developer Resources: Backups, rechecked July 21, 2026.