Website backup: what needs saving and how often?

Define what recovery means

A backup plan should begin with a recovery question: if the website disappears today, what must be available tomorrow? A brochure site may need pages, images, forms and settings restored. A shop may also need products, orders, customer accounts, payment configuration and integrations. The right plan depends on the business impact of downtime and the amount of recent data it cannot afford to lose.

Define a realistic recovery time and recovery point. Recovery time is how quickly the site needs to work again. Recovery point is how much recent activity the business can afford to lose. A site updated once a month may not need the same schedule as a booking site receiving reservations every hour. These decisions help avoid both false confidence and unnecessary cost.

Write the recovery priority down and share it with the people who handle incidents. In a stressful outage, a short list of essential pages and systems is more useful than an undocumented assumption that everything has equal priority.

Save more than visible page files

Website files are only one part of a working site. Save the database, uploaded media, themes, plugins, custom code, configuration files, environment settings and scheduled tasks where relevant. Record DNS, domain, hosting, email and third-party integration details separately in a secure handover document. Without configuration, a folder of files may not be enough to recreate the service.

Include forms, submissions and important downloads in the plan. A backup that restores the page design but loses enquiry data may fail the business’s real recovery need. For a shop or booking system, confirm how orders, availability, customer records and payment settings are protected. Ask the provider exactly what its automated backup includes instead of assuming that “daily backup” covers everything.

Check whether the provider can restore a database and files together. Version mismatches can leave a site looking present while forms, logins or stored content fail. A recovery test should check behaviour, not only whether the homepage opens.

Choose a frequency based on change

Create backups more often when the site changes more often or when lost activity has a direct cost. A small information site may need a weekly full backup with more frequent database copies if forms are active. A shop or booking service may need daily or near-continuous protection for important data. Keep a backup before major updates, migrations, redesigns and bulk content changes.

Do not confuse frequency with retention. A schedule tells you how often copies are created; retention tells you how many past versions remain available. Keep enough history to recover from a problem discovered late, such as a damaged plugin or unnoticed account compromise. Choose a retention period that fits the business, legal duties and storage cost.

Keep at least one known-good version from before major changes. If a problem is introduced gradually, the newest copy may contain the same problem. Historical versions give the team a safer point from which to investigate.

Keep copies separate and protected

If every backup lives on the same server as the website, one incident may affect both. Keep at least one copy in a separate environment or account. Consider offline or otherwise isolated copies for higher-risk systems. Use encryption where appropriate, restrict access and protect recovery credentials with multi-factor authentication.

Backups can contain personal information, customer messages and account data. Treat them as sensitive business information. Limit who can download or restore them, check the provider’s security practices and avoid keeping unnecessary data forever. A backup plan should support privacy and recovery at the same time rather than creating an uncontrolled second database.

Use separate permissions for reading, creating and deleting backups where the provider supports them. The person who edits the website does not necessarily need the ability to erase every recovery copy.

Test restoration in a safe place

A completed backup is not proof that recovery works. Restore a copy in a staging environment and check that pages load, forms submit, media appears, integrations connect and users can complete important journeys. For shops, test product data and order history without sending real payments. Record how long the process takes and which credentials or manual steps are needed.

Test after changing hosting, plugins, payment tools or the backup provider. Keep instructions understandable to someone who did not create the original setup. If restoration depends on one person’s private knowledge, the plan is fragile. A short, repeatable recovery exercise can expose missing files, incompatible versions and access problems before a real outage does.

Explain to staff what a backup does not solve. It cannot automatically remove malware, reverse a fraudulent payment or decide whether personal data should be retained. Recovery also needs security and business decisions.

Assign responsibility and review the plan

Decide who receives backup alerts, investigates failures and approves a restore. Check logs rather than assuming that a scheduled job completed. Document where copies are stored, how long they are retained, who has access and what the first recovery steps are. Include contacts for hosting, domain, email and critical integrations.

Review the plan after business or website changes. New forms, customer accounts, payment flows, languages and integrations can create new recovery requirements. Once or twice a year, perform a practical restore test and update the documentation. The purpose of a backup is not to own copies; it is to give the business a reliable path back to a working website.

Record the outcome of each test, including time, missing steps and improvements. Treat failed restoration as useful information and fix the process before the next update or incident.

Sources

• Data Integrity: Recovering from Ransomware and Other Destructive Events · NIST

Frequently asked

Is a hosting provider’s automatic backup enough?

It may be part of the plan, but check what it includes, how long copies are retained, where they are stored and whether you can restore independently. Keep a separate recovery option for important sites.

How often should a small business back up its website?

Match frequency to how often content, enquiries, orders or bookings change. Weekly may suit a simple site, while a transactional site may need daily or more frequent protection.

How do I know whether a backup works?

Restore it in a safe staging environment and test pages, forms, media, integrations and important customer journeys. A file existing on a server is not the same as a usable recovery.