What Is a Backup: Types, 3-2-1 Rule and Business Strategy

A backup is an independent copy of a system's data, kept on a different medium, that lets you recover if the originals get lost, corrupted, deleted or encrypted. The definition looks obvious, but the word "independent" does almost all the work: a copy that shares failure with the original isn't a backup, it's a replica. And a copy nobody has tried to restore isn't a backup either, it's hope. This piece explains what a backup is in technical terms, the types that exist, the 3-2-1 rule that has become minimum standard and why most companies suffering a serious ransomware had backups and still couldn't restore.

What a backup is: technical definition

A backup is a coherent copy of a dataset at a point in time, stored on a different medium from the original, autonomously recoverable and verifiable. The three operational pieces:

• Coherent: the system being copied has to be in a consistent state. Copying a database mid-write without snapshot or pausing transactions produces a backup that can't be restored.
• Independent: the copy has to survive the original's failure. If ransomware encrypts the server and also the network drive where "the backups are", that drive wasn't a backup, it was another copy reachable to the same attacker.
• Verifiable: you have to be able to restore the data from the backup in a clean environment and check that the restore works. If it's never been tested, the backup doesn't exist in practice.

The backup is the last defence of information security, the one that fires when every other has failed. A well-designed plan turns a serious ransomware into an operational problem of days; a badly-designed plan turns it into a crisis that paralyses the organisation for weeks.

Backup types by copy strategy

Three classic types based on what data gets copied each cycle. Almost every modern solution combines the three.

Full backup

Copies all the data of the protected set every time it runs. Takes more space and time, but lets you restore by reading a single set. Usually the base copy on which the following ones get built.

Incremental backup

Copies only the data that changed since the last copy, whether full or incremental. Takes little space and runs fast, but restoring requires reading the last full plus the whole chain of incrementals up to the desired point. If an intermediate link breaks, restoration from that point gets complicated.

Differential backup

Copies the data that changed since the last full copy, regardless of how many differentials were done in between. Takes more than an incremental, less than a full, and restoring is simpler: a full plus a differential.

Synthetic backup

Combines an old full with later incrementals on the backup storage itself, without touching the source system, to produce a new virtual "full" without network cost or load on production. The usual technique in modern enterprise solutions.

Mirror and replication

Keep a continuous replica of the dataset at another location. They aren't backups by themselves: if you delete a file, the mirror replicates the deletion. Replication protects against hardware failure or physical disaster, but not against attacks or human error. Part of a strategy, not a substitute for it.

The 3-2-1 rule (and its 3-2-1-1-0 evolution)

The 3-2-1 rule was born in the nineties, remains the minimum standard and gets cited in every relevant regulation (ISO 27001, ENS, NIS2, DORA, NIST). It says:

• 3 copies of the data: the original plus two backups.
• 2 different media: if the original is on SSD, the copies should be on at least two different types (disk, tape, cloud, NAS, etc.).
• 1 copy off the main location: if the original is at the office, one copy must be at another office or in cloud.

In the ransomware era it has extended to 3-2-1-1-0:

• 1 copy immutable or air-gapped (not accessible for write from the production network). The only one that survives ransomware compromising the administrator.
• 0 errors: the copy must get verified and successfully restored periodically.

This version is what gets cited in recent recommendations from INCIBE-CERT, CCN-CERT and equivalent European entities.

Backup vs disaster recovery vs archiving: not the same

Three different concepts that in small enterprise get mixed and in mid-sized already need to be separated.

Backup

Recovers data. Its goal is to have files, databases, configurations and mailboxes back the way they were at a point in time. The metrics that matter: RPO (Recovery Point Objective, how much data loss you accept) and RTO (Recovery Time Objective, how long it takes you to be operational again).

Disaster Recovery

Recovers the ability to operate, not just the data. Implies alternative infrastructure ready or reconstructible, procedures to bring up services in another location, teams prepared to execute them and client communication. DR uses backups, but it isn't just backups: includes networks, identities, servers, integrations and people.

Archiving

Stores data long-term for legal, regulatory or business reasons. Designed for sporadic consultation, not fast operational recovery. Meets obligations (GDPR, accounting regulations, NIS2 log retention) but doesn't replace operational backup.

