A reliable cloud hosting backup strategy does more than copy website files. This practical checklist shows what to back up, where to store it, how to set retention, and how to test a restore before an outage makes the decision for you.
Overview
A website backup is a recoverable copy of the systems and data required to resume normal operation. For a typical cloud-hosted website, that may include application files, databases, uploaded media, DNS records, server configuration, deployment settings, and business email. Treating all of these as one backup job can leave important gaps.
Start by defining two recovery objectives:
- Recovery point objective (RPO): the maximum amount of recent data you can afford to lose. If the site changes frequently, daily database backups may not be sufficient.
- Recovery time objective (RTO): the target time for restoring a usable website. A backup that takes hours to locate, download, configure, and validate may not meet an urgent operational need.
Your hosting provider may offer automated snapshots or backups, but provider features should be documented rather than assumed. Confirm what is included, how long copies are retained, whether backups are stored separately from the production environment, and whether you can download or restore them without provider intervention. A managed cloud hosting plan can simplify operations, but responsibility for recovery decisions still belongs with the site owner.
For related infrastructure checks, review the website uptime and performance checklist for reliable cloud hosting and keep a current inventory of domains, DNS records, certificates, and hosting access.
Checklist by scenario
Use the following inventory to build a website backup checklist. Mark each item as automated, manually exported, or not applicable.
| Item | What to preserve | How to verify recovery |
|---|---|---|
| Website files | Application code, themes, plugins, templates, uploads, and custom scripts. | Restore to a test location and confirm pages, assets, forms, and permissions work. |
| Database | Content, users, orders, settings, metadata, and other structured application data. | Import a copy into an isolated database and check login, search, checkout, and key records. |
| Media and documents | Images, videos, downloadable files, invoices, and user-generated content. | Open representative files and check that links resolve after restoration. |
| DNS | A, AAAA, CNAME, MX, TXT, CAA, and other records, including TTL notes. | Compare the restored zone with the approved production configuration. |
| Server configuration | Environment variables, scheduled jobs, rewrite rules, runtime versions, firewall rules, and deployment settings. | Recreate the application in a staging environment and inspect logs for configuration errors. |
| SSL and certificates | Certificate management details, renewal method, and any required private configuration. | Load the restored site over HTTPS and check for certificate, redirect, and mixed-content errors. |
| Mailbox data, aliases, forwarding rules, and authentication records where applicable. | Confirm mail routing and review the provider’s separate retention and export process. |
For a brochure or low-change site
Prioritize a complete copy of files, the database if the site uses a content management system, media, DNS documentation, and SSL configuration notes. Schedule backups around the frequency of content changes, and take an additional backup before design, plugin, runtime, or hosting changes.
For WordPress or another database-backed application
Keep files and database backups coordinated. A database without its matching media and code can produce a partially functional restore. Record the application version, extensions, PHP or runtime version, and critical environment settings. Before an update, create a clearly labeled restore point and confirm that it can be downloaded.
For ecommerce or frequently changing sites
Use a shorter backup interval for transactional data when the business can tolerate less data loss. Identify orders, customer records, inventory, payment configuration, and integrations as high-priority items. Do not assume that a hosting backup replaces exports or retention controls provided by payment, email, analytics, or fulfillment platforms.
For a migration or major infrastructure change
Take a pre-change backup, export DNS records, document the current origin and email routing, and preserve the old environment until validation is complete. The website hosting migration checklist can help coordinate domains, DNS, email, and SSL during the move.
What to double-check
Storage and retention
Keep at least one copy outside the production hosting environment. This may be a separate account, storage service, or controlled offline location, depending on your operational and security requirements. Use clear names that include the site, environment, backup type, and date. Define a retention pattern that preserves recent restore points while keeping selected older copies for historical recovery. For example, you might retain frequent short-term copies and a smaller number of monthly or milestone backups. The right schedule depends on change frequency, storage limits, and business requirements.
Access and security
Restrict backup access to the people and systems that need it. Protect stored copies with encryption where supported, use separate credentials from the production server, and avoid placing database dumps or private configuration files in a public web directory. Document who can start a restore and who approves a production rollback.
Restore testing
A successful backup job does not prove that recovery will work. At least periodically, follow this restore test template:
- Select a backup without relying on the newest copy only.
- Record its date, source, size, and checksum or provider verification if available.
- Restore files and the database into an isolated environment.
- Apply configuration, DNS notes, and required runtime settings.
- Test the homepage, representative content, administration, forms, authentication, media, redirects, and important integrations.
- Check HTTPS, logs, scheduled tasks, and database connectivity.
- Record the time taken, failures found, and corrective actions.
Keep the test environment private and remove temporary credentials or copied personal data when the exercise ends. For DNS-specific recovery, maintain an approved record inventory; the DNS records guide explains the main record types to review.
Common mistakes
- Backing up only public files: the database, uploads, configuration, or scheduled jobs may be missing.
- Keeping every copy on one server: a host failure, account issue, or accidental deletion can affect both production and backups.
- Confusing snapshots with a full recovery plan: a snapshot may depend on the same platform, account, or configuration that failed.
- Never testing a restore: corrupted archives, incompatible versions, missing credentials, and undocumented dependencies are easier to find during a planned drill.
- Ignoring email and DNS: a restored website may appear healthy while mail delivery or domain routing remains broken. For email authentication records, see the SPF, DKIM, and DMARC checklist.
- Overlooking sensitive data: backup copies often contain personal, customer, or authentication information and require controlled access.
- Using unclear ownership: a recovery contact list should identify technical owners, business approvers, hosting support contacts, and the location of current documentation.
When to revisit
Review this website disaster recovery plan before seasonal planning cycles, major campaigns, hosting changes, application updates, domain transfers, or changes to payment and email systems. Revisit it whenever workflows or tools change, because a new deployment process or hosting provider can alter what must be captured and how restoration works.
As a practical monthly or quarterly routine, confirm that backup jobs completed, storage remains available, retention still matches requirements, and recovery contacts are current. Perform a restore drill on a rotating basis rather than testing only the newest backup. After every drill, update the runbook with the exact commands, provider screens, credentials process, DNS steps, and validation checks needed by the person who will perform the recovery.
Finish by assigning an owner and a next review date. A backup strategy becomes useful when someone can locate a known-good copy, restore it safely, verify the result, and communicate the recovery status without guesswork.
