Business Continuity and the 3-2-1 Backup Model Explained

The 3-2-1 backup model requires three copies of important data, held on two different types of storage, with at least one copy stored offsite. The production data itself counts as one of the three copies. The purpose is to reduce the probability that a single event, such as hardware failure, ransomware or a physical incident, destroys every copy simultaneously.

• Three copies of the data, including the live production copy.
• Two different storage types, so a single technology failure cannot destroy every copy.
• One offsite copy, so a physical or environmental event at the primary location does not affect it.

A single backup is a single point of failure. It can be affected by hardware failure on the storage device it lives on, by ransomware that reaches the network share it sits on, by accidental deletion, by misconfiguration during a change, or by theft or fire at the same physical location. Multiple copies across different storage types and locations address each of those failure modes independently.

• Microsoft 365 data across Exchange Online, OneDrive, SharePoint and Teams.
• File servers, network shares and archive locations.
• Cloud applications used by the business, especially those holding customer records.
• Databases behind line-of-business applications.
• Employee laptops and any workstation with local data.
• Business systems configuration, including firewall rules and identity settings.
• Website content, application code and any related deployment configuration.

No. Cloud storage services such as OneDrive, Google Drive or Dropbox synchronise files across devices. That is not the same as backup. If a file is deleted or corrupted, the change is synchronised to the cloud copy. Recycle bins and version history mitigate this to some extent, but they are limited in scope and duration and are not designed as a comprehensive recovery mechanism. A separate backup, held in a different system with its own retention rules, is what makes recovery reliable.

Microsoft is responsible for the availability of the Microsoft 365 service and for protecting its own infrastructure. Customers are responsible for the data they create in that service. Native features such as recycle bins, version history and retention policies protect against many everyday scenarios, but they do not replace an independent backup for scenarios such as accidental site deletion, long-term retention beyond native limits, or ransomware that reaches synced files.

For the wider Microsoft 365 posture that backup fits inside, see Why Microsoft 365 configuration matters for business security.

Recovery Point Objective describes the maximum amount of data the business can accept losing. If a system is backed up every four hours and fails immediately before the next backup, the RPO for that system is up to four hours of work. Recovery Time Objective describes the maximum amount of time the business can accept a system being unavailable while it is being restored.

Ransomware groups actively target backup infrastructure. An immutable backup copy cannot be modified or deleted within a defined retention window, even by an administrator. An offline copy is disconnected from the production network for most of its life. Either mechanism significantly increases the probability that a business can recover from ransomware without paying, provided the copy predates the encryption event.

The 3-2-1-1-0 extension adds one offline or immutable copy to the three-two-one baseline, and requires zero unresolved errors following verification of the backup. It reflects the reality that a backup with errors is not really a backup, and that offline or immutable copies are now a common expectation rather than an advanced control. The extension does not replace risk assessment. It complements it.

A successful backup job proves that data was copied. It does not prove that the copy can be restored, that the restored data is usable, or that dependent systems will function once restored. Regular restore testing is the only way to confirm that. A small, structured restore test each quarter is more valuable than an exhaustive test that never happens because it is too big to schedule.

• Critical systems ranked by how quickly the business needs them back.
• Responsible people for each system, including a nominated backup contact.
• Communication plan covering staff, clients and suppliers during an incident.
• Recovery priorities so the order of restoration is decided in advance.
• Supplier contacts including account numbers and after-hours support paths.
• Alternative working arrangements for premises loss or network outage.
• Restoration process documented in enough detail that it does not rely on memory.
• Testing schedule for both technical restores and communication rehearsals.