RAID is not a backup: putting 3-2-1-1-0 into practice

RAID addresses availability, not historical versions

RAID distributes data and redundancy over drives. Within the selected level's failure tolerance, the system can continue after a drive fails. That reduces interruption but does not make an independent historical copy. Deletion, ransomware encryption, corrupt application writes or a faulty script can immediately affect the array's current data.

Controller faults, power damage, operator mistakes and theft can affect the entire array. RAID belongs to availability planning; backups belong to recovery planning. They complement one another, but their protection must not be counted as interchangeable in a risk assessment or budget.

Rebuilds are a period of increased risk

Rebuilding reads and writes large volumes, stressing remaining drives and potentially revealing latent read errors. Larger drives and heavier load can keep an array degraded longer. Monitoring, appropriate hot-spare arrangements and a current backup matter more than nominal capacity alone.

Select the level using failure tolerance, write workload, rebuild time and operational needs. RAID 1 mirrors, RAID 5 typically tolerates one drive failure, RAID 6 two, and RAID 10 combines mirroring and striping. None protects against logical corruption or a compromised administrator.

Read 3-2-1-1-0 as a process

The rule means three copies including production, two media types, one off-site copy, one offline or immutable copy and zero uninvestigated restore errors. Version history permits returning to a pre-incident state. WORM or Object Lock can protect retained versions; an air gap separates an offline copy.

The final zero is operational: inspect logs, check integrity and actually restore. Otherwise the strategy remains an assumption. Snapshots are useful fast recovery points but often share storage and administrative control. Replication can copy deletion or encryption immediately. Independent retained versions, external storage and offline or immutable protection provide the missing recovery options.

Set objectives, retention and responsibilities

RPO specifies tolerable data loss, illustrated as one or 24 hours; RTO specifies acceptable interruption, such as four hours. A policy states who backs up what, when and where. An illustrative schedule uses daily incrementals, weekly full backups and, when justified by RPO, hourly protection for critical databases. Retention examples of 30, 90 and 365 days are protection-class choices, not universal requirements.

Encrypt in transit and at rest, manage keys through appropriate KMS/HSM arrangements and separate backup roles from general administration. Deduplication and compression can support cost efficiency. Monitor job failures, capacity and objective breaches; do not leave keys and backups exposed together or give one account unrestricted control over every copy.

An illustrative small-business setup

Protect files, databases and virtual machines through suitable agents or hypervisor integration. Use a versioned local NAS or appliance for quick restoration, an encrypted off-site S3 copy with Object Lock, and a weekly offline medium for critical data.

A general plan can include quarterly sampled file, VM and application restores; this example setup instead uses monthly logged exercises. Choose and document the cadence for the actual risk. A skipped restore test can leave incomplete or unbootable backups unnoticed for weeks.

• Source: protected application workloads.
• Primary target: versioned local NAS or appliance.
• Off-site copy: encrypted object storage with appropriate retention protection.
• Air gap: controlled offline copy of critical data.
• Audit: scheduled restores, timing and recorded business checks.

Demonstrate the entire recovery sequence

Prepare infrastructure, secure identities, select clean recovery points, start core systems and only then release dependent services. An exercise establishes whether staff, passwords, keys, bandwidth and replacement hardware are actually available.

Document the most recent restore, its unresolved errors and the next scheduled test. RAID, snapshots or a green job report alone do not establish readiness for a real incident.