A reliable website backup and disaster recovery plan protects more than hosting files: it preserves databases, media, DNS settings, SSL configuration, and the content workflows that keep a site useful. This practical checklist explains how often to back up, what to store, how to test a restore, and how to recover methodically after a failure.
Overview
A website backup strategy should answer four operational questions: what must be backed up, how frequently backups run, where copies are stored, and how quickly the site can be restored. A backup that exists but cannot be located, decrypted, or restored is not a dependable recovery plan.
For a typical cloud-hosted website, the recovery set includes application files, databases, uploaded media, theme and plugin settings, environment variables, deployment configuration, DNS records, SSL details, scheduled jobs, and email-related settings. Content teams should also consider source documents, generated images, audio files, transcripts, prompts, and other working assets that may not live on the production server. If AI or content tools are part of the publishing workflow, document where their inputs and outputs are stored and whether they can be exported in a reusable format.
Use the recovery time objective (RTO) to describe how quickly the site should be online again, and the recovery point objective (RPO) to describe how much recent data the business can afford to lose. A brochure site may tolerate a longer recovery window than a site that receives orders, registrations, or frequent editorial updates. These are planning targets, not guarantees; your hosting plan, backup system, staff availability, and application complexity all affect the result.
For background on hosting architecture and operational choices, see the cloud hosting plan comparison guide. If you are launching a new site, the complete website launch checklist places backups alongside domains, DNS, SSL, SEO, and performance tasks.
Checklist by scenario
Routine website backup schedule
| Scenario | Recommended action | Verification |
|---|---|---|
| Frequently updated site | Run automated database and file backups on a schedule that matches publishing and transaction activity. | Review the latest successful run and confirm its size is plausible. |
| Occasionally updated site | Use recurring backups and create a manual snapshot before significant changes. | Record the date, scope, and storage location of each snapshot. |
| Before a major update | Back up files, database, media, configuration, and the current version of the application. | Confirm the backup completed before updating themes, plugins, code, or the platform. |
| Before migration | Export a complete copy and document DNS, SSL, email, redirects, cron jobs, and environment settings. | Restore the copy in a staging or temporary environment before switching traffic. |
| After a security incident | Preserve relevant logs and make a controlled copy before cleaning or rebuilding. | Separate known-clean recovery points from potentially compromised files. |
Minimum backup contents
- Website files: application code, themes, plugins, templates, configuration files, and custom scripts.
- Database: posts, pages, accounts, orders, settings, forms, and other structured content.
- Media: images, video, audio, downloadable files, thumbnails, and metadata.
- Infrastructure settings: deployment instructions, environment variable names, runtime versions, scheduled tasks, and server rules. Store secrets in an approved secure system rather than exposing them in general documentation.
- Domain and delivery configuration: DNS records, redirect rules, CDN settings, SSL renewal details, and transactional email configuration.
- Content workflow assets: editorial source files, approved copy, transcripts, voice notes, prompt templates, and exported outputs where they are important to publishing.
Retention policy template
Adapt this simple policy to the site’s risk and update frequency:
- Keep recent backups for day-to-day rollback.
- Keep several older recovery points so a problem discovered late is not copied into every backup.
- Keep a periodic long-term copy for major milestones, such as a redesign, migration, or seasonal campaign.
- Keep at least one copy in a separate storage location or account from the live server.
- Delete expired copies according to a documented rule, while retaining records needed for operational or legal requirements.
Restore-test worksheet
At least periodically, complete a controlled restore test and record:
- Date, person responsible, backup identifier, and intended recovery point.
- Files and database restored, including their versions and sizes.
- Environment used for testing and any required software or runtime versions.
- Pages, forms, logins, media, search, redirects, and integrations checked.
- DNS, SSL, caching, email delivery, and scheduled tasks reviewed.
- Problems found, corrective actions, and the date of the next test.
How to restore a website after a failure
- Declare the incident: note the symptoms, time discovered, recent changes, and who is coordinating the response.
- Protect evidence and access: preserve logs where appropriate, rotate exposed credentials, and restrict administrative access if compromise is suspected.
- Choose a recovery point: select the newest known-good backup, not simply the newest available backup.
- Prepare the destination: verify the hosting account, runtime, database engine, storage, permissions, and required extensions.
- Restore files and database: follow the provider’s documented order, then update connection settings and file permissions.
- Validate privately: use a staging URL or temporary host before changing public DNS. Check core pages, forms, accounts, media, and content publishing.
- Reconnect supporting services: confirm SSL, CDN or caching, DNS records, email, analytics, integrations, and scheduled jobs.
- Redirect traffic carefully: update DNS only after validation. Monitor errors, uptime, logs, and key user journeys.
- Document the outcome: record the recovery point, downtime, data loss if any, root cause, and follow-up work.
For DNS-specific recovery work, use the domain connection and DNS setup guide and the domain, DNS, and email guide. Keeping these records with the backup plan reduces delays when the usual administrator is unavailable.
What to double-check
- Backup scope: confirm that uploads and databases are included rather than only application code.
- Consistency: make sure database and file backups represent a compatible point in time, especially during active transactions.
- Storage independence: do not rely exclusively on a backup stored on the same server, account, or failure domain as the live site.
- Encryption and access: limit who can download or delete backups, and document how encrypted copies are recovered.
- Restore dependencies: record software versions, credentials, DNS access, SSL renewal access, and third-party service details.
- Content ownership: export important drafts and AI-assisted workflow assets from tools that are not part of the hosting backup.
- Observability: enable notifications for failed jobs and inspect logs rather than assuming a scheduled task succeeded.
- Search and SEO: after recovery, check canonical URLs, redirects, robots rules, XML sitemaps, and indexable content. The technical SEO and performance checklist can help with this review.
Common mistakes
- Having backups but never testing them: a successful backup job does not prove that restoration will work.
- Keeping only one recent copy: corruption, accidental deletion, or a delayed compromise can make the newest backup unsuitable.
- Backing up only the database: the database cannot recreate missing media, code, configuration, or deployment settings by itself.
- Forgetting DNS and email: the website may load while forms, mailboxes, verification records, or transactional messages fail.
- Restoring directly over production: validate in an isolated environment when possible, especially after a security event.
- Storing secrets in plain text: keep recovery documentation useful without publishing passwords, private keys, or API tokens.
- Confusing content exports with full backups: an export may omit settings, users, media relationships, or custom functionality.
Developer utilities can support the investigation, but sensitive production data should not be pasted into an unfamiliar online tool. For general workflow references, see the guide to JSON, Base64, JWT, and Markdown tools and the JWT decoder safety guide.
When to revisit
Review this website disaster recovery plan before seasonal planning cycles, migrations, redesigns, hosting changes, and major application or content workflow updates. Revisit it whenever the site adds a database, payment flow, user accounts, new media process, AI content tool, CDN, email provider, or external integration.
Once a month, check the latest backup status, available storage, retention behavior, access permissions, and incident contacts. On a schedule appropriate to the site’s risk, perform a restore test and update the worksheet. After every failed test, change the process before the next test rather than treating the result as a paperwork issue.
Start today with three actions: identify the files and services that must be recovered, verify that an off-site copy exists, and schedule a test restore. Then store the completed checklist where the people responsible for the website can access it during an outage.