Mixing these three concepts is one of the most expensive errors we see in incident response: the client says "we have backup" when what they have is replication, or "we have DR" when what they have is an off-site copy without procedure or infrastructure to bring anything up.

How to design a backup strategy at a company

A reasonable enterprise backup strategy answers six questions in this order.

1. What needs protecting

Realistic inventory: physical servers, virtual machines, databases, mailboxes (Microsoft 365, Google Workspace), code repositories, SaaS data (Salesforce, Notion, Jira), cloud infrastructure configurations (CloudFormation templates, Terraform), critical endpoints. What's not in the inventory doesn't get backed up.

2. What loss is acceptable (RPO)

How much information would you lose without the business breaking? In critical B2B systems, RPO is usually minutes, requiring replication plus frequent backups. In non-critical internal systems, 24 hours is usually enough. This figure determines backup frequency.

3. How long can you be down (RTO)

How long can you be stopped? Defines the technology you need: low RTOs require backup with instant restore (mounting the copy as operational disk), hot virtualisation, executable DR plan. For high RTOs (days), a standard cloud restore is enough.

4. How long do you keep the copies

The retention policy depends on three things: legal obligations, audit cycles and attack pattern. A common scheme in SMEs:

• Daily backups: 14 to 30 days.
• Weekly backups: 3 to 6 months.
• Monthly backups: 1 to 7 years (depending on regulated sector).

5. Where they get stored

Meeting 3-2-1-1-0: production plus at least two copies on different media and locations, with at least one immutable. The usual options:

• Local NAS for fast restores.
• Tape or offline disk for real immutability.
• Cloud with object lock for managed immutability.
• Secondary site or DR provider for geographic resilience.

6. Who proves it works

Responsibility must be named and the test must run periodically (at least quarterly on critical systems, semi-annual on the rest). Without documented testing, the plan doesn't exist in practice.

Why many companies with backup couldn't restore

Patterns appearing again and again in ransomware incident response:

1. The backup was on a reachable network drive. The ransomware encrypted it alongside production. Without an immutable copy, there was nothing to restore.
2. The backups were replication, not independent copies. When critical files got deleted, the mirror replicated the deletion.
3. Backup management credentials were in compromised Active Directory. The attacker accessed the console and deleted restore points before executing encryption.
4. No one tested restoring. The copy existed, but had gone months without verification. At incident time, they discovered it had been silently failing for months.
5. Real RTO was 5x the paper RTO. The organisation dimensioned the network, servers and human capacity for a small restore; when it came to restoring 30 servers and 200 endpoints at once, the plan collapsed.
6. Backup encryption keys were lost or in the same compromised domain. Encrypted backup without key isn't a backup.

These six failures summarise almost every DFIR response incident where we see companies with paralysed copies for weeks.

Cloud, on-premise and hybrid backup

Each model has a different profile.

On-premise backup

Storage on the client's own infrastructure. Advantage: fast restore on local network, full control. Disadvantage: vulnerable to physical disaster and internal network compromise. Needs an additional off-site copy to meet 3-2-1.

Cloud backup

Storage in a cloud provider (AWS S3, Azure Blob, Google Cloud Storage, Backblaze B2 or specialised solutions like Veeam Cloud Connect, Acronis, Datto). Advantage: native remote location, scalability, managed immutability models (object lock). Disadvantage: egress cost if you need to restore large volumes, provider dependency, latency on low RTOs.

Hybrid backup

Combines local copies (for low RTOs) with cloud copies (for geographic resilience and immutability). The most common model in mid-sized companies by 2026.

SaaS backup

Data in SaaS (Microsoft 365, Google Workspace, Salesforce) needs backup independent of the provider itself. The shared responsibility model leaves recovery of deleted or encrypted data as the client's responsibility, not the SaaS provider's. Tools like Veeam for M365, Druva, Spanning Backup (Kaseya) or AvePoint cover this case. Ignoring it is a common failure.

Immutability: the piece that changes the game against ransomware

An immutable copy is a copy that can't be modified or deleted during a defined period, not even by the system administrator. The only real defence when the attacker gains administrator privileges on production and goes for the backups before encrypting.

Three usual ways to achieve it:

