Bucket

Results

Compared to other ways to hold several TB

The $/TiB-year number Bucket gives you is hard to read in isolation. Here's how it lands against the common alternatives for someone with a working set of 5 to 50 TiB:

* Drought-vulnerable rows assume nothing actually fails. Once you risk-adjust for real-world failure rates and the cost of data loss when it happens, the effective $/TiB-yr on those rows is much higher.

Two structurally different financial products. Bucket and DIY are capital expense — you own the bytes, the cost amortizes over a 5–7 year wagon refresh cycle, and once paid you owe nothing. Cloud is operational expense — you rent the bytes forever, and the meter never stops. They look comparable at one-year horizons; they diverge sharply at five-year horizons. Over 5 years at 20 TiB, cloud at ~$80/TiB-yr costs ~$8,000; the Bucket wagon costs ~$1,500 and ends with you owning the hardware.

Where each option fits:

• Under 5 TiB — cloud or a single external drive with cloud backup is reasonable. Wagon fixed costs amortize badly at small scale.
• 5–15 TiB — turnkey 2-bay NAS works if you accept the drought-vulnerability and the vendor lock-in. DIY 2-way mirror buys back sovereignty but not drought resistance.
• 15 TiB and up — Bucket wagon (3-way mirror) is structurally and economically right. Below this scale the wagon's fixed costs dominate; at this scale and above, the drought-resistance pays for itself within the first failure cycle.

The honest read: Bucket isn't competing with cloud on price for 1 TB of family photos — there, Backblaze B2 at ~$72/year is fine and the operator overhead of a wagon isn't worth it. Bucket's claim is for the operator with a working set of 15 TiB or more who values both drought-resistant integrity and full sovereignty, and who's willing to outfit a wagon once and re-bucket it on a 5–7-year cadence.

About the math

Bucket models per-drive failure rate as a piecewise bathtub curve fit from Backblaze's public stats (CC-BY 4.0). For a mirror of N drives in parallel, expected time to first failure is the integral of S(t)^N. Cold spares absorb failures sequentially. Confidence bands ±20% on the effective AFR. Swimming pools apply a 1.2× multiplier on top of condition-class AFR — active scrubs, snapshots, and replication stress drives harder than archival.

About cold spares — buy them now, not later

The cold spare on the shelf is the part of the calculation most people underweight. Bucket reserves two bays of your wagon for them by default. Here's why that matters more than the per-bucket price suggests:

Drive availability decays faster than pool lifespan. A triplet you outfit today is expected to deliver 5–7 years of drought-resistant service. The drive model you bought today, however, is end-of-life within 2–3 years and out of new production within 4–5. By year 4, the only matching drives are on the used market — pulled from someone else's decom'd fleet, with unknown power-on hours, undisclosed firmware, and pricing that climbs as supply thins.

Quality decays alongside availability. The fresh-from-the-factory recerts you can buy today come with seller warranties and SMART-clean disclosure. The same model in year 4 is mostly gray-market pulls from operators with worse vibration profiles and longer duty cycles than yours. The drive that "plays well with your zpool" is increasingly rare to find at any price.

Compatibility decays alongside quality. Sector size transitions, firmware revisions, and HBA/interface generations all shift over a 5-year horizon. A 22 TB bucket sourced in 2030 is likely a different physical generation than a 22 TB bucket sourced in 2026 — different vibration profiles, different idle behaviors, possibly different recording technology. ZFS will tolerate the mismatch but the pool will run at the worst-leg characteristics.

The pattern that survives this:

• Buy spares with your active drives — same shipping lot if possible. Don't wait to need them.
• Over-stock while supply is fresh. Two cold spares per wagon costs $600–800 today; matching them in year 4 may cost twice that or be impossible at any reasonable price.
• Keep spares unspun on the shelf. The clock starts when you energize them. An unspun spare in year 5 is still a year-zero drive.
• Plan whole-wagon refresh at year 5–7, not whole-wagon panic at year 4. Bucket's $/TiB-year framing assumes you'll re-bucket the wagon as a planned event, not chase replacement parts.

The $311 you spend today on a spare is not just $311 of redundancy — it's insurance against a 3am sourcing search in 2030 when the drive you actually need is no longer made.

→ See current pricing for each tier on /market

When something breaks — the redundancy IS the recovery

A pool reaches the day where a bucket dies, one or two others start throwing errors, and the rest are still clean. Most people imagine this means professional data recovery on a separate rig. With a 3-way or 4-way mirror, it doesn't. The redundancy class you paid for is the recovery procedure — it runs on the original wagon, with one fresh replacement bucket and some patience.

The structural move: conserve the clean leg. Before you start any resilver, offline the still-good bucket. ZFS marks it not-participating; no read or write touches it from that moment on. Now the recovery operation reads only from the erroring legs. The clean leg sits in its bay as your last-resort backup — untouched, unstressed, ready to come online if and only if the erroring legs together can't supply some block.

In practice they almost always can. Errors on different drives sit on different blocks; ZFS's per-block checksums let it pick the good copy from whichever leg still has it. The clean leg never has to lift a finger. In the rare case where both erroring legs lost the same block, you bring the clean leg online and it supplies the missing data. Strict improvement either way: the clean leg can never get worse by being offlined, only by being read from during a stressful resilver.

The full sequence:

1. Power off cleanly while you still have a clean leg. Don't keep running degraded — every degraded operation accumulates wear on the leg you most want to preserve.
2. zpool offline <pool> <clean-id> — conserve the clean leg.
3. Pull the dead bucket; insert a fresh replacement (same-lot from your shelf if you stocked spares; recert with warranty if sourcing fresh).
4. zpool replace <pool> <dead-id> <new-id> — resilver from the erroring legs.
5. If zpool status -v reports unrecoverable blocks during the resilver, zpool online the clean leg and re-run scrub. Otherwise it stays offline through the entire resilver.
6. Bring the clean leg online; scrub the pool to verify.
7. Replace the erroring legs one at a time, scrubbing between each. Margin grows as you go.

End state: fresh-or-clean buckets across the triplet, full redundancy restored, days elapsed, data never at risk.

This is what the third (or fourth) bucket actually pays for. Not abstract redundancy — the specific option to do recovery conservatively, with a guaranteed-clean leg held in reserve as insurance. A 2-way mirror in the same scenario forces you to read from your only surviving leg during the resilver; a single read error there is data loss. The 3+ way mirror buys you the choice to be unhurried.

The professional-lab procedure (forensic disk imaging on a separate rig, read-only ZFS imports, copy-out before any repair) is the right call only when redundancy is below the floor — 2-way mirror with both throwing errors, or a single drive with no copies, or a wagon whose controller is suspected of causing the failures. The lab is for when you've lost the redundancy game. Buying the third bucket up front is what means you haven't.

If you're stocking spares now: current per-tier pricing on /market.