Proxy Workflows and Data Management: Why Footage Needs a System

The one asset you cannot recreate

You can re-light a scene. You can recast a role, rebook a location, rent a second camera, or add a day to the schedule. All of those cost money, but they are recoverable. What you cannot do is reshoot a moment that already happened: the founder who flew in from out of state for a two-hour window, the practical stunt that only worked once, the golden-hour light that was the whole reason you were there. Footage is the only asset on a production that has no cheap replacement, because the conditions that produced it are already gone.

And the ways footage gets lost are almost never dramatic. Nobody drops the drive in a lake. What actually happens is boring: a card gets formatted before anyone confirmed the backup finished, a single drive fails three weeks later with the only copy on it, a folder full of unlabeled clips turns up a year later and nobody can tell which reel is which. Data management is the least glamorous part of the job, and it is the exact line between delivering the project and writing the apology email. This is a systems problem, and the fix is a system.

Offload before you format: the on-set discipline

The camera card is the single most dangerous place footage can live. It is fast, it is small, and it is one accidental format away from empty. The entire job of on-set data management is to move footage off that card into a safer state as quickly as possible, and to prove the copy is good before anyone reuses the card.

On a larger production this is the digital imaging technician's whole reason for being on set. The DIT pulls each card, offloads it to at least two destinations, and verifies the copy with a checksum before the card goes back to the camera team clear to format. On a smaller run-and-gun job there is no DIT and the shooter owns the offload, but the discipline does not change. The rule that has never once let anyone down: two copies, verified, before the format button.

The word that matters there is verified. Dragging files across in the Finder tells you the copy finished, not that it is correct. A dedicated offload tool such as Hedge, Silverstack, Shot Put Pro, or the free Offload app reads every byte of the source and every byte of the destination and confirms they match with a checksum (MD5 or the faster xxHash). That verification is the difference between a copy you can trust and a copy you are hoping is fine. Cards fail mid-write, cables drop, and a truncated file looks perfectly normal in a folder listing until an editor tries to open it in month two.

Practical habits that ride on top of that: label your cards and keep a simple reel log so you know what has been offloaded and what has not, keep offloaded cards in a separate pouch from empty ones, and never trust a single card reader on a long day. CFexpress, SD UHS-II, and camera-mounted SSDs all die the same way, and the format button does not care how expensive the day was.

The 3-2-1 rule, translated to a set

Once footage is off the card, one copy is not safety. It is a single point of failure that happens to be off the camera. The backup standard the whole industry converged on is the 3-2-1 rule, and it is worth stating plainly because most people can recite it and fewer actually run it: three copies of the footage, on two different types of media, with one copy kept offsite.

Three copies means the camera originals plus two independent backups, not one file you have been careful with. Two media types is the part people skip: if all three copies live on identical drives from the same box, a bad batch can fail all of them the same way at the same time. Split it across an SSD and a spinning RAID, or a drive and cloud object storage, so no single failure mode takes everything. And one copy offsite is the rule that quietly saves entire projects, because fire, flood, theft, and a burst pipe all take everything in one room regardless of how many drives are in it.

In production terms that usually looks like a working SSD you cut from, a backup RAID or second drive that stays at the office, and a cloud or LTO copy in a different building entirely. Cloud archive is cheaper than most people assume: object storage like Backblaze B2 runs roughly six dollars per terabyte per month, which is trivial next to the cost of a reshoot that cannot happen. The offsite copy is the one nobody wants to wait on, and it is the one you will be grateful for the day a drive walks out of a car window in a parking lot.

Proxies: why you never cut the camera original

Camera originals are heavy on purpose. ARRIRAW runs close to a terabyte an hour. REDCODE and the high-end ProRes flavors are not far behind. You do not edit on those files, and not because your machine cannot open them. You avoid it because dragging multi-gigabyte-per-minute media across a timeline is slow, it chains the editor to the one machine the originals live on, and every scrub is hammering the drives that hold your only high-value copies.