1. Physical tapes in external custody: the classic, still robust.
2. Cloud with object lock in compliance mode: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage retention policies. Configured in compliance mode, not even the owner can delete them before expiration.
3. Backup appliances with native immutability: Veeam Hardened Repository, Rubrik, Cohesity, Datto SIRIS and similar offer managed immutability models.

Immutability is slow to configure and painful when data needs moving, but it's the difference between recovering or not recovering after a serious attack.

Testing the copies: the step almost nobody executes

Testing means really restoring, in a test environment, with no shortcuts, and validating that the restored data works. Reasonable minimums:

• Isolated file restore monthly: pull any file from the backup and check it opens.
• Full machine restore quarterly: bring up a VM or server from backup in an isolated environment and check it boots and operates.
• Disaster drill annually: rehearse the full recovery of a critical service, measuring real RTO and comparing to paper RTO.

A backup that doesn't get tested isn't a strategy: nobody knows if it works until the day it's needed, and that day is too late to find out.

Common mistakes and how to avoid them

Patterns appearing in audits and reviews:

1. Backup on the same network, without segmentation or MFA. Add MFA to the backup system, isolate the management network and use dedicated accounts independent from the main directory.
2. Backup logs and telemetry unmonitored. If nobody sees failures, failures pile up silently. Integrate the backup platform into the SIEM and the SOC.
3. No database strategy. File backups over folders containing open database files don't produce coherent copies. Use the database agent or method (SQL Server Backup, pg_dump, consistent mysqldump, Oracle RMAN, etc.).
4. No version retention for SaaS. Microsoft 365 keeps deletes typically 30-93 days depending on licence; past that, without independent backup, the data gets lost.
5. No documentation. The restore procedure must be written, accessible offline and tested by people other than whoever wrote it.

Frequently asked questions

What's a backup and what's it for?

A backup is an independent copy of the data that lets you recover if the originals get lost through hardware failure, human error, physical disaster, attack (especially ransomware) or logical corruption. The last layer of information security defence: when everything else fails, the backup is what separates the annoying incident from the existential crisis.

What's the difference between full, incremental and differential backup?

The full copies all data each time; the incremental copies only what changed since the last copy (full or incremental); the differential copies what changed since the last full copy. Full takes more space and time; incremental runs fast but requires an intact chain to restore; differential sits in the middle.

What's the 3-2-1 backup rule?

3 copies of the data (original plus two backups), on 2 different media, with 1 copy off the main location. The minimum standard for decades. The modern 3-2-1-1-0 extension adds 1 immutable copy and 0 verified errors in test restores.

How often do you have to back up?

It depends on the RPO the business accepts. In critical B2B systems, RPO is usually minutes, requiring very frequent backups or replication with snapshots. In non-critical internal systems, 24 hours is usually enough. It's a business decision before a technical one.

Is having backup enough to protect against ransomware?

No. The backup is the last layer, not the only one. Protects against ransomware if and only if backups are immutable or isolated from the network, management credentials are independent, telemetry is monitored and restoration is tested periodically. Without those conditions, the modern attacker deletes or encrypts backups before demanding ransom.

Does Microsoft 365 already do automatic backups?

Microsoft 365 keeps retention and recycle bin, but it isn't an independent backup service. Deleted data gets recovered within the retention window (typically 30-93 days depending on licence); past that period, without third-party independent backup, data gets lost. The same logic applies to Google Workspace and most critical SaaS.

Is it legal to restore personal data after an incident?

Yes, and in some cases it's required by the GDPR integrity and availability principle and by continuity regulations for essential services (NIS2, DORA). What changes is the notification of the incident to the authority and, where appropriate, to those affected. The restore procedure must be documented and traced for later audits.

Related resources

• What is ransomware
• Types of malware
• What is a SOC
• NIS2 in Spain
• DORA compliance for financial entities
• IaaS, PaaS and SaaS: security differences

Backup strategy at Secra

At Secra we review the backup strategy as a standard part of any defensive audit: alignment with 3-2-1-1-0, real verification of immutability, segmentation and dedicated credentials, periodic test restores documented, mailbox and critical SaaS protection. If your organisation has backups but has never run a real disaster drill or doesn't know what its real RTO is, get in touch via contact.