Website Backups: What to Back Up and How to Test Recovery

Website Management August 19, 2025

A backup is only useful if it contains what you need and can actually be restored. Copying a few website files to another directory is not necessarily a backup strategy, especially for a database-driven website.

A practical backup plan answers four questions: what gets backed up, how often it is backed up, where copies are stored, and how recovery is tested.

Server and data storage concept — Backups should provide recovery options when the production environment fails.

What Should a Website Backup Include?

Data	Why it matters	Common mistake
Website files	Application code, themes, plugins, uploads	Backing up only the database
Database	Posts, users, settings, orders, application data	Assuming files contain everything
Configuration	Credentials, environment settings, custom configuration	Not documenting secrets or dependencies
Email	Messages and mail configuration	Assuming website backups include mailboxes
DNS information	Helps reconstruct services after a move	Having no record of DNS settings

Files and the Database Are Different

For WordPress, the database contains posts, pages, users, settings, menus, and other information that does not exist as ordinary files. The uploads directory contains media, while themes and plugins contain application code.

Restoring only one side can produce a broken website. A complete backup strategy therefore needs both the file system and the database, along with configuration information required to connect them.

How Often Should You Back Up?

The correct schedule depends on how much data you can afford to lose. A static business website that changes once a month has different requirements from an online store processing orders every hour.

Website type	Possible starting point	Why
Static brochure site	Weekly or after changes	Low change frequency
Active business site	Daily	Regular content and form activity
Busy WordPress site	Daily or more frequently	Frequent content changes
Ecommerce	Frequent database backups	Transactions can be difficult to recreate

These are planning examples, not universal requirements. Your recovery point objective should determine the schedule.

Keep More Than One Recovery Point

If a site becomes infected or corrupted and you discover the problem several days later, the newest backup may contain the problem too. Retaining multiple historical recovery points gives you more options.

A practical retention policy might keep daily backups for a short period and weekly or monthly snapshots for longer-term recovery. The right retention period depends on the site’s operational needs and available storage.

Store Backups Away From the Production Server

A backup stored only on the same server is vulnerable to the same server-level failure. Hardware failure, filesystem corruption, account compromise, or an administrative mistake can affect both the live site and the local backups.

Keep independent copies in another storage location whenever practical. The exact architecture can range from another server to dedicated backup storage or object storage.

Test Restoration

This is the part many backup strategies skip. A backup job can report success while the resulting files are incomplete, corrupted, inaccessible, or missing a required database.

Periodically restore a backup to a test environment. Verify that the application starts, the database connects, uploaded media exists, configuration is correct, and important functions work.

Protect Backups

Backups contain valuable information and may contain credentials, customer information, private documents, or other sensitive data. Protect backup storage with appropriate authentication and access controls.

Use separate credentials where practical.
Restrict who can delete or modify backups.
Encrypt backups when appropriate.
Monitor backup jobs and failures.
Retain enough historical copies to recover from delayed problems.

Recovery Checklist

Identify the failure and stop making unnecessary changes.
Choose a known-good recovery point.
Restore files and database data.
Restore required configuration.
Verify permissions and ownership.
Test the application before returning it to production.
Document what caused the failure and what was changed.

Final Thoughts

A reliable backup strategy is not measured by how many files are copied. It is measured by whether you can recover the website and its data when something goes wrong.

GaugeHosting provides hosting environments where website files, databases, domains, and other services can be managed from one hosting account. Learn more at GaugeHosting.

RPO and RTO

Two useful concepts for backup planning are recovery point objective and recovery time objective. RPO describes how much recent data you can afford to lose. RTO describes how quickly the service needs to be restored.

A site that can tolerate losing a day’s content has a very different backup design from an application where losing ten minutes of transactions is unacceptable.

Snapshots Are Not Always a Complete Backup

A server snapshot can be useful, but it should not automatically be treated as the only recovery mechanism. A snapshot tied to the same infrastructure may not protect against every type of failure, and application-consistent backups can provide additional recovery options.

Document the Recovery Procedure

Write down where backups live, which credentials are required, how the database is restored, how DNS is changed, and how the application is brought back online. During an outage, documentation reduces the amount of information someone has to reconstruct from memory.

Back Up Before Major Changes

Create a known-good recovery point before major WordPress updates, plugin changes, theme replacements, database maintenance, or configuration changes. The backup gives you a defined point to return to if the change causes an unexpected failure.

Know What Your Host Actually Backs Up

Do not assume a hosting provider’s backup service covers every service associated with your account. Ask whether databases, mailboxes, configuration, and scheduled tasks are included, how long copies are retained, and whether restoration can be performed selectively.

Website Backups: What to Back Up, How Often, and How to Test Recovery