Tutorials Developer

Storage Tiers and Archive Strategy for Media Teams

Intermediate · ~20 min

Overview

Media storage costs are dominated by two decisions: how many copies of the high-resolution material exist, and how much of it sits on expensive fast storage. Get those right and a large archive is affordable. Get them wrong and cost scales with volume until someone starts deleting masters. This guide covers how tiering actually works, what proxies do to the economics, and the distinction between redundancy and backup that catches teams out at the worst possible moment.

What You Need

An honest inventory of what you are storing and how large it is
Access-frequency data, or at least a reasonable guess
A stated retention policy: how long things are kept, and why
A budget you can actually check the plan against
Somewhere off-site, whether that is cloud or physical media
A restore test scheduled, not merely intended

Steps

Separate masters from working files from derivatives

These three have completely different requirements. Masters are irreplaceable and rarely touched. Working files are large, actively used, and reproducible from masters. Derivatives (proxies, thumbnails, delivery renditions) are cheap to regenerate. Treating all three the same is the root cause of most storage overspend.

Put the working set on fast storage and nothing else

Fast storage should hold what people are actively touching: current projects and their proxies. Everything else can live somewhere slower. The most common mistake is leaving completed projects on production storage indefinitely because nobody owns the decision to move them, which is a policy problem rather than a technical one.

Use proxies to shrink the working set

A low-resolution proxy is a fraction of the size of its master, so a team can browse, log, and rough-cut against proxies while masters sit on cheaper storage entirely. This is the single largest cost lever available in a media archive, and it improves responsiveness at the same time.

Tier by access frequency, not by age alone

Age is a convenient proxy for likely access and a poor one on its own. A three-year-old asset requested monthly should not be in cold storage, and a two-week-old one nobody has opened since delivery probably should. Where your system can track access, use it. Where it cannot, age plus project status is the fallback.

Understand what cold storage actually costs

The cheapest cloud tiers are cheap to store and expensive to retrieve, sometimes with minimum retention periods and per-request retrieval fees. That is correct for material you genuinely will not touch, and a trap for anything you might. Model a realistic restore, including a bad case where you need a lot back at once, before committing.

Test a restore, on a schedule

An untested backup is a belief. Pick a random asset, restore it from your archive, and verify it opens and matches its checksum. Do this on a schedule rather than when you finally need it. Silent corruption and misconfigured retention are both discovered this way or not at all.

Pro Tips

RAID is availability, not backup. It protects against a drive failing, not against deletion, corruption, ransomware, or fire.
Checksum on ingest and verify on restore. Without it you cannot distinguish a good copy from a rotted one.
Derivatives should be deletable without anxiety. If regenerating them is painful, that is a pipeline problem worth fixing.
Write down the retention policy. Storage grows without limit precisely where nobody decided when things expire.
Keep at least one copy off-site and one offline. The threats that take out a site take out everything connected to it.

Knowledge Base

What You'll Learn

Storage strategy is mostly about matching cost to how likely something is to be needed. Below: the redundancy-versus-backup distinction that teams learn the hard way, and how proxies change the economics.

RAID Is Not a Backup, and the Difference Matters

This is the most consequential misunderstanding in media storage, and it is usually discovered during an incident.

RAID provides availability. It keeps a volume online when a drive fails, which is genuinely valuable. A production does not stop. That is the entire scope of what it does.

RAID does not protect against accidental deletion, because the deletion is faithfully replicated across every drive. Nor against file corruption, ransomware, a failed controller writing garbage, theft, fire, flood, or someone reformatting the wrong volume. In every one of those cases the redundancy is irrelevant because all copies are affected simultaneously.

A backup is a separate copy, at a separate point in time, in a separate place. The conventional formulation is three copies of the data, on two different kinds of media, with one off-site, and increasingly one offline, because ransomware follows network connections.

The practical test: if the building were gone tomorrow, what would you still have? If the answer is nothing, you have redundancy and no backup, regardless of how many drives are in the array.

How Proxies Change the Economics

Proxies are usually introduced for performance, editors can cut smoothly on modest hardware, and their larger effect is on storage cost.

A media team's day-to-day activity is overwhelmingly browsing, searching, logging, reviewing, and rough-cutting. None of that requires full-resolution material. If proxies are generated at ingest, the entire working set that needs to be fast and always-available becomes a small fraction of the total archive size.

That means masters can live on bulk or cold storage from the moment they arrive, being pulled only for finishing and delivery. The expensive tier is then sized against the proxy library rather than the master library. A difference that compounds substantially as an archive grows.

The requirement this creates is that the link between proxy and master must be reliable and automatic. Systems where relinking is manual and error-prone push teams back toward keeping everything online, which is exactly the expensive behaviour the proxies were meant to prevent.

Where This Fits

This guide covers one specific part of media asset management. The wider picture, metadata schemas, naming conventions, proxies and storage tiers, governance, and avoiding vendor lock-in, is in Media Asset Management (MAM) Explained, which frames the discipline as a whole and links out to the detailed guides underneath it, including this one. If you are starting from scratch rather than solving a specific problem, read that first and come back here.

FAQ

Q: Is RAID enough to protect my footage?
A: No. RAID keeps a volume online when a drive fails, which is availability rather than backup. It replicates deletions and corruption faithfully across every drive and offers nothing against theft, fire, or ransomware. You need separate copies in separate places, with at least one off-site and ideally one offline.

Q: How many copies of my archive do I need?
A: The common baseline is three copies on two different kinds of media with one off-site. For irreplaceable masters that is a floor rather than a target, and adding an offline copy is increasingly recommended because ransomware propagates along network connections to anything writable.

Q: When should I move material to cold storage?
A: When you are confident you will rarely retrieve it, and after modelling the retrieval cost. The cheapest tiers charge meaningfully for restores and sometimes impose minimum retention periods. Tier by access frequency where you can measure it rather than by age alone, since old-but-active assets are common.

Q: Do I need to keep the original camera files?
A: Keep the masters. Derivatives and mezzanine copies are regenerable. A source is not. Teams that delete originals to save storage almost always encounter a later requirement (a higher-quality reversion, a different aspect ratio, a rights audit) that only the original can satisfy.