Jump to a section +
A provider can honestly say “we take daily backups” while leaving the owner unable to recover. The copy may include files but not the database, remain inside the disabled hosting account, omit DNS and email routing, expire before a slow corruption is noticed, or require a technician whose contact information is outdated. Backup claims become useful only when scope, independence, retention, access, and restoration are defined.
Recovery is also a business decision. A brochure site, appointment system, membership portal, and online store have different change rates and customer consequences. The owner should define which functions matter first and how much recent data can be recreated, instead of copying another company’s schedule or assuming every page must return at the same time.
Separate backup, restore, and recovery
NIST SP 800-34 describes contingency planning as a coordinated strategy involving plans, procedures, and technical measures and includes business impact analysis, contingency strategies, plan development, testing, training, and maintenance. It was written for federal information systems, so a small business should adapt the concepts proportionally rather than claim federal compliance from a website checklist.
Inventory what the website depends on
The recovery package extends beyond what a browser displays.
| Asset or dependency | Possible recovery source | Question to answer |
|---|---|---|
| Code, theme, templates, and build configuration | Version-control repository, platform export, deployment artifact, or verified file backup | Can the exact supported version be built or redeployed without the original developer’s computer? |
| Database and CMS content | Database dump, platform backup, CMS export, or provider snapshot | Does the copy preserve relationships, authors, settings, URLs, and current data formats? |
| Media and downloadable files | Object storage copy, media export, or file-system backup | Are original files present, not merely generated thumbnails or broken external links? |
| Forms, orders, members, and customer records | Approved application export or system-of-record backup | Which data is necessary, sensitive, retained lawfully, and recoverable in the correct system? |
| DNS and domain configuration | Export, recorded zone, registrar inventory, and screenshots as secondary evidence | Can the business identify the registrar, authoritative DNS, records, contacts, locks, and renewal state? |
| Redirects, canonical logic, and SEO configuration | Application rules, server configuration, CMS export, and crawl inventory | Will existing public URLs and search signals still reach the intended content? |
| Integrations and secrets | Documented connection inventory and approved secrets manager | Which systems need new credentials rather than restoring an exposed key from a backup? |
| Accounts, billing, and vendor support | Business-owned access register and contract records | Who can authenticate, pay, escalate, transfer, and recover each service if the usual administrator is unavailable? |
Platform backups have platform-specific boundaries. Webflow’s backup documentation, for example, describes site backups and restoration within Webflow; WordPress documentation describes files and database components. Neither should be generalized to a different stack. Read the current provider’s documentation for included data, retention, export, restore behavior, plan limits, and what happens after cancellation.
Create a recovery inventory without exposing secrets
Draw the customer path
Follow domain and DNS through hosting, CDN, application, forms, payment or booking, email, CRM, analytics, and staff response. Mark which systems are authoritative for each record.
Assign an owner to each asset
Name a business role and technical provider for backup configuration, monitoring, retention, restore, credential rotation, and validation. Avoid relying on one person’s memory.
Record recovery evidence
Keep provider names, account owners, support routes, configuration exports, version identifiers, and restore instructions in a protected location. Reference secrets rather than copying passwords or private keys into the plan.
Classify data appropriately
Identify sensitive, regulated, contractual, operational, and public information so encryption, access, retention, deletion, and restoration follow the organization’s approved requirements.
Identify missing exports
If a hosted tool cannot provide a complete export, document the limitation, alternate records, migration path, and business decision. Do not discover platform lock-in during an outage.
Set frequency and retention from business impact
Recovery point objective, or RPO, expresses the maximum targeted period of data loss for a disruption. Recovery time objective, or RTO, expresses the targeted time to restore a function. They are planning targets, not guarantees. A site updated monthly may tolerate an older content copy, while orders or reservations change continuously and may require a different system, replication, or reconciliation process.
Connect the schedule to the rate and consequence of change.
| Content or function | Change pattern to examine | Recovery decision |
|---|---|---|
| Static marketing pages | Planned releases and occasional edits | Back up at meaningful change points and on a schedule that covers unnoticed errors |
| Blog or CMS library | Editor publishing and revisions | Choose frequency and version retention based on publishing pace and correction needs |
| Leads and form submissions | Unpredictable customer activity | Prefer a dependable system of record and export or recovery path; do not assume a website snapshot includes delivered leads |
| Orders, bookings, or accounts | Continuous transactions and state changes | Use the application provider’s supported continuity and reconciliation capabilities; a nightly page backup may be irrelevant |
| Code and configuration | Deployments, plugin updates, infrastructure and integration changes | Create versioned change records and known-good recovery points before risky releases |
| Domain and DNS | Infrequent but high-impact changes | Record and protect the current state, then capture every authorized change and account handoff |
- Keep enough versions to recover from an error or compromise discovered later, not only the most recent state.
- Protect at least one recovery path from deletion or encryption through the same credentials and system as production.
- Use offline, immutable, or otherwise separated copies when the risk and platform support justify them, and test the actual controls.
- Encrypt backups according to data sensitivity and protect the keys and recovery access separately.
- Monitor failed, partial, unusually small, or stale backups and route alerts to a current owner and backup owner.
- Define secure expiration and disposal so old customer data does not persist indefinitely merely because storage is inexpensive.
The familiar “3-2-1” approach—multiple copies, different media or systems, and an offsite copy—can start a conversation, but it is not proof of recoverability. Cloud copies controlled by one compromised identity may fail together. A separated copy without credentials or documentation may be unreachable. Design from likely failures and test the boundaries.
Logs can show that data moved without proving that every dependency is present, the copy is usable, credentials are available, or the restored site passes business tests. Schedule restore exercises before an emergency.
Protect backups as sensitive production assets
CISA’s business and ransomware guidance recommends protected backups and restoration testing among broader resilience measures. A backup repository is valuable to attackers because it can contain code, credentials, customer data, configuration, and a path to erase recovery. Restrict and monitor access according to its sensitivity; do not expose it through a public file link or a former vendor’s account.
Test a restore before calling the plan complete
Run a safe restoration exercise
Choose a scenario and target
Restore one deleted page, a known site version, or the full service according to the exercise. Use an isolated environment or provider-supported method that cannot overwrite production accidentally.
Start with the on-call materials
Have the designated person use the current access register, instructions, support routes, and backups without relying on the original builder’s undocumented knowledge.
Record elapsed and blocked time
Measure waiting for access, downloads, imports, DNS, vendor support, credential reset, build, and validation separately. Compare the result with the stated recovery targets.
Validate the business path
Check representative URLs, navigation, media, forms, email, booking or purchase in an approved test mode, integrations, redirects, authentication, accessibility, performance, analytics, and staff handoff.
Prove data boundaries
Confirm the restored version and expected missing interval, verify that sensitive data and access are appropriate, and reconcile transactions that occurred outside the recovered copy.
Update the plan
Correct instructions, ownership, retention, export gaps, alerting, and targets. Record the exercise date and outcome rather than changing a review date without testing.
Write the recovery playbook around decisions
A short usable plan is better than a long document nobody can activate.
| Decision | Named information | Approval |
|---|---|---|
| Declare and classify the event | Symptoms, affected functions, evidence, recent changes, and escalation threshold | Incident owner and alternate |
| Contain or fail over | Systems or access to isolate, temporary page or customer route, and evidence-preservation steps | Technical and business authority |
| Select a recovery point | Available versions, integrity evidence, known incident window, and accepted data-loss interval | System owner and data owner |
| Restore in priority order | Domain, DNS, certificate, hosting, application, data, integrations, email, and customer functions | Recovery coordinator |
| Validate and return | Technical checks, business transactions, accessibility, security, data reconciliation, monitoring, and rollback criteria | Named production-release authority |
| Communicate | Internal contacts, vendors, customers, insurers, counsel, and authorities as applicable to the facts | Authorized communications and legal roles |
| Review | Root cause, control changes, missed records, costs, owner actions, and next exercise | Business leadership and responsible providers |
Provider loss belongs in the plan even when no technical incident occurs. The guide for when a web designer disappears explains how to recover domain, DNS, platform, billing, analytics, and records calmly. A good backup reduces dependency, but business-owned access and exportability are what make the copy usable.
Web Respawn’s website care plans can define ongoing backup, monitoring, update, and recovery responsibilities for the website layer. The platforms, hosting, and ownership hub connects continuity planning with domains, hosting, security, maintenance, and provider handoff.
How often should a small-business website be backed up?
Base frequency on how quickly each asset changes and how much loss the business can tolerate. Static pages, code releases, CMS content, leads, orders, and bookings may need different mechanisms. Also back up before risky changes and retain enough versions for delayed discovery.
Does my hosting provider’s backup mean I am covered?
Not until you verify scope, frequency, retention, account dependence, restore process, plan limits, cancellation behavior, and a real test. A provider snapshot may be useful but omit external DNS, email, leads, SaaS data, repositories, credentials, or an independent path after account loss.
Should website backups be stored offsite?
A recovery path separated from the primary failure is often valuable. “Offsite” alone is not enough: consider identity, provider, region, mutability, encryption, keys, retention, export format, and access during an incident. Choose separation according to the system’s risk and test it.
Can I restore a backup after a website is hacked?
Possibly, but do not assume the newest copy is clean or that restoration removes the original access path. Qualified responders should determine the incident window, preserve evidence, select and validate a recovery point, rotate affected credentials, patch the cause, reconcile data, and monitor the recovered service.
Evidence behind the guide
Sources and further reading
- Secure Your BusinessCybersecurity and Infrastructure Security Agency
- Contingency Planning Guide for Federal Information SystemsNational Institute of Standards and Technology
- StopRansomware GuideCybersecurity and Infrastructure Security Agency
- Save and restore Webflow backupsWebflow Help Center
- BackupsWordPress Developer Resources
Continue on Web Respawn
Pages that actually connect to this decision.
These links are selected for the subject of this guide. They are not a generic service dump.
