Media, Codecs, and the Backup Workflow That Does Not Lose a Day

A card gets corrupted, a drive dies, or a checksum comes back mismatched three weeks after wrap. That is not a hypothetical on this scale of production, it is a Tuesday. The question that actually matters is not whether it can happen. It is what was recorded, what it was backed up onto, and who signed up in writing to be the person who checks.

This is a working procedure, not a case for why backups matter. It covers three decisions that get made before the day starts and rarely get revisited once it does: what codec to actually record in-camera, what RAID level the vault runs on, and who owns the risk on paper if the footage is gone.

What You Actually Record: The Codec Decision

Codec choice is not a technical afterthought the DP defaults to out of habit. It is a budget decision with a storage tax and a post-production tax attached, and the right answer changes by job.

There are four practical tiers. RAW, meaning ARRIRAW or REDCODE RAW, captures the most information and gives a colorist the most room to push exposure and white balance after the fact, because nothing has been baked in yet. A high-quality intermediate, ProRes 4444 or DNxHR 444, keeps that same latitude for VFX and greenscreen work while cutting the file size and skipping the RAW debayer step in the edit. A mezzanine codec, ProRes 422 HQ or DNxHR HQ, is the workhorse tier most commercial and corporate work should default to: full broadcast-grade color depth at a fraction of RAW's footprint. A proxy-only H.264 or H.265 mirror is the lightest option and belongs only on b-roll or archival material where original quality is not the point.

The storage and workflow tax between these tiers is real, not marginal. Apple's own published data rates at 1080p put ProRes 4444 at roughly 330 Mbps, ProRes 422 HQ at roughly 220 Mbps, standard ProRes 422 at roughly 147 Mbps, and ProRes Proxy at roughly 45 Mbps, a spread of more than 7 to 1 between the top and bottom tier before resolution even scales it up further. The REDCODE HQ, MQ, and LQ tiers on a V-Raptor tell the same story from the RAW side, landing at roughly 3:1, 5:1, and 8:1 compression in published tests, with the exact ratio shifting by resolution and frame rate. In one published V-Raptor review, a single 512GB CFexpress card held about 29 minutes of recording time at 8K Medium Quality versus more than four times that at ProRes 422. That is not a rounding error on a full shoot day. It is the difference between packing four cards or one.

RAW is worth the tax when the deliverable justifies it: a hero broadcast spot with heavy VFX compositing, a greenscreen shoot where the key has to survive multiple revisions, a campaign asset the client will re-cut and re-grade for a year. It is a waste of money and time on a single-day corporate interview, a testimonial package, or any job with a same-week turnaround and a post budget that cannot absorb a RAW debayer pass. The mezzanine tier, ProRes 422 HQ or DNxHR HQ, is the right default for the large middle of commercial work: it gives an editor and colorist real room to work without doubling the storage kit or slowing down the post-production workflow your editor wishes you understood. Decide the tier at the prep day, tied to the deliverable and the post budget, not on set based on what feels safest in the moment.

RAID at the Vault: What Actually Protects Storage After Wrap

Once footage clears the card, it lands on office or vault storage, and that storage runs on some RAID level whether anyone chose it deliberately or not. The five levels that matter are not interchangeable, and the differences are not cosmetic.

RAID 0 stripes data across drives with zero redundancy. It is fast and it is disposable: one drive failure loses everything on the array. It has a legitimate use as scratch or proxy-render storage where the source files live safely elsewhere, and no legitimate use as a home for masters.

RAID 1 mirrors data across two drives. Usable capacity is half the raw total, but the array survives one drive failure cleanly, which makes it a reasonable, simple choice for a small edit bay or a two-drive backup pair.

RAID 5 stripes data with a single parity drive, giving N minus one drives of usable capacity across an N-drive array and surviving one drive failure. It has been the standard on small post setups for years, and it still works on smaller, older drives. The problem is what has happened to drive capacity since RAID 5 became the default. Rebuilding a failed drive means reading every bit on every surviving drive, and consumer hard drives carry a rated unrecoverable read error, or URE, of roughly one error per 10^14 bits read. On a 10TB drive, reading the full surface during a rebuild carries close to a 55 percent chance of hitting one of those errors, and a 16TB drive can take 20 to 48 hours to rebuild depending on controller speed and array load. NAS and enterprise drives at these sizes are usually rated tenfold better, near one error per 10^15 bits, which drops the same math to under 10 percent, but the conservative number is the one to plan around because the array does not know which drive class it was sold with. RAID 5 runs completely unprotected for that entire window: if a second error shows up anywhere on the remaining drives before the rebuild finishes, the rebuild fails and the array is gone.

