Website Backup Strategy: What to Back Up and How Often

Why Backup Strategy Matters More Than Backups

Most websites have backups. Fewer have a backup strategy. The difference shows up at the worst possible moment: when you actually need to restore.

A backup without a strategy means you might have a copy of your files from three months ago, but no database backup. Or you have daily database backups, but they are stored on the same server as the database itself. Or you have everything backed up, but you have never tested a restore and have no idea whether the backups actually work.

A backup strategy answers five questions: what to back up, how often, where to store it, how long to keep it, and how to verify it. This guide covers all five. For the broader context on maintenance workflows, see the website maintenance and monitoring guide.

What to Back Up

A complete website backup includes more than just the files visible in your web directory. Miss any of these components and your restore will be incomplete.

Application Files

This includes your CMS core files, themes, templates, plugins, custom code, uploaded media (images, PDFs, videos), and static assets. For a WordPress site, this means the entire wp-content directory plus any custom files in the root. For a custom application, it means your entire deployment directory.

Do not assume you can just reinstall the CMS and plugins from scratch. Your specific versions, configurations, and customizations matter. A plugin you installed two years ago may no longer be available in the exact version you are running.

Database

Most dynamic websites store content, user data, settings, and metadata in a database. WordPress uses MySQL or MariaDB. Many modern applications use PostgreSQL. Some use both a relational database and a document store like MongoDB.

The database is often the most critical component to back up. Your files can potentially be rebuilt from version control, but your content, user accounts, orders, and application data exist only in the database.

Database backups require a different approach than file backups. You cannot just copy the database files while the database is running. You need a logical dump (using mysqldump, pg_dump, or equivalent) or a snapshot taken while the database is in a consistent state.

Configuration Files

Server configuration files are easy to overlook but painful to reconstruct from memory. Back up:

• Web server config (Nginx nginx.conf and site configs, Apache httpd.conf and .htaccess)
• Application environment files (.env, config.yml, settings.py)
• SSL certificate files and private keys
• Cron job definitions (crontab -l output)
• Firewall rules
• Container orchestration files (Docker Compose, Kubernetes manifests)

These files contain the logic that makes your server work the way it does. Without them, restoring files and database to a new server requires manually reconfiguring everything.

DNS Records

Your DNS configuration is not stored on your server. It lives at your DNS provider (your registrar, Cloudflare, Route 53, etc.). If you lose access to your DNS provider or make a mistake editing records, you need a record of what they should be.

Export your DNS zone file periodically. Most DNS providers offer an export feature. Store the export alongside your other backups. For more on DNS-related resilience, see DNS monitoring explained.

SSL Certificates and Keys

