Hot, Warm, and Cold Storage Tiers

Start with the access contract. Decide whether reads must complete immediately or may wait for a restore operation, how often objects are read or changed, and how much data must be retrieved during a recovery. Hot, warm and cold are relative labels for that placement decision, not a universal ladder of SSD, HDD and tape.

An instructive example is the 2014 f4 paper: both the hot Haystack system and warm f4 system used SATA HDDs. Their different layouts, redundancy and workload assignments created the tiers. The proposed age-based cutoff in section 3 was not the deployed policy: section 6.2, footnote 4, reports an approximately three-month migration age for simplicity. These observations concern immutable blobs, not every storage workload. [13]

Capacity savings also depend on retained deleted data. For an illustrative 65 PB, evaluating f4's printed equation without early rounding gives 38.72 PB at factor 2.8 and 87.54 PB at 2.1. Substituting the paper's rounded multiplier 1.07 gives 39.26 and 87.945 PB instead. Neither reproduces its printed 30/68-PB pair. The actual corpus exceeded 65 PB, so these substitutions do not refute its prose or reconstruct its mixed deployment. The linked audit includes code and exact fractions. [13] [18]

Cold does not necessarily mean offline. Azure Blob Storage documents Hot, Cool and Cold as online tiers; Archive requires rehydration before payload access. These are named block-blob service contracts, not definitions of all cold storage. Some metadata operations remain available while the payload is archived. [14]

Archive labels also need qualification. In S3 Intelligent-Tiering, Archive Instant Access serves reads directly. The optional Archive Access and Deep Archive Access tiers require a RestoreObject request and a wait until the object returns to Frequent Access before payload reads. Request acceptance is not restore completion. [15] [17]

The S3 Glacier Flexible Retrieval and Deep Archive storage classes use a different restoration model: a temporary readable copy is made, and the storage class does not change. Its expiry is calculated from restore completion plus the requested number of days, rounded up to the next midnight UTC. Intelligent-Tiering restoration does not accept a Days parameter. Record which model applies before planning a recovery window. [17]

Separate financial duration from preservation policy; the corpus defines minimum storage duration and minimum billable object size independently. [5] [6] Early-deletion charges can apply when an object leaves a tier before its minimum billable duration; they do not themselves prevent a delete. Specify retention locks, independent recovery copies and access controls separately from temperature. [14]

Billing minimums are service-specific. Google Cloud Storage documents 30/90/365 days for Nearline/Coldline/Archive, while all its classes provide online retrieval. Its Lifecycle class changes and Autoclass have early-deletion exceptions. S3 Lifecycle can instead incur the remaining minimum charge when leaving a class early. Neither a billing period nor an archive label proves a read delay or a deletion lock. [11] [10] [9]

Object-size rules need separate accounting. S3 Standard-IA has a 128 KB per-object billing floor; Flexible Retrieval and Deep Archive instead add 40 KB of metadata at two rates. Neither rule enlarges the payload. Lifecycle transition eligibility is another constraint, not the billing floor. [8] [9]

A deliberately hypothetical example uses a 128 KiB size floor and 30-day duration floor. Ten 16 KiB objects removed after five days produce 38,400 KiB-days of modeled billable quantity versus 800 KiB-days of payload residence: 48 times the payload byte-time. One 160 KiB object with the same lifetime gives 4,800 KiB-days, or six times its payload residence. These are byte-time quantities, not money or a provider invoice. The model excludes metadata, request, retrieval and transfer costs, exemptions and version retention; bundling also changes read and update granularity. Code and executable tests accompany the example. [12] [7]

Pergamum's design uses cached algebraic signatures to check inter-disk consistency while drives are spun down. Full scrubbing instead reads disk blocks against stored signatures. Cached agreement cannot reveal unread payload changes: an inference from the mechanism. Section 5.3 says the evaluated prototype omitted scrubbing and consistency checking. Its reliability estimates are simulations, not field observations; annual scrubbing is not a general recommendation. Spun-down disks are not inherently air-gapped. [16]

Algebraic signatures preserve selected linear relationships between data and parity, but are not cryptographic signatures. The basic consistency protocol in Schwarz and Miller's paper allows cooperating sites to invent a consistent response; the authors add secret-dependent coding and blinding for that threat. Do not attribute the larger protocol's protection to the checksum alone. [1] [2]

A small worked example makes the collision boundary inspectable: four GF(16) symbols map to a two-symbol signature, giving 65,536 inputs, 256 signatures and 256 inputs per signature. The difference [2,3,1,0] preserves both evaluations. Extending the same construction to 16 input symbols also admits two-symbol collisions: equal changes at positions 0 and 15 cancel. The supplement enumerates the boundary and shows why retaining separate page signatures differs from XORing them together. This is not the Pergamum implementation or a storage error-rate estimate. Derivation, code and tests are linked. [3] [4]

Pelican shows another constraint: only 96 of its 1,152 drives can spin concurrently under the cooling budget. That rack-wide limit is insufficient by itself: each cooling domain permits one drive and each power domain two, counting both spinning and spinning-up drives. Placement and scheduling must respect the overlapping domains. This is the 2014 prototype design, not a universal archive configuration. [19]

A six-drive worked example makes the distinction concrete. With two power domains and three cooling domains, a total budget of three accepts 42 of 64 subsets; checking each domain accepts only 25. Two disks sharing one cooling domain already conflict despite fitting the total budget. All subsets and the code are downloadable. These are exhaustive synthetic counts, not a measured failure rate, a Pelican replication or a hardware safety certification. [20]

For an engineering evaluation, measure the request distribution and total bytes retrieved, including rare bulk restores. Record first-byte latency, completion time, available parallelism and migration behavior under load. Include request, retrieval, transition, temporary-copy and transfer costs where applicable. This is a decision checklist, not a benchmark or a claim that one tier is universally cheapest.