The answer is proxies: lightweight stand-in files, ProRes Proxy or a light H.264 or DNxHR LB, generated from the camera originals and carrying the same filenames and timecode so they relink cleanly later. The editor cuts on proxies, which are small enough to live on a laptop and travel on a fast SSD, so the work happens anywhere while the originals stay locked on the vault. Many cameras will even record a matching H.264 mirror alongside the RAW file in-camera, which skips the proxy-generation step entirely and hands editorial something usable the moment the card is offloaded.

When the cut locks, you relink the timeline back to the camera originals and finish there. That final pass, color, cleanup, mastering, is the online, and it is the only stage that touches the heavy files. The whole point of the proxy workflow is to keep the expensive, fragile originals sitting still while the editing happens on cheap, portable copies you would not cry over losing. Editorial gets speed, the originals get left alone, and the two only meet again at finishing.

Naming and folders: do not build an archaeology dig

The second way footage dies is not deletion. It is disorganization so complete that finding a specific shot becomes an excavation. A drive full of camera-default folders, DCIM directories named by nothing but a counter, no dates, no reel numbers, no project name, is not an archive. It is a landfill you happen to own, and the cost of it comes due the day a client asks for an alternate take from a shoot that wrapped eight months ago.

The fix is a naming and folder convention you decide once and never improvise on set. A date-based top folder, camera and reel subfolders under it, consistent card and clip names, and a short ingest template you reuse every single job. Log your scenes and takes as you offload rather than promising to sort it later, because later never has the context that the shoot day had. The concrete test for whether your system works: can someone who was not on set find one specific shot in under two minutes, a year from now, without calling you? If the answer is no, the problem is the structure, not the search.

This is the least technical discipline in the entire pipeline and the one that pays off longest. Storage is cheap and getting cheaper. The hours a poorly organized archive costs you, and the alternate takes you cannot deliver because you cannot find them, are not.

Sizing the drive kit before the truck rolls

All of this has a number attached to it, and you want that number before the shoot, not at wrap when the cards are full and the drives are not. Sizing storage is simple arithmetic once you know your codec's data rate. ProRes 422 HQ at 4K runs about six gigabytes a minute. Blackmagic RAW at reasonable compression is closer to two and a half. ARRIRAW is fifteen or more. Multiply your codec's per-minute rate by the minutes you actually expect to record, times the number of cameras, times the number of days, and you have your raw footage volume.

Then remember that the raw number is only one of the three copies the 3-2-1 rule requires, and that you need two verified copies on hand before you can format a single card on set. A two-camera day recording a couple of hours each on ProRes 422 HQ generates a few terabytes of originals, which means you are carrying enough drive capacity to hold two full copies of that to the location, plus a backup that stays behind, plus proxies on top. That is why a job that feels like a modest shoot can quietly need a ten-terabyte drive kit once you account for redundancy.

The interactive companion to this post does exactly this math. Pick a codec, set the camera count and shoot length, and it walks the footage from the card through the 3-2-1 backup, generates a proxy estimate, and gives you a drive kit you can actually pack. Run your worst-case day through it before you rent, because discovering you are one drive short happens at the least convenient possible moment.

The system is the deliverable

Footage is not yours until it exists in three places. Until then you are one dead drive or one early format away from a conversation no client forgives quickly. The productions that lose footage are almost never the unlucky ones. They are the ones that improvised the single part of the job that should never be improvised, treating the offload and the backup as something to figure out at the end of a long day instead of a fixed procedure that runs the same way every time.

Build the pipeline once. The offload with verification, the 3-2-1 copies, the proxy generation, the folder structure that a stranger could navigate. Run it identically on the smallest corporate interview and the largest commercial, so it becomes muscle memory rather than a nightly gamble. The gear gets the attention on set, but the system that protects what the gear captured is the part that actually determines whether the project ships. Treat data management as production infrastructure, not post-production cleanup, and the footage stops being the thing that keeps you up at night.