How to build a website backup and restore routine

Nobody discovers their backup strategy is broken on a quiet afternoon — it happens mid-restore, with the site down and everyone watching. A backup earns its keep only if it contains everything required, survives the incident that took production down, and restores within the time the business can tolerate. Design the routine backwards from that restore.

Define recovery objectives

The recovery point objective (RPO) is the maximum acceptable data loss measured in time. The recovery time objective (RTO) is the target time to restore service.

A brochure site updated monthly may accept a longer RPO. A store receiving orders continuously needs more frequent database protection. Document separate objectives for content, transactions, uploads, and infrastructure.

Inventory what must be recoverable

Include:

• databases and uploaded files,
• application code or release artifacts,
• environment configuration and secrets recovery,
• web-server and runtime configuration,
• DNS zones and domain ownership records,
• certificates or the ability to reissue them,
• scheduled jobs, queues, and integration settings,
• deployment definitions and required documentation.

Do not assume a server snapshot captures external storage, managed databases, DNS, or SaaS configuration.

Choose frequency and consistency

Match backup frequency to the RPO. Coordinate database and file backups so they represent a consistent state. For high-write systems, use application-aware database backups, replication, or transaction logs as appropriate.

Retain multiple recovery points. A single daily backup can copy corruption or deletion before anyone notices.

Separate and protect copies

Keep at least one copy outside the production server and account or use properly configured immutable storage. CISA recommends offline, encrypted backups and regular integrity testing because ransomware often targets accessible backups.

Encrypt sensitive data in transit and at rest. Restrict backup deletion, change retention settings through controlled accounts, and monitor unexpected changes.

Monitor every run

Alert on missed jobs, incomplete scope, zero-byte or unusually small archives, retention gaps, failed uploads, and expiring credentials. Verify checksums or the backup system’s integrity mechanism.

A green scheduler status proves the job ran. It says nothing about whether the archive contains a working website.

Run a restore exercise

Restore into an isolated environment. Recreate configuration, import data, reconnect storage, start the application, and test critical functions. Measure elapsed time and compare it with the RTO.

Confirm users, permissions, media, forms, transactions, background jobs, and HTTPS. Record missing items and update the inventory and automation.

Run smaller tests regularly and a full recovery exercise after major architecture changes. Ensure more than one authorized person can execute the runbook.

Retire backups deliberately

Set retention according to recovery, legal, privacy, and cost needs. Deleting old backups should be a controlled process with an audit trail. When data must be removed, include backup retention in the deletion policy rather than promising immediate erasure that the architecture cannot perform.

Sources and further reading

• CISA: #StopRansomware Guide