Back up a small website

What it means

A website backup is a separately retained, restorable copy of the information needed to recover the site after a failure or mistake. For a small static site that might include source, build inputs, configuration and necessary release artifacts. A dynamic site can also require database-consistent backups, uploads, object storage and external-service settings. A backup is useful only if the complete recovery path has been tested. Recovery testing

A Git repository does not necessarily include uploads or a database. A snapshot of one server does not necessarily cover external storage, DNS configuration or secrets. A copy of files on the same failing disk is not a sufficient independent recovery location.

Try it

Simulation — lose the primary site and test a recovery point. Inspect the synthetic inventory, simulate primary-disk loss, restore into the isolated rehearsal and verify. The states separate a stored backup, an attempted restore and a verified synthetic recovery.

The default dynamic site needs compatible source/configuration, a consistent database and uploads. Choose the missing-database recovery point to see why source plus output is incomplete. Choose a copy stored only on the primary disk, inspect it and simulate loss: its previous existence does not make it independently recoverable. A mismatched version, inconsistent database or corrupt copy also blocks successful restoration.

The incident is fixed at 12:00 and the selected point at 11:00 in this exercise, giving a 60-minute potential data gap. The rehearsal uses a declared 45-minute recovery duration. Compare those constants with your chosen RPO and RTO targets, but do not treat them as measured performance or a promise for any backup product.

Reset restores the complete separate recovery point, target values and initial uninspected state. Changing the recovery plan starts a fresh rehearsal. The scene never reads files, databases, provider credentials or real timestamps, and does not create a backup archive. Verification covers only the stated synthetic site. Recovery objectives Testing recovery

Environment, safety and rollback

The real procedure applies to an owner-authorized site with an identified recovery operator and approved backup locations. Use the product's documented consistency mechanism for each live datastore; there is no universal safe command to copy every running database. Test restoration in a new isolated destination with appropriately protected test-safe access. Keep the current production system unchanged during the experiment.

Stop if a required component, decryption/access path, consistent data point or compatible application version is missing. Do not put database exports, private keys or real environment files into a public website source package. A failed isolated restore is evidence to retain, not a reason to overwrite production with the partial result. The safe rollback of this test is to leave the active site untouched; any later production recovery and cleanup need their own authorized plan and verification.

Plan before copying anything

1. Inventory where the site really stores state: source, configuration, uploaded content, databases, hosted forms, third-party providers and DNS. Identify what can be regenerated and what cannot.
2. Define a realistic recovery point objective (RPO) — how much recent change can be lost — and recovery time objective (RTO) — acceptable restoration delay. More frequent copies reduce potential loss but add operational cost. Recovery objectives
3. Choose versioned backups and independent/offsite retention; protect them against accidental deletion and ransomware with appropriate access controls and, where available, immutability. Decide retention and who can authorize destruction.
4. For a running database, use the database or managed service's supported consistent backup mechanism. Copying live database files without its documented snapshot/transaction method can produce a corrupt or internally inconsistent restore.
5. Record who owns each restore step and what credentials/tools are required. Keep recovery instructions accessible during a primary-site outage, but store actual secrets in a protected system, not in a public runbook.

Execute and verify safely

Use an approved backup service or documented product-specific export routine for each layer. Collect success/failure evidence, sizes, timestamps, encryption state and destination inventory. Compare hashes for file integrity where appropriate; a matching hash alone does not prove an application can boot from the backup.

Test recovery in a separate isolated environment with test-safe data access. Reconstruct the selected source/release, restore the compatible database and uploads, apply restricted configuration, then check actual page responses and application behavior. Never overwrite production to perform a first restore experiment. Record what failed and update the runbook. Restore test requirement

If recovery fails, keep existing production unchanged, investigate the missing layer, and revise the backup plan before declaring it reliable. Test both a small file recovery and a representative complete-site scenario at a schedule consistent with site risk.

In practice

Start with the smallest independently useful restore: a rebuilt static site plus a known-good release. Add database consistency and uploads only when the application uses them. See Static vs dynamic website for what may be generated, SSH vs SFTP for secure authorized transfer, and HTTP 404 troubleshooting for verifying restored routes. Backup completion, verified restore and public release are distinct outcomes.

Key takeaways

Inventory everything required to rebuild and operate the site, including mutable state and recovery access. Keep independently recoverable copies, test compatibility and consistency, and record restore verification separately from backup-job success. A source ZIP, checksum or same-disk copy is not a complete recovery proof.