Linux 归档、压缩与同步：从打包到可验证恢复

上一部分解决了“怎样准确找到文件”。找到之后，新的问题马上出现：怎样把一组文件完整交给别人，怎样减少传输体积，怎样让两个目录保持一致，又怎样保证事故发生后真的能恢复？

这几个动作看起来都像“复制文件”，实际承担的责任完全不同。压缩关注字节体积，归档关注成员和元数据，同步关注两端状态，备份还必须保留时间维度并通过恢复验证。把它们混成一个动作，最常见的结果是：压缩包能打开，却缺权限或链接；目录看起来同步成功，误删也同步过去了；备份任务每天显示绿色，真正恢复时才发现链条不完整。

我们会从数据流开始，逐层搭起一套可审阅、可验证、能恢复的流程。文中的命令都以受控目录为例；任何解包、覆盖或删除动作，都先看清作用范围。

先把压缩、归档、同步和备份分开

归档解决“装什么”，压缩解决“占多大”

归档器把多个路径变成一个成员序列。每个成员除了内容，还可能带有名称、类型、权限、所有者、修改时间和链接关系。tar 最典型：它先回答“包里有哪些成员、这些成员之间是什么关系”，并不要求数据一定变小。

压缩器处理的是字节流中的重复模式。gzip、bzip2、xz 和 zstd 都可以接收标准输入，再把压缩流写到标准输出。它们并不知道一段字节属于十个文件还是一个文件，也不会自动保存目录结构。于是，常见的 .tar.gz 实际包含两层：先用 tar 生成归档流，再用 gzip 压缩这条流。

这个区分会直接改变排错方法。gzip -t package.tar.gz 成功，只能说明 gzip 流能完整解码；它没有证明归档成员符合预期，更没有证明恢复后的应用可用。下一步仍应运行 tar -tzf 审阅成员，并在隔离目录恢复验证。

同步解决“现在像不像”，备份解决“过去回不回得去”

同步器比较源和目标，然后更新目标。rsync 可以跳过未变化文件、只传需要更新的数据，还能让目标删除源中已经不存在的成员。它非常适合发布、镜像和副本刷新。

但镜像只有“当前状态”。源端误删一个目录，下一次带 --delete 的同步可能忠实地删掉目标副本；源端文件被勒索软件加密，同步也可能把加密结果覆盖过去。备份必须增加同步本身没有的能力：版本、保留周期、独立故障域、不可变或离线副本，以及定期恢复演练。

判断一个流程是不是备份，不要只问“有没有第二份”，而要问三个更具体的问题：能回到哪个时间点；源端凭据失守后副本是否仍受保护；选定恢复目标后，多久能把数据还原并验证可用。

后缀是提示，不是内容证明

用 file、列表模式和魔数建立证据

.gz、.xz、.zip 只是命名约定。文件可以被误命名，也可能被刻意伪装。可靠的处理顺序是：先识别类型，再调用只读检查，最后才考虑解包。

file incoming.data
od -An -tx1 -N16 incoming.data
gzip -t incoming.data
tar -tf archive.tar
unzip -t package.zip

file 会结合节点类型、文件开头的特征值和上下文测试给出分类。gzip 流常以十六进制 1f 8b 开始，XZ 流常以 fd 37 7a 58 5a 00 开始，ZIP 常见局部文件头以 50 4b 03 04 开始。这些“魔数”比后缀更接近内容，但仍只是格式证据：一段有效 ZIP 数据也可能装着不该覆盖的路径。

隔离实验把 sample.txt.gz 改名为 report.data，file 仍识别出 gzip 数据。这说明工具看的是内容特征，而不是扩展名。反过来，把普通文本改成 .gz 并不会让它变成 gzip 流。

完整性、真实性和可恢复性是三道不同的检查

完整性检查回答“数据是否在存储或传输中损坏”。gzip、bzip2、xz 和 ZIP 都有格式内部的校验机制，sha256sum 还能为整个交付物生成外部摘要：

sha256sum release.tar.xz > release.tar.xz.sha256
sha256sum -c release.tar.xz.sha256

