Website Backup Strategy: What to Back Up, How Often, and Where to Store It

Overview

A website is usually more than the files served by a web hosting account. A complete recovery may require the application code, uploaded media, configuration files, databases, DNS details, deployment settings, and records of third-party services. If one of these pieces is missing, a backup may exist but still be difficult to use.

Start by listing the components that would have to be restored after accidental deletion, malware, a failed update, hardware trouble, or a hosting migration:

• Website files: themes, plugins, application code, images, documents, and other uploads.
• Databases: posts, products, orders, customer records, settings, and other dynamic content.
• Configuration: environment variables, web server settings, deployment files, scheduled jobs, and application secrets. Store secrets securely rather than exposing them in a general archive.
• Domain and DNS information: registrar access, DNS records, mail routing, verification records, and the intended values for A, CNAME, MX, TXT, or AAAA records. For background, see this practical guide to DNS records.
• Operational documentation: the hosting account, database engine, runtime versions, deployment steps, SSL certificate process, and contact details for critical providers.

A useful baseline is the 3-2-1 approach: keep at least three copies of important data, use at least two different storage locations or media types, and keep at least one copy separate from the primary hosting environment. The exact implementation can vary, but the principle is important: a backup stored only on the same server is not a complete disaster-recovery plan.

Checklist by scenario

Small brochure or business website

• Schedule a full backup of site files and any database used by the CMS.
• Save a separate copy of important brand assets, downloadable files, and contact-form configuration.
• Export or document DNS records and confirm who controls the domain and hosting accounts.
• Keep one recent backup off the hosting account.
• Test restoring the site to a temporary location before relying on it.

If the site changes only occasionally, a weekly backup may be adequate as a starting point, with a manual backup before substantial edits. The right frequency depends on how much new work the business can afford to recreate.

WordPress website

• Back up both the WordPress database and the complete wp-content directory, including uploads, themes, and plugins.
• Include configuration details such as wp-config.php, while protecting database credentials and secret keys.
• Take a fresh backup before WordPress core, theme, plugin, PHP, or hosting changes.
• Keep a known-good copy from before the update, not only the newest copy.
• Restore to a staging or temporary environment and check the front end, administration area, forms, search, media, and key integrations.

A WordPress backup plan should account for content frequency. A site publishing every day needs more frequent database backups than a site updated once a month. A performance review, such as the WordPress hosting performance checklist, is also a good opportunity to verify that backups and restore procedures remain usable.

Online store or membership site

• Use a backup frequency that limits the possible loss of orders, customer changes, inventory updates, or subscriptions.
• Confirm whether payment, email, shipping, analytics, and membership data are stored locally or with external providers.
• Protect personal and financial data with access controls and encryption where supported.
• Document how to pause transactions or place the site in maintenance mode during recovery.
• Test that restored orders, accounts, product data, and transactional email behave as expected without sending duplicate messages or charges.

Custom application or developer deployment

• Version application code in a repository and treat the repository as one part of the recovery plan, not the entire plan.
• Back up production databases, user uploads, object-storage data, and required infrastructure configuration.
• Record runtime versions, build commands, dependency sources, migration steps, and scheduled tasks.
• Store environment secrets in an appropriate secret-management system and document how authorized operators retrieve them.
• Perform a clean deployment to a separate environment using the documented process.

Deployment utilities can help inspect configuration and scheduled tasks during preparation; the developer deployment tools guide covers several related workflow checks.

What to double-check

Do not judge a backup by whether a job reports “successful.” Verify its contents and its recovery path.

1. Coverage: open the archive or backup dashboard and confirm that recent files, uploads, and database data are present.
2. Timing: compare the backup timestamp with the site’s update schedule. A daily backup that runs before daily publishing may not capture the latest changes.
3. Retention: define how many daily, weekly, or monthly restore points are needed. Retention should cover routine mistakes as well as delayed discovery of corruption or compromise.
4. Independence: confirm that at least one copy is outside the primary hosting account and cannot be deleted by the same credentials or automated process.
5. Access: check that the people responsible for recovery can reach the storage location, recovery instructions, hosting account, and domain registrar.
6. Integrity: use checksums, provider verification, or a test extraction where available. A file that cannot be opened is not a dependable backup.
7. Restore scope: decide whether you need a complete site restore, database-only recovery, individual-file recovery, or a new-server deployment.

Host-managed backups can be convenient and may simplify restoration, but they should not automatically be treated as the only copy. Ask what is included, how long backups are retained, whether restoration requires support, and whether the backup remains available if the hosting account is inaccessible. These details vary by provider and plan, so record the answers for your specific environment.

Common mistakes

• Backing up only the database: this may preserve content while omitting media, code, themes, plugins, or configuration.
• Backing up only the files: dynamic content often lives in a database and will not be recreated from the file system alone.
• Keeping every copy on one host: an account lockout, server issue, compromised credentials, or accidental deletion can affect all copies.
• Never testing a restore: backup success does not prove that the archive is complete or that the recovery steps are understood.
• Ignoring DNS and email: a restored website can still appear offline or lose mail if DNS records and mail settings are missing.
• Overwriting the only good backup: retain restore points from before major updates and keep a longer-term copy according to your risk.
• Exposing sensitive archives: backups may contain credentials, personal information, or private business data. Restrict access and avoid placing archives in publicly served directories.

When to revisit

Review the backup plan before seasonal planning cycles, major launches, platform upgrades, and hosting changes. Revisit it immediately when the site adds a database, changes its publishing frequency, introduces customer accounts, moves providers, or adopts a new deployment workflow.

Use this recurring routine:

• After each major change: create a manual snapshot and record what changed.
• Monthly: inspect backup logs, verify storage access, and perform a small restore or extraction.
• Quarterly: complete a restoration rehearsal on temporary infrastructure and update recovery documentation.
• Annually: review retention, storage costs, account ownership, DNS documentation, security controls, and the capabilities of your hosting backup service.

Finish by writing a short recovery runbook: identify the incident, protect the remaining data, choose the correct restore point, rebuild or restore the environment, verify DNS and SSL, test core user journeys, and communicate the result. A backup strategy becomes dependable when another authorized person can follow that runbook without guessing.