Website Backups and Disaster Recovery: A Practical Guide

Start with four recovery gates

Maintain at least one backup outside the hosting account. Provider-managed recovery points can be convenient, but availability, retention, scope, account isolation and restore permissions differ. A “daily backup” label does not prove that the last job completed, that enough versions remain, or that you can restore within the time the business needs.

01

Impact gate

Identify the business process, transactions, content and customer service affected by data loss or downtime.

02

Coverage gate

Confirm that the recovery point includes every required component, not only website files.

03

Independence gate

Ensure at least one copy can survive failure, deletion or compromise of the production account.

04

Proof gate

Restore in isolation, measure elapsed time, locate the newest recovered change and test the application.

Practical verdict: set recovery point objective (RPO) and recovery time objective (RTO) from real site activity, protect coordinated files and database copies, map external dependencies, and test the full path before an incident.

Backup, snapshot, replication, staging and archive are not interchangeable

Recovery mechanisms and their main limits
Mechanism	Primary purpose	Version depth	Independence	Main limitation
Backup	Recover an earlier data or system state	Multiple points when retention permits	Depends on storage and credentials	Recoverability remains unproven until restored
Snapshot	Create a fast infrastructure checkpoint	Often limited	Frequently tied to the platform account	May share the same account and provider failure domain
Replication	Keep another system close to current	Often mirrors the latest state	Can be independent	Deletion, corruption or malicious changes can replicate
Staging copy	Test changes away from production	Usually current or temporary	Not designed as recovery storage	May be stale, incomplete or reachable through the same account
Archive	Retain records for a long period	Long	Usually separate	Retrieval may be slow and the archive may not be runnable

These mechanisms can complement one another. None is automatically sufficient for every workload.

Set RPO and RTO from the workload

RPO is the maximum acceptable period of lost changes. RTO is the target time to restore an acceptable service. They are planning targets, not guarantees. A schedule can support an RPO only when the job succeeds and the recovery point is usable; a one-click control does not prove an RTO until the realistic restore path is timed.

Starting questions by website workload
Workload	Change pattern	Loss to consider	RPO question	RTO question
Static brochure	Occasional edits	Recent content or configuration	Can the last editing session be recreated?	How long can leads see an unavailable site?
Publisher	Posts, comments and member activity	Editorial work and audience contributions	How much publishing activity can be replayed?	What outage affects deadlines or traffic?
Lead generation	Form submissions	Unexported leads and consent records	How many leads can be lost or reconstructed?	How long can forms be unavailable?
Membership or LMS	Continuous user state	Accounts, progress and payments	How much member activity can be reconstructed?	What downtime breaches expectations?
Ecommerce	Orders, inventory and payment events	Revenue, stock and customer records	How many transactions can be reconciled?	How long can checkout be unavailable?
Agency portfolio	Multiple client sites	Contractual and reputational impact	Define the target per client	Include provider and support dependencies

Printable recovery-objective worksheet

Complete this in a secure operational document. Do not record passwords, private keys or secret values here.

RPO and RTO planning worksheet
System or workflow	Owner	Changes per hour/day	Maximum lost changes	Maximum downtime	Required frequency	Restore path	Last test / measured time

Map the complete recovery scope

A hosting archive may not cover the domain, DNS, mail, third-party services or the instructions needed to rebuild them. Treat files and the database as one coordinated application state, then map the dependencies around them.

Website state

Application files, uploads, themes, plugins, custom code, configuration files and source repository.

Database state

Content, users, settings, orders, stock, form entries, sessions and scheduled-action state.

Email

Messages, accounts, aliases, filters, forwarders, Mail Exchange and authentication records.

Domain and DNS

Registrar control, nameservers, zone records, DNS Security Extensions and renewal ownership.

Runtime

Scheduled jobs, environment configuration, certificates, redirects, server rules and deployment instructions.

External services

Object storage, CDN, webhooks, payment callbacks, analytics, tag management, search verification and licences.

WordPress: official documentation distinguishes files from the MySQL or MariaDB database. A WordPress XML export is not a complete database backup. Keep file and database recovery points close enough to avoid inconsistent application state.

WooCommerce: products, orders and settings live in database tables. Restoring an older whole-site backup can overwrite legitimate orders, inventory changes, form submissions and customer updates created after that point. Plan how new writes will be frozen or reconciled before rollback.

Compare provider evidence, not the word “backup”

The following examples show why product context and caveats matter. They are not rankings and do not prove performance. Every row was checked against the cited official source on 28 July 2026; verify the exact plan because interfaces and terms change.