RAID 6 fixes exactly that gap with a second parity drive, giving N minus two usable drives but surviving two drive failures, or one failure plus one read error during rebuild, at the same time. It is the level general storage guidance now recommends for any HDD array built on drives larger than roughly 8TB, which by 2026 is effectively every array a production company would buy today. RAID 10, which mirrors pairs of drives and then stripes across the mirrored pairs, gives up half the raw capacity like RAID 1 but rebuilds faster than either parity level, because reconstructing a mirror only means copying from its surviving partner rather than recomputing parity from every other drive in the array. It also holds up better under heavy simultaneous read and write, which matters if editors are cutting directly off the vault rather than off local proxies.

For a small-to-midsize production company's dailies and vault storage, the practical recommendation is RAID 6 as the default on today's high-capacity drives, with RAID 10 worth the extra drive cost specifically when the array is also serving live editorial traffic and not just archiving finished projects. RAID 5 stays defensible only on smaller arrays running drives under roughly 8TB, which is a shrinking category. None of this replaces the offsite leg of a real backup discipline; RAID protects against a drive dying, not against a fire, a theft, or someone deleting the wrong folder, which is exactly why it is one piece of a 3-2-1 backup plan and not a substitute for it. A company that owns and runs this infrastructure in-house, rather than improvising it job by job, is making the same kind of investment as building an equipment package it can bring to every job instead of renting from scratch each time.

Who Owns Dailies Risk

This is the part that rarely gets written down, and it is the part that actually determines what happens on the bad day.

Most production paperwork simply does not address it. A standard video production agreement template will typically cap the production company's overall liability at the total fees paid and exclude indirect or consequential damages, but that generic language does not say anything specific about who is responsible when footage itself, as opposed to money or equipment, is lost or corrupted. The gap is not an oversight in any one contract; it is the industry default. Ownership of dailies risk is treated as obvious until the day it is not, and on that day everyone has a different memory of who was supposed to check.

The honest allocation looks like this. If no dedicated DIT was hired, the DP or camera operator owns the offload and verification by default, whether or not anyone said so out loud, because they are the last person to touch the card before it either gets copied or gets formatted. If a dedicated DIT was hired, responsibility for verified backup should sit with them explicitly, but only becomes real obligation if the crew deal memo actually says so; a DIT credited on a call sheet with no written scope may have agreed to very little that is enforceable, and nothing that is clear. The production company carries the risk regardless of who technically failed to check a checksum, because the client relationship, the reshoot cost, and the reputational hit all land on the company's desk first. The client or agency is almost never the party at fault technically, but a client that cuts the DIT line item or compresses the schedule to save money is a client that increased the risk, and that choice deserves to be documented, not absorbed silently.

The fix is not more insurance and it is not a longer boilerplate paragraph. It is naming one person, by name, as the backup verification owner for that specific day, before the day starts, in a place everyone already reads. Three places do this cheaply. On the call sheet, a single line naming who owns data backup and confirming verification before wrap turns an assumption into a fact everyone on set saw the same morning. In a crew deal memo for a hired DIT, explicit language assigning backup-verification responsibility, and stating what happens if it is not met, converts a job title into an actual obligation. In the production services agreement with the client, the clause to ask counsel for is one that states the production's backup protocol plainly, caps the production company's liability for footage loss to a defined figure absent gross negligence, and requires the client's written sign-off if they choose to cut the DIT or backup budget line. Drafted well, it moves the risk to whoever actually made that decision instead of leaving it to be argued after the fact. This is general information, not legal advice; have an attorney review any liability language before it goes into a contract.

None of this is expensive to write. It is a sentence on a call sheet, a paragraph in a deal memo, a clause in an agreement the production company already sends out on every job. The alternative is arguing about who should have checked the checksum after the footage is already gone, which costs far more than the sentence would have, in money, in time, and in a client relationship that does not usually survive the argument even when the production company wins it.

Set It Before the Day Starts

Codec, storage tier, and named ownership are three decisions, and all three are cheap to make in advance and expensive to improvise under pressure. Pick the codec against the deliverable and the post budget at the prep day, not on set. Run the vault on a RAID level that matches the drives actually in it, not whatever was standard a decade ago. And put one name on the backup-verification line before the card goes in the camera, so a lost day never turns into a lost argument on top of it.