但校验和不是签名。攻击者如果能同时替换文件和 .sha256 清单，校验仍会通过。需要验证来源时，摘要必须通过独立可信渠道获得，或使用经过验证的数字签名。

可恢复性又高一层。归档摘要一致，只能证明交付物字节没变；恢复后还要核对成员数量、权限、链接、配置、数据库一致性和应用启动检查。三道检查的关系可以记成：格式检查发现“能不能读”，外部校验发现“有没有变”，恢复演练证明“能不能用”。

选择压缩格式时看数据、CPU 和接收端

gzip：兼容性和速度优先

gzip 使用 DEFLATE，是许多环境都能处理的通用选择。下面的 -k 保留输入，避免默认的原地替换；-1 偏向速度，-9 偏向压缩率，默认等级处在中间：

gzip -k report.log
gzip -1 -c report.log > report.fast.gz
gzip -9 -c report.log > report.small.gz
gzip -t report.small.gz
gzip -dc report.small.gz > restored.log

压缩等级只在同一格式、同一输入和相近实现内有比较意义。-9 不保证比其他算法更小，也不保证总任务更快。一次跨网络交付的总时间大致由读取、压缩、传输、解压和写入共同组成；如果网络很快而 CPU 紧张，更高等级可能增加总时长。

gzip 默认处理命名文件时会用 .gz 文件替换输入。自动化任务若要保留源文件，使用 -k 或 -c 更容易审阅；输出前还应检查目标是否已经存在，避免无意覆盖。

bzip2 与 xz：用更多计算换更小体积

bzip2 和 xz 对可压缩文本、源码或重复数据常能得到比 gzip 更小的结果，但压缩更慢，内存需求也可能更高。命令接口相似：

bzip2 -k dataset.txt
bzip2 -t dataset.txt.bz2
bzip2 -dc dataset.txt.bz2 > dataset.bz2.out
 
xz -k dataset.txt
xz -t dataset.txt.xz
xz -dc dataset.txt.xz > dataset.xz.out

隔离实验中，1,160,000 字节的高度重复文本分别得到 3,472 字节 gzip、447 字节 bzip2 和 352 字节 xz。这个结果展示的是输入结构，不是格式排行榜。换成编译产物、照片或加密数据，差距会完全不同。

选择 xz 常见于“发布一次、下载很多次”的静态交付，因为创建端愿意多花时间换下载体积。频繁生成、低延迟或资源紧张时，gzip 可能更合适。bzip2 仍有存量兼容场景，但新流程应先确认接收端已有解码器和性能目标，而不是只追求最小数字。

zstd：现代速度档位，但先确认安装与兼容性

Zstandard 提供很宽的速度与压缩率档位，低等级适合实时或频繁任务，高等级可投入更多内存和 CPU。常见命令如下：

zstd -k data.json
zstd -t data.json.zst
zstd -dc data.json.zst > data.json.out
tar --zstd -cf snapshot.tar.zst snapshot/

它的优势不意味着可以无条件替换 gzip。精简系统、旧恢复介质或某些固件环境可能没有 zstd；GNU tar 是否支持 --zstd 也取决于编译和版本。真正的备份流程应在恢复环境里验证解码器，而不是只在创建端确认命令存在。

高压缩等级还可能显著增加内存。面对不可信压缩流，解压端应设置文件大小、总输出量、时间和内存限制，防止小输入膨胀成超出预算的大输出。

已压缩或近似随机的数据可能越压越大

JPEG、MP4、ZIP、加密数据和随机字节通常已经消除了大部分重复模式。再次压缩不仅收益很小，还会增加格式头、CPU 和延迟。隔离实验把 131,072 字节随机数据交给 gzip，输出变成 131,121 字节，多了 49 字节。

压缩前可以做小样本基准，但不要只比较最终大小。记录压缩和解压耗时、峰值内存、接收端支持、失败后的恢复路径。对于已经压缩的媒体归档，tar -cf media.tar media/ 可能比 tar -czf 更合理；归档仍能把成员组织在一起，但不强求二次压缩。

标准输入和标准输出把工具接成数据流

-c、-d 与 -t 分别控制输出、方向和检查

