3-2-1 for Video Archives, and How to Actually Verify It
Updated July 17, 2026
3-2-1 for Video Archives, and How to Actually Verify It
The 3-2-1 rule is the one piece of backup advice everybody agrees on: keep three copies of your data, on two different kinds of storage, with one of them somewhere else. It is credited to photographer Peter Krogh, who wrote it down for digital photo libraries, and it survived because it is simple and it works.
What the rule does not say is the part that ruins people: a copy you have never read back is not a copy. It is a hope. This article covers what 3-2-1 means for finished video projects specifically, and then the half nobody does: proving your copies are actually there.
Video archives are not backups
Backup software is built for data that changes: documents, databases, a laptop. It runs continuously, keeps versions, and prunes old ones.
A finished video project is the opposite. When a job wraps, the media never changes again. You need it off the expensive editing storage, protected, and findable in five years. That is an archive, not a backup, and it changes what 3-2-1 means in practice:
- Three copies of the final project folder, made once, at wrap.
- Two kinds of storage so one failure mode cannot take both. A copy on a local drive or NAS, plus a copy on LTO tape or in cloud storage, is the classic pairing. Two hard drives from the same batch in the same office fail more alike than you would think.
- One offsite so the fire, the flood, or the ransomware event does not get everything. Cloud storage is offsite by definition. A tape on a shelf in another building also counts, and costs nothing per month.
Where the three copies usually live
For small studios and independent editors, the pattern that keeps showing up:
- A local copy on a NAS or archive drive. Fast to restore from, first to be reached for.
- A cloud copy in S3-compatible object storage (AWS S3, Backblaze B2, Cloudflare R2). Offsite, no hardware to manage, priced per stored terabyte per month.
- An LTO tape copy. Highest upfront cost (a drive), lowest cost per terabyte after that, no monthly bill, and a shelf life rated in decades. Written as LTFS, the tape carries its own open, self-describing filesystem, so it is not locked to one vendor's software.
You do not need all three kinds. You need three copies, two kinds, one offsite. Disk plus cloud satisfies it. Disk plus tape (tape stored elsewhere) satisfies it too.
The verification gap
Here is the uncomfortable part. Almost everyone who "does 3-2-1" actually does this: copy the folder three times, eyeball the file count, and move on.
Every step in that copy chain can lie to you:
- Transfers corrupt in flight: a flaky cable, a bad RAM stick, a USB bridge that drops writes under load.
- Media decays at rest. Disk sectors rot. Cheap drives on shelves lose data over the years, silently.
- A copy tool that says "done" is reporting that it sent the bytes, not that the medium kept them.
None of this announces itself. The failure surfaces years later, at restore time, on the day you need the archive, which is the only day it matters.
What verification actually means
Real verification is one specific thing: read the copy back off the medium it lives on, hash what came back, and compare it to the hash of the original. A cryptographic checksum (SHA-256 is the common choice) changes if even one bit changed. If the hashes match, the copy is provably intact today. If they do not, you found out now, while your other copies can still replace it.
Two details separate a real verification regime from a gesture:
- Verify at write time, from the medium. Hash the source, write the copy, read the copy back from the destination, compare. Not "the tool's progress bar finished."
- Re-verify on a schedule. A copy verified at write time was intact at write time. Media decays; re-reading and re-hashing every so many months is what turns "was intact" into "is intact."
Doing it by hand
You can run this regime manually, and if you have one small archive, you should at least do this much:
- Generate a SHA-256 manifest of the source folder before copying.
- Copy to each destination.
- Re-hash each destination copy from the destination and diff against the manifest.
- Store the manifest with each copy.
- Put a recurring calendar entry to re-run step 3, and actually do it.
The manual approach fails in predictable places: cloud copies have to be re-downloaded to hash them honestly, tape copies have to be mounted and read, and the recurring calendar entry is the first thing dropped in a busy month. Discipline is the weak link, which is exactly why the verification gap exists.
Automating it
This is the problem Hiberden exists to solve, so here is the short, honest version: it writes each archive to every destination your policy requires (disk, S3-compatible cloud, LTO tape), and by default verifies every copy at write time by reading it back from its medium and comparing hashes before calling anything done. Re-verifying later is a click instead of a project: pick any copy, run Verify, and get a fresh answer from the medium itself. One honest caveat: the recurring part of the regime is still yours to run. A policy records the re-verify cadence you intend, but in the current build nothing executes it for you on a timer, so put that calendar entry in and let Hiberden make each re-run trivial. Restore and verification are free and unlicensed, so an archive is never hostage to a license. The mechanics are covered in Verified 3-2-1 Archiving.
Whatever tool you use, including none, hold it to the standard above: it is not archived until it has been read back and matched, on every copy, on a schedule.
A restore you have never tested is part of the gap
Once a year, pick a project and restore it somewhere fresh: a scratch drive, a temp folder. Confirm it opens, relinks, and plays. Verification proves the bytes are intact; a restore drill proves the archive is usable and that you still remember how. The first time you do this should not be the day a client calls.
Where to go next
- Verified 3-2-1 Archiving: how coverage and verification work in Hiberden.
- Quickstart: Your First Verified Archive: the whole happy path in one pass.
- Running a Verification: re-verifying a copy on demand.
- The minimal S3 permissions Hiberden needs: scoping cloud credentials for an archive bucket.