Backups and disaster recovery for a small business

A small business should keep three copies of its important data, on two kinds of storage, with one copy offsite and out of reach of an attacker, and should test restoring from them on a schedule. Add two numbers, how much data you can lose and how long you can be down, and you have the core of a disaster recovery plan.

What can actually go wrong?

Most data loss is ordinary: a deleted folder, a failed disk, a developer running a command on the wrong database, a laptop stolen from a car. Others are larger: ransomware that encrypts files and the backups next to them, a cloud account taken over by someone with a stolen password, a hosting provider that closes down, or a data centre that goes offline.

A plan should cover the common failures first and the rare ones second.

What is the 3-2-1 rule?

The rule says: three copies of your data, on two different media, with one copy offsite. The live data is copy one. A local backup is copy two. An offsite backup, such as cloud storage in another account or region, is copy three.

Two additions are worth making:

• An immutable or offline copy: ransomware often goes looking for backups. Storage with object lock, write-once settings or a physically disconnected disk cannot be encrypted or deleted by an attacker who has taken over your admin account.
• A separate login for backups: if the same password that runs your servers also runs your backups, one theft takes both.

What should be backed up?

Make a list. People tend to remember the database and forget the rest.

• Databases and uploaded files.
• Source code and configuration, including infrastructure settings.
• Email, documents and shared drives (the contents of Google Workspace or Microsoft 365).
• DNS records and domain settings. A list of records saved today can save hours later.
• Secrets and credentials, stored safely in a password manager or vault, with a recovery path.
• Accounting and HR records.
• The laptops of people who keep unique work on their devices.

For each item write down where it lives, how often it is copied and who is responsible.

What are RPO and RTO?

Two figures shape the plan.

Recovery Point Objective (RPO) is how much recent data you can afford to lose. If it is one day, a nightly backup is fine. If it is five minutes, you need continuous replication.

Recovery Time Objective (RTO) is how long you can afford to be down. If it is a day, rebuilding from backup is acceptable. If it is an hour, you need a ready standby.

Ask the people who run the business, not the engineers, what loss they can bear. A booking site that takes payments will answer very differently from a brochure site. Shorter targets cost more, so set them per system and not for everything.

Is Google Workspace or Microsoft 365 already a backup?

Not in the sense that matters. Both keep your data available and give limited recovery for deleted items, usually for a fixed period. They are not independent copies. If an employee deletes a shared drive, an attacker removes data from an admin account, or a sync tool corrupts files, the change spreads to every device. Many businesses add a third-party backup for mail and drive data. That decision depends on how much those files matter.

How do you test a restore?

This step is the one that gets skipped. A backup you have not restored is a hope, not a safeguard.

1. Pick a system and a backup from a few days ago.
2. Restore it into a separate, empty environment.
3. Check that the data opens, the application starts and recent records are there.
4. Time the process, and compare the time with your RTO.
5. Write down every step and every surprise.
6. Fix what broke and repeat in a few months.

Use the results to build a runbook that someone other than the original engineer can follow. During an outage the person who knows the system may be asleep, travelling or gone from the company.

What belongs in a short disaster recovery plan?

One to two pages is enough for a small business. Include:

• A list of critical systems with owners, RPO and RTO.
• Where backups are kept and who can access them.
• Step-by-step restore instructions for each critical system.
• Contact details for the hosting provider, domain registrar, payment gateway and key vendors.
• Who decides to declare an incident, who talks to customers and who handles the technical recovery.
• Where the plan itself is stored, in a place you can reach if your main systems are down.

How do backups connect to security and compliance?

Backups hold personal data too, so they fall under your security duties. The Digital Personal Data Protection Act, 2023 requires reasonable security safeguards (section 8(5)) and the DPDP Rules, 2025 (rule 6) list measures that include backups and the ability to continue processing after a failure. Encrypt backups and restrict who can read them. When a person asks for erasure, your process should explain how it handles older backups (see data access and erasure requests). This is not legal advice; partner counsel advises on interpretation.

If a ransomware incident hits, CERT-In's Directions of 28 April 2022 also require reporting within six hours. A tested backup shortens the recovery, and the reporting rule shapes the response.

What are the trade-offs?

More copies, shorter targets and longer retention all increase cost. Offsite and immutable storage add steps to recovery. Frequent backups of busy databases can slow the live system if not scheduled well.

Start with the data that would hurt most to lose, set a realistic target, and widen the plan as the business grows. A simple plan that is tested beats an elaborate one that is not.

Where does TechSum fit?

We design the backup schedule, set up immutable copies, write the restore runbook and run the test with your team. We also set up uptime monitoring so you hear about a problem before your customers do. See Digital Infrastructure for how we work, and use the free health check or a Digital Health Check to see where your basics stand.