← All articles

Production Teams: Archive Video Projects with a Three Copy Checklist

Production Teams: Archive Video Projects with a Three Copy Checklist

NAS enclosure and tape cartridges in archive storage

Archive a finished video project by keeping final masters, original source media, project files, and rights documents in at least three diversified locations, verifying integrity with checksums, and refreshing storage roughly every five years. This approach draws on the Library of Congress recommended formats, the OAIS reference model for archival functions, and workspace tools like Posthive that capture version history as you work.

TL;DR:

  • Keep final masters, source media, project files, rights records, captions, and interchange files; exclude caches and abandoned cuts, then package a README and checksum manifest.
  • Use FFV1 in Matroska or MXF under RDD 48 for preservation masters, ProRes in QuickTime for editing, and MP4 for access copies.
  • Use an on site NAS, a separate location, and LTO tape or cold cloud storage; projects with little reuse potential may not need fast access.
  • Generate checksums at ingest, store them in the manifest, run fixity checks at least annually, and refresh storage media about every five years.
  • Test actual restores periodically, because checksum checks only detect corruption; verify files open in the intended editing software and document any conversion.
Posthive
Keep Video Projects Organized
Posthive helps production teams manage project versions, track tasks, and collaborate in one workspace while maintaining ownership of deliverables.
Explore Posthive

Table of Contents

1. What to keep (and what to throw away)

Most archive failures start with hoarding. Teams dump every render, every temp file, and every abandoned cut into a folder labeled “FINAL” and call it archived. That’s not archiving, it’s clutter with a deadline attached.

Keep these four categories:

  • Final delivery masters and mezzanines: the actual deliverables you sent to the client or broadcaster, plus a high-quality intermediate version.
  • Original source media: camera files, audio recordings, and any raw assets used in the edit.
  • Active project files: your NLE project(s), including any linked audio or effects projects.
  • Licensing, rights documents, captions and subtitles, and interchange files (EDLs, XML, AAF) along with an inventory manifest.

Discard render caches, waveform caches, preview files, auto-save duplicates, and abandoned sequence versions that never shipped. These regenerate automatically and add gigabytes of dead weight to every backup.

Before sealing the package, write a one-page README describing the project, the client, key contacts, and where the rights documents live. Pair it with a manifest file listing every asset and its checksum, which becomes your reference point for every future verification.

Pro Tip: Build your exclusion list once as a script filter (cache folders, .tmp extensions, preview directories) and reuse it on every project so nothing slips through during archiving.

Format choice determines whether your archive opens cleanly in ten years or turns into a support ticket. A tiered approach works best: a preservation master that prioritizes fidelity, a mezzanine for editing flexibility, and an access copy for quick review.

For preservation masters, the Library of Congress recommends non-proprietary, well-documented containers: FFV1 (version 3) wrapped in Matroska (.mkv), or MXF built on SMPTE RDD 48 for archive-specific constraints. Preservation practitioners writing in the Journal of Film Preservation favor FFV1-in-Matroska specifically because it’s open-source and lossless, while noting that MXF and IMF remain the standard in broadcast and distribution pipelines where tool support matters more than openness.

Format tiers at a glance:

  • Preservation master: FFV1 in Matroska, or MXF (RDD 48) for broadcast-aligned workflows; IMF for packaged, versioned masters.
  • Mezzanine: ProRes 4444/XQ or ProRes 422 HQ in QuickTime (.mov), chosen for near-universal NLE compatibility.
  • Access/proxy: H.264 or H.265 in MP4 for fast playback and review on any device.

The Library of Congress lists Matroska (.mkv), MXF (RDD 48), and QuickTime with ProRes codecs as its recommended formats for moving image works, giving production teams a defensible standard to point to when a client or legal team asks why a format was chosen.

When migrating between containers, rewrap rather than re-encode whenever possible. Rewrapping preserves the original bitstream and runs faster; reserve re-encoding for cases where the original codec has become genuinely obsolete.

3. Building a storage strategy across NAS, tape, and the cloud

No single storage medium is safe alone. A local NAS gives fast access but shares your building’s risk profile: fire, theft, flood. LTO tape offers extremely low cost per terabyte and strong longevity when stored correctly, but restoring from tape is slow and requires maintained hardware. Cloud cold storage trades upfront cost for ongoing fees and depends on your internet connection for both upload and retrieval.

The standard answer is a three-copy pattern:

  • Primary copy: a fast, on-site NAS or server for active reference and quick restores.
  • Off-site copy: a second physical location, whether a colleague’s office, a secondary facility, or a shipped drive.
  • Cold copy: LTO tape in a controlled environment or a cloud cold-storage tier, intended to sit untouched except for verification and true recovery events.

