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

Example — a backup coverage sheet, not a running backup job. Use each applicable row as a checklist for your own deployment; no live data is read or transferred here.

The sheet identifies required classes of data, not permission to place private keys, .env files or database dumps in a website source ZIP. Sensitive backup material belongs in separately access-controlled, encrypted storage with defined recovery ownership. Secure backup practices

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.