A dependable cloud hosting backup strategy protects more than your website files. This checklist explains what to back up, how often to capture each type of data, how long to retain versions, and how to test a restore before an incident makes the decision for you.
Overview
A website backup is a recoverable copy of the information and configuration required to restore a working site. For a cloud-hosted website, that usually includes application files, databases, media uploads, deployment configuration, domain and DNS details, SSL information, and selected secrets or environment variables. The exact list depends on how the site is built, but treating “the website” as a single folder is rarely sufficient.
Backups are different from redundancy. A hosting provider may replicate data across infrastructure to improve availability, but replication can also reproduce accidental deletion, corrupted files, or unwanted changes. A separate backup retained for an appropriate period gives you a point-in-time recovery option.
Your plan should answer four practical questions:
- What must be restored? Identify the data and services required to make the site usable.
- How much recent work can you afford to lose? This determines backup frequency.
- How far back might you need to recover? This determines retention.
- Can you actually restore it? A backup that has never been tested is an assumption, not a recovery plan.
For broader infrastructure context, compare your backup approach with your hosting model in this guide to managed cloud hosting versus shared hosting.
Checklist by scenario
Use the following as a starting schedule, then adjust it according to how often your site changes and how costly downtime or lost data would be.
| Website component | What to include | Suggested starting frequency | Retention guidance |
|---|---|---|---|
| Database | All production tables, content, users, orders, settings, and metadata | Daily for active sites; more often for frequently changing applications | Keep multiple recent versions plus older checkpoints |
| Media and uploads | Images, documents, videos, generated files, and user-uploaded assets | Daily or whenever new content is published | Retain versions long enough to recover from unnoticed deletion |
| Application and theme files | Source code, templates, plugins, dependencies, and build output where needed | At every release, with repository history as an additional copy | Keep release points and the current known-good version |
| Configuration | Deployment files, scheduled jobs, rewrite rules, runtime settings, and service configuration | Whenever configuration changes | Retain alongside the corresponding application release |
| DNS and domain records | Nameservers, A and AAAA records, CNAMEs, MX records, TXT records, and verification entries | After every change, with a periodic export or written record | Keep the latest known-good record set and change history |
| Secrets and environment variables | API credentials, database connection details, signing keys, and third-party settings | When changed, stored securely rather than in ordinary file backups | Retain only as long as necessary and rotate when exposure is suspected |
For a brochure, portfolio, or landing page
Static sites often have fewer moving parts, but they still need a recoverable copy of the source repository, deployment settings, custom redirects, form destinations, and domain configuration. Back up uploaded assets and any content managed through an external service. If a website builder or hosted editor is involved, confirm how content export works rather than assuming the provider’s editor is your only copy.
For a content-managed site
Prioritize the database and uploads. A copy of the application files alone may restore the software but not the articles, user accounts, menus, or settings. Capture a backup before major plugin, theme, or platform changes, and keep a known-good version so you can roll back after an unsuccessful update.
For an ecommerce or account-based application
Include orders, customer records, inventory, transactional settings, uploaded documents, background jobs, and integrations. Define the acceptable loss window with the people responsible for operations. You may need more frequent database backups than a marketing site, along with a carefully controlled restore process that avoids duplicating transactions.
For a migration or major redesign
Create a full pre-change backup before moving hosts, changing DNS, upgrading the application, or restructuring the database. Keep the original copy until the new deployment has been verified and the rollback window has passed. The website migration checklist can help organize the change itself.
What to double-check
- Storage independence: Keep at least one backup outside the primary hosting environment or account. A hosting outage, account lockout, or mistaken deletion should not remove every copy.
- Access control: Limit who can read, delete, or restore backups. Use separate credentials where practical, and protect backup storage with strong authentication.
- Encryption: Treat databases, customer records, credentials, and private uploads as sensitive. Confirm encryption is used during transfer and at rest where supported by your storage design.
- Completeness: Check that database dumps can be opened, archives contain expected directories, and exports include hidden configuration or custom uploads when required.
- Retention: Do not keep only the most recent copy. A problem may remain unnoticed for days or weeks, so retain older versions appropriate to the site’s risk and storage constraints.
- Restore dependencies: Document the runtime version, database engine, deployment steps, DNS records, certificates, and external services needed to bring the site back.
- Monitoring: Alert on failed backup jobs, unusual backup size changes, expired credentials, and storage limits. Uptime monitoring complements backups but does not replace them; see the guide to monitoring website uptime and performance.
A practical restore test
Once a month, or at a cadence that fits your risk, restore a recent backup to a temporary environment. Do not overwrite production for the test. Verify that the application starts, the database connects, media loads, logins behave as expected, forms reach their intended destinations, and important pages return the correct content. Record how long the process takes and any manual steps. A quarterly test can also use an older retained version to confirm that retention is working as intended.
After the test, remove temporary credentials and the test environment or restrict it properly. Never leave a restored copy publicly accessible, especially when it contains personal or customer data.
Common mistakes
- Backing up only the web root: The database, uploads directory, DNS records, and environment settings may live elsewhere.
- Relying exclusively on provider snapshots: Snapshots can be useful, but confirm their scope, retention, restore process, and account-level failure assumptions.
- Saving secrets in an unprotected archive: Backups often contain credentials and private data. Secure them as carefully as production systems.
- Never testing recovery: A successful job log does not prove that the backup is complete or usable.
- Overwriting the only good copy: Preserve multiple restore points so a corrupted or compromised recent version does not eliminate recovery options.
- Forgetting DNS and email: A restored website can still appear offline if domain records, email records, or verification entries are missing.
- Confusing source control with a full backup: A repository may not contain uploads, production data, secrets, or infrastructure configuration.
When to revisit
Review this website backup strategy before seasonal planning cycles, after changing hosting providers, and whenever your deployment or content workflow changes. Also revisit it after adding ecommerce features, user accounts, new integrations, scheduled jobs, or a different website builder.
Use a simple recurring review:
- Monthly: Check backup job results, storage access, recent versions, and one restore workflow.
- Quarterly: Test an older restore point, review retention, and confirm DNS, SSL, email, and environment documentation.
- After major changes: Capture a pre-change backup and update the recovery runbook.
- Every six months: Recheck provider backup features, storage costs and limits, authentication settings, and recovery assumptions against the current platform.
Keep the final checklist somewhere the people responsible for the site can access during an incident. A clear inventory, a tested restore, and an independent copy will do more for cloud website recovery than an elaborate plan no one can execute.
