十年后还能打开吗：视频长期归档的格式选择、校验与迁移

客户有批 2014 年前后的视频，想重新利用。结果三分之一打不开——当年流行的封装和编码，现在要么没有解码器，要么播放器早就不再支持。

更麻烦的是：他们唯一的存档就是这些文件，没有原始母版，没有转码副本。那三分之一基本等于永久丢失了。

这件事之后，我们给所有长期保存类的项目补了一套归档规范。这篇写完整内容：格式怎么选、为什么"流行"不等于"适合归档"、怎么发现文件悄悄损坏（比特腐烂），以及什么时候该迁移。

TL;DR：归档格式的四个标准：开放标准、文档完整、无专利风险、支持广泛。推荐组合：珍贵内容 → FFV1 + MKV（无损、开放、有 CRC）；常用母版 → ProRes 422 + MOV（广泛支持）；分发 → H.264/MP4（通用）。三个必须做的动作：生成校验和清单并定期校验（发现比特腐烂）、3-2-1 存储（三份、两种介质、一份异地）、每 3~5 年评估一次是否需要迁移。另外：没有元数据的内容等于没有内容——每个归档包要有一份说明文档（来源、格式、创建时间、校验值）。

目录

• 一、"能打开"的三个层次
• 二、归档格式的四个标准
• 三、为什么"流行"不等于"适合归档"
• 四、推荐组合
• 五、比特腐烂：文件会悄悄坏掉
• 六、校验策略
• 七、存储策略：3-2-1（+1）
• 八、元数据：没有说明的归档等于没有归档
• 九、什么时候迁移
• 十、坑清单

一、"能打开"的三个层次

判断一个文件"还能不能用"，其实有三层：

归档的目标是保住第三层——因为前两层会随时间失效（软件会停止维护），但第三层不会（只要规范还在，理论上永远能解码）。

这就是为什么"开放标准 + 完整文档"对归档如此重要。

二、归档格式的四个标准

理想的归档格式 = 开放 + 有文档 + 无专利 + 有一定支持度。

这四个标准往往有冲突（比如"最开放"和"支持最广"通常不是同一个），所以要权衡。

三、为什么"流行"不等于"适合归档"

看看过去三十年"流行过又消失"的格式：

共同特点：

• 由某个厂商推动（Real、Microsoft、Adobe）；
• 格式规范不公开或不完整；
• 有专利/授权约束。

反过来看"活得久"的：

教训："现在最流行"和"十年后还能打开"是两件事。 归档应该选择"开放且被足够多的人使用"的格式，而不是"当前最热门"的格式。

四、推荐组合

按保存期限和价值分三层：

第一层：珍贵内容的长期归档（10 年以上）

ffmpeg -i input.mov \
  -c:v ffv1 -level 3 -coder 1 -context 1 -g 1 -slices 4 -slicecrc 1 \
  -c:a flac \
  archive/master_2026.mkv

代价：体积巨大（1080p 约 400 Mbps，1 小时 ≈ 180 GB）。

这是国际档案界（图书馆、电影资料馆）的主流选择之一——比如美国国会图书馆、多个欧洲国家档案馆都指定了 FFV1 用于视频数字化保存。

第二层：常用母版（项目进行中 / 中期保存）

ffmpeg -i input.mov \
  -c:v prores_ks -profile:v 3 -pix_fmt yuv422p10le \
  -c:a pcm_s16le \
  archive/master_prores.mov

ProRes 422 HQ（前面母版那篇讲过）：体积约为 FFV1 的一半（100 GB/小时），支持度好得多（所有剪辑软件都认），代价是有损（视觉无损）。

这一层是"实用性和开放性的平衡"——它不够"永久"，但足够"现在好用"，而且 Apple 已经公开了规范。

第三层：分发/访问副本

H.264 MP4（兼容性最好）或 H.265/AV1（省空间）。

这一层的寿命最短（几年），但它是最容易被替换的——只要母版还在，随时可以重新生成。

三层结构图

