Video file naming and structure for decade-scale retrieval

Cold storage for video archives: keeping home media findable after a decade

A video archive you cannot read a decade later is just a warm drive waiting to die. The two things that usually ruin long-term video archiving are ambiguous filenames and no verification schedule. Fix those, and the rest is manageable.

Naming files so they survive decade-scale storage

The sort key that works across every file system, every OS, and every decade is an ISO 8601 date prefix: YYYY-MM-DD. Put it at the very start of the filename. 2024-07-14 sorts correctly on ext4, APFS, NTFS, and anything else likely to appear later. A name like holiday_july_14.mkv is ambiguous from day one and turns into noise once you have years of files mixed together.

After the date, put the source, resolution, and codec in the filename. A pattern like 2024-07-14_cornwall-coast_4k_h265.mkv tells you what you need without opening the file. Source identifies the camera or capture device; resolution and codec matter because playback in 2035 may not match today, and you need to know which files need transcoding before you can use them.

Keep the path strictly ASCII, lower case, and hyphen-separated. Spaces get in the way of command-line tools. Parentheses, ampersands, and locale-specific characters such as accented vowels can cause silent truncation or rename failures on Windows paths. You will not remember which convention you used in five years; pick ASCII hyphens now and stick with them.

Write a sidecar manifest at ingest. A plain-text .manifest.csv file alongside each directory should list filename, SHA-256 hash, file size in bytes, capture date, and a human-readable description. Embedded metadata in MKV or MP4 containers gets stripped during re-encodes, copies through some NAS applications, and cloud sync clients. The sidecar file is the ground truth. Treat it as part of the archive, not a convenience.

For re-encodes, add a version suffix rather than overwriting. _v1 for the original capture, _v2 for a first transcode, _proxy for a low-resolution viewing copy. This keeps your offline backup strategy honest: you always know which copy is the master and which is derivative. Overwriting the original with a re-encode is a one-way door you will regret on the day the re-encode turns out to have a fault.

Directory structure and redundancy schedule

Keep the folder structure flat. Two levels is the right depth: one top-level directory per year, one subdirectory per event or subject. 2024/2024-07-14_cornwall-coast/ covers everything you need. Anything deeper than two levels hits path-length limits on Windows (260 characters by default without long path support), and some copy tools on macOS silently truncate long paths. Flat structures also keep the manifest files close to the content they describe.

The nearline NAS setup should be your working layer. Set up a mirrored or RAIDZ pool on ZFS, or a Btrfs RAID-1 mirror, for day-to-day access. ZFS and Btrfs both store per-block checksums and verify them on read, which means bit rot found early can be repaired automatically from the mirror. Schedule a zpool scrub monthly at minimum. For drives that spin down regularly or see little read traffic, monthly scrubs matter more, not less: data that goes unread for months can collect silent corruption that only shows up when you need the file.

Pair the NAS with a snapshot rotation cycle. Take a ZFS or Btrfs snapshot on the NAS before every new ingest, keep four weekly snapshots and three monthly snapshots, and prune automatically. This protects against accidental deletions and bad copies without eating the whole pool.

The cold drives are a separate layer. Every quarter, clone the NAS archive to a new offline backup drive using rsync --checksum or rclone copy --checksum. Do not use a plain rsync -av; it compares timestamps and sizes, not content. The --checksum flag re-reads every byte and compares hashes, which is the only verification worth having for long-term media preservation.

At ingest, generate a SHA-256 checksum log for the entire directory tree:

find /mnt/archive/2024 -type f -exec sha256sum {} \; > /mnt/archive/2024/checksums-2024.sha256

Store that file on the NAS and copy it to each cold drive alongside the data. Every time you spin up a cold drive, whether for a quarterly copy or an annual verify, run the check:

sha256sum -c /mnt/cold-drive/2024/checksums-2024.sha256

Any mismatch is a corruption event. Cross-reference it against the NAS copy straight away.

Labelling offline drives without trusting the filesystem

Do not rely on volume labels as your only identifier. A filesystem label can be changed accidentally, or it may not mount correctly on a different OS. Every cold drive should carry a permanent physical label on the drive itself, a matching entry in a plain-text drive-registry.csv file on the NAS, and a duplicate of that registry burned to each drive. The registry should record: drive serial number, purchase date, capacity, archive date range, pool name if applicable, and physical location. When you pull a drive out of a box in 2033 and the volume name reads UNTITLED, the serial number on the label and the registry entry together tell you what is on it. The filesystem metadata is a convenience; the registry is the record.

This whole setup — filename convention, sidecar manifests, quarterly checksum verification, and physical labelling — is the boring approach. It is also the one that works.