A website backup checklist should answer one question: can the business restore a working, trustworthy site within an acceptable time and with an acceptable amount of lost data? Identify the files, database, uploads and configuration needed; set a backup frequency from the amount of change; keep protected copies outside the main site; test a restore in an isolated place; and record who can perform it. A successful backup notification is not proof of recovery.
Backups are often treated as a hosting feature rather than a business process. That leaves awkward gaps: the files are copied but the database is not, the archive is stored under the same compromised account, or nobody knows how to reconnect forms after a restore. The UK's NCSC small-business recovery guidance recommends regular backups of essential information, testing that restoration works and assigning responsibilities. The details below are questions an owner can ask a technical partner, not instructions to overwrite a live site.
Start a website backup checklist with the full recovery scope
List everything needed to reproduce the customer experience and business records. Compare the site's published services with the routes that must work after recovery. For a content-managed site this may include application code, themes and plugins, database, uploaded media, environment configuration, scheduled tasks and integration settings. A shop may additionally need product data, orders and payment-provider references. A brochure site may still depend on forms, email routing and DNS. Do not assume that a host's “site files” backup covers every component.
Map dependencies outside the web server. Domain registration, DNS, email delivery, analytics, payment service and third-party embeds may be held in other accounts. A copy of page files will not restore access to an expired domain or a missing form inbox. Record the owner and recovery route for each dependency, with sensitive credentials stored securely outside the document. The website development handover should identify these dependencies before an incident.
Identify business-critical data first. Which records would cause immediate harm if lost? Which can be reconstructed from another approved system? Do not duplicate personal information without understanding who can access the copy, how it is encrypted and when it should be deleted. A backup can preserve sensitive data long after the live site removes it, so retention needs a deliberate policy.
Choose frequency from change and tolerance
Ask how much new information the business can afford to re-enter after a failure. A site receiving orders throughout the day may need a different backup cadence from a site updated twice a month. Set a recovery point objective in plain language: the oldest acceptable state to which you might return. Then set a recovery time objective: how long the main customer route may be unavailable before serious harm. These are planning targets, not guarantees from a checkbox in a dashboard.
For example, a hypothetical appointment site that changes bookings daily would need to examine whether a weekly database backup is acceptable. This is a scenario for planning, not a prescription for a real business. The right cadence depends on transaction volume, architecture, other records and the cost of lost data. Review the choice whenever the site begins collecting a new type of information.
Know whether backups are full, incremental or snapshots and what is required to reconstruct a chosen point in time. If an incremental chain is broken, a recent-looking file may not be enough. Ask how to find the last known clean copy if a problem went unnoticed for days. Retention should be long enough to support investigation but not so long that risk and cost grow without purpose.
Protect copies from the same failure
A backup stored on the same server and controlled by the same administrator account may disappear with the original. Use a separately controlled or otherwise protected copy appropriate to the threat model. CISA's ransomware guide recommends offline, encrypted backups of critical data and regular testing because attackers may try to delete or encrypt accessible backups. The technical design may use offline, immutable or isolated storage; ask the provider to explain the actual protection, not just name a feature.
Restrict who can delete or alter backups. Use distinct access where practical, MFA, encryption and monitored alerts for failed jobs or unusual deletion. Check the credentials needed to restore, not only to create a backup. A business that cannot reach its backup account during an outage has a hidden single point of failure.
Consider physical and provider risks. A local disk can be lost, damaged or left permanently connected. A cloud copy can be affected by account compromise, misconfiguration or provider issues. No location is perfect. The purpose of separated copies is to avoid relying on one system, one administrator or one incident path. Ask for evidence of where copies are stored and how access is controlled.
Ask whether the provider offers a way to detect damaged or incomplete copies. A job may report success after copying only part of a large archive, or may omit a database that was temporarily unavailable. Check job logs, archive size changes and restore-test findings together. Do not publish backup locations or access details in public project documentation. If a provider cannot explain which components are covered, treat coverage as unknown until demonstrated.
Test a restore without harming the live site
Schedule a restore into a staging or otherwise isolated environment. Do not replace production data just to prove the backup exists. Have the technical owner document the chosen copy, steps, time taken, errors and unresolved dependencies. Open representative pages, view uploaded images, log in with a test account if appropriate, and confirm that the database reflects the expected date. Test forms with a clearly marked internal message, making sure it cannot be mistaken for a real customer enquiry.
Compare recovered content with the inventory. Did product images return? Are recent articles present? Do contact routes point to the right inbox? A restored site can be technically reachable yet operationally wrong. If the test uses real personal information, protect the isolated environment and remove the copy when the test is complete under the business's retention policy.
NIST's small-business basics advises protecting and testing backups. The test should make that statement concrete: record whether restoration actually completed and which important tasks worked. A drill that stops when files finish uploading has not tested the business's recovery path. Bring a specialist in where the stack or data sensitivity exceeds in-house capability.
Write a runbook a second person can follow
Name the person who decides to restore, the technician who performs it, the host or vendor contact, and a backup contact for absences. Record how to reach them when the site and business email are unavailable. The runbook should say how to choose a clean copy, isolate a possibly compromised environment, restore components in order, verify data and reopen customer routes. It should also explain where credentials are stored securely, without embedding them in the runbook.
Include a communication plan. If a booking form is down, who changes the public contact information or answers customers through an approved alternative? Avoid making a public promise about recovery time until the situation is assessed. If personal data may be involved, seek qualified incident and legal advice about notification obligations rather than assuming a restore ends the matter.
After a test or real restore, update the runbook with what was difficult. A successful recovery may reveal that a plugin license, DNS step or form integration had to be found in someone's inbox. Capture the dependency and owner while it is fresh. Do not publish operational secrets on a public blog; keep the detailed runbook in a controlled location.
Also plan for a change of vendor. Can the business export a usable backup and the information needed to interpret it without relying on the old provider's dashboard? Who owns the code, database, media and domain? A recovery plan that works only while one vendor account remains active may not survive a billing dispute, closure or account lockout. Test portability before there is urgency, and agree a secure transfer method rather than emailing large archives casually.
Review backup health as an operating control
For each backup job, log the expected schedule, last successful completion, alert recipient and action for a failure. For periodic restore tests, record the date, source copy, recovered components, duration and gaps. Review access to the backup destination after staff or vendor changes. Revisit the cadence when content, orders or customer records grow.
A useful evidence card might say: “The last isolated test restored pages and media, but form mail routing was not verified.” That is more honest and actionable than “backup complete.” Assign a due date for the missing check. A focused audit can ask whether a website's backup covers the actual business workflow; it should not require sending backup archives through an ordinary enquiry form.
For a small site, begin with the simplest verified coverage. For a complex site, ask the provider for a documented recovery design and regular exercises. A website backup checklist is complete only when a person with authority can find a protected, usable copy, restore it safely and prove that the important customer and business tasks work. A backup is valuable because it supports that recovery, not because it creates a reassuring notification.
