The 3-2-1 backup strategy: a concrete guide

What 3-2-1 really means

The rule fits in three numbers. Three: keep at least three copies of your data (the original and two backups). Two: store these copies on two different types of media (for example a local disk and cloud storage). One: keep at least one copy off-site, geographically separated.

The idea behind each number is redundancy against distinct risks: hardware failure, logical corruption, and a local disaster. No single copy covers all three risks at once.

Why the off-site copy is non-negotiable

Imagine a fire, water damage or theft on your premises. If all your copies are in the same place, they vanish together. The off-site copy, whether in a remote datacenter or the cloud, survives the local disaster.

For a Quebec business, hosting this copy in Canada also simplifies compliance. Managed hosting that is local combines geographic distance with controlled jurisdiction.

Add immutability against ransomware

The 3-2-1 rule predates the ransomware era. Today it must be enriched with a fourth principle: immutability. An immutable backup cannot be modified or deleted for a defined period, even by a compromised administrator.

This is what guarantees a clean restore after an attack. Without immutability, ransomware that reaches your backups leaves you with no safety net. Hence the growing talk of a 3-2-1-1 rule, the last 1 standing for the immutable or offline copy.

Automate so nothing is forgotten

A backup that depends on a manual action always ends up forgotten, especially on busy days. Automation guarantees regularity: copies run on a schedule, with no human intervention.

But automating without monitoring is dangerous: a backup that fails silently gives a false sense of security. A managed IT provider supervises the jobs and alerts on failure, so the problem is fixed before you need the copy.

Set the right frequency

Frequency depends on your tolerance for data loss, the famous RPO. For data that changes little, a daily backup suffices. For a transactional database, you sometimes need several backups a day, or even continuous protection.

This calibration is done together with your recovery plan: backup frequency and recovery objective must be consistent, otherwise one cancels the other.

The only test that counts: the restore

A backup is only worth something if you can restore it. Yet many businesses never test their restores and discover at the worst moment that the files are corrupted, incomplete or impossible to recover in time.

Schedule regular restore tests on a representative sample. Also measure how long the restore takes: that is what determines your real downtime during an incident, and it is often longer than imagined.

Back up the cloud too: a dangerous myth

A false belief persists: data in the cloud (Microsoft 365, Google Workspace) would be automatically protected. In reality, these services guarantee the availability of their infrastructure, not the recovery of your data after a deletion, a human error or ransomware.

The shared responsibility model is explicit: the provider protects the platform, you remain responsible for your data. A mailbox emptied by mistake or encrypted by an attack is not always recoverable beyond a short window.

Backing up your cloud environments with a third-party solution, following the same 3-2-1 logic, fills this gap. It is an often-forgotten protection, until the day a permanent deletion is a reminder of its importance.

Encrypt your backups

A backup holds a complete copy of your most sensitive data. If it falls into the wrong hands, unencrypted, it is a major leak. Encrypting backups, at rest and in transit, is therefore indispensable, not optional.

This is especially true for off-site and cloud copies, which travel and reside outside your walls. Encryption guarantees that even with unauthorized access to the medium, the data stays unreadable.

This requirement meets compliance: Law 25 and the GDPR expect adequate protection of personal information, including in backups. Encrypting is therefore not just good practice, it is effectively an obligation.

Versioning to roll back cleanly

Beyond having copies, you need the right point in time to restore. Ransomware and silent corruption may sit undetected for days, so a single recent backup can already be poisoned. Keeping multiple dated versions lets you roll back to a known-clean state rather than to whatever the latest copy happens to be.

Versioning answers the practical question that arises in every incident: not just "do we have a backup?" but "do we have a good one, from before the problem started?". Without history, you may faithfully restore the very corruption you were trying to escape.

Tie version retention to your recovery objectives and to the nature of your data. The aim is to always have a clean, restorable point within an acceptable window, which is what turns a backup set from a comforting idea into a genuine recovery capability.

Offline and air-gapped copies

Immutability protects backups from being altered, but an offline or air-gapped copy goes one step further: it is physically or logically disconnected, so an attacker who compromises your network simply cannot reach it. It is the ultimate last resort when everything else is encrypted.

This copy need not be exotic. It can be a rotated offline medium or a backup target reachable only through a tightly controlled, time-limited path. The principle is the same: at least one copy that ransomware cannot touch even with full network access.

Combined with the 3-2-1 rule and immutability, the offline copy completes a layered defence. Each layer covers a different failure mode, and together they make the difference between a clean recovery and a total loss.

Restore-time objectives in practice

Having a copy is only half the answer; how fast you can use it is the other half. Restoring several terabytes over a constrained link can take far longer than expected, and that real duration, not the backup's existence, defines your downtime.

Measuring restore time during tests turns a vague assumption into a known figure. It also reveals practical bottlenecks: bandwidth, the order of restoration, dependencies that must come back first. These are exactly the details that derail an unprepared recovery.

Once known, restore time can be improved: local copies for speed, prioritized restoration of critical systems, or higher-performance targets. The aim is to bring real recovery within the window your business can actually tolerate.

Documenting and assigning responsibility

A backup strategy rests on decisions that must be written down: what is backed up, how often, where, for how long, and who is responsible. Without documentation, these choices vanish over time and you end up with gaps no one noticed until it was too late.

Responsibility must be clearly assigned. When everyone assumes someone else handles backups, no one truly does. Naming an owner, even if the task is delegated to a provider, ensures a specific person answers for their reliability.

This documentation also serves compliance. In an audit or after an incident, a written backup policy and evidence of its application demonstrate diligence, which is exactly what Law 25 and the GDPR expect on the technical side.

Define a retention policy and monitor it

Keeping every backup forever is costly and complicates management; keeping only the latest is dangerous. Between the two, a retention policy defines how many versions to keep and for how long, according to the nature of the data.

A common approach combines daily backups kept for a few weeks, weekly ones over a few months, and monthly ones over one or more years. This gradation lets you go far back without exploding volumes.

A silent backup is a suspect backup. Without supervision, a job can fail for weeks unnoticed. Entrusting this monitoring to a managed provider ensures a human actually looks at the results and reacts, and the logs serve as proof in a compliance audit.

FAQ