800 TB media archive with twenty editors and a five-year retention order
A provincial broadcaster holds 800 TB of interview and programme footage. Twenty editors in two offices must open and write to the same project folders from Windows workstations; editing 4K proxies across the internet is unusable today. Finished programmes must be kept five years for regulatory audit, and about 5% of archived items are re-requested each year, usually on a 48-hour deadline. The NAS is out of capacity and the refresh budget covers only one year of growth, around 150 TB. Legal requires that deleted footage stay recoverable for 30 days and that no one, including the storage administrator, can silently alter archived masters.
1. Map the three workloads (editing collaboration, finished masters, local render scratch) onto EVS, SFS and OBS, and justify each choice against the constraints.
Read the worked answer
Three different access patterns, three different services.
- Shared project editing → SFS Turbo. Twenty editors need concurrent read/write on the same directories over SMB/NFS with predictable throughput on large sequential files. EVS is block storage attached to a single server (shared SCSI disks exist but are for cluster filesystems, not Windows desktops) and would force you to build and operate a file server. SFS Turbo scales capacity and bandwidth upward with the purchased tier, which is what 4K proxy scrubbing needs; classic capacity-oriented SFS is cheaper per GB but is the wrong latency class here.
- Finished programme masters → OBS. Object storage is the only one of the three that scales past 800 TB without provisioning, and it carries lifecycle, versioning and retention features that legal has explicitly asked for.
- Render scratch / local cache → EVS. Temporary high-IOPS block volumes attached to render nodes, deleted with the job. Do not let scratch volumes grow into a permanent tier.
The judgement is that SFS Turbo holds the working set, not the archive: keeping 800 TB on SFS to preserve "one namespace" would cost far more than the OBS tiering it avoids.
2. Legal's two requirements conflict with the cost target. Design the lifecycle and protection policy and quantify the risk you are taking.
Read the worked answer
Retention is cheap; retrieval latency and immutability are where the money and the risk sit.
- Immutability: enable OBS WORM retention on the masters bucket for five years, plus versioning. Object Lock stops even an administrator from overwriting or deleting a retained object, which is the only way to satisfy "nobody can silently alter masters" with a human admin in the loop. Enable versioning on the production bucket so accidental overwrites become recoverable versions, and set a 30-day noncurrent-version retention so "deleted" footage survives the legal window without keeping every version forever.
- Tiering: keep months 0–12 in Standard or Infrequent Access, transition to Archive from month 12, and consider Deep Archive only for material older than roughly three years. The driver is that 5% of 800 TB - about 40 TB - is re-requested annually on a 48-hour clock. Archive and Deep Archive charge for retrieval and take hours to restore, so a policy that archives everything on day 31 would meet the storage target but miss the 48-hour editorial promise and add retrieval fees on 40 TB per year.
- Second copy: although the question does not demand it, a five-year regulatory obligation on a single bucket is a single point of loss. Cross-region replication to a second bucket, with the same retention policy, is the cheap half of a 3-2-1 posture.
State the trade-off explicitly to legal: Deep Archive for recent material is incompatible with the 48-hour SLA, and the cost model must include restore fees, not just storage per GB.
3. The finance team asks why not simply archive everything on day one, since archive is the cheapest tier. How do you answer?
Read the worked answer
Run the numbers on the access pattern rather than quoting tier prices.
Archiving on day one minimises the storage line and breaks two things: re-requested items are unavailable for hours (against the 48-hour editorial commitment), and every restore is billable per GB plus a retrieval request charge, so 40 TB of annual restores lands as an unbudgeted operating cost that recurs every year. A tier is cheaper per GB-month only if the object is not read; the true cost per object is storage plus retrieval plus the people waiting.
The defensible policy is a function of the re-request curve: items are overwhelmingly requested within twelve months of archive, so hold that window in a fast tier and let the long tail go cold. Then measure - enable access logging on the bucket and review the transition boundaries after two quarters. If the re-request rate for 12–24 month material turns out to be 0.2% rather than 5%, move the boundary earlier; if it is 20%, move it later. The lifecycle rule is a hypothesis, and OBS lifecycle configuration is cheap to change.