Selected official backup-policy evidence
Provider and context	Documented evidence	Buyer caveat	Official source
Hostinger managed hosting	Support documents file and database download and restoration controls.	Support and legal wording describe plan-specific retention and customer responsibility differently. Verify the exact plan, recovery points and deletion terms.	Download backups; hosting agreement
Namecheap shared hosting and AutoBackup	Official pages describe full-account archives, plan-dependent restoration and eligible AutoBackup schedules.	Size, inode and product conditions can prevent creation; some full restores require support. Verify eligibility and current limits.	Server backups; AutoBackup
SiteGround hosting	Official documentation describes automatic backups, separate backup servers and component restoration.	Hourly and downloadable backup features vary; high disk, inode or database usage can delay creation. Verify product access.	Backup service
Cloudways Flexible/server context	Official documentation describes configurable frequency, retention, off-site storage and server/application scope.	Retention has platform limits and deleted-server recovery is time-limited. Confirm scope, export path and deletion window.	Server backups
HostGator automatic service example	The official help page describes a weekly backup that overwrites the previous copy for the relevant service.	A single overwritten point offers little delayed-discovery depth. Verify the current package and maintain independent copies.	Backup frequency
cPanel account backup	cPanel documents full and partial backup creation.	A cPanel user cannot automatically restore a full account archive; WHM access or provider support may be required, and quota can affect creation.	Backup Wizard

Twelve fields to record for every plan

Product and plan name.
Scheduled creation frequency and completion window.
Number or age of recovery points.
Files, database, email and DNS scope.
Storage location and failure-domain separation.
Download or open-format export.
Granular, application and full-account restore options.
Self-service or support dependency.
Any stated restore fee.
Size, inode, database or quota exclusions.
Cancellation, suspension and deletion recovery window.
Official source, control-panel evidence and verification date.

Build copies across different failure domains

A practical 3-2-1-style approach can include production data, provider-managed recovery points and an independently controlled export. The numbers are a planning prompt, not a guarantee or universal legal rule. Independence matters more than counting copies that share one account.

Keep at least one copy that cannot be deleted through the production hosting credentials.
Use separate access, multifactor authentication and restricted deletion where available.
Encrypt copies in transit and at rest, and document who controls the encryption keys.
Retain enough version depth to recover from errors discovered days or weeks later.
Record successful-job evidence; a configured schedule does not prove completion.
Download and test an exit copy before migration, cancellation, suspension risk or a major platform change.

For exit planning, use the safe hosting cancellation runbook. For contractual interpretation, review the hosting backup-policy comparison.

Run a production-safe restore drill

Do not overwrite the live website merely to test a backup. Restore to an isolated temporary environment, preserve current production state and define how new writes will be handled before any rollback.

Define the incident and target point. State what failed, the clean recovery point required and who authorises the drill.
Preserve current state and new writes. Capture production, decide whether to freeze activity and protect transactions created after the target point.
Prepare isolation. Use a temporary environment that cannot send live email, charge cards, call production webhooks or affect public DNS.
Investigate the recovery point. When compromise is possible, contain the incident and check that the selected copy predates the intrusion.
Restore in the documented order. Recover files and database as a coordinated state, then apply environment-specific configuration without exposing secrets.
Check content and identity. Verify representative pages, media, authentication, user roles, search and database reads and writes.
Check operational workflows. Test forms, uploads, scheduled jobs, redirects, certificates, logs and notification delivery.
Check transaction workflows. For ecommerce, test products, carts, checkout, orders, stock, payment callbacks, scheduled actions and transactional email using safe test modes.
Check external dependencies. Verify DNS, CDN, object storage, analytics and integrations separately from the hosting archive.
Measure elapsed recovery time. Compare the complete usable-service time with the RTO target.
Locate the newest recovered change. Compare its timestamp or identifier with production to measure actual data loss against the RPO.
Record failures and retest. Name owners, corrective actions and the next drill date.

Post-restore acceptance checklist

Checkbox progress is stored only in this browser. No operational details are collected or sent.

Restore evidence incomplete0 of 13 acceptance checks confirmed

For a platform-specific exercise, follow the WordPress backup and restore drill.

Choose the recovery branch that matches the incident

Accidental file deletion

A granular file restore may minimise rollback. Confirm that the database is still valid before replacing more than necessary.

Failed update

Restore code or files first when current database state remains valid. Reverting the whole database can erase legitimate new activity.