How you weight these three depends on the project’s value, how often you expect to need it back, and what you can afford. A client’s flagship campaign that might get repurposed next year deserves a NAS copy you can grab in minutes. A one-off corporate video with no reuse plan might live comfortably on tape and in cold cloud storage alone, skipping the expensive fast copy.

A few operational notes matter more than people expect. Label every tape physically and in your manifest, including the date and contents summary, because an unlabeled tape years later is effectively lost. Test restores periodically, not just fixity checks, since the point is proving you can actually get a working file back. Understand your cloud provider’s egress fees before you need a large restore, as pulling terabytes back out can cost far more than storing them did. And remember that RAID protects against a drive failure, not against accidental deletion, ransomware, or a fire. RAID is redundancy, not archiving.

Pro Tip: Keep a simple spreadsheet mapping each project to its three copy locations and the date each was last verified. It takes five minutes per project and saves hours when a client calls two years later.

4. Organizing archives: folders, naming, metadata, and the README

A technically sound archive that nobody can navigate is functionally dead. Organization is what makes the difference between a usable archive and digital landfill.

A canonical structure that scales across projects looks like this:

  1. Project root folder, named with client, project title, and date.
  2. Masters subfolder, containing final deliverables and mezzanine files.
  3. Source subfolder, containing original camera and audio files.
  4. Project_Files subfolder, holding the NLE project and any linked sequences.
  5. Docs subfolder, containing the README, manifest, licensing, and rights documents.

Naming should stay consistent across every project: a date token (YYYY-MM-DD), a version token (v01, v02), and where possible a short unique identifier so two similarly named projects never collide. Avoid spaces and special characters that break scripts and cross-platform transfers.

Metadata field Why it matters
Title and client Identifies the project without opening a file
Production date Anchors the project in time for rights and reuse
Codec and frame rate Confirms technical compatibility before restore
Rights and licensing status Prevents reuse of footage without clearance
Unique project ID Avoids confusion across similarly named projects

Metadata about provenance and licensing matters as much as the technical fields. Getty’s guidance on metadata notes that a technically intact archive without documented provenance or licensing information is practically unusable later, no matter how clean the files are.

For IMF or MXF packages, rely on the standard’s own structure rather than inventing your own: a PKL (Packing List) and CPL (Composition Playlist) or asset map already document what belongs together and how it assembles, which sidecar text files can’t replace.

5. Verification and media refresh: don’t let silence fool you

Storage media fails silently more often than it fails loudly. A drive can sit untouched for two years and come back with corrupted sectors nobody noticed until the restore.

The fix is checksums generated at ingest, before the files ever leave your working system. SHA-256 is the standard choice, and each checksum should live inside the manifest file packaged with the archive.

  • Generate checksums at ingest and store them in the manifest, not just in your head or a chat message.
  • Run fixity checks on a scheduled basis, annually at minimum, and log every result with a date.
  • When a checksum mismatch appears, restore the affected file from a separate copy immediately rather than trusting the damaged one.
  • Adopt a media refresh cycle: digital preservation guidance from CINES recommends refreshing storage media roughly every five years to stay ahead of physical degradation and hardware obsolescence.

Tools like Archivematica automate much of this: OAIS-aligned ingest pipelines that generate manifests, run fixity checks, and apply format-policy normalization without manual scripting. Smaller teams without that infrastructure can get most of the benefit from a documented process and a simple scheduled script that recalculates checksums and flags mismatches.

Pro Tip: Set a recurring calendar reminder for fixity checks the same way you’d schedule a tape refresh. Verification that depends on someone remembering never happens consistently.

5. Verification and media refresh: don't let silence fool you — overview diagram

6. Exporting a compact archive straight from your NLE

Most editors over-pack their archives because they export everything in the project bin instead of just what shipped.

  1. Duplicate the project and delete every sequence except the ones that were actually delivered.
  2. Run your NLE’s consolidate or collect function to gather only the media referenced by those sequences, which naturally excludes caches and unused clips.
  3. Export interchange files (EDL, XML, or AAF) alongside the native project so the edit can be reconstructed even if the original software becomes unavailable.
  4. If you don’t already have mezzanine and proxy files from ingest, generate them now rather than leaving future reconversion work for whoever restores the project.
  5. Drop the inventory manifest and checksum file into the package before sealing it.

This produces an archive that’s smaller, faster to transfer, and far easier to reconstruct than a raw copy of the entire project folder.

7. Restoring a project: the retrieval workflow

