A dependable website backup and recovery plan protects more than page files. It preserves databases, uploads, email, DNS records, and the configuration needed to bring a site back online after deletion, malware, a failed update, or a hosting problem. This checklist explains what to back up, how often to retain copies, how to test them, and how to restore a site methodically across common hosting environments.
Overview
A useful website backup strategy starts with a simple question: what would you need to rebuild the site if the current server disappeared? The answer usually includes several separate systems, not just the visible website.
- Website files: application code, themes, plugins, templates, scripts, configuration files, and server rules such as
.htaccess. - Databases: posts, pages, user accounts, orders, settings, form entries, and other structured content.
- Media and generated content: images, videos, documents, caches that cannot be recreated easily, and user-uploaded files.
- Email information: mailboxes, aliases, forwarding rules, and any locally stored messages that are not held by a separate email provider.
- DNS and domain information: nameservers, A and AAAA records, CNAME records, MX records, TXT verification records, and the registrar account details needed to manage them.
- Infrastructure configuration: PHP or runtime versions, environment variables, scheduled jobs, firewall rules, deployment settings, SSL configuration, and external service credentials stored securely.
A backup is not a recovery plan until you know where it is stored, who can access it, how long it is retained, and how to restore it. Keep at least one copy separate from the production hosting account. A backup stored only on the same server can be lost in the same incident as the website. Protect backup access with strong authentication and limit credentials to the people or systems that need them.
For a broader maintenance checklist, see How to Back Up a Website: Files, Databases, Frequency, and Restore Testing. If your recovery plan involves moving providers, the website migration checklist can help you coordinate DNS, testing, and the final switch.
Checklist by scenario
Routine protection
Set backup frequency according to how often the site changes and how much recent data you can afford to lose. A brochure site that changes monthly may need a different schedule from an ecommerce site or publishing platform that receives updates throughout the day.
| Backup type | Recommended starting point | What to verify |
|---|---|---|
| Database | Daily for active sites; more often when transactions or frequent publishing make that necessary | The export completes, has a sensible file size, and can be opened or restored in a test environment |
| Website files and media | After meaningful changes, plus a scheduled full copy | Uploads, themes, plugins, application files, and hidden configuration files are included |
| DNS and configuration | After every infrastructure or domain change, with a periodic review | Records, runtime versions, scheduled jobs, certificates, and deployment notes are documented |
| According to the email provider's export and retention options | Mailboxes, aliases, forwarding rules, and required archives are covered separately from web hosting |
Use a practical retention pattern rather than keeping every copy indefinitely. For example, retain several recent daily backups, a smaller set of weekly backups, and selected monthly or pre-change snapshots. The right periods depend on storage capacity, compliance requirements, recovery objectives, and how long it might take to discover a problem. Malware or data corruption may not be noticed immediately, so relying only on the newest copy can remove your clean recovery point.
Before updates, migrations, or major changes
- Record the current application, runtime, plugin, theme, and database versions.
- Take a fresh database backup and a full file backup. Label both with the site name, date, and change being made.
- Confirm that the backup finished successfully and is accessible outside the production account.
- Write down the rollback decision: what failure would cause you to stop, and which snapshot would you restore?
- Test the change on a staging copy when the platform supports it.
This is especially important when changing cloud hosting, VPS hosting, managed WordPress hosting, or server software. A sizing and infrastructure review may be useful alongside the cloud server guide, but capacity planning does not replace a restorable backup.
After accidental deletion or a failed update
- Stop making changes that could overwrite the damaged files or database.
- Capture the current state if possible, including error messages, logs, and a copy of the affected database.
- Identify the last known good backup before the incident.
- Restore to a staging location first, or place the site in maintenance mode if a staging environment is unavailable.
- Check the homepage, key content, login, forms, search, media, database connections, and payment or third-party integrations.
- Restore production only after the test result is understood and the rollback path is still available.
After suspected malware or unauthorized access
Do not assume the newest backup is clean. Isolate the site, preserve relevant logs, rotate hosting, database, CMS, SSH, SFTP, registrar, and API credentials, and identify when the compromise may have started. Choose a known-clean recovery point, update the application and dependencies, remove unnecessary accounts, and review file changes before reconnecting the site to normal traffic. If you cannot establish a clean recovery point, get qualified security assistance rather than repeatedly restoring unknown copies.
When the hosting account is unavailable
Use an off-server backup and your documented DNS and domain information. Create the required database and runtime environment on the replacement hosting platform, upload the files, import the database, recreate environment variables and scheduled tasks, and test with a temporary hostname or hosts-file entry. Only then update DNS. DNS changes can take time to appear consistently, so avoid deleting the old environment until the new site and email routing have been verified.
What to double-check
A backup job can report success while still missing an important part of the site. Use this inventory before calling a plan complete:
- Database completeness: Confirm all application databases are included, not just the default database. Check tables for orders, users, forms, and custom content.
- File completeness: Include uploads and media directories, custom code, configuration files, and files outside the web root that the application needs.
- Secrets and privacy: Store credentials and personal data securely. Do not place database passwords or private keys in an unprotected shared folder.
- Portability: Know whether the backup is a standard database export and ordinary files or a provider-specific archive that requires a particular tool.
- Permissions: Confirm the restored files have appropriate ownership and permissions. Overly broad permissions can create a security problem; restrictive permissions can break the application.
- External dependencies: Document payment processors, email delivery, analytics, storage buckets, webhooks, API keys, and license information. These may not be included in a hosting backup.
- DNS and email: Export or record DNS records before a migration. Pay special attention to MX, SPF, DKIM, DMARC, verification, and subdomain records. The DNS records guide provides a useful reference for this inventory.
- Recovery access: Store administrator and registrar recovery details in a controlled password manager. A backup is less useful if nobody can access the hosting account or encryption key.
Test restores quarterly as a baseline, and test sooner after changing backup software, hosting providers, storage destinations, encryption methods, or the website's architecture. A restore test should produce a working page, not merely a downloaded archive. Record the start and finish times, issues found, and the steps required to correct them.
Common mistakes
- Keeping backups only on the live server: Server failure, account loss, or a destructive attack can affect both the website and its backups.
- Backing up files but not the database: A WordPress or database-driven site may look complete while its content and settings are absent.
- Assuming a hosting snapshot covers email and DNS: These services may be managed separately and require their own records or exports.
- Never testing restoration: An archive can be incomplete, corrupted, incompatible, or missing the credentials needed to use it.
- Overwriting the only good copy: Keep several recovery points so a delayed problem does not eliminate every clean version.
- Restoring malware without investigating it: Recovery should include a security review, credential rotation, and updates where appropriate.
- Changing DNS too early: Verify the replacement site and email configuration before directing visitors and mail to a new server.
- Failing to document manual steps: Note runtime versions, database names, cron jobs, redirects, SSL settings, and integration configuration while the site is healthy.
For availability planning, pair backups with monitoring and an incident process. The website uptime monitoring guide explains how alerts can help distinguish a short outage from a recovery event. Backups restore data; monitoring helps you discover that something needs attention.
When to revisit
Review this website disaster recovery plan before seasonal planning cycles, major campaigns, or periods when the cost of downtime is higher. Revisit it immediately after a domain transfer, hosting migration, CMS change, database change, new ecommerce feature, email provider change, or security incident. Update it whenever backup tools, storage locations, authentication methods, or recovery personnel change.
Set a recurring quarterly restore test and record the result in a simple log. At minimum, note the backup selected, restore environment, time to recovery, missing components, and corrective actions. If the site has strict recovery requirements, define two targets: the maximum acceptable amount of lost data and the maximum acceptable time to restore service. Use those targets to adjust backup frequency, storage, staffing, and hosting design rather than choosing intervals by habit.
To act now, create one fresh full backup, confirm it is stored separately from production, document DNS and configuration details, and restore a copy in a staging environment. Assign an owner for the next test and put the review date on the operations calendar. A short, tested procedure is more valuable during an incident than a long plan that has never been used.
