Backblaze Hard Drive Test Data (Drive Stats Raw Dataset)

One series has counted storage deaths longer than anyone else. Backblaze Hard Drive Test Data snapshots every operational drive in Backblaze's data centers once a day - since April 2013 without a break - logging identity (serial number, model, capacity), physical placement (datacenter, cluster, vault, pod, slot), a failure flag for drives pulled from service, and every SMART attribute the device exposes, in both raw-counter and vendor-normalized form. The current fleet stands near 341,000 drives, and the cumulative ledger has passed about 530 million drive-days.

Two figures make the corpus statistically interesting. Lifetime annualized failure rate across the whole ledger runs near 1.39%, and a single recent quarter contributes roughly 30 million drive-days holding about 1,030 failures - enough terminal events to fit survival curves per model rather than per fleet. Failure-rate summaries circulate widely; the drive-day rows underneath them are what this record carries, and they support far more than any summary table can.

Three zones per row - identity, placement, telemetry - flat and identical in shape whether the day falls in 2013 or last month:

date           : 2026-02-15
serial_number  : 000a43e7dee60010
model          : DELLBOSS VD
capacity_bytes : 480036847616
failure        : 0
datacenter     : ams5
cluster_id     : 031
vault_id       : 2017
pod_id         : 05

date          : 2026-02-15
model         : TOSHIBA MG07ACA14TA
capacity_bytes: 14000519643136
failure       : 0
smart_5_raw   : 0
smart_9_raw   : 46458

date          : 2026-02-15
model         : TOSHIBA MG07ACA14TEY
capacity_bytes: 14000519643136
failure       : 0
smart_5_raw   : 0
smart_9_raw   : 2798

The DELLBOSS unit is a 480 GB boot device riding along in a fleet dominated by 14 TB workhorses, and its row shows the complete placement spine, down to the pod. The Toshiba pair shows the telemetry zone doing its job: smart_5_raw (reallocated sector count) parked at zero while smart_9_raw (power-on hours) reads 46,458 and 2,798 - two drives of the same model family at very different ages. A boolean marks pre-2018 legacy-layout records, so early and current vintages sit in one panel without guessing which schema you are reading.

Eleven fixed columns carry identity, placement and the failure label; a wildcard pair carries telemetry - one column per SMART attribute ID the drive reports, in raw and normalized variants. Because different models report different attribute sets, the telemetry zone breathes with the fleet. Definitions below are verified against the documented headers, with examples pulled from actual rows. Anything beyond these columns - model-level rollups, placement hierarchies, reshapes - is derived from these same rows and confirmed on request before delivery.

Geography - an operational fleet, not a geographic sample: every drive lives in a Backblaze data center, US sites alongside international ones such as the Amsterdam facility (ams5), with the mix skewed toward high-capacity enterprise and NAS drives. That bias is a feature for reliability work - the fleet resembles what a serious storage buyer deploys, not a random drawer of leftover disks.

Temporal - April 2013 through the most recent completed quarter (Q1 2026 at verification), thirteen years of unbroken daily snapshots. Early vintages are effectively HDD-only; SSD representation becomes meaningful only in later years, so solid-state claims need late-vintage windows.

Granularity - one row per drive per day, carrying every SMART attribute that drive reports. Column sets shift as models rotate through the fleet, and two documented schema layouts (pre-2018 legacy and current) span the entire timeline.

API, files, or your warehouse. Daily, weekly, or hourly.

Samples precede any commitment, and recurring deliveries land keyed on serial number and date so each pull joins cleanly to the last - and to whatever else you already hold. Vintage-to-vintage schema drift gets normalized away before anything ships.

• Survival analysis and failure modeling - a failure flag plus per-drive exposure days turns half a billion drive-days into hazard curves and time-to-failure distributions at per-model resolution; rare-event statistics need exactly this much runway.
• Procurement benchmarking - buyers compare annualized failure rate by model, capacity and vintage before signing purchase orders, replacing anecdotes and vendor datasheets with observed fleet behavior.
• Predictive-maintenance ML - SMART counters as features, the next-day failure flag as a label; the class imbalance is brutal and honest, which is precisely what makes trained models transfer.
• Capacity and lifecycle planning - watching which models and capacities exit service, and when, informs spares pools, warranty windows and replacement budgets years out.

Data scientists and ML engineers get a labeled reliability panel with a decade of history behind every feature vector (data scientists view). Investors and quant researchers read replacement cycles and hardware demand straight off failure curves (investors view). Developers and builders get a schema-stable longitudinal corpus for stress-testing storage assumptions (developers view). Market researchers and consultants get procurement-grade observed behavior for storage market sizing (market researchers view).

Raw telemetry arrives messy in predictable ways: attribute sets differ by model and vintage, legacy and current layouts interleave, and a defensible failure rate means getting the exposure-time denominator right down to the individual drive-day. Datadory hands over the cleaned panel - one schema across all thirteen years, SMART attributes aligned, denominators correct - plus the derived folds when the analysis calls for them. Start with a sample scoped to your models and window; scale to recurring delivery once the joins prove out.

Other Systems Software catalog records bracket the hardware story. Endoflife Date Product Lifecycle Catalog pairs naturally here: failure curves tell you when drives die in practice, lifecycle dates tell you when vendor support disappears in principle. Steam Hardware & Software Survey covers consumer hardware mix rather than data-center fleets. GitHub Octoverse & REST/GraphQL API measures what gets built on the software side of the same infrastructure. For a packaging-world contrast, see the head-to-head with Repology Packaging Hub.