Restoring should never start with guesswork. Pull the manifest and README first to confirm exactly which files you need and where they’re supposed to live.

  • Check the manifest’s checksums against the archived copy before transferring anything, catching corruption before it becomes someone else’s problem.
  • Restore to a staging location that mirrors the original directory layout, then run a fresh fixity check against the manifest to confirm nothing broke in transit.
  • Open the project in the matching NLE and relink any missing media; if the original codec or container is no longer supported, rewrap or transcode and document exactly what changed.
  • Log the restore event with a date and generate a new checksum manifest for the restored copy, noting any format conversions in the project’s history.

8. How Posthive helps production teams create archive-ready projects

Version management, task tracking, and cloud connectivity are the features that make archiving easier instead of a scramble at project close. When version history lives in Posthive by default, the provenance record that README guidance calls for is already half-written before anyone sits down to build the archive package.

Deliverable ownership stays with the client throughout, which means handoff documentation reflects actual approvals rather than someone’s best guess weeks later. Our version control setup is built for exactly this kind of traceability.

9. Documenting editing decisions and version histories

A project file tells you what the final cut looks like. It doesn’t tell you why three scenes got cut or why the color grade changed in round four. That context disappears fastest, and it’s often what a client asks for first when they come back a year later wanting a re-edit.

Keep a running changelog alongside the project, even a plain text file, noting major decisions: why a sequence was trimmed, when a client requested a specific change, which version introduced a new graphics package. Tie each entry to a version number so it maps directly onto your file naming.

Save intermediate versions at meaningful milestones, not every auto-save, but every client-approved cut and every major creative pivot. Label each with what changed and who approved it. This turns a flat file history into an actual record of decisions, which matters enormously if a dispute arises over scope or if the project gets revived for a sequel or re-cut months later.

10. Archiving the assets around the project: fonts, effects, and plugins

A project file that calls for a font nobody has installed, or an effect from a plugin that’s since been discontinued, is a project you can’t actually open. These dependencies are easy to forget because they live outside the main media folder.

Package the fonts used in titles and graphics directly into the Docs subfolder rather than assuming they’ll still be installed system-wide. Note every third-party plugin and effect by name and version in the manifest, including where to find an installer or license key if one is needed. Where a plugin produced a baked-in effect, consider rendering a flattened version as a fallback in case the plugin itself disappears from the market entirely.

11. Security and access control for archived video files

Archived footage is often more sensitive than active projects: unreleased client work, personal interviews, or licensed material with strict usage terms. Treat access control as part of the archive itself, not an afterthought.

Restrict who can read or write to archive locations, separate from your active production permissions, and keep a record of who has access. Encrypt cold storage copies and cloud archives, particularly anything shipped off-site or stored with a third-party provider, and track encryption keys as carefully as the footage itself. Review access periodically, since a freelancer’s credentials from a two-year-old project shouldn’t still open this year’s client archive.

Common mistakes and quick cultural fixes

The worst archives aren’t technical failures, they’re organizational ones: everything gets kept, nobody owns the folder, and fixity checks never happen because no one’s job includes them. Fix it by naming an archive owner, scheduling a quarterly audit, and requiring a short intake checklist before any project gets marked done.

— Lorenz

Posthive: where to implement archive-ready version control and project provenance

Our plans allow your whole team and your clients to see version history and deliverable ownership without paying per editor. That matters most at archive time, when the people who need manifest details and approval records aren’t always the ones who built the project.

Posthive

Our workspace structure keeps provenance, tasks, and deliverables in one place instead of scattered across chat threads and spreadsheets. Compare plans and pricing to see which tier fits your team’s archive volume.

FAQ

What is video archiving?

Video archiving is the practice of preserving finished project files, source media, and supporting documents in formats and storage systems designed to remain usable for years. It typically combines stable file formats, redundant storage locations, and periodic verification rather than a single backup.

What happens when you archive a project?

Archiving a project means selecting the final masters, source media, project files, and rights documents, packaging them with a manifest and README, and storing copies across at least two or three separate locations. The package is then checked periodically for corruption and refreshed onto new media roughly every five years, per digital preservation guidance.

What is the best video format for archiving?

There’s no single best format, but the Library of Congress recommends FFV1 in Matroska (.mkv) or MXF (RDD 48) for preservation masters, with ProRes in QuickTime (.mov) as a widely compatible mezzanine option. The right choice depends on whether you prioritize long-term openness or broad tool support.

Can you give me some examples of archival footage?

Archival footage generally refers to original camera files, finished masters, and historical recordings kept long after a project wraps, often reused in documentaries, retrospectives, or legal proceedings. Examples include a production’s raw interview tapes, a broadcaster’s final delivered master, or licensed stock footage kept alongside its usage rights documentation.

Sources