Most business owners we meet can tell us that they have a backup. Far fewer can tell us when they last restored something from it, how long it took, and whether every file came back. That gap is where small businesses get hurt. A backup that has never been tested is a hope, not a plan.
This article explains why backups fail, how the 3-2-1 rule works, how to run and record a simple test restore, what to ask your IT provider, and why the data in Microsoft 365 needs its own protection.
Why backups fail when you need them
Backups rarely fail in a dramatic way. They fail quietly, months before anyone notices. The most common causes we see are:
- The job stopped running. A password changed, a drive filled up or a computer was replaced, and the backup has been failing for weeks with nobody reading the alerts.
- The wrong things are backed up. The server is covered, but the accounting file lives on one person's desktop, or a new shared folder was never added to the backup.
- The backup was reachable by the attacker. Ransomware does not only encrypt your files. It often looks for connected backup drives and network shares and encrypts or deletes those too.
- Nobody knows how to restore. The person who set it up has left, the recovery password is missing, or the restore takes days instead of hours.
- The copy is too old. The backup works, but it only keeps a week of history, and the problem started three weeks ago.
Every one of these is found by a test restore. None of them is found by a green tick on a dashboard.
The 3-2-1 rule in plain English
The Canadian Centre for Cyber Security describes the 3-2-1 rule this way: keep three copies of your information (the original plus two backups), store the backups on two different types of media, and keep one copy off site. It also recommends keeping at least one backup disconnected from your network, because an offline copy cannot be reached by ransomware spreading across connected devices.
For a typical small office, this might mean your working files in Microsoft 365 or on a server, a backup to a local device in the office, and a second backup to a separate cloud service that keeps copies which cannot be changed or deleted for a set period. The exact tools matter less than the principle: no single event, whether a fire, a stolen laptop, a ransomware attack or a mistaken deletion, should be able to destroy every copy.
How to run a test restore
The Canadian Centre for Cyber Security recommends routinely testing that you can recover from your backups, and defining who does what during recovery. A test restore does not have to be complicated. It needs to be real, regular and written down.
Step 1
Pick what to restore
Choose something that matters: a folder of client files, a mailbox, the accounting database or, once a year, a whole computer or server. Rotate through different systems so that, over a year, everything important has been tested at least once.
Step 2
Restore to a safe place
Restore to a separate folder or test machine, not over the live data. You are checking that the backup works, not replacing anything.
Step 3
Check it opens and is complete
Open several files. Confirm the dates are recent and the file count matches. For a database or accounting file, confirm the application can open it and the latest entries are there.
Step 4
Time it
Note how long the restore took. If restoring your main system takes two days, you now know your business could be down for two days, and you can decide whether that is acceptable.
Step 5
Record the result
Write it down in a simple log, and fix anything that failed before the next test.
What to record each time
Test restore log: one line per test
- Date and time of the test, and who ran it
- What was restored, and from which backup copy and date
- How long the restore took
- Result: complete, partial or failed, and what was checked
- Problems found and the date each one was fixed
This log is also useful evidence. Cyber insurers often ask about backups and recovery when you apply or renew, and a record of real tests is a far stronger answer than "yes, we have backups." Our article on cyber insurance requirements in Canada covers what underwriters typically ask.
Microsoft 365 data needs its own backup
Many businesses assume that because their email and files live in Microsoft 365, Microsoft is backing them up. Microsoft does build a lot of resilience into its service, keeping copies of data in separate locations so that hardware failures in its data centres do not lose your mail. But that protects against Microsoft's problems, not yours.
Microsoft's own documentation on data resiliency says that most data loss results from customer actions, and its Services Agreement states: "We recommend that you regularly backup Your Content and Data." The built-in recovery tools are time limited. For example, Microsoft documents that deleted SharePoint sites are kept for 93 days, and that when a user's licence is removed or the account is deleted, the mailbox content is kept for 30 days before it is permanently deleted.
That leaves real gaps:
- An employee deletes a folder and nobody notices for four months.
- A departing staff member's account is removed and, six weeks later, someone needs an email from their mailbox.
- An attacker who takes over an account deletes or encrypts files in OneDrive and SharePoint.
A separate backup of Microsoft 365, kept outside your Microsoft 365 account, closes those gaps. It should include Exchange mailboxes, OneDrive, SharePoint and Teams files, and it should be tested the same way as everything else. Our Microsoft 365 page explains how we manage it for clients.
Questions to ask your IT provider
You do not need to understand the technology to hold your provider to account. These questions get to the point quickly:
- What exactly is being backed up, and what is not? Can I see the list?
- Where are the copies kept, and is at least one of them offline or protected so it cannot be changed or deleted by an attacker?
- How far back can we restore? Days, weeks, months?
- Is Microsoft 365 backed up separately, including mailboxes, OneDrive, SharePoint and Teams?
- When was the last test restore, what was restored, and can I see the record?
- If our main system was lost today, how long would it take to get running again?
- Who is alerted when a backup fails, and how quickly is it fixed?
- Are the backups encrypted, and who holds the recovery keys?
A good provider will welcome these questions and answer them in writing. If the answers are vague, treat that as a finding in itself.
Privacy and backups
Backups usually contain personal information about customers and staff, so they need the same protection as the original data. The BC Personal Information Protection Act (PIPA) requires organizations to protect personal information in their custody or under their control with reasonable security arrangements, and federal PIPEDA has a similar safeguarding principle. In practice, that means encrypting backups, limiting who can access them, and knowing where they are stored.
Start with one test this month
If you have never tested a restore, do not wait for the perfect plan. Pick one important folder, restore it to a safe place this week, and write down what happened. That single test will tell you more about your real recovery ability than any report. For a broader view of planning for outages and ransomware, see our backup and disaster recovery page and our article on the first 60 minutes of a ransomware attack.
Not Sure Your Backups Would Work?
Hexafusion helps Vancouver and Lower Mainland businesses review what is backed up, run test restores and keep a clear record of the results. Call us at 604-332-1500 or send us a message to talk it through.
Contact Hexafusion 604-332-1500Related articles: Ransomware Note on Your Screen: The First 60 Minutes · Lost Microsoft 365 Admin Access · Cyber Insurance Requirements in Canada
