The 3-2-1 backup rule

The shape of it

Three copies of one dataset: production and a local NAS on your site, and a third copy received by CapyArk off site over Tailscale. — Three copies of the data, on two kinds of storage, with one copy outside the blast radius of the first two. Lose any single thing — a disk, a building, an admin account — and you still have a path back.

3

Three copies of the data

The live copy counts as one. A snapshot on the same pool does not count as a second — it shares the disks, the controller, and the person who typed zfs destroy -r. Two independent copies beyond production is the floor.

2

On two different media

Different hardware, different failure mode. Two arrays from the same batch of drives, in the same chassis, on the same firmware, fail in correlated ways — that's one medium wearing two hats. NAS plus remote pool, or disk plus tape, is two.

1

One copy off site

Off site means a different failure domain, not a different room. Different building, different power, different network, and ideally different credentials — so an attacker holding your hypervisor doesn't also hold your history.

Some people extend this to 3-2-1-1-0: one copy immutable or offline, and zero errors on your last verified restore. Both additions are about the same thing — a backup you haven't restored from is a hypothesis.

Why sync isn't the third copy

A sync target holds only the current state and ends up encrypted with it; a snapshot chain keeps the earlier days restorable. — A sync tool's job is to make the far end match the near end. It does that job perfectly during a ransomware event. Retention is what turns storage into a backup.

Drive, Dropbox, iDrive and friends are good at what they're for: files you're actively working on, reachable from a phone. They are not version control for a database volume, and their history windows are measured against an average consumer's mistakes, not an incident that goes unnoticed for three weeks.

What incremental actually means here

One full baseline send followed by small incremental sends, with retention keeping 24 hourly, 14 daily, 8 weekly and 12 monthly snapshots. — The first send is the whole dataset. Everything after it is the difference, block by block, which is why nightly protection of a multi-terabyte pool costs a coffee's worth of bandwidth instead of a maintenance window.

The part nobody advertises

A backup you can't prove is a backup you're hoping about. CapyArk records every send, receive, prune and restore with a timestamp and an actor, alerts when a chain stops advancing or a snapshot arrives short, and makes the last verified restore a number you can look at rather than a thing you assume.

That's the whole pitch. If that's the problem you have, get on the list. If it isn't, the 3-2-1 rule above still works, and it's free.

Three copies. Two media. One of them somewhere else.