Database corruption

Isolate writes, select a consistent recovery point and plan how later valid changes will be reconciled.

Compromised website

Contain the incident, preserve evidence, identify a clean point, rotate credentials and patch the cause before returning service.

Provider outage

Recovery depends on an independent copy, domain and DNS control, an alternate deployment path and current configuration instructions.

Suspension or deletion

Use the exit copy and separately controlled registrar and DNS access. Provider recovery windows are not substitutes for an owned copy.

Migration rollback

Preserve source and destination state, identify the authoritative write location and avoid split orders or form submissions.

Ecommerce incident

Protect new orders and payment state before database rollback. Reconcile gateways, stock, scheduled actions and customer communications.

Questions to ask before buying hosting

Creation and retention

How often are jobs scheduled, when do they complete, how many successful recovery points remain, and how far back can I recover?

Scope and exclusions

Are files, databases, email, DNS and configuration included? Which size, inode, database, quota or product limits can prevent a job?

Isolation and security

Is storage off-server or off-account? Can production credentials delete every copy? What encryption, multifactor and deletion controls apply?

Export and portability

Can I download an open-format copy without support, and can another provider or standard tool use it?

Restore controls

Can I restore a file, directory, database, application or full account? Does restoration overwrite current data, and can it be reversed?

Support and cost

Which restores require support, what response time and charge apply, and what service state should I expect while restoration runs?

Exit resilience

What happens to recovery points after suspension, cancellation, expiry, account deletion or server deletion?

Proof

Can I see successful-job logs, failed-job alerts and recovery-point timestamps, and can I run a test restore?

Frequently asked questions

Are backups included with web hosting?

Sometimes, but frequency, retention, scope, export and restoration differ by provider, product and plan. Verify the control panel and current terms.

Can I rely only on the hosting provider’s backup?

No single provider-controlled copy protects against every account, credential, platform or contractual failure. Keep at least one independently controlled, tested copy.

How often should a website be backed up?

Often enough to meet its RPO. A store processing continuous orders may need far tighter protection than a brochure site edited monthly.

How long should backups be retained?

Long enough to cover delayed discovery and business or legal needs. Retention should include multiple points, not only the latest copy.

What is the difference between RPO and RTO?

RPO measures the maximum acceptable period of lost changes. RTO is the target time to restore an acceptable service.

Is a server snapshot the same as a backup?

No. A snapshot is usually a fast infrastructure checkpoint and may remain tied to the same platform and account. Its independence and retention must be checked.

Does WordPress need both files and database?

Yes for a typical complete restore. Files hold code, themes, plugins and uploads; the database holds content, users, settings and much application state.

Does a website backup include email, DNS and SSL?

Not necessarily. Hosting archives differ, while DNS, registrar control, certificates and email can be managed by separate systems.

Can I restore a full cPanel backup myself?

cPanel documents that a user cannot automatically restore a full backup through the cPanel interface; WHM access or provider support may be required.

How do I test without affecting the live website?

Restore to an isolated temporary environment, block production side effects, preserve current state and validate through a documented checklist.

What can be lost when an ecommerce backup is restored?

Orders, stock changes, customer updates, forms and other database writes created after the recovery point can be overwritten.

What happens after hosting is cancelled?

Provider-specific deletion and recovery windows apply. Download and restore-test an exit copy before cancellation rather than depending on a grace period.

How should backups be protected from ransomware?

Use encrypted, tested copies with separate access, restricted deletion and at least one recovery point unavailable to production credentials. Restore only after containment and clean-point review.

How many independent copies are enough?

There is no universal count. Use enough copies, versions and failure-domain separation to meet the defined risks, RPO, RTO and delayed-discovery period.

What proves a restore worked?

A timed isolated restore that recovers the intended scope, identifies the newest recovered change and passes functional, security and operational checks.

Continue only after defining the requirement

First determine whether an independent backup service or operational change can close the gap. If the hosting platform itself cannot meet a documented recovery requirement, use the neutral hosting comparator, review relevant provider dossiers, or plan a controlled move with the website migration guide. Transaction-heavy sites should also review the ecommerce hosting guide.

Affiliate disclosure: Some outbound commercial links may earn Web Host Lens a commission at no additional cost to you. Commission does not determine inclusion, evidence grading or conclusions. A paid upgrade does not guarantee recoverability.

Primary sources

Evidence accessed 28 July 2026. Product rules change; verify the exact plan. Submit corrections through the corrections process.