在压缩工具里，-c 通常表示把结果写到标准输出，-d 表示解压，-t 表示试解码并丢弃输出。它们组合后能形成不落地的检查和转换：

gzip -dc logs.gz | less
xz -dc dump.sql.xz | sha256sum
bzip2 -t archive.bz2

标准流的价值是减少中间文件，并让每个工具只做一件事。但管道不会自动保存输入文件名、权限或目录结构；这些信息要由归档层负责。把多个普通文件直接依次送给 gzip，也不能获得像 tar 那样可按成员名独立恢复的目录归档。

管道成功要检查每一段的退出状态

下面的命令很短，但有两个可能失败的程序：

tar -C project -cf - . | gzip -c > project.tar.gz

在 Bash 脚本里，仅检查整条管道最后一个命令，可能漏掉前面的 tar 读取错误。应开启 pipefail，使用临时输出，成功后再原子改名：

set -euo pipefail
tmp=project.tar.gz.part
trap 'rm -f "$tmp"' EXIT
tar -C project -cf - . | gzip -c > "$tmp"
gzip -t "$tmp"
mv -- "$tmp" project.tar.gz
trap - EXIT

这样做的原因不是追求脚本形式，而是避免把半成品当成成功产物。归档活跃目录时还会有另一类问题：文件在读取期间发生变化。对数据库或要求一致性的目录，应先生成应用一致快照或只读副本，再从快照归档。

tar 的骨架：模式、归档文件和成员

create、list、extract 是互斥的主模式

一条 tar 命令先选主模式，再指定归档和成员：

tar --create  --file project.tar project/
tar --list    --file project.tar
tar --extract --file project.tar --directory restore/

短选项分别是 -c、-t、-x 和 -f。-f 的参数是归档文件名，不是要归档的成员。为了减少参数位置误读，脚本中使用长选项往往更清楚。

列表模式是恢复前的只读观察面。它能告诉我们成员的精确名字；选择性提取必须使用归档中实际记录的名字，而不是凭感觉写一个宿主路径。详细列表 tar -tvf 还能看到类型、模式、所有者、大小、时间和链接指向。

短选项紧凑，长选项更适合审阅

下面两条命令表达相同主干：

tar -czf release.tar.gz -C build release
tar --create --gzip --file=release.tar.gz --directory=build release

传统写法常省略短选项前的连字符，例如 tar czf，但新脚本更推荐带连字符或长选项。关键不是风格，而是避免把参数归属看错：-f、-C、--strip-components 都需要参数；-v 只是增加诊断，不改变归档内容。

创建、列表和提取不要在同一命令中混用。看到陌生 tar 命令时，可以按“主模式 → 过滤器 → 归档文件 → 工作目录 → 成员”重新排版，再判断风险。

用 -C 控制归档中记录的路径

推荐从一个明确根目录创建相对成员：

tar -C /srv/app -cf app-config.tar config templates
tar -tf app-config.tar

成员会是 config/... 和 templates/...，而不是 /srv/app/...。相对成员更容易在隔离目录恢复，也减少覆盖绝对位置的风险。

GNU tar 在创建时遇到绝对路径，默认会移除前导 / 并给出提示。隔离实验请求归档 /tmp/welearn-ch18/source/docs/normal.txt，实际成员变成 tmp/welearn-ch18/source/docs/normal.txt。不要把这个默认保护理解成“绝对路径随便写”；清楚使用 -C 才能让归档布局成为有意设计。

tar 与压缩可以组合，也可以显式分层

-z、-j、-J 与 --zstd

GNU tar 能调用常见压缩器：

tar -czf project.tar.gz  project/
tar -cjf project.tar.bz2 project/
tar -cJf project.tar.xz  project/
tar --zstd -cf project.tar.zst project/
 
tar -tzf project.tar.gz
tar -tjf project.tar.bz2
tar -tJf project.tar.xz

扩展名仍是约定。显式写过滤器选项能让命令意图不依赖自动探测，也更容易看出恢复环境需要哪个解码器。创建后至少做一次列表；关键交付还应记录整个归档的独立摘要并试恢复。

用 - 把 tar 流交给下一个程序

- 通常表示标准输入或标准输出。下面两条命令展示创建与读取两个方向：

