3-2-1 backups in downpipes: what is verified and what is attested
The 3-2-1 rule is a backup convention: keep three copies of your data, on two different media, with one copy offsite. This page is for an evaluator deciding what downpipes actually proves against that rule.
downpipes proves redundant copies and offsite-by-nature. It does not, and for cloud-only object storage it cannot, verify the two-different-media leg. That leg is an operator attestation. The rest of this page sets out what is machine-proven, what is your judgement, and how the posture screen shows each.
What the three copies are here
For a downpipe with two destinations, the copies are:
| Copy | What it is | Who proves it |
|---|---|---|
| 1 | The live production data on the source itself | This is your running system, not something downpipes writes. |
| 2 | The archive on the primary destination | downpipes seals here and verifies the archive at seal time. |
| 3 | The archive on the replica destination | A scheduled replication pass copies the finalised run here. |
So a downpipe with two destinations gives you two independent off-source archive copies (the primary plus one replica), and the third copy is the production data itself. If you configure two destinations, that is two off-source copies plus the live source, not three off-source copies. Adding a third destination adds a third off-source copy, and so on.
The offsite leg is inherent. Every cloud destination is offsite from the source by nature: it is a different bucket, often a different account or provider, reached over the network. You do not have to attest “one offsite” separately, because cloud object storage is offsite by construction.
Where the platform proves it, and where it cannot
The platform verifies two legs of the rule and cannot verify the third.
The platform proves redundant copies and offsite-by-nature. The redundant-copies leg is machine-checked two ways. First, every downpipe should write to two or more distinct destinations, so a backed-up source is configured to exist in more than one place off-source. Second, and separately from the configured count, the map shows an “N of M copies” readout derived from proven replication outcomes, so you can see how many destinations hold the latest run. The offsite leg needs no attestation, because all cloud storage is offsite from the source by construction.
The platform cannot verify the two-different-media leg. downpipes is a cloud-only object-storage backup. Two R2 buckets, or R2 plus an external S3 store, are the same media class as far as the platform can tell. There is no physical medium to inspect, so the platform cannot certify “two different media” for you. That is your call to make and to attest.
The platform does not verify 3-2-1 end to end
downpipes verifies redundant copies and offsite-by-nature. The two-media leg is an operator attestation that reads as needs-attestation until an Owner attests it. Treat any blanket “3-2-1 verified” claim as wrong, including framings that map a compliance article straight onto 3-2-1 failover. downpipes verifies two legs, and you attest the third.
The posture controls that express this
The security posture screen splits the picture into separate checks so the distinction is visible. Four of them touch redundancy and 3-2-1, and they are deliberately different checks at different severities.
| Check | Category | Severity | What it actually tests |
|---|---|---|---|
| Archive destination configured (second copy) | Redundancy | critical | At least one destination is configured, so a backed-up source has a second copy off-source. This is deliberately not labelled 3-2-1, because one destination is not 3-2-1. |
| Sources fan out to two destinations | 3-2-1 | high | Every downpipe is configured to write to two or more destinations. This checks the configured destination count, not that the latest run landed. |
| Media diversity attested (3-2-1 “two media”) | 3-2-1 | medium | Operator-attested. Once any source fans out, this reads as needs-attestation (amber, not a red fail) until an Owner attests it. The platform cannot verify media type for cloud-only storage. |
| Object-Lock (WORM) immutability | ISO A.8.13 | medium | A separate concern from copy count: it reports the real Object-Lock status from a live capability probe, not inferred from delete permission. |
The first control proves only the second copy: a live source plus one archive. It is on purpose not called a 3-2-1 control, because calling a single destination 3-2-1 would overstate the posture. The 3-2-1 checks are the two below it.
The critical distinction: configured count versus proven landing
The “Sources fan out to two destinations” control checks the configured destination count. It passes when every downpipe lists two or more destinations. It does not, by itself, confirm that the latest run actually landed in two places. That is a separate signal.
The proven-landing signal is the map’s “N of M copies” readout. It is derived entirely from proven replication outcomes (a destination’s recorded holdsRunId matching the downpipe’s latest successful run, plus that destination’s last reachability), never inferred from how stale a run looks or from the canary. So the two signals answer two different questions: the posture control answers “is this downpipe configured for redundancy?”, and the map answers “does the latest run physically exist on N of its M destinations right now?”. Right after a run, the configured count can be two while the proven copies are still one, because replication catches up on a later pass.
Why media diversity is an attestation, not a check
The media-diversity control is operator-attested because there is nothing for the platform to measure. Cloud object storage gives no signal about the underlying physical medium, so the platform cannot tell whether two destinations are different media or two buckets on the same storage class. Rather than show a green tick, the control surfaces as needs-attestation (amber, not a red fail) the moment a source fans out. It stays in that state until an Owner reviews their destinations and attests the check.
The control to use is named, and the name matters. On the check, an Owner opens Attest or override and chooses Pass: I attest this control is satisfied, recording a reason. This records your judgement, not a platform fact, and the reports show it as a pass attested by you.
Do not reach for “Accept this risk” instead. That is a different determination on the same modal, and it records a different meaning: the finding is real and you are living with it for now. It counts toward the score, but it stays listed as an accepted risk, not as a pass, until an Owner changes or withdraws it. Until then, every report shows an estate that meets its own media-diversity policy as an estate that does not.
Before any fan-out exists, the control does not apply and passes silently, because media diversity is meaningless when there is only one place to write.
How a healthy posture reads
A full 3-2-1 posture has a destination configured, every downpipe fanning out to at least two destinations, and the media-diversity check attested by an Owner. A downpipe with a destination count of two passes the redundant-copies control, and the media-diversity control is attested, so it counts as a pass rather than a silent green. A full mark is two machine-proven legs and one attested leg.
Where to go next
Set up multiple destinations
The step-by-step task: add destinations, attach two or more to a downpipe, and understand primary versus replica.
How a run is captured
The end-to-end shape of a run, including why copies fan out on a later pass rather than during the run.
The posture screen
The security posture screen where these checks live, including how a check is attested or overridden.
Security properties and limits
The security properties downpipes has and the limit on each, including verify versus attest.
Last updated .