为什么“免清单文件(No-Manifest)”恢复设计对容灾至关重要:消除元数据单点隐患
传统备份软件严重依赖外部清单索引数据库,一旦索引损坏整个备份库即刻报废。本文解析无状态自包含二进制头部的抗灾实现。
为什么“免清单文件(No-Manifest)”恢复设计对容灾至关重要:消除元数据单点隐患
在许多传统去重备份软件(如各类商业备份代理与开源去重工具)的设计中,数据块通常被高度碎片化地分散存储,而系统必须依赖一个单独的**清单文件(Manifest)或中心数据库索引(如 SQLite / RocksDB)**来维护分块哈希与原始文件名、目录树及加密盐值之间的映射关系。
这种设计虽然有利于实现块级去重,却引入了极其致命的元数据单点故障(Single Point of Failure):
一旦该清册文件发生损坏、索引数据库出现静默坏块或因软件版本升级不兼容导致索引无法加载,原本完好无损存放在磁盘上的数万个数据分块,将在瞬间彻底沦为无法拼装的垃圾文件!
集中式清单架构的脆弱性示意
[ 传统去重备份系统架构 ]
┌────────────────────────────────────────────────────────┐
│ 核心清单文件 / SQLite 索引数据库(极度脆弱的单点隐患) │
└────────────────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
[分块 001.bin] [分块 002.bin] [分块 003.bin] ... (成千上万个无名碎片)
* 致命风险:只要 Manifest 文件损坏或丢失,所有分块彻底无法还原!
YourKeep 免清单(No-Manifest)无状态架构解析
YourKeep 从底层彻底废除了外部清单文件和中心索引库的概念,使每一个 .keep 分片都成为100% 自包含、自验证的独立密码学实体:
+-------------------------------------------------------------------------+
| 魔数标识 (0x594B454550 "YKEEP") | 协议格式版本号 (0x01) |
+-------------------------------------------------------------------------+
| 全局唯一容器 UUID (128-bit) | 当前分片索引 (k) / 总分片数 (N) |
+-------------------------------------------------------------------------+
| 最小恢复门限 (K) | 原始明文 SHA-256 校验和 |
+-------------------------------------------------------------------------+
| AEAD Nonce (96-bit) | GHASH 认证完整性标签 (128-bit) |
+-------------------------------------------------------------------------+
| 加密数据分片载荷 |
+-------------------------------------------------------------------------+
免清单设计的革命性优势:
- 彻底消除索引损坏风险:没有中心数据库可以被损坏,所有元数据安全封装在各个分片自身内部;
- 纯无状态即时重构:恢复时只需将存放分片的文件夹导入 YourKeep,引擎自动解析头部、按 UUID 智能归组并秒级重构;
- 免疫文件名与目录打乱:即便分片被操作系统重命名或散落在不同子文件夹中,恢复引擎依旧能依据二进制头部自识别。