Website Backup and Recovery Plan: A Practical Guide
A backup you have never restored is a rumour. The plan matters less than the test, and the test takes an afternoon.
Every website owner says they have backups. Far fewer have restored one. The gap between the two is where small businesses lose weeks of content, orders and search rankings. A backup is not a file that exists; it is a file you have successfully used to bring the site back.
This guide builds a practical backup and recovery plan for a small site in 2026, then shows how to test it without waiting for a disaster.
Decide what a full restore means
A website is more than its HTML. It includes the database, uploaded media, theme and plugin files, configuration, email templates and any integrations. For a small shop, it also includes orders, customers and product data. Write down every component a new server would need to reproduce the site exactly.
Then decide the two numbers that shape the plan: how much data you can afford to lose, and how long the site can be offline. A brochure site might accept a day of lost form submissions and four hours of downtime. A shop taking orders may need fifteen-minute backups and a one-hour restore. The numbers set the budget.
The 3-2-1 rule for websites
Keep three copies of the site, on two different types of storage, with one copy off-site. In practice: the live site, an automated backup on a separate provider, and a periodic archive downloaded to a local drive or cold storage. The off-site copy is the one that survives a host outage, a ransomware attack or an account suspension.
Make sure the backup provider is not the same account as the hosting provider. If one login controls both, a compromised account can delete the site and its backups together. Separate accounts, separate credentials, separate recovery paths.
Backup frequency and retention
Daily automatic backups are a sensible default for most small sites. Increase to every few hours if you take orders or publish frequently. Keep at least seven daily copies, four weekly copies and three monthly copies. That retention covers the common cases: a bad update noticed the next morning, a compromise discovered a week later, and a slow data corruption that takes a month to surface.
Check that the backup actually includes the database and uploads, not just files. Many "one-click" backups quietly exclude large media folders. Check the size and the file list, and compare it with the live site. A backup that is missing images is a partial backup.
Where to store copies safely
Use storage that the production server cannot overwrite. Object storage with versioning and an immutable retention period is a strong option. A local drive kept offline is a good third copy, as long as it is not permanently connected to the same network. Encrypt archives that contain customer data and store the encryption key separately.
Restrict access to the backup account, enable two-factor authentication and log who downloads an archive. A backup contains everything an attacker wants, so it deserves the same care as the live database. Do not email archives to yourself or leave them in a public folder.
A backup stored on the same server as the site is not a backup. It is a second copy of the disaster.
Helen Park
Test a restore
Schedule a restore test every quarter. Create a staging environment, restore the latest archive and check that the homepage, a product page, the login and a checkout all work. Compare a few records with the live database. Note the time it took and the steps that were unclear.
- Pick the most recent backup and confirm its timestamp.
- Restore to a separate environment, never over the live site.
- Check pages, images, forms, logins and payments.
- Record the restore duration and any missing pieces.
- Update the runbook with what you learned.
If the restore fails, fix the plan now. A failed test is cheap; a failed recovery during a real incident is not. Keep the last successful test date visible in the runbook so nobody assumes a backup is healthy because the dashboard is green.
Key facts
- Three copies, two storage types, one off-site.
- Daily backups minimum; hourly for active shops.
- Keep 7 daily, 4 weekly and 3 monthly copies.
- Use immutable or offline storage for the third copy.
- Test a restore every quarter and record the time.
The incident runbook
Write one page with the steps to take when the site is down or compromised. Start by deciding whether to restore or clean. If malware or an unauthorised admin account is involved, restore from a known-good backup taken before the compromise, then change every password. If the host is down, contact support and use the off-site copy elsewhere.
Include contacts for the host, domain registrar, payment provider and a developer who can help. Include the location of the encryption key and the backup account recovery codes. Print the page and keep a copy offline. Our guide to web security basics covers the prevention side.
After a recovery
Once the site is back, confirm that search engines can crawl it, that email still sends and that no stale admin accounts remain. Review logs for the cause and close the gap that allowed it. Tell customers what happened in plain language if their data or orders were affected, and check whether notification rules apply in your region.
Then update the backup schedule and retention based on what you learned. A recovery is also a review. The goal is not to return to the old setup unchanged; it is to return with one fewer single point of failure.
For independent guidance on backup practice, the CISA data backup guidance is short and practical. If you are launching a new product, the startup launch checklist includes the backup step before the first customer arrives.
Final word
Backups are insurance, and insurance is only real when the claim process works. Keep copies separate, test the restore and write the runbook for the worst day. The afternoon you spend testing is the cheapest downtime you will ever buy.