Backup and Disaster Recovery Plan for Small Businesses

By Grocito12 October 2026

A backup and disaster recovery plan for a small business has two parts: regular, automated copies of everything you cannot afford to lose, and a written, tested procedure for getting back to work after something breaks. Backups protect your data; disaster recovery protects your operations. A backup you have never restored is only a hope.

Key takeaways

Backup is about copies of data; disaster recovery is about getting systems and people working again. You need both.
List what you depend on (website, database, email, files, SaaS tools) before deciding how to protect it.
Follow the 3-2-1 idea: several copies, on different types of storage, with at least one kept offsite and protected from changes.
Decide how much data loss (RPO) and downtime (RTO) your business can tolerate, then buy protection that matches.
Test restores on a schedule and keep a one-page runbook that anyone on the team can follow.

Backup versus disaster recovery

What a backup is

A backup is a separate copy of data taken at a point in time. It lets you recover a deleted file, an overwritten record or a database that was corrupted by a bad update.

What disaster recovery is

Disaster recovery is the plan for restoring service when something bigger goes wrong: a server failure, a hosting outage, ransomware, a deleted cloud account or an office that is inaccessible. It covers who does what, in which order, using which backups, and how customers are told.

Many small businesses have the first and not the second. They have copies somewhere, but nobody knows how long a restore would take or who would run it.

What to protect

Start with an honest inventory. For each item, write down where it lives, who owns it and how it is currently backed up.

Website: code, theme or application files, media uploads and configuration.
Databases: orders, customers, bookings, content. This is usually the most valuable item.
Email and calendars: often hosted by a provider, but not automatically backed up in a way you control.
Files and documents: shared drives, contracts, designs, accounting exports.
SaaS data: CRM, helpdesk, project tools and accounting software. Vendors keep their systems running, but that is not the same as keeping your data recoverable if you delete it by mistake.
Secrets and access: domain registrar login, DNS records, hosting credentials, API keys and licence details. Losing these can block recovery even when the data is safe.

The 3-2-1 backup idea

A well-known rule of thumb is 3-2-1:

3 copies of your data: the live version and two backups.
2 different types of storage, so one failure mode does not take out both.
1 copy offsite, in a different location or provider from the original.

Modern variations add an immutable or offline copy, meaning a backup that cannot be changed or deleted for a set period, even by an administrator account. That extra layer matters because attackers and mistakes both tend to target whatever the main account can reach.

RPO and RTO in plain English

Two terms decide how much protection you need.

RPO (recovery point objective): how much recent data you can afford to lose. If your answer is "a day of orders is fine", back up daily. If it is "almost none", you need more frequent copies or replication.
RTO (recovery time objective): how long you can be offline before the damage becomes serious. A brochure website can usually wait longer than an online shop in the middle of a sale.

Set these per system, not for the whole business. Your booking system and your marketing blog do not deserve the same budget. Faster recovery and less data loss cost more, so the point is to spend where an outage would hurt most.

Automate, separate and protect

Automate

Manual backups depend on someone remembering. Schedule them, and make sure a failed job sends an alert to a person, not to an unread mailbox.

Keep copies away from the original

A backup stored on the same server, or reachable with the same admin login, can be lost in the same incident. Use a separate account or provider for at least one copy, with its own credentials and multi-factor authentication.

Encrypt and control access

Backups hold the same sensitive data as production. Encrypt them, restrict who can read or delete them, and keep a record of changes.

Test your restores

This is the step most plans skip. A backup job that reports success may still produce an empty file, a corrupted archive or data nobody can read.

Run a restore test on a schedule and after major changes:

Restore a recent backup into a separate test environment, not over production.
Check that the site loads, that records are present and that key functions work.
Time the process and compare it with your RTO.
Write down anything that was unclear or missing, and fix the runbook.

Ransomware resilience

Ransomware locks or deletes your files and demands payment. A sound backup design is your best defence because it lets you recover without negotiating. Keep at least one immutable or offline copy, limit who can delete backups, patch software promptly, use multi-factor authentication and give staff basic training on suspicious links. Our website security checklist for business owners covers the preventive side. Backups are for when prevention fails.

Roles and a one-page runbook

During an incident people panic, so write the plan when things are calm. A single page is enough if it includes:

Who decides: the incident lead and a backup person.
Who does what: who restores systems, who talks to customers, who contacts the hosting provider.
Where things are: backup locations, credentials vault, supplier support contacts.
Restore order: which systems come first (usually database and website, then email and internal tools).
Communication: a short message template for customers and staff.
Contacts: hosting, domain, payment provider and your technical partner.

Store a copy somewhere that does not depend on the systems that might be down.

Cloud and SaaS: shared responsibility

Cloud providers and SaaS vendors generally secure and operate their platform, while you remain responsible for your data, your accounts and your configuration. Read what your provider does and does not back up, how long deleted data is retained and how you can export it. If a critical tool offers no practical export, take that as a risk to manage. If you want help designing backups on a cloud setup, see our cloud services and DevOps services.

A hypothetical example

Imagine a small online shop run by six people. Its site, database and product images sit on one hosting account, and the only backup is a nightly copy stored in the same account. The owner decides orders are the critical data and that a few hours of downtime is tolerable, but losing a day of orders is not. The team moves to frequent database backups, sends a daily copy to a separate provider with its own login, keeps one copy that cannot be deleted for a set period and schedules a restore test each quarter. During the first test they discover the media folder was never included, and they fix it before it matters.

Review schedule

Monthly: check backup job reports and alerts.
Quarterly: run a restore test and review who has access.
Yearly or after big changes: revisit RPO and RTO, update the runbook and confirm contact details.

Common mistakes

Keeping backups on the same system or account as production.
Never testing a restore.
Forgetting email, SaaS data or DNS and domain access.
Having no named owner for the plan.
Assuming the hosting provider backs up everything you care about.

FAQ

How often should a small business back up its data?

It depends on how much recent data you can afford to lose. Data that changes constantly, such as orders and bookings, needs frequent backups, while static content can be backed up less often. Choose a schedule per system based on your RPO.

Is cloud storage the same as a backup?

Not necessarily. Syncing a folder to the cloud mirrors changes, including accidental deletions and encrypted files. A true backup keeps earlier versions that you can restore from.

What is the 3-2-1 backup rule?

It means keeping three copies of your data, on two different types of storage, with one copy offsite. Many teams add an immutable or offline copy as a protection against ransomware and accidental deletion.

Do I need a disaster recovery plan if I use SaaS tools?

Yes, though it looks different. You still need to know how to export your data, who holds the admin accounts and what you would do if a vendor were unavailable for some time.

Next steps

This week, list your critical systems, name an owner for each and run one restore test on the most important one. If you would like help designing backups, hosting or a recovery runbook, contact us and we can talk through what fits your setup.