Cloud Backup and Disaster Recovery for Small Business in Canada

Short answer: a backup is only a copy. What protects your business is a disaster recovery plan: you know which systems matter most, how much data you can afford to lose (RPO), how quickly each system must be back (RTO), and you have proven, by actually restoring, that you can meet those targets. Follow the 3-2-1 rule, keep at least one copy that ransomware cannot touch, back up your SaaS data too, and test on a schedule.

Backup, disaster recovery and business continuity: what is the difference?

These three terms get used as if they meant the same thing. They do not, and mixing them up is how businesses end up with backups but no way to recover.

Backup is a copy of your data, stored somewhere other than the original. It answers the question “do we still have the information?”
Disaster recovery (DR) is the plan, people and tools that get your systems working again after something goes wrong: a failed server, a ransomware attack, a deleted mailbox, a flood in the office. It answers “how do we get back to work, and how fast?”
Business continuity is wider still. It covers how the business keeps operating while systems are down: taking orders by phone, paying staff, telling customers what is happening. It answers “how do we keep serving people in the meantime?”

A small business does not need a thick binder for each. It needs all three to exist, even in a simple form, and to connect to each other.

The 3-2-1 backup rule, and why it still works

The 3-2-1 rule is a long-standing guideline that is easy to remember and hard to beat:

3 copies of your data: the original plus two backups.
2 different types of storage, so one failure does not take everything. For example, a cloud backup service and a separate storage account, or a local device and the cloud.
1 copy offsite, away from your office and your main systems, so a fire, theft or flood does not destroy every copy at once.

Many businesses now extend this to 3-2-1-1-0: one copy that is offline or immutable (it cannot be changed or deleted, even by an administrator, for a set period), and zero errors when you test a restore. The extra “1” is what makes the difference against ransomware.

A worked example

Imagine a 12-person accounting firm in Mississauga that keeps client files on SharePoint and email in Microsoft 365, and runs its practice software on a cloud server.

Copy 1: the live data in Microsoft 365 and on the cloud server.
Copy 2: a daily backup of Microsoft 365 and nightly snapshots of the server, stored with a separate backup service in a Canadian region.
Copy 3: a weekly immutable copy in a different storage account, locked for a set retention period, with separate administrator credentials that nobody uses day to day.

If a partner deletes a folder, copy 2 brings it back in minutes. If ransomware encrypts the server and the attacker tries to delete the backups, copy 3 is still there.

RPO and RTO in plain language

Two numbers turn “we should have backups” into a real plan.

Recovery point objective (RPO) is how much data you can afford to lose, measured in time. If you back up once a night and your system fails at 4 p.m., you lose everything since last night. Your RPO is roughly 24 hours. If that would mean re-entering a full day of orders, you need more frequent backups.

Recovery time objective (RTO) is how long a system can be down before the harm becomes serious. For an online store in peak season, that might be a couple of hours. For an archive of old project files, a week could be fine.

Setting them for each system

You do not need the same targets for everything. Tighter targets cost more, so match them to what each system is worth to the business.

System	Example RPO	Example RTO	Why
Online store and orders	15 minutes to 1 hour	A few hours	Every hour down is lost sales and unhappy customers
Email and calendars	A few hours	Same business day	The team can use phones briefly, but not for days
Accounting and payroll	End of the previous day	1 to 2 days, faster near payroll dates	Transactions can be re-entered, deadlines cannot move
Shared files and documents	End of the previous day	1 business day	Most work can continue from recent files
Old archives	1 week	1 to 2 weeks	Rarely used and rarely changes

These are illustrations, not rules. The right numbers come from asking managers one question per system: “if this stopped right now, when would it start to really hurt?”

What to back up (it is more than the server)

When businesses list their data, they often stop at the office server or the main database. A complete list usually includes:

Business applications and databases: accounting, ERP, CRM, practice management, inventory.
Cloud servers and virtual machines, including their configuration, not only the data.
Microsoft 365 or Google Workspace: email, OneDrive or Drive, SharePoint or shared drives, Teams chats and files.
Your website: files, database, media and plugins or themes, with the domain and DNS settings written down.
Laptops that hold files that never reach shared storage.
Configuration and credentials: firewall settings, admin accounts, licence keys and recovery codes, stored securely in a password manager.
Other SaaS tools that hold business data you would struggle to recreate, such as forms, e-commerce platforms or project management tools.

SaaS is not automatically “backed up” the way people assume

A common belief is that Microsoft 365 or Google Workspace data is safe because it lives in the cloud. These services are designed to stay available and protect against hardware failure on their side. That is different from keeping an independent copy you control, which is what you need when a user deletes something, an account is compromised, a sync goes wrong or data is lost when a licence is removed.

Microsoft is direct about this. Its services agreement recommends that customers regularly back up the content and data they store on its services. Built-in features like recycle bins and version history help with small mistakes, but they have time limits and are not designed as a full, separate backup. Check the current terms and retention settings for each SaaS product you depend on, and decide whether a dedicated backup is needed.

Protecting backups from ransomware

Modern ransomware groups know that backups are what let victims recover without paying. They often look for backups and try to encrypt or delete them before launching the main attack. Your plan has to assume that an attacker may get administrator access to your main systems.

Keep one copy offline or immutable. The Canadian Centre for Cyber Security advises that backups be encrypted and stored offline, without connection to the internet or local networks. In the cloud, immutable storage with a retention lock gives a similar protection.
Use separate credentials. The account that manages backups should not be the same as your everyday admin account, and it must use multi-factor authentication.
Separate the backup location. A different cloud account, subscription or provider, so one compromised login does not reach everything.
Keep enough history. Ransomware can sit quietly before it strikes. Keeping several weeks of restore points means you can go back to a point before the infection.
Watch for warning signs. Alerts for failed backup jobs, sudden deletion of backups or unusual changes to retention settings.

