Guide
Business backups: what “backed up” actually means
A business backup is a copy of your data that you have proven you can restore. Until a restore has actually been performed, what you have is a backup job that reports success, which is a different thing, and the difference only becomes apparent on the worst day of your year. This guide covers what to back up, the 3-2-1 rule, why Microsoft 365 is not covered by default, and how to test a restore without disrupting anything.
By James 11 min read
The definition that matters
A backup is not a copy. A backup is a copy you have restored from. Everything else is a hypothesis.
This sounds pedantic until you have watched a business discover, mid-incident, that the job has been reporting success for fourteen months while backing up an empty folder, or that the retention was set to seven days and the corruption started three weeks ago, or that the restore requires a licence key nobody can find.
All three of those are real failure modes and all three are invisible from a dashboard. The only thing that surfaces them is performing a restore while nothing is wrong.
The 3-2-1 rule, and why it still holds
Three copies of your data, on two different types of storage, with one copy held offsite. It is decades old and it has survived because each part addresses a different failure.
Three copies covers accidental deletion and corruption. You need a version from before the mistake. Two types of storage covers the failure of one technology, which used to mean a bad batch of tapes and now more often means a storage device that fails silently. One offsite copy covers everything that takes out the building: fire, flood, theft, and increasingly ransomware, which is specifically designed to reach every backup it can see from an infected network.
Ransomware is why the offsite copy has become the important one rather than the belt-and-braces one. An attacker who gains administrative access will look for backups and encrypt or delete them first, because that is what makes you pay. A copy that is immutable, or held somewhere the compromised network cannot authenticate to, is the copy that saves the business.
Free, before any money changes hands
Want this looked at properly, for nothing?
Ninety minutes mapping how the work actually flows, then a written plan and a fixed quote you keep either way. A working session, not a sales meeting.
- No obligation, no follow-up sequence
- You keep the plan and the quote
or call 01623 354250
Microsoft 365 is not backed up by default
This is the single most common and most consequential misunderstanding in small business IT, so it is worth stating plainly: Microsoft replicates your data for their own resilience, and that is not a backup for you.
What Microsoft provides is limited retention: a deleted items folder, a recycle bin, version history in SharePoint and OneDrive, and a retention window for deleted mailboxes that is measured in days rather than years. All of it is designed for recovering from an accident noticed quickly. None of it is designed for recovering from a deletion noticed four months later, a departing employee who cleared their mailbox, or ransomware that encrypted files which then synchronised.
Microsoft is explicit about this in its own shared responsibility documentation: they are responsible for the infrastructure, you are responsible for your data. Third-party Microsoft 365 backup costs a few pounds per user per month and is, per pound, probably the best-value protection a small business can buy.
The same tested-restore principle drives our business backup and disaster recovery.
What should be backed up
A surprising amount of what a business depends on is not in the obvious places.
- File servers and shared drives, including the permissions structure, not just the files
- Microsoft 365: mailboxes, OneDrive, SharePoint and Teams data, which needs a separate product
- Line-of-business application databases, which frequently need an application-aware backup rather than a file copy
- Server system state and configuration, so a rebuild is a restore rather than a reconstruction
- Endpoint machines, at least for the users who keep anything locally, which is more of them than they will admit
- Website and application data if you run anything beyond a brochure site
- Configuration for network equipment, so a failed firewall is an afternoon rather than a redesign
- The documentation itself, held somewhere that does not depend on the systems it documents
RPO and RTO, without the jargon
Two questions decide what your backup arrangement needs to be, and both are business questions rather than technical ones.
How much data can you afford to lose? If your backup runs nightly at 10pm and the server fails at 4pm, you have lost a day of work. For a lot of businesses that is survivable. For one taking orders continuously it is not, and the answer is more frequent snapshots. That tolerance is your recovery point objective.
How long can you afford to be down? Restoring two terabytes from cloud storage over a business broadband connection takes considerably longer than most people assume, potentially a day or more. If you need to be running in four hours, you need a local copy to restore from, or the ability to run temporarily from the backup itself. That tolerance is your recovery time objective.
Almost every disappointing recovery comes from never having answered these two questions, and therefore having bought an arrangement that was never designed to meet them.
We test restores rather than assuming them
Backups on our plans run to both local and cloud storage, and restores are tested on a schedule. If you are not sure whether yours would work, a test restore is part of the free review, and it is the single most useful hour we can spend with a new client.
How to test a restore without breaking anything
A restore test does not mean restoring over your live systems. It means restoring somewhere else and checking the result, which carries no risk to production at all.
At the simplest level: pick a file from two months ago, restore it to a temporary location, and open it. That takes ten minutes and catches retention problems and empty-backup problems immediately. Do that monthly.
At the level that actually matters: restore a full server or a full mailbox to an isolated environment, start it, and confirm the application works and the data is current to the expected point. That takes a few hours and should happen quarterly. It is the only test that catches the failures involving licence keys, dependencies and application-consistency.
Write down the date and the result each time. When an insurer, an auditor or a client asks whether your backups are tested, a dated log is the answer and a verbal assurance is not.
Retention: longer than you think
Thirty days is the common default and it is frequently too short. The problem is not the dramatic failure, which you notice immediately. It is the quiet one: a corrupted database, a folder deleted in March and needed in July, a departing employee who tidied up on their last day.
Sector requirements push this further. Clinical records, financial records and employment records all carry retention periods measured in years, and a backup arrangement designed around thirty days does not satisfy them regardless of what the policy document says.
The practical answer is tiered: frequent snapshots kept for weeks, daily copies kept for months, and monthly copies kept for as long as your obligations require. Storage is cheap enough now that the main cost of this is thinking about it once.
The failures that make a restore fail
Backups rarely fail by not existing. They fail at restore time, for a small set of recurring reasons worth knowing in advance.
The backup captured the files but not the application. A database copied while it was running is frequently not restorable, because the copy caught it mid-write. Application-aware backups solve this and file-copy backups do not, which is why a nightly copy of a folder is not a backup of the system inside it.
The restore needs something you no longer have. A licence key, an installer, a vendor account, a version of software that has since been withdrawn. Documenting these alongside the backup costs an hour and saves a day.
The restore is slower than the business can absorb. Two terabytes over a business broadband connection is not a four-hour job, and discovering that during an incident is the wrong time.
Nobody knows how. The process lives in one person’s head, and that person is on holiday. Writing the restore procedure down, and having somebody else follow it once, is the cheapest resilience improvement available to most businesses.
What to do in the first hour of a data loss
Stop writing to the affected system. Every additional write reduces what is recoverable, and in a ransomware case it can also spread the damage. Disconnect the machine from the network rather than shutting it down, unless you are advised otherwise. Memory can hold useful evidence.
Do not restore over the top of the live system. Restore to a separate location first, verify what you have, then decide. Restoring in a panic over corrupted data is how a recoverable incident becomes an unrecoverable one.
Work out the point in time you need. If the corruption began three weeks ago, last night’s backup contains it too. This is where retention earns its keep, and where thirty-day defaults quietly fail.
And if personal data may have been lost or exposed, note the time you became aware. UK GDPR gives you 72 hours to notify the Information Commissioner’s Office where the breach is likely to result in a risk to individuals, and the clock starts at awareness rather than at resolution.
Frequently asked questions
If the answer is not here, ask us. You will get a straight one, from someone who does the work.
Mon–Fri, 9am–5:30pm
What does the 3-2-1 backup rule mean?
Three copies of your data, on two different types of storage, with one copy held offsite. Each part addresses a different failure: three copies covers deletion and corruption, two storage types covers a technology failing, and the offsite copy covers fire, flood, theft and ransomware.
Is Microsoft 365 backed up automatically?
No. Microsoft replicates data for their own infrastructure resilience, which is not a backup for you. What you get is short retention: recycle bins, version history and a deleted mailbox window measured in days. Recovering from a deletion noticed months later, or from ransomware that synchronised, needs a separate third-party backup.
How often should business backups be tested?
A file-level spot check monthly, and a full restore of a server or mailbox to an isolated environment quarterly. The quarterly test is the one that catches licence, dependency and application-consistency failures, and it carries no risk to production because nothing is restored over live systems.
How long should backups be retained?
Longer than the common thirty-day default. Use tiered retention: frequent snapshots for weeks, daily copies for months, monthly copies for as long as your sector obligations require. Clinical, financial and employment records all carry retention periods measured in years.
What is the difference between RPO and RTO?
Recovery point objective is how much data you can afford to lose, if backups run nightly and the failure is at 4pm, you lose a day. Recovery time objective is how long you can afford to be down. Both are business decisions, and most disappointing recoveries come from never having answered either.
Will ransomware encrypt our backups too?
It will try, and that is exactly what makes businesses pay. An attacker with administrative access looks for backups first. The protection is a copy that is immutable, or held somewhere the compromised network cannot authenticate to, which is why the offsite copy has become the important one rather than the spare.
Do we need to back up staff laptops?
At least for users who keep anything locally, which is more of them than will admit it. Even with everything nominally in the cloud, downloads folders and desktops accumulate work that exists nowhere else.
What should we do in the first hour of a data loss?
Stop writing to the affected system, and disconnect it from the network rather than shutting it down. Restore to a separate location and verify before touching the live system. Work out the point in time you actually need, because if corruption began three weeks ago then last night’s backup contains it too.
Why do backups fail when you actually need them?
Rarely because they do not exist. Usually because the copy caught a database mid-write and is not restorable, because the restore needs a licence key or installer nobody kept, because it is slower than the business can absorb, or because the only person who knows the process is on holiday.