珍贵内容
   ├─ 归档层：FFV1 + MKV（冷存储，不动）
   ├─ 母版层：ProRes + MOV（项目中使用）
   └─ 访问层：H.264/MP4（分发、预览）

不是所有内容都需要三层——按价值判断：

五、比特腐烂：文件会悄悄坏掉

Bit rot（比特腐烂）：存储介质上的数据会静默损坏——没有报错，没有警告，但某几位翻转了。

原因：

• 磁盘磁性衰减；
• SSD 电荷泄漏（长时间不通电）；
• 宇宙射线（真的）；
• 控制器/固件 bug；
• 传输过程中的错误（未校验）。

发生率不高但会累积：消费级硬盘的年损坏率大约 0.5%~1%（每 bit），对 1TB 的数据来说，一年可能出现几位到几十位的错误——对一个视频文件来说，一个 bit 错了可能就是一小块花屏，或者整个文件打不开。

关键特征：静默。文件系统不会告诉你"这个文件坏了"（除非它自己有校验，如 ZFS/btrfs）。

所以必须主动校验。

六、校验策略

1. 生成校验和清单

# 用 xxhash（快）或 sha256（更通用）
xxhsum -H2 archive/*.mkv > CHECKSUMS.xxh

或者自己算（xxhash 比 sha256 快 5~10 倍，适合大文件）：

import xxhash
from pathlib import Path


def file_hash(path: str, chunk=8 * 1024 * 1024) -> str:
    h = xxhash.xxh3_128()
    with open(path, 'rb') as f:
        while True:
            b = f.read(chunk)
            if not b:
                break
            h.update(b)
    return h.hexdigest()


def write_manifest(root: str, out: str):
    lines = []
    for p in sorted(Path(root).rglob('*')):
        if p.is_file() and p.name not in ('CHECKSUMS.txt',):
            lines.append(f'{file_hash(str(p))}  {p.relative_to(root)}')
    Path(out).write_text('\n'.join(lines) + '\n', encoding='utf-8')

2. 定期校验（比如每季度）

xxhsum -c CHECKSUMS.xxh 2>&1 | grep -v ': OK' 
# 有输出说明有文件损坏

3. 损坏了怎么办 → 从另一个副本恢复（这就是为什么要有多份）。

4. 校验要自动化 + 告警——手工跑一次会忘，做成定时任务并告警。

FFV1 的 -slicecrc 1 在这里有额外价值：文件内部有 CRC，即使没有外部校验和，解码时也能发现损坏（ffmpeg 会报错或者画面异常）。这是双层保护。

注意：校验不等于备份。校验只是"发现问题"，解决问题要靠副本。

七、存储策略：3-2-1（+1）

经典原则：

3 份副本
2 种不同介质（比如 磁盘 + 磁带 / 对象存储）
1 份异地（不同机房/城市）
（+1）1 份离线（offline，防勒索软件/误删）

我们的实际配置：

最后一条（离线副本）很多人忽略——但它是防范"勒索软件加密了你所有在线副本"和"误删"的唯一手段。云存储的版本控制也能起到类似作用（开启版本保留 + 对象锁）。

介质老化：

没有一种介质是永久的——所以"迁移"（下一节）是必须的。

八、元数据：没有说明的归档等于没有归档

一个只有一堆 .mkv 文件的目录，十年后就是一堆无法理解的数据。

每个归档包必须有一份 README / manifest：

{
  "collection": "客户A-讲座录像数字化",
  "created": "2026-03-11",
  "contact": "xxx",
  "source": {
    "original_format": "DV 磁带",
    "capture_device": "xxx",
    "capture_date": "2026-02",
    "resolution": "720x576",
    "note": "原始素材为隔行 25fps，已做去隔行"
  },
  "archive": {
    "container": "Matroska (.mkv)",
    "video_codec": "FFV1 level 3 (lossless, all-intra)",
    "audio_codec": "FLAC 48kHz 16bit stereo",
    "ffmpeg_command": "ffmpeg -i in.mov -c:v ffv1 -level 3 ... -c:a flac out.mkv"
  },
  "files": [
    {"name": "master_001.mkv", "duration": "01:23:45",
     "size_bytes": 123456789, "xxh3": "abc123..."}
  ],
  "checksum_algorithm": "xxh3-128",
  "checksum_file": "CHECKSUMS.txt",
  "license": "客户所有，仅内部使用"
}

必须包含的字段：

1. 来源（从哪来的、原始格式、数字化方式）；
2. 格式说明（容器、编码、参数、用什么命令生成的）；
3. 文件清单 + 校验值；
4. 创建时间和负责人；
5. 权利/授权信息（谁能用）。

格式用纯文本（Markdown 或 JSON），不要用 Word/Excel（十年后可能打不开，而且不好程序化处理）。

这份文档要跟着数据一起备份（存在同一个归档包里，而不是只存在某个人的电脑里）。

九、什么时候迁移

迁移的触发条件：

迁移的原则：

1. 保留原始（除非原始已经损坏）——迁移是"增加一份新格式"，不是"替换"；
2. 迁移后重新校验（新文件的校验和要重新生成）；
3. 更新元数据文档（记录这次迁移）；
4. 验证新文件能打开（迁移完抽几个文件播放测试）。

不要过度迁移：我见过"每两年把所有数据重新转一遍"的做法，这不仅浪费，每次转换都有风险（可能引入错误）。迁移应该在"有理由"的时候做，而不是"定期必须做"。

十、坑清单

1. 用"现在流行"的格式归档 → 十年后打不开。用开放标准。
2. 只有一份副本 → 坏了就没了。至少 3 份。
3. 所有副本在同一个地方/同一种介质 → 一次事故全损。异地 + 异质。
4. 没有离线副本 → 勒索软件/误删无法恢复。
5. 从不校验 → 比特腐烂发现不了，直到需要用时才发现文件坏了。定期校验 + 告警。
6. 校验了但没有副本可恢复 → 只是知道了坏消息。
7. 没有元数据文档 → 十年后不知道这些文件是什么。
8. 元数据用专有格式（Word/Excel）→ 将来打不开。用纯文本。
9. 元数据只存在一份（且和数据分开）→ 跟着数据一起备份。
10. 迁移时不保留原始 → 原始没了，新格式有问题就完了。
11. 过度迁移（每两年全量转一遍）→ 浪费且有风险。
12. 忽略了介质的通电需求 → SSD 长期不通电丢数据。
13. 以为云存储是"永久"的 → 服务商可能倒闭/停服/涨价。云也是一份副本，不是全部。
14. 归档包命名混乱（新建文件夹(2)/最终版_final.mkv）→ 用规范的命名和目录结构。
15. 归档后从不验证 → 定期做恢复演练（前面备份那篇讲过，同样的道理）。

最后说说这次事故给我的触动。

我们做技术的，天然关注"现在能不能用"，很少想"十年后还能不能用"。 但归档这件事的全部意义就在后者。

那三分之一打不开的文件，不是因为技术不行——而是因为当年没有人问一句"这个格式能撑多久"。

所以现在我在任何"保存类"的项目里都会先问三个问题：

1. 这份内容保存多久？（1 年 / 10 年 / 永久）
2. 它可不可以再生成？（可再生的内容，归档要求可以低很多）
3. 如果十年后打不开，损失是什么？

第 2 个问题特别有用——它决定了要不要投入"永久保存"的成本。很多内容其实是"可再生"的（比如从母版重新压的分发版），丢了就重新做；只有真正不可再生的（原始素材、历史影像）才值得三层归档。

还有一个我觉得值得分享的原则：归档方案里，"能被发现损坏"和"有多个副本"比"格式选得多完美"更重要。

格式选得再开放，如果文件坏了你不知道、或者知道了没法恢复，那也是白搭。所以我们的归档规范里，校验和副本是强制项，格式是建议项——因为前者是"保命"的，后者是"加分"的。