For the wider picture of how these attacks start and how to stop them, see our guide to protecting your business from ransomware and phishing.

Testing restores: the step most businesses skip

A backup that has never been restored is an assumption. Testing is where you find out that the backup job silently stopped months ago, that nobody has the password, or that restoring the database takes a day instead of an hour.

A realistic testing routine:

Monthly: restore a few random files and one mailbox item. Confirm they open.
Quarterly: restore a full system or database to a separate test environment and check that it works, not just that it copied.
Yearly: run a tabletop exercise. Walk through a scenario, such as “ransomware on a Monday morning”, with the people who would actually respond, and time how long each step takes.
After every major change: a new application, a migration or a new backup tool means a new test.

Write down the result of each test: what you restored, how long it took and what went wrong. That record shows whether you can meet your RTO, and it is useful evidence for insurers and clients.

A simple disaster recovery plan template

Your plan does not need to be long. It needs to be findable during a crisis (keep a copy outside your main systems, even a printed one) and specific enough that someone other than you could follow it.

Contacts. Who declares a disaster, who leads recovery, IT provider, cyber insurance, bank, key suppliers. Phone numbers, not only email.
System list with priorities. Every system, its owner, its RPO and RTO, and the order in which to restore.
Where the backups are. Each system’s backup location, how to access it and where the credentials are stored.
Recovery steps. For each critical system, the steps to restore it, written so a competent technician who does not know your setup could follow them.
Continuity workarounds. How the business operates while systems are down: manual order forms, a phone script for customers, how payroll runs.
Communication. Who tells staff, customers and partners, what they say and through which channel if email is down.
Legal and reporting. When to call your insurer, when to involve police, and how to assess whether personal information was affected.
After recovery. What went wrong, what to change, and a date to update the plan.

What drives the cost of backup and disaster recovery

We do not publish prices, and any number without knowing your setup would be a guess. These are the factors that move the cost up or down:

Amount of data and how quickly it grows.
How far back you keep copies. Longer retention and more restore points mean more storage.
How tight your RPO and RTO are. Recovering within minutes, with standby systems ready to run, costs far more than restoring within a day.
Number of copies and locations, including immutable storage.
Number of users and SaaS services covered, since many SaaS backup tools are priced per user.
Testing and management time. Someone has to watch the jobs, run the tests and keep the plan current.

The useful question is not “what is the cheapest backup?” but “what would a day without this system cost us?” That answer tells you how much protection is worth buying.

Data residency: keeping backups in Canada

AWS, Microsoft Azure and Google Cloud all operate data centre regions in Canada, and many backup services let you choose where copies are stored. If you hold personal, health or financial information, or your clients require Canadian storage, check the region for every copy. The offsite or immutable copy is sometimes created in a default region you did not pick.

Canadian privacy law (PIPEDA) keeps your business accountable for personal information even when a provider stores it for you. That makes backup location, encryption and access control part of your privacy obligations, not only an IT choice. Our cloud migration guide covers data residency and the shared responsibility model in more detail.

Common mistakes

Treating sync as backup. File sync tools copy deletions and encrypted files just as faithfully as good ones.
Backing up to a drive that is always connected. Ransomware encrypts it along with everything else.
Never testing a restore, or only testing single files and never a full system.
One person knows everything. When they are on holiday, nobody can recover.
Forgetting SaaS data, on the assumption that the provider keeps copies for you.
Using the same admin account for daily work and for managing backups.
Keeping too little history to go back before a quiet infection started.
Keeping the recovery plan only on the server that has just failed.

Questions to ask a backup or DR provider

Where exactly are our copies stored, and can we keep all of them in Canada?
Is at least one copy immutable or offline, and who can change the retention?
Which of our SaaS services do you cover, and what exactly is included (mailboxes, shared drives, chats)?
How long does a full restore of our main system take, and have you tested it with our data?
How will we be alerted if a backup fails?
What happens to our backups if we end the contract?

Where to start

This week, list your five most important systems and write down, for each, where the backup is and when someone last restored from it. That short exercise usually shows exactly where the gaps are.

Our cloud and data service designs and runs backup and recovery on AWS, Azure and Google Cloud, including Microsoft 365 and Canadian data residency, and our cybersecurity service makes sure those backups hold up against ransomware. Tell us what you run today and we will help you build a plan you can actually test.

Frequently asked questions

What is the difference between backup and disaster recovery?

A backup is a copy of your data. Disaster recovery is the tested plan, people and tools that get your systems running again from that copy, within a time your business can live with.

Is Microsoft 365 or Google Workspace data backed up automatically?

These services are built to stay available, but that is not the same as keeping a copy you control. Microsoft's own services agreement recommends that customers regularly back up their content and data, so a separate backup is worth considering for email, files and shared drives.

What is the 3-2-1 backup rule?

Keep at least three copies of your data, on two different types of storage, with one copy kept offsite. Many businesses now add that one copy should be offline or immutable so ransomware cannot change or delete it.

What do RPO and RTO mean?

RPO (recovery point objective) is how much recent data you can afford to lose, measured in time. RTO (recovery time objective) is how long a system can be down before the damage becomes serious.

How often should we test our backups?

Restore a few files on a regular schedule and run a fuller recovery test of your most important system at least once a year, and after any major change. The first test almost always reveals something to fix.

Can our cloud backups stay in Canada?

Yes. The major cloud providers operate data centre regions in Canada, and many backup services let you choose where copies are stored. Confirm the region for every copy, including the offsite one, in writing.

Cloud backup and disaster recovery: a plan your business can actually use