3-2-1 backups in downpipes, and exactly what is and is not verified
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. It is written to be exact, because the easy thing to say is that the platform verifies 3-2-1, and that would be an over-claim.
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 is the precise breakdown of which part is machine-proven, which part is your informed judgement, and how the posture screen expresses each one honestly.
What the three copies are here
Counting copies is where most 3-2-1 descriptions quietly inflate. Here is the honest count for a downpipe with two destinations:
| 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 honest line runs straight through the middle of the 3-2-1 rule.
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 genuinely 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 accepts it. Treat any blanket “3-2-1 verified” claim as wrong, including framings that map a compliance article straight onto 3-2-1 failover. The honest statement is verify-some, attest-one.
The posture controls that express this
The security posture screen splits the picture into separate checks so the honest distinction is visible rather than buried. 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 (“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 accepts it. The platform cannot verify media type for cloud-only storage. |
| Immutability (WORM / Object-Lock) | 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. True 3-2-1 lives in the two checks 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 genuinely different media or two buckets on the same storage class. Rather than fabricate a green tick, the control surfaces as needs-attestation (amber, not a red fail) the moment a source fans out, and stays in that state until an Owner reviews their destinations and accepts the check to attest that they meet their own media-diversity policy. Accepting is the honest tick. It records your judgement, it does not assert a platform fact.
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 genuinely 3-2-1 posture has a destination configured, has every downpipe fanning out to at least two destinations, and has the media-diversity check accepted by an Owner. The posture test fixture encodes exactly this. A downpipe with a destination count of two passes the redundant-copies control, and the media-diversity control is accepted, so it counts as a pass rather than a silent green. That is the shape of an honest full mark: two machine-proven legs alongside 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.
Precise claims
The canonical list of what downpipes may and may not claim, including the verify-versus-attest wording used here.
Last updated .