A hosting backup is useful only if it can be found, trusted, and restored within the time your website can afford to be unavailable. This practical checklist explains what to back up, how long to retain each backup, how to test restores safely, and how to build a website disaster recovery process for WordPress sites, business websites, applications, email, and databases.
Overview
Website hosting backups protect more than the visible files that load in a browser. A usable recovery plan may need website files, databases, uploaded media, configuration files, scheduled tasks, email data, DNS information, SSL settings, and deployment instructions. The exact scope depends on how the site is built and which services are managed by your hosting provider.
Start by defining two targets:
- Recovery point objective (RPO): the maximum acceptable amount of recent data you could lose. For example, if your RPO is 24 hours, a daily backup may be sufficient for some sites. A store, membership site, or frequently updated application may need more frequent backups.
- Recovery time objective (RTO): the maximum acceptable time before the site or service is operational again. A brochure website may tolerate a longer manual recovery, while a business-critical application may require documented automation and a tested standby environment.
Do not assume that a hosting control panel snapshot, provider backup, or WordPress backup plugin covers everything. Confirm what is included, where copies are stored, how long they remain available, and whether you can download or restore them independently. A backup stored only on the same hosting account may be inaccessible if the account, server, or credentials are compromised.
If you are changing providers, pair the backup plan with a documented website migration checklist. Migration copies and disaster recovery backups serve related but different purposes: a migration copy supports a planned move, while a recovery backup must remain available when the original environment is damaged or unavailable.
Checklist by scenario
Use this table to decide which backup types apply to your website hosting environment. Keep a written inventory so that a future administrator can understand what must be restored and in what order.
| Backup type | What it should include | Useful when | Restore check |
|---|---|---|---|
| Full-site backup | Website files, databases, uploads, themes, plugins, and relevant configuration | You need to rebuild the hosting account or move to another server | Restore to a clean staging account and verify the site loads correctly |
| Database backup | Content, users, orders, settings, and application records stored in the database | Content changes frequently or the database is separate from website files | Import into a test database and check tables, encoding, users, and application connections |
| File backup | Code, media, documents, themes, plugins, environment templates, and custom scripts | Uploaded files or deployed code change independently of database content | Compare permissions, ownership, paths, and required configuration files |
| Email backup | Mailbox content, contacts, and any required mail configuration | Email is hosted with the domain or hosting account and business records must be retained | Restore a test mailbox or verify export files with the mail provider |
| Off-site copy | An encrypted copy stored outside the primary hosting environment | The hosting account, server, region, or account credentials are unavailable | Download a copy using a separate recovery account and confirm it is readable |
| Configuration record | DNS records, deployment steps, runtime versions, cron jobs, API dependencies, and access contacts | A rebuild requires more than uploading files | Follow the instructions from a clean environment without relying on undocumented knowledge |
Set a practical retention schedule
A backup retention policy should reflect how often data changes and how far back you may need to investigate an incident. One reasonable starting model is to keep several recent backups, a smaller number of weekly copies, and selected monthly or milestone copies. Treat this as a planning pattern rather than a universal rule.
- Retain frequent backups long enough to reverse a recent update, deletion, or deployment error.
- Retain weekly backups to cover issues discovered after several days.
- Retain periodic milestone backups before major redesigns, plugin changes, migrations, or database work.
- Apply separate retention and access rules to personal data, financial records, or regulated information where applicable.
- Delete expired copies securely so old credentials or sensitive data are not retained without a purpose.
Match the process to the hosting environment
For managed WordPress hosting, confirm whether provider backups include the database, media library, custom code, and recent changes. Before updates, create or identify a known-good restore point and review the managed WordPress hosting checklist for backup and operational features to compare.
On shared hosting, check the control panel's backup scope, download options, storage limits, and restore procedure. With VPS hosting or cloud hosting, you may be responsible for configuring scheduled backups, database dumps, object storage, encryption, monitoring, and recovery permissions. The distinction between shared hosting and VPS hosting is therefore relevant to operational responsibility, not only server resources.
What to double-check
1. Confirm backup completeness
List every component required for a working site. For a content management system, this commonly includes the database, uploads, themes, plugins, and configuration. For a custom application, include source code, dependency definitions, build instructions, environment variables held in a secure system, database schemas, queues, and required external services. Never place live secrets in an ordinary downloadable backup without encryption and access controls.
2. Separate backup access from daily administration
Use unique credentials, least-privilege access, multi-factor authentication where available, and a separate recovery account or storage location. Keep at least one copy outside the primary hosting account. If an attacker can delete both the live website and its backups with the same credentials, the backup plan is incomplete.
3. Test a staging restore
A successful backup job is not proof of a successful restore. Restore a copy to a staging server or isolated directory, then check the homepage, login, forms, search, media, checkout or other critical transactions, scheduled tasks, redirects, and integrations. For database-backed sites, verify that the restored application connects to the intended database and that character encoding has not changed.
4. Document DNS and deployment dependencies
Record domain ownership, DNS records, nameservers, mail routing, SSL certificate requirements, runtime versions, repository locations, and deployment steps. DNS changes can take time to propagate and may affect email as well as the website. For background, keep your DNS records guide available when documenting recovery dependencies. If the site is deployed with Git, include the repository, branch, build commands, and secrets-handling process; the Git hosting workflow guide can help structure that record.
5. Measure the actual recovery time
During a restore test, record how long it takes to locate the backup, provision an environment, restore files and data, configure the domain, validate the site, and communicate completion. Compare the result with your RTO. If the target cannot be met, reduce manual steps, improve documentation, or choose hosting capabilities that better fit the requirement.
Common mistakes
- Keeping only one copy: A single backup can be corrupted, deleted, or tied to the same failure as the live site.
- Backing up files but not the database: This can restore the design while losing content, users, orders, or settings.
- Ignoring email: Website recovery does not automatically recover mailboxes or mail records. Document mail hosting separately, including SPF, DKIM, and DMARC requirements; see the email authentication guide for the domain side.
- Testing only the homepage: A page that loads may still have broken forms, permissions, payments, search, images, or scheduled jobs.
- Relying on undocumented provider features: Backup frequency, retention, storage limits, and restore controls can differ by plan and may change. Verify the current feature set before relying on it.
- Overlooking version compatibility: A restore may require a compatible PHP, database, operating system, framework, or plugin version.
- Restoring over production first: Use an isolated staging environment whenever possible. Preserve the current state before replacing live data.
- Confusing uptime with recoverability: An uptime commitment does not replace an independent backup and restore plan.
When to revisit
Review the backup and disaster recovery plan before seasonal planning cycles, major campaigns, platform upgrades, ownership changes, and hosting migrations. Revisit it whenever the website architecture, DNS provider, email provider, deployment workflow, database, or hosting plan changes.
Use this recurring checklist:
- Confirm that scheduled backups completed and that retained copies are within policy.
- Download or inspect an off-site copy and verify that it can be opened or decrypted.
- Run a staging restore at a planned interval and record the actual RTO.
- Update the inventory of domains, DNS records, mail services, applications, integrations, and responsible contacts.
- Test administrator access, recovery credentials, and multi-factor authentication without exposing secrets in the documentation.
- Review whether the current web hosting plan still meets the site’s RPO, RTO, storage, and operational needs.
Before a major update, take a clearly labeled restore point and note the change being made. After the update, keep the restore point until the site has passed functional checks. When moving providers, complete at least one restore or rebuild test on the destination before changing DNS. This approach turns website hosting backups from a passive feature into a repeatable recovery capability.
