Storage Building Blocks

Brief

At Halcyon Clinics, a scheduling database, a shared imaging folder, and an export archive all appear on one inventory as 'cloud disks'. During a storage outage, the archive retains every byte but cannot serve requests. The operations lead declares that the archive's eleven durability nines should have prevented the outage. Meanwhile, a shared export link exposes patient records without anyone stealing a password.

Your job is to separate interface, resilience, recovery, and access. A disk-like volume is not a shared folder; a surviving replica is not necessarily a clean historical copy; and encryption does not stop an authorised anonymous download. For each dataset, identify how applications use it, how much interruption and data loss the business tolerates, and which policy exports and restore tests prove those limits are met.

Ask four separate questions: how is data addressed, will it survive, can it be reached, and can a known-good state be restored?

Blocks, paths, and keys are different contracts

Block storage exposes numbered fixed-size units to a host. The host typically builds a filesystem on the volume; a database can update small pages without uploading an entire dataset. A 16 KiB database page may span four 4 KiB blocks. Attaching the same writable volume to two ordinary filesystems without cluster coordination risks corruption; a volume is not automatically a safe shared drive.

File storage exposes directories and filenames through a shared filesystem protocol. Multiple clients can open paths such as /imaging/visit-104/scan.dat, with permissions and locking defined by the service and protocol. Object storage instead addresses a complete object by a key, metadata, and sometimes a version identifier through an API. A slash in an object key usually creates a listing prefix, not a true directory. Ordinary object updates replace the object rather than modifying a disk sector; rename may require copy followed by delete.

Choose blocks for page-oriented database workloads, files for applications that require shared path and locking semantics, and objects for exports or large immutable media. For change-management evidence, keep the workload requirements and selected interface in the architecture record. An auditor should be able to ask why two writers cannot corrupt the database and receive an attachment or locking design, not merely a capacity screenshot.

Nines measure different failures

Durability concerns retaining data over a stated period; availability concerns successfully accessing the service under a defined measurement. A design target of 99.999999999% annual object durability does not promise eleven nines of uptime or that a particular object cannot be lost. Read the metric's unit, assumptions, exclusions, and population. A 99.9% time-based availability objective permits about 43.2 minutes unavailable in a 30-day month: 43,200 minutes multiplied by 0.001. At 99.99%, the same budget is 4.32 minutes. Request-based objectives instead count failed requests and cannot be converted directly into downtime.

Replication places copies in separate failure domains. Synchronous acknowledgement can wait for multiple copies, increasing write latency while reducing the acknowledged-write loss window. Asynchronous replication returns sooner but leaves a lag: if the remote copy is 90 seconds behind, losing the source can lose those recent writes. A second copy in the same failure domain does not survive that domain's destruction. Regional replication also requires residency approval and a tested route to the surviving copy; bytes existing elsewhere do not guarantee a usable application.

For continuity controls, document the recovery point objective (RPO: tolerable lost changes) and recovery time objective (RTO: tolerable restoration delay). Keep lag measurements, failure-domain topology, and timed failover results alongside the service commitment. The audit question is whether measured loss and interruption fit business requirements, not how many nines appear in marketing language.

A replica is not a clean recovery point

Replication can faithfully copy an accidental overwrite or malicious deletion. Versioning retains earlier object states; a delete may create a marker hiding the current view rather than removing every historical version. Recovery must locate the right version and restore or promote it. Versioning is not immutability: an identity with version-deletion privileges may still destroy the history unless a separately enforced retention control prevents it.

Snapshots capture a volume or filesystem state at a point in time, often by recording changed blocks relative to earlier data. A live snapshot may be crash-consistent, like recovering after power loss, rather than application-consistent. Quiesce writes or coordinate database checkpoints when required. A snapshot every six hours can lose nearly six hours of changes without additional logging. Verify dependencies and restore an isolated copy; a successful snapshot job alone does not prove a database will start or transactions reconcile.

Lifecycle rules transition or expire data based on age and scope. For example, move current exports to a colder tier at day 30 and expire at day 365 only if policy allows. Configure historical-version expiry separately: hiding the current key is not erasure of every version. Colder tiers can add retrieval delay and cost, so test them against RTO. Retention holds must override deletion where required. Evidence should include current and historical-version rules, hold status, and restored-file or database validation results with timestamps.

Private objects require effective access tests

Object access can depend on identity permissions, container policies, object-level grants, public-access guardrails, and explicit denials. Evaluate the combined rules for a specific principal, action, and resource; a private label on one screen is not proof. A public read grant can expose a patient export even when it is encrypted at rest. Separate list, read, write, delete, and historical-version permissions, and scope the export-reader identity to the required prefix rather than the whole container.

A time-limited signed URL delegates access to anyone possessing the URL until its validity ends or another enforced condition blocks it. It is not equivalent to requiring the recipient to sign in. Keep expiry short, prevent links from leaking through logs, and verify the exact operation and object authorised. Where public access is prohibited, enforce blocking controls and test an unsigned, unauthenticated read; do not treat an authenticated administrator's successful download as a privacy test.

For confidentiality and least-privilege evidence, preserve dated policy exports, principal inventories, access-decision logs, and positive and negative test results. A useful audit sample shows that the approved reader can fetch one permitted export, cannot fetch a neighbouring prefix, and an anonymous caller cannot fetch either. Add a historical-version test so recovery copies do not silently bypass the current object's access boundary.

Answers are graded on the server: the answer key never reaches your browser.