A reliable website backup and recovery plan protects more than your page files. It preserves databases, uploads, configuration, DNS records, and the settings needed to bring a site back online after an update failure, security incident, hosting problem, or accidental deletion. This checklist explains what to back up, how to store it, how to test a restore, and which steps to follow when recovery is urgent.
Overview
A website backup is a recoverable copy of the components that make a site work. The exact list depends on your platform, but a complete plan usually covers five areas:
- Website files: application code, themes, plugins, templates, server-side scripts, and custom assets.
- Database content: pages, posts, products, users, orders, settings, and other structured records.
- Media and documents: images, videos, downloadable files, customer uploads, and brand assets.
- Configuration: environment variables, deployment settings, scheduled jobs, rewrite rules, SSL-related settings, and version information. Store secrets securely rather than exposing them in ordinary backup folders.
- External records: DNS records, domain details, email-related settings, third-party integrations, and a list of services the website depends on.
Do not assume that a hosting snapshot covers everything. A provider may back up a server or account without preserving domain registrar settings, DNS history, email configuration, external forms, payment settings, or a separate service's data. Confirm exactly what your cloud hosting backup includes, how long it is retained, where it is stored, and whether you can download or restore it independently.
A useful plan separates the recovery point objective from the recovery time objective. The first asks how much recent work you can afford to lose. The second asks how quickly the website needs to be usable again. A brochure site may tolerate a simpler schedule than a site that receives orders, bookings, or customer submissions. Set these expectations before selecting backup frequency.
Checklist by scenario
Routine cloud hosting backup checklist
- List every production website, subdomain, database, storage bucket, and connected service.
- Identify where each item is stored and who can access it.
- Schedule backups for both files and databases. Backing up only one of these creates an incomplete recovery copy.
- Keep at least one copy separate from the primary hosting account or environment.
- Encrypt backups where appropriate and restrict access to the people or systems that need it.
- Record the backup date, scope, software version, and restoration instructions.
- Review backup logs for completion rather than assuming a scheduled job succeeded.
- Run a restore test in a staging or isolated environment.
Before a redesign, migration, or major update
- Take a clearly labeled pre-change backup of files, databases, and media.
- Export DNS records and document the current time-to-live settings if a domain change is planned.
- Record hosting details, runtime versions, database credentials location, deployment commands, cron jobs, and integration endpoints.
- Confirm that the backup can be read and that the intended restore method still works on the destination environment.
- Freeze or document content changes during the final migration window so the source and restored versions can be compared.
- Keep the pre-change copy until the new site has passed functional, performance, and monitoring checks.
After an outage, failed update, or suspected compromise
- Confirm the scope of the problem and preserve useful evidence, such as timestamps, logs, error messages, and recent change history.
- Prevent further damage by pausing deployments or isolating affected credentials and services where appropriate.
- Choose a known-good backup from before the failure, not simply the most recent copy.
- Restore to an isolated environment first when there is any possibility of corruption or unauthorized changes.
- Update or rotate credentials that may have been exposed before reconnecting the restored site to production.
- Validate the site, database relationships, forms, user access, transactions, email delivery, and external integrations.
- Point traffic to the recovered environment only after the validation checklist is complete.
- Monitor uptime, error logs, and important user journeys after recovery.
Retention comparison
| Retention approach | Useful for | Trade-off |
|---|---|---|
| Short rolling retention | Recovering from recent deployment or content mistakes | Older problems may be preserved in every available copy |
| Daily copies for several weeks | Small business sites with regular content changes | Requires more storage and review |
| Weekly or monthly archive copies | Longer-term rollback and seasonal records | May not contain the latest changes |
| Milestone backups | Before migrations, redesigns, plugin changes, or infrastructure work | Must be created consistently and labeled clearly |
Use a combination that matches the site's content change rate and recovery needs. A retention schedule is useful only if the copies are accessible, identifiable, and restorable.
What to double-check
Restore test worksheet
Complete this worksheet during a scheduled recovery test and keep the result with your operational documentation:
- Test date and operator: ____________________
- Backup selected and creation date: ____________________
- Source and destination environments: ____________________
- Files restored successfully? Yes / No
- Database imported successfully? Yes / No
- Media and downloads available? Yes / No
- Configuration and runtime versions confirmed? Yes / No
- DNS and domain steps documented? Yes / No / Not applicable
- Forms, logins, search, checkout, and key workflows tested? Yes / No / Not applicable
- Email notifications and integrations tested? Yes / No / Not applicable
- Time to restore and validate: ____________________
- Problems found and corrective action: ____________________
Check version compatibility before restoring. A backup created from one application, database, or runtime version may require a compatible destination or an upgrade path. Also verify file permissions, URL settings, cache behavior, background jobs, and any environment-specific variables. A site that displays a homepage but cannot process a form or load its media is not fully recovered.
For DNS and email, document the records rather than relying on memory. Include web records, verification records, mail exchange records, sender-policy records, and any provider-specific entries that your services require. Do not copy sensitive values into a public document. If email is hosted separately, confirm whether mailboxes and messages are covered by that provider's own retention and recovery process.
For operational visibility, pair recovery testing with website uptime monitoring. After a restore, monitoring can help reveal recurring errors or an incomplete cutover. If the recovery follows a migration, use the cloud hosting migration checklist to review traffic, DNS, and validation steps.
Common mistakes
- Keeping every copy in one account: An account lockout, deletion, or infrastructure issue can affect both the website and its backups.
- Backing up files but not the database: The code may return while the actual content, users, or orders are missing.
- Backing up a database but not uploaded media: Pages can appear incomplete even when the database is intact.
- Never testing restoration: A successful backup job does not prove that the copy is complete or usable.
- Using the newest copy automatically: It may contain corruption, a failed update, or unwanted changes. Select a known-good restore point.
- Forgetting external dependencies: DNS, email, payment, analytics, forms, and authentication services may require separate recovery steps.
- Storing secrets without protection: Backup files can contain credentials or personal data. Apply access controls, encryption, and an appropriate deletion policy.
- Failing to document ownership: A recovery plan should identify who can approve a restore, access the hosting account, update DNS, and verify the result.
For broader preventive work, review the cloud hosting security checklist. Security controls and backups serve different purposes: a backup helps recover from a problem, while security practices reduce the chance and impact of one.
When to revisit
Review this website backup and recovery plan before seasonal planning cycles, major campaigns, redesigns, migrations, framework or CMS updates, hosting changes, and changes to payment or email providers. Revisit it whenever workflows or tools change, including a new deployment pipeline, backup provider, database engine, storage location, or monitoring system.
At minimum, schedule a recurring review of backup logs and retention, plus a practical restore test at an interval appropriate to the site's risk and change rate. Repeat the test after a significant platform change rather than assuming the previous result still applies. Update the inventory whenever a new subdomain, integration, database, or storage location is introduced.
To finish the plan, create one recovery document with the asset inventory, backup schedule, retention rules, access owners, restore sequence, validation checklist, and escalation contacts. Label a known-good backup, test it in an isolated environment, and record how long recovery takes. That small preparation turns a collection of cloud hosting backups into a usable business continuity process.
