Good DIT data management comes down to one rule that fits on a label: a camera card is not formatted until two copies exist on two separate physical volumes and both have passed a checksum verification against the source. A copy that finished is not a copy that is correct. Progress bars measure how fast data moved, not whether it arrived intact. What follows is the operating procedure that turns that rule into something a crew can execute at hour fourteen of a shooting day.
What DIT data management actually covers
On a professional shoot, DIT data management is the discipline of moving camera media from cards to verified storage and proving that the movement was correct. On a smaller production the same work falls to a data wrangler or an assistant, but the task is identical: receive a card, copy it, verify it, record it, hold it, and release it.
The role is sometimes confused with color work, because a digital imaging technician on a large show may also handle look management and on-set grading. Those are separate duties. Data management is defined by three artifacts: verified destination folders, a checksum report, and a signed handoff record. When all three exist for every card, the data is defensible in an insurance claim.
It is worth stating what this process is not. Offloading to two drives on set is not a backup strategy by itself: drives fail, get dropped, get wiped by mistake, and travel in the same vehicle as the only other copy. The 3-2-1 backup rule still applies after the wrap.
The offload station: what must be true before the first card arrives
Most offload failures are set up in the first ten minutes of the day, long before a card appears.
Two destinations on two separate buses. Two drives in one enclosure are one point of failure unless it is a hardware RAID reporting its own health. Two partitions on one physical disk are not two copies, and two drives on a cheap hub share a controller. Pair a bus-powered SSD on one port with an external drive on a different controller.
A reader for every media type on the call sheet. CFexpress Type A, Type B, CFast 2.0, and SD UHS-II each need their own reader. Label each reader and cable, because forcing a Type A reader into a Type B slot is a known way to bend pins.
Power that survives the set. Laptop on mains with a UPS where possible, drives on their own power, and a machine that does not sleep, hibernate, or update during a copy.
A pre-built folder template. Project, shoot date, camera body, card identifier, and one folder per destination. Consistent naming is what makes a later search possible.
An offload utility that verifies. Hedge, ShotPut Pro, Silverstack, YoYotta, and OffShoot manage multi-destination copies and generate reports. A plain drag-and-drop in the operating system verifies nothing.
Step 1: Copy to two destinations, never one at a time
Run both destination copies in the same operation rather than copying to drive A and then to drive B later. Sequential copying is where “the second copy never happened” stories come from. When a utility writes to both destinations in one pass, the report covers both and the second copy cannot be quietly skipped at the end of a long day.
Two details matter. Never offload through the camera over USB on a working shoot: the camera can write to the card while connected, changing the source while you hash it, and camera USB throughput is often a fraction of a reader’s. And name destination folders with the card’s physical identifier, not just the camera’s, because cameras with dual card slots write two cards with overlapping content and a structure that records only the camera name will eventually collide.
| Copy method | What it protects against | What it does not |
|---|---|---|
| Drag and drop in the OS | Nothing; no log, no verification | Read errors, truncated files, silent write failures |
| Offload utility with checksum verification | Read errors, corrupt writes, truncated files | Physical loss of both drives later |
Step 2: Verify with checksums, not with a progress bar
A checksum is a fingerprint computed from a file’s bytes. The utility reads the data, computes a fingerprint, writes to the destination, reads it back, and computes again. If the values differ, the copy failed, even when file size and modification date look perfect.
The counterintuitive part is which side of the transfer you hash. Many workflows verify only the destination, which confirms that it matches whatever the source returned, not that the source returned the right bytes. A failing card can hand back damaged data consistently, and a destination-only check will certify that damaged data as a good copy. The stronger method hashes the source as it is read and the destination as it is written, so a bad read surfaces as a mismatch. A card that produces a mismatch should be pulled from the rotation and imaged once, following the practice described in our guide to imaging a card before any recovery attempt.
| Verification method | Collision resistance | Typical speed | When to use |
|---|---|---|---|
| File size and timestamp | None | Instant | Never, as a sole check |
| MD5 | Weak against tampering, fine for accidental corruption | 400–700 MB/s | Deliverable manifests, legacy post pipelines |
| SHA-256 | Strong | 250–500 MB/s | When a client or studio specifies it |
| xxHash64 | Good for accidental corruption | Multiple GB/s | Fast on-set verification of large cards |
| Byte-for-byte compare | Perfect | Disk-bound | Short clips and final QC spot checks |
Speed matters more than people expect. A 512 GB card over a USB 3.2 Gen 2 reader takes roughly 25 to 45 minutes to copy at realistic sustained speeds. Adding a second destination and a read-back verification can push one card past two hours, which is the real constraint on a busy day.
Step 3: Lock the source card read-only until the backups are confirmed
The moment a card is mounted read-write, the operating system starts writing to it: System Volume Information on Windows, .Spotlight-V100 and .DS_Store files on macOS, thumbnail caches, and sometimes a repair pass after an unclean removal. None of these harm the footage, but all of them change the card, so a re-verification later will not produce the same fingerprint.
Lock the card three ways. Use the physical write-protect tab on SD and microSD cards at the moment of offload. Mount read-only where the operating system allows it. Where it does not, set the read-only attribute on the volume, and prefer readers that present the card as a removable volume rather than mounting it through the camera. The same instinct applies at the end of the process: eject properly before pulling anything, as described in the guide to safe card removal.
Step 4: The second confirmation before a card is formatted
Formatting is the only irreversible action in the workflow, and it should never be a one-person decision made at the end of the day. Use a two-person release: the person who ran the offload states the card identifier aloud, and the second person reads the checksum report and confirms that both destinations show the same top-level hash and file count. Only then does the card return to the camera department for formatting, and the disposition is written into the log with both sets of initials. On features and commercials, many productions hold cards for 24 hours or until post confirms that dailies have been transcoded. The hold pile is physically separate from the return pile, and the DIT owns that boundary.
One technical fact changes how a mistake should be handled. A camera format is a quick format: the file-system table is rewritten, but the video data stays on the flash memory until new recordings overwrite it. A card formatted by mistake and immediately pulled from service is very often recoverable. A card that has since been shot on for a day is not.
Step 5: The handoff record
The handoff record is what turns a technical process into an auditable one, and it is what an insurer or a client will ask for when something goes wrong.
| Field | Example | Why it exists |
|---|---|---|
| Card identifier | A-CAM-03 / card 07 | Ties the physical media to the record |
| Camera and reel | A Cam, reel A007 | Maps the card to the day’s coverage |
| Offload time | 14:22 local | Establishes sequence and responsibility |
| Destination volumes | DIT-SSD-02 (serial 4021), Back-02 | Proves two separate devices were used |
| File count and total size | 1,204 files, 402.6 GB | Detects a copy that silently dropped a folder |
| Checksum method and value | xxHash64, 8f3c… | Proves verification was performed |
| Offload and verification initials | R.M. / S.K. | Accountability plus independent confirmation |
| Disposition | Held, formatted, or released to post | Documents the irreversible step |
Generate the record as a PDF from the offload utility rather than retyping numbers, and store three copies: one on each destination drive and one sent to production the same day. A log that lives only on the laptop traveling with the drives is not a log.
The printable on-set checklist
| Phase | Action | Evidence |
|---|---|---|
| Station setup | Two destinations on separate buses, both confirmed writable | Volume names and serial numbers recorded |
| Station setup | Sleep, hibernation, and auto-update disabled | Screenshot saved to the day’s folder |
| Per card | Reader matched to media type; write-protect tab enabled | Reader label checked |
| Per card | Dual-destination offload started with verification enabled | Utility log open |
| Per card | Checksum report checked for mismatches; file count compared to source | Report saved as PDF |
| Per card | Source card mounted read-only, with no writes performed | Mount flags checked |
| Per card | Second person confirms the report before release | Two sets of initials in the log |
| Per card | Disposition recorded; card moved to hold or return pile | Handoff log row complete |
| End of day | Destinations reconciled against the day’s card list | Card count equals log row count |
| End of day | Daily report emailed to production as a third copy | Sent item timestamp |
Where on-set workflows break in practice
The failures are predictable, and they are almost never caused by the software.
The second copy exists but was never checked. The utility reported success and nobody read the report. A checksum mismatch on drive B is invisible unless a human reads the result column.
Both copies travel together. Two drives in one bag, one car, one checked suitcase is one copy from a risk standpoint.
The card gets formatted by someone who was not in the room. The hold pile must be labeled, physically separate, and owned by the DIT.
A two-bay enclosure is mistaken for two backups. Striping has less redundancy than a single drive, and mirroring is still one device with one power supply.
A checksum was computed against a card that had already been written to. Mounting read-write invalidates later comparisons, so the read-only step belongs before the copy.
When the process fails anyway
If a card is formatted and then reused, any data that new recordings have overwritten is gone. No software recovers it and no lab recovers it either. That is a hard boundary of flash storage, and it is the reason the two-copy rule exists.
If a card fails before it is reused — it stops mounting, disappears from the reader, or throws errors during offload — the data is usually still present. The priority is to stop reading the card, image it once, and run every later attempt against the image rather than the original, following the corrupted card workflow.
If you are on Windows and the card is still detected by a computer, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive. Recovered clips that will not play are usually missing an index rather than missing data, which is a repairable condition.
A failed card on set deserves the same record as everything else. The card identifier, the failure symptoms, and the last successful verification belong in the log, because how cinema productions lose footage is rarely a mystery in hindsight; the evidence is simply never written down at the time. Productions without a full DIT station can adapt these steps with the lighter kit described in the field backup workflow, which trades speed for redundancy but keeps verification intact.
Frequently Asked Questions
Is checksum verification really necessary when the copy finished without errors?
Yes. A completed copy proves that data moved, not that it arrived intact. Cards with failing cells can return corrupted reads that the operating system reports as successful writes, and only a checksum comparison detects that. It is the step that separates a professional offload from a hopeful one.
How many copies does an on-set workflow need?
Two verified copies on separate physical devices before a card is formatted, and a third at a different location once the shoot day ends. Two drives in one bag are one copy from a risk perspective, because a lost bag or a vehicle break-in removes both at once.
Should the camera card be formatted after the offload, or left as is?
Hold it until post confirms the footage is usable, then format it in camera. If a card is formatted by mistake, stop using it immediately: a camera format is a quick format, so the video data usually remains until new recordings overwrite it.
What happens if a card fails during an offload?
Stop, and do not keep retrying reads on a failing card. Image it once with a dedicated imaging tool, then run recovery scans against that image instead of the original. Data that has not been overwritten can be recovered in full; data that later recordings have overwritten cannot be recovered by any tool.