Business Backups: A Protection Plan and Recovery Testing

A backup protects your business only under three conditions: you know exactly which data is critical, the copies are independent of each other, and recovery is tested regularly. If even one of these conditions isn't met, "our backups are configured" is not protection — it's hope. Below is a plan for putting things in order, plus the questions a business owner should ask their IT team today.

Step 1. Decide what to protect

Backing up "everything" is expensive and, worse, unreliable: the important data gets lost in the pile. Start with an inventory — a list of data whose loss stops or cripples the business:

• the database of your accounting system (1C or similar);
• the CRM database and client history;
• accounting documents, contracts, HR files;
• shared folders with working documents;
• email, if it is stored locally;
• server and network equipment configurations — these are forgotten most often, and rebuilding "from scratch" without them takes days.

For each item, answer two questions: how many hours of downtime are tolerable during recovery, and how much lost data is acceptable — a day of work, an hour, none at all? These two answers determine how often to make copies and how much to pay for storage infrastructure. The answers for your accounting database and your scan archive will differ — and that's fine.

Step 2. Several independent copies

The main principle: copies must not share fate with the original or with each other. The classic guideline is the "3-2-1" rule: three copies of the data, on two different types of media, with one kept off-site. Keep in mind: it's a design guideline, not a magic guarantee — the exact scheme depends on your data and risks.

What "independence" means in practice:

• A copy on the same server as the original is not independent. If the disk or the server fails, it dies together with the original.
• A copy on a drive permanently connected to the server is vulnerable to ransomware. Malware that gains sufficient privileges on the server can encrypt the connected drives it can reach — including such a copy. At least one copy must be unreachable from the main network: a cloud with a separate account, a detachable drive, or storage with versioning or immutable copies — if the chosen service supports it and your tech team confirms it.
• Off-site means protection against fire, flood, and theft. For most companies the cloud plays this role; a server in another branch office works too.
• Versions, not a mirror. Cloud sync is not a backup: a corrupted file syncs over the healthy one. You need version history covering at least a few weeks — data corruption is not always noticed the same day.

Step 3. Storage and access

A backup is a concentrate of all your company's valuable data, and it needs protection no weaker than the original.

• Access to backup storage — only for those who need it for their work. "The whole office knows the cloud password" is a common problem.
• The backup account must be separate — not an employee's personal email and not a shared admin account. When someone leaves, the backups must not leave with them.
• Copies containing personal and financial data should be encrypted, with the keys stored separately from the copies themselves.
• Check what happens when an IT specialist quits or you switch providers: does the company keep the credentials and the documentation for the backup scheme? This is part of general access hygiene — more about it in our IT security for business service description.

Step 4. The recovery test — the step everyone skips

The only proof that a backup works is successfully restored data. Not a "job completed" report, not a green checkmark in the software — an opened database and working files.

What good practice looks like:

• Restore selectively on a regular basis: one database, one folder — to a test location, not over production data. Frequency depends on criticality; for most offices, at least once a quarter is a reasonable baseline.
• Once a year, run a bigger drill: restore a critical system end to end and time it. That's when it turns out that "we'll be back up in a couple of hours" actually means a full day.
• Record the result: the date, what was restored, how long it took, what went wrong. Four lines in a log that turn faith into knowledge.

If your provider or sysadmin has never shown you the result of a test recovery — that's the first question to ask after reading this article.

Step 5. Ownership and schedule

A backup is not a one-time setup but a process. To keep it from dying in six months:

• There is a named owner — a specific person or provider, by name. "The IT guys handle backups" means nobody does.
• There is a schedule: what gets copied, how often, how many versions are kept, when recovery tests happen.
• Failures are visible immediately: a failed-backup notification goes to a person, not into a log nobody reads. A backup that has been silent for three weeks should be an emergency, not a surprise during a disaster.
• The scheme is documented — so that the data can be restored by someone other than the person who set it up.

For the server side this is usually covered by ongoing maintenance with monitoring — how we do it is described on our server maintenance page.

Frequently asked questions

Everything we have is in the cloud — Google Drive, cloud accounting. Do we still need backups?

Yes. The cloud protects you from your own hardware failing, but it doesn't remove the need to check things with your specific provider: is there version history and for how long, how long are copies kept, who has access to the account, and how recovery actually works. Accidental deletion and ransomware syncing corrupted files remain your risks. For a cloud-hosted accounting system, ask: how often copies are made, how long they are kept, and how quickly you would get them. "It's the cloud, it's safe there" is not an answer.

How much does it cost?

It depends on the data volume and acceptable downtime, so there is no honest universal number. The right way to budget is to compare it not against an abstract "backup price per month" but against your own numbers from step 1: the cost of an hour of downtime and the price of the lost data. Every company does that math on its own figures.

How often should copies be made?

Step 1 gives the answer: how much lost work is acceptable for the specific data. If losing more than a couple of hours of entries is unacceptable for your working database, copy frequency must match those two hours. If losing a week of a document archive is not critical, weekly copies are enough. There is no universal "once a night" for all data: frequency follows from the acceptable loss, not the other way around.

Where do we start tomorrow?

Ask your IT team three questions: what exactly is backed up, where is the copy that ransomware cannot reach, and when recovery was last tested. If there is no confident answer to at least one of them — start there.

← Back to all articles