Website Backup and Disaster Recovery Plan for Small Businesses

A website backup and disaster recovery plan answers three questions before anything goes wrong: what is backed up and how often, where the copies are kept, and who restores the site, how, and how fast. For most small businesses that means automatic daily backups of the files and database, at least one copy stored away from the hosting company, several weeks of history, and a restore test every few months. A backup you have never restored is a hope, not a plan.

This guide is for business owners and managers who rely on their website for leads or sales and want to know if they are covered. It works for WordPress, WooCommerce and most other sites.

#Why a host backup alone is not enough

Many hosts include backups, and they are a good first layer. They are not a full plan, for three reasons:

• Same place, same risk. If the backups sit in the same account or data centre as the site, an account lock, a billing dispute, a hack with control panel access or a provider outage can affect both.
• Short history. Some host backups only keep a short window. Malware is often found weeks after it arrived, and every backup in that window may contain it.
• No one owns the restore. A backup is only useful if someone knows how to restore it, to which server, and how long it takes.

CISA, the US cybersecurity agency, advises small businesses to use backups that run automatically and regularly, to protect them with encryption, physical security and offline copies, and to test that the team can restore data fully and partially. That last point is the one most often skipped.

#The 3-2-1 rule for websites

The 3-2-1 rule means keeping three copies of important data, on two different types of storage, with one copy off-site. CISA uses a hard drive and the cloud as its example of two types of storage. For a website, it looks like this:

The off-site copy is the one that matters most. Store it in a separate cloud storage account (for example an object storage bucket) with its own login and two-factor authentication. Where the storage supports it, turn on versioning or immutable storage, so a backup cannot be changed or deleted for a set period, even by someone with the password. WordPress's own documentation suggests keeping copies in several places: on the server, in cloud storage and on your own computer.

#How often to back up, by site type

Set the backup frequency by how much data you can afford to lose. In disaster recovery terms, this is the recovery point objective (RPO): NIST defines it as the point in time to which data must be recovered after an outage. If you back up nightly and the site fails at 6pm, you lose up to a day of changes.

WordPress's documentation suggests weekly backups for small sites with few posts and daily for busy ones, and always a backup before an upgrade. These are starting points; a store that takes orders all day should not accept a 24-hour gap in orders.

Two points that save trouble later:

• Back up both halves. A WordPress site is the files (themes, plugins, uploads, wp-config.php, .htaccess) plus the database (pages, orders, users, settings). Backing up the files does not back up the database. WordPress says you need both to restore the site.
• Back up before every change. Take a fresh backup before updates, plugin installs and theme changes. Our guide to what to do when a WordPress update breaks your site shows why.

#Retention: how long to keep backups

Keep enough history to go back to a clean copy from before a problem started. CISA suggests being able to roll data back at least seven days, and WordPress suggests keeping at least three to five recent backups. For a business site, more is usually better, because hacks and slow data corruption are often found weeks later.

A simple pattern that works for most small businesses:

1. Daily backups kept for 30 days.
2. Weekly backups kept for three months.
3. Monthly backups kept for a year.

Check the legal side too. Backups of a store or CRM contain personal data, so they need the same protection as the live site, should be encrypted, and should not be kept forever. If you collect data from customers in India, our guide to the DPDP Act for website owners covers the wider duties.

#Testing restores

Test a restore at least every few months, and after any big change to the site or hosting. A test proves three things: the backup is complete, someone knows the steps, and you know how long it takes.

1. Pick a backup from the off-site copy, not the host's, since that is the one you would need in a real disaster.
2. Restore it to a staging site or a temporary server, never over the live site.
3. Check the home page, key pages, images, contact forms, logins and, for stores, recent orders and the checkout in test mode.
4. Time the whole process, from "the site is down" to "the site works". This is your real recovery time.
5. Fix anything missing (a database not included, an expired storage key, a missing licence file) and update the plan.

That measured time is your recovery time objective (RTO) in practice. NIST describes the RTO as how long a system can be in recovery before it harms the business. If your test took six hours and your business can only bear two, the plan needs to change.

#A recovery plan table: what, who and how long

Write the plan down on one page and keep a copy outside the website and hosting account, for example in a shared drive and on paper. Fill in the names and times for your business.

Also list where to find logins: the registrar, DNS, hosting, the off-site storage and the payment gateway. Keep them in a business password manager, not in the website itself. Our website maintenance checklist has the monthly checks that keep this list up to date, and our guide to website monitoring tools covers the alerts that tell you something has gone wrong in the first place.

#When to get help

You can run a simple setup alone: a trusted backup plugin sending daily copies to your own cloud storage, plus a restore test on a staging site. Get help when:

• The site is a store, booking or membership site where lost orders cost money.
• You have never restored a backup, or the last attempt failed.
• The site is on a VPS or custom stack with no backup tool in a control panel.
• The site was hacked and you need a clean restore point.

Our website backup and disaster recovery service sets up automatic off-site backups, retention and a tested restore with the times written down. If you would rather hand the whole job over, a maintenance and support plan includes backups and updates. For a site that is down right now, use emergency WordPress fixes, and read our guide to 500, 502 and 504 errors for safe first steps.