tar -C project -cf - . | gzip -c > project.tar.gz
gzip -dc project.tar.gz | tar -tf -

第一条把 tar 归档写到标准输出，第二条让 tar 从标准输入读取解压后的归档。这样不会产生中间 .tar，能减少磁盘空间和 I/O。不过，流式处理仍要把错误传播、临时输出和退出状态设计好。

归档流是顺序结构。只提取尾部某个成员时，工具通常仍要扫描前面的记录；网络流中途断开也可能留下不可用结果。若业务需要高频随机访问或部分恢复，单一 tar 流未必是合适存储层。

解包不是“打开文件”，而是一次受控写入

先列表，再决定恢复目录和成员范围

对未知归档，第一遍只读：

file incoming.tar.xz
xz -t incoming.tar.xz
tar -tJf incoming.tar.xz
tar -tvJf incoming.tar.xz | less

审阅时至少看五件事：是否有统一顶层目录；是否出现绝对成员；是否含 .. 分量；是否有指向目录外的符号链接；成员数量和总展开体积是否超出预算。成员名还可能含空格、制表符或换行，自动化检查不能用简单的逐行拆分假定“一行一个安全名字”。

确认结构后，在权限受限的空目录恢复：

install -d -m 700 restore-check
tar -xJf incoming.tar.xz -C restore-check --no-same-owner

--no-same-owner 明确让普通交付不尝试恢复归档所有者。它不是万能安全开关；恢复后仍要检查权限、链接、特殊文件和内容。

路径穿越、覆盖和权限恢复属于同一可信边界

路径穿越成员如 ../escape.txt 试图跳出恢复根。隔离实验构造了这样的归档，GNU tar 列表立即暴露成员，默认提取返回状态 2 并拒绝写出。但不能只依赖某个版本的默认保护：其他格式、实现、选项或链接组合可能表现不同。

覆盖风险更常见。即使所有成员都是相对路径，直接在已有目录提取也可能覆盖同名配置或可执行文件。GNU tar 提供 --keep-old-files、--skip-old-files 等拒绝覆盖控制；已有目录符号链接还要单独审查。最稳妥的第一恢复仍是空目录。

高权限提取会扩大影响。归档中可能记录 setuid 位、设备节点、陌生 UID/GID 或宽松权限。普通内容交付优先低权限恢复并使用 --no-same-owner；系统级恢复则应在受控恢复环境按清单逐项验收，不要把“需要 root”当成跳过审阅的理由。

--strip-components 先做路径推演，再执行

假设成员为：

bundle/v1/files/readme.txt
bundle/v1/files/config.ini

使用 --strip-components=1 会得到 v1/files/...，使用 =2 会得到 files/...，使用 =3 才会直接得到文件名。被剥离后没有剩余分量的成员会被跳过。

tar -tf release.tar
mkdir -m 700 restore
tar -xf release.tar -C restore --strip-components=2
find restore -maxdepth 3 -print

这个选项适合去掉版本包装层，但不能代替安全检查。先在纸面或交互审查器中推演每个代表性成员，再在空目录执行，最后核对实际树。

“完整恢复”要逐项定义元数据

权限、所有者和时间并非总能原样落地

tar 通常记录 Unix 模式、UID/GID、用户名组名和修改时间。能否恢复取决于执行身份、选项、目标文件系统和归档格式。普通用户不能随意把文件所有者改成其他 UID；umask 也会影响新建文件，GNU tar 的 -p 或 --preserve-permissions 用于按归档模式恢复，但高权限使用时要先信任归档。

修改时间 mtime 常被保存，状态变化时间 ctime 不能简单恢复为历史值，因为恢复动作本身会改变 inode 状态。访问时间、纳秒精度、ACL、扩展属性和安全标签需要额外选项或格式支持，例如 GNU tar 的 --acls、--xattrs、--selinux。跨文件系统时即使命令成功，目标也可能无法表达全部属性。

因此“tar 能保权限”不是验收标准。更好的写法是列矩阵：哪些属性必须保留、创建命令用了什么选项、恢复身份是什么、目标文件系统支持什么、恢复后用 stat、getfacl、getfattr 或应用检查验证什么。