If you manage your own SSL certificates (not using auto-provisioned certs from services like Let's Encrypt or Cloudflare), back up both the certificate file and the private key. Losing the private key means you cannot use the certificate and need to reissue.

Even with auto-provisioned certificates, document which provider handles your SSL and how to re-provision. During a migration or disaster recovery, you need to restore HTTPS quickly. For renewal processes, see the SSL renewal checklist.

How Often to Back Up

Backup frequency depends on how often your data changes and how much data loss you can tolerate. This is called your Recovery Point Objective (RPO): the maximum amount of data you are willing to lose.

Database: Daily (Minimum)

For most websites, daily database backups are the minimum. If your site has frequent content updates, user-generated content, or e-commerce transactions, consider more frequent backups. An e-commerce site processing orders should back up its database every few hours at minimum. Losing a full day of orders is unacceptable for most businesses.

High-traffic applications with continuous data changes may need continuous replication (a real-time copy of the database on a separate server) rather than periodic snapshots. This provides near-zero RPO.

Files: Weekly (Plus Before Every Change)

Website files change less frequently than databases. For most sites, weekly file backups are sufficient. But there is a critical addition: always back up before making changes.

Before you update your CMS, install a new plugin, modify a theme, or deploy new code, take a backup. If the change breaks something, you can roll back immediately instead of waiting for the next scheduled backup.

If your deployment process is automated (CI/CD pipeline), build the backup into the pipeline. A pre-deployment backup should be a standard step, not something you remember to do manually.

Configuration: After Every Change

Configuration files change infrequently, but each change is significant. The best approach is to keep configuration in version control (Git). Every change is tracked, reversible, and documented. If you cannot use version control for your server configs, back them up immediately after any modification.

DNS Records: Monthly (Plus Before Every Change)

DNS changes are infrequent for most sites. A monthly export of your zone file catches any drift. Always export before making DNS changes so you can revert if a change causes problems. Your domain renewal checklist should include a DNS backup step.

Backup Methods

Hosting Provider Snapshots

Most cloud hosting providers (AWS, DigitalOcean, Linode, Vultr) offer server snapshots. A snapshot captures the entire server state: files, database, configuration, everything. Snapshots are the easiest backup method because they require no setup beyond clicking a button or scheduling an API call.

The downside: snapshots are stored within the same provider. If you lose access to your hosting account, you lose your snapshots. Snapshots should be one layer of your backup strategy, not the entire strategy.

Plugin-Based Backups

CMS platforms like WordPress have backup plugins (UpdraftPlus, BackWPup, Duplicator) that handle file and database backups and can send them to remote storage (S3, Google Drive, Dropbox). These are convenient and require minimal technical knowledge.

The limitation: plugins back up what the CMS knows about. They may miss server configuration files, cron jobs, or files outside the CMS directory. They also depend on the CMS being functional. If your WordPress installation is broken, you cannot use a WordPress plugin to back it up.

Manual Backups

Manual backups involve SSH-ing into your server, running mysqldump for the database, and using tar or rsync for files. This gives you full control over what is included and where the backup is stored.

The downside: manual backups depend on you remembering to do them. Automate the process with a cron job or a script in your deployment pipeline.

CI/CD Pipeline Backups

If your site is deployed through a CI/CD pipeline (GitHub Actions, GitLab CI, Jenkins), your application code is already backed up in version control. Add database backup and configuration backup steps to your pipeline. Before each deployment, dump the database and push it to secure storage.

This approach ties backups to deployments, which is when you are most likely to need a rollback.

Managed Database Backups

If you use a managed database service (AWS RDS, Google Cloud SQL, PlanetScale, Supabase), the provider handles automated backups with point-in-time recovery. Verify the backup retention period and test the restore process. Managed backups are reliable but you still need to know how to use them.

Where to Store Backups

The cardinal rule of backup storage: your backups must not be stored in the same failure domain as the original data.

Offsite Storage

If your server is at Provider A, store backups at Provider B. If your entire hosting account is compromised, deleted, or suspended, your backups at a separate provider remain accessible.

Common offsite storage options:

• Amazon S3 (with versioning enabled)
• Google Cloud Storage
• Backblaze B2
• A different hosting provider than your primary
• A separate cloud account (even at the same provider, a separate account isolates against account-level issues)

Multiple Locations

The 3-2-1 backup rule: keep 3 copies of your data, on 2 different types of media, with 1 copy offsite. In modern cloud terms, this translates to: keep your primary data, a backup at your hosting provider (snapshots), and a backup at a separate provider (offsite).

For critical sites, add geographic diversity. Store backups in a different geographic region than your primary server. A natural disaster, power grid failure, or regional internet outage that affects your server will not affect backups stored thousands of miles away.

Retention Policy

Do not keep only the most recent backup. Define a retention policy:

• Keep daily backups for 7 days
• Keep weekly backups for 4 weeks
• Keep monthly backups for 12 months

This protects against problems that are not immediately obvious. If malware corrupts your database and you do not notice for three days, your last 3 daily backups all contain the corruption. Having a weekly backup from before the corruption occurred gives you a clean restore point.

Adjust retention based on your storage budget and data sensitivity. More retention means more storage costs, but also more recovery options.

Testing Restores

A backup that has never been tested is not a backup. It is a hope.

Regular Restore Tests

Schedule restore tests at least quarterly. Take your most recent backup, restore it to a separate environment (a staging server, a local development machine, a temporary cloud instance), and verify that the site works.

Check:

• Does the site load and function correctly?
• Is the database data complete and current?
• Do all media files (images, uploads) display?
• Does the configuration match the production environment?
• Are SSL certificates present and valid (or can you provision new ones quickly)?

Measure Recovery Time

During your restore test, time the process from start to finish. This is your Recovery Time Objective (RTO) in practice. If it takes you 4 hours to restore from a backup, you need to know that before an actual disaster. If 4 hours is too long, invest in faster restore methods (pre-built server images, automated provisioning scripts, database replication).

Document the Restore Process

Write down every step of the restore process. What commands to run, in what order, with what credentials. Store this documentation outside your server (if the server is down, you cannot access documentation stored on it). A simple document in your team's shared drive or a dedicated runbook in your incident response system works.

For a complete incident response framework, see the incident response plan template.

Disaster Recovery Planning

Backups are one part of disaster recovery. The full plan also covers:

Communication. Who needs to know when disaster strikes? How do you notify users that the site is down and being restored? See the website downtime causes and prevention guide for context.

Priority order. If you have multiple sites or services, which ones do you restore first? Define priorities before the disaster, not during it.

Alternative operations. What do you do while the site is being restored? Can you put up a static maintenance page? Can you redirect to a temporary site? Can critical business functions continue offline?

Provider contacts. Have support contact information for your hosting provider, DNS provider, domain registrar, and CDN readily available. You do not want to search for a support phone number during an outage.

Credentials access. Ensure that server passwords, database credentials, API keys, and provider login details are accessible to the people who need them during a disaster. Use a team password manager with emergency access provisions.

Backup Automation Checklist

A practical summary for implementing your backup strategy:

1. Identify every component that needs to be backed up (files, database, config, DNS, SSL)
2. Set backup frequency for each component based on how often it changes
3. Choose backup methods for each component
4. Configure offsite storage with a separate provider
5. Set up a retention policy (7 daily, 4 weekly, 12 monthly as a starting point)
6. Automate everything. No backup should depend on someone remembering to run it
7. Test a full restore quarterly
8. Document the restore process in a location accessible when the server is down
9. Review and update the strategy whenever your infrastructure changes

The best time to build a backup strategy is before you need it. The second best time is now.