硬链接与符号链接保存的是不同关系

硬链接是多个目录项指向同一 inode。归档器识别到关系时，可以保存一份内容和后续链接记录；恢复后应检查两条路径 inode 是否相同。只选择性提取硬链接记录而缺少其目标成员，可能失败或得不到预期关系。

符号链接保存的是一段目标路径文本。默认归档符号链接本身时，恢复后目标可能不存在，也可能是绝对路径或含 ..。tar --dereference 会沿链接归档目标内容，这会改变语义，还可能把预期范围外的数据带入归档。

隔离实验中的 latest.txt -> docs/normal.txt 恢复后仍是链接；两条普通文件路径恢复后 inode 相同。这个结果来自当前格式、选项和文件系统，迁移流程仍应在目标环境验收。

稀疏文件和活跃数据需要专门策略

稀疏文件的逻辑长度很大，但大段零区没有实际分配数据块。普通复制若把空洞写成零字节，内容校验仍可能一致，磁盘占用却暴涨。GNU tar 创建时可用 --sparse；恢复后同时比较逻辑长度与已分配块数。

隔离实验的 16 MiB 稀疏文件创建前后都只分配 8 个块。相同文件经 ZIP 往返后占用 32,768 个块，说明内容可恢复不等于存储布局可恢复。

活跃数据还有时间一致性问题。归档器逐项读取时，应用可能正在修改文件。日志目录可以接受一个区间内的视图，数据库通常不行。应先定义一致性级别，再选择停写、应用导出、文件系统快照或只读副本。

ZIP 适合跨平台交换，但不是 Unix 元数据镜像

zip 与 unzip 的优势和边界

ZIP 把归档与按成员压缩放在同一格式中，桌面系统和图形工具普遍支持。交换普通文档、图片和发布包时，它经常是兼容性更好的选择：

zip -r deliverable.zip deliverable/
unzip -l deliverable.zip
unzip -t deliverable.zip
unzip deliverable.zip -d restore-check/

Info-ZIP 的 zip -y 会保存符号链接本身，而不是跟随链接。但接收端工具和文件系统未必按同一语义恢复。硬链接关系、Unix 所有者、ACL、扩展属性、设备节点和稀疏布局也不应默认跨平台保真。

隔离实验中，符号链接成功往返；原本共享 inode 的硬链接变成两份独立文件；16 MiB 稀疏文件的空洞被实体化。于是，ZIP 的合理定位是“内容和基础目录结构的跨平台交付”，系统级恢复则要选择能满足元数据矩阵的格式并在目标环境验证。

rsync 先定义源根，再谈高效同步

源路径尾斜杠决定复制目录还是目录内容

假设目标 backup/ 已存在：

rsync -a project  backup/
 # 结果：backup/project/...
 
rsync -a project/ backup/
 # 结果：backup/...，复制 project 内的内容

隔离实验得到的树正是这样：不带斜杠时出现 rs-src/a.txt，带斜杠时直接出现 a.txt。这不是显示差异，而是同步根发生了变化。

目的路径是否存在、是否带尾斜杠以及源是否只有一个成员，也会影响命名规则。安全做法是预先创建目标目录，在命令旁写出预期目标树，再用 -n -i 验证。Tab 补全可能自动给目录加 /，执行前必须重新审阅完整命令。

quick check 很快，但不是逐文件内容比较

默认情况下，rsync 用文件大小和修改时间做 quick check。大小与时间相同就跳过读取内容，这能显著降低大目录的扫描成本。

隔离实验让两端文件同为 5 字节且 mtime 相同，但内容分别是 AAAA 和 BBBB。默认 dry-run 没有变更，实际同步后目标仍是 BBBB。加 --checksum 后，-i 输出 >fc........ payload.txt，目标才更新为 AAAA：

rsync -ani  source/ target/
rsync -anic source/ target/

--checksum 会读取两端同尺寸文件计算摘要，用更多磁盘 I/O 和 CPU 换更强的传输前判定。它与传输过程中的完整性校验不同：rsync 对实际传输文件会验证重建结果，而 -c 决定“是否需要传”。

--dry-run 和 --itemize-changes 是删除前的双闸门

rsync -ani --delete source/ target/

-n 保证本轮不写入，-i 为每个成员输出变更摘要。删除项会显示 *deleting。隔离实验的目标多出 stale.txt，预演清楚列出它，文件仍存在；去掉 -n 后，只有受控目标里的该文件被删除。

--delete 只应在确实需要镜像语义时出现。源目录暂时挂载失败、过滤规则写错或变量为空，都可能让接收端看见一个意外变小的源集合。自动化还应设置“最大删除数量/比例”、源端健康检查、日志留存和人工审批阈值。

通配符也会改变语义。source/* 由 shell 展开成若干独立成员，不等同于让 rsync 同步整个 source/ 目录，隐藏文件也可能被遗漏。删除任务应传递明确目录根，而不是依赖通配符拼出集合。

-a 是常用集合，不是全部元数据

-a 等价于 -rlptgoD：递归，保留符号链接、权限、修改时间、组、所有者，以及设备与特殊文件语义。实际能否设置所有者或设备仍受权限和目标文件系统约束。

它不包含硬链接发现、ACL、扩展属性、访问时间、创建时间：

rsync -aHAXS source/ target/

这里 -H 保硬链接关系，-A 保 ACL，-X 保扩展属性，-S 让连续零区以稀疏方式写入。隔离实验验证了 -a 会把两条硬链接变成独立 inode，而 -aH 保持同一 inode；-aHS 也保留了稀疏布局。

过滤规则同样参与删除语义。普通 --exclude 通常既让发送端隐藏成员，也在接收端保护它不被删除；--delete-excluded 会改变这一点。复杂任务应把规则文件纳入版本控制，并在与真实树相似的副本上预演。

远程 rsync 经常借 SSH 传输，但边界仍在两端

常见远程语法：

rsync -ani -e ssh source/ user@host:/srv/backup/project/
rsync -ai  -e ssh source/ user@host:/srv/backup/project/

两端都需要可用的 rsync。SSH 负责连接认证、通道加密和完整性，但不会替你判断远端路径是否正确、账号权限是否过宽、目标是否有版本保留。自动化应使用受限凭据、固定主机密钥验证、明确远端根和最小权限。

-z 会在传输中压缩数据。慢链路上的文本可能受益；高速局域网或已经压缩的媒体可能被 CPU 拖慢。rsync 的增量算法也不等于“永远只传少量字节”：首次传输、目标不存在、算法协商、数据布局和本地复制模式都会影响实际传输。

备份从保留时间点开始，以恢复验收结束

同步可以参与备份，但不能独自定义备份

rsync 很适合把数据送到备份存储，也能配合快照或 --link-dest 形成按时间点浏览的目录。真正的保护来自接收端的版本和权限隔离，而不是传输命令本身。

一个可操作的备份设计至少写清：恢复点目标 RPO，允许丢失多少时间的数据；恢复时间目标 RTO，多久恢复到可服务状态；保留周期；加密与密钥恢复；谁有删除权限；哪些副本不接受源端凭据直接改写。

不要用“任务退出 0”代替这些目标。退出 0 只能说明本轮程序按其规则完成，不能证明输入集合完整、版本可回溯、密钥可用或恢复后的应用一致。

GNU tar 增量备份依赖快照元数据

GNU tar 的 --listed-incremental 或 -g 使用独立快照文件记录上次观察到的目录状态：

tar -g state.snar -cf level0.tar data/
 # 数据发生变化后
tar -g state.snar -cf level1.tar data/

第一次没有快照文件时会建立完整基线，后续运行读取并更新同一文件，只归档判定为新增或变化的成员，并记录目录状态。state.snar 不是可随意删除的缓存，它决定下一次增量的比较基准；要从同一基线分出多条增量链，必须先复制对应快照。

恢复要按顺序应用完整备份和后续增量。增量恢复为了重建当时目录状态，可能删除那个时间点不应存在的成员，所以必须在空恢复根演练。时间回拨、修改时间变化和设备号变化也会影响判定；跨实现兼容前要确认 GNU 增量扩展。

3-2-1 是起点，恢复演练才闭环

3-2-1 的实践含义是：重要数据至少保留 3 份副本，放在 2 类介质或独立故障域中，至少 1 份位于异地。现代环境还常增加不可变或离线副本，防止同一凭据同时破坏所有版本。

副本数量不是终点。每次恢复演练应随机选择一个时间点和一组对象，在隔离环境执行：验证清单和签名；恢复完整与增量链；核对数量、摘要、权限、链接和稀疏布局；启动应用检查；记录耗时与缺失依赖；清理演练环境。

最有价值的产物不是一句“恢复成功”，而是一份可复现证据：用的是哪一版工具、哪个时间点、哪些命令、哪些验收项、实际花了多久、发现什么偏差、偏差如何修复。

三套可以直接落地的受控流程

交付归档：创建、校验、列表、试恢复

下面以一个静态发布目录为例。先固定归档根，再写临时文件：

set -euo pipefail
src=/srv/releases/app-1.4.0
out=app-1.4.0.tar.xz
tmp="$out.part"
members="$out.members.part"
checksum="$out.sha256.part"
trap 'rm -f "$tmp" "$members" "$checksum"' EXIT
 
tar -C "$(dirname "$src")" -cJf "$tmp" "$(basename "$src

接着在权限受限的空目录恢复，核对成员清单、摘要、权限和启动前检查。若目录在创建期间仍会变化，先从快照或不可变构建产物读取。

这套顺序为什么有效：临时文件隔离半成品；格式测试检查压缩层；列表暴露成员层；外部摘要固定交付物；试恢复验证实际落盘结果。每一层都回答一个不同问题。

目录镜像：先画目标树，再审阅删除计划

set -euo pipefail
src=/srv/export/
dst=/mnt/mirror/export/
 
test -d "$src"
test -d "$dst"
findmnt --target "$dst"
 
rsync -aHAXSni --delete-delay --max-delete=100 "$src" "$dst"
 # 人工或策略批准后，才移除 -n
rsync -aHAXSi --delete-delay --max-delete=100 "$src

--max-delete 是异常刹车，不是路径正确性的证明。执行后还要重新 dry-run，预期应无内容变化；关键集合可定期加 -c 做内容审计。目标端若承担备份角色，还要在 rsync 权限之外建立快照、版本和不可变策略。

远程任务把相同流程放到 SSH 通道两端，并额外验证主机密钥、远端 rsync 版本、远端磁盘与配额。不要在首次运行就把预演和执行合成一条命令。

恢复演练：从目标时间点反推全部依赖

一次合格演练从问题开始：“把项目恢复到周二 16:00，并在 60 分钟内通过健康检查。”随后按清单寻找对应完整备份、增量链、校验清单、解密密钥、工具镜像和配置。

恢复目录必须隔离，最好限制网络出口和执行权限。先只读检查格式与成员，再按顺序恢复；核对文件数量、摘要、权限、链接和磁盘占用；最后由应用执行一致性或启动验证。演练结束删除临时环境，但保留命令、输出、耗时和差异记录。

如果演练失败，不要只修当前命令。把缺失的工具、过期密钥、模糊成员名、超时步骤或无法表达的元数据写回备份设计。恢复演练的价值正是提前暴露这些问题。

最后的判断顺序：先定义恢复，再选择命令

当你要把一组文件交付、镜像或备份时，可以按下面顺序做决定：

1. 先写恢复目标：恢复哪些对象、回到哪个时间点、允许多久、必须保留哪些元数据。
2. 再识别数据：可压缩性、是否正在变化、文件名与链接是否复杂、接收端支持哪些工具。
3. 用归档器定义成员根和元数据，用压缩器定义体积与计算取舍，用同步器定义两端当前状态。
4. 所有未知归档先列表，所有删除型同步先 dry-run 和 itemize，所有正式产物先写临时名。
5. 把校验和、版本、异地副本和恢复演练接到流程末端；没有恢复证据，就继续把它当作“尚未验证的副本”。

真正可靠的方案往往不复杂：相对成员、明确根目录、受限权限、可读计划、独立校验、空目录恢复。难点不在记住多少参数，而在每次都能说清楚这个参数改变了哪一层、风险落到哪里、结果怎样被验证。