Linux tar 备份如何保留 ACL 与扩展属性：打包、恢复和验收命令

在Linux里把目录打包成tar包，解压后文件能正常读出，可不代表整套权限环境都完整恢复了。除了常规的读写执行mode位、属主、属组之外，ACL和扩展属性分别会影响“额外用户的访问规则”和“文件绑定的各类安全标记”。如果你的备份对象包含共享文件夹、带特殊权限的服务配置目录、或者启用了访问控制的上传存储路径，打包和恢复时都应该显式保留这两类元数据。

最小可靠做法是：归档时使用 --acls --xattrs，恢复时继续带上这两个选项，再用 getfacl 和 getfattr 对源目录、临时恢复目录逐项比对。

先区分三种容易混在一起的权限信息

文件的基本权限可以用 ls -l 看到，例如所有者、所属组和读写执行位。ACL 是更细粒度的访问控制列表，常见表现是权限字符串末尾出现 +；它可以给某个具体用户或额外用户组授予权限。扩展属性则由文件系统保存键值数据，安全标签、文件能力或应用自定义标记都可能放在这里。

实际操作里经常遇到三条看起来差不多、但作用完全不同的命令，处理的不是同一件事：

ls -l /srv/share/report.csv
getfacl -p /srv/share/report.csv
getfattr -d -m- /srv/share/report.csv

正式恢复前先导出一份源端的基线信息留存，尤其要把所有相关命令的输出保存好。这样就算恢复后的属主因为跨环境被映射、某个xattr因为目标文件系统能力不足被跳过，也能清晰核对出所有差异，不用事后再溯源。

归档命令：把 ACL 与 xattr 一起写入 tar

GNU tar 中，--acls 保存 POSIX ACL，--xattrs 保存扩展属性。建议从目录的父级执行，让归档内路径保持稳定：

cd /srv
tar --create --file share-2026-08-24.tar \
  --acls --xattrs \
  --numeric-owner \
  share

--numeric-owner 会把数字 UID/GID 写入归档，适合跨机器恢复时避免同名用户造成误判。但它不替代 ACL，也不负责解决目标机器上 UID 不存在的问题。归档完成后，可以先查看条目，再抽查元数据：

tar --list --file share-2026-08-24.tar | sed -n '1,20p'
tar --list --verbose --file share-2026-08-24.tar | sed -n '1,20p'

恢复命令：目标目录要先准备好

恢复操作不要直接覆盖线上正在运行的生产目录。先把归档包完整解压到一个空的临时目录，做完所有元数据检查确认没问题之后，再切换目录或者同步文件过去：

install -d -m 700 /var/tmp/share-restore
tar --extract --file share-2026-08-24.tar \
  --directory /var/tmp/share-restore \
  --acls --xattrs \
  --numeric-owner

如果只在恢复端加 --acls，而归档生成时没有保存 ACL，tar 没有凭空恢复数据的来源。反过来，归档含有 xattr，但目标文件系统或挂载选项不支持对应属性时，也可能出现警告或部分跳过。这里不要用“命令成功”替代验收。

用可比较的快照验收，而不是只看文件列表

可以对源目录和恢复目录分别输出稳定的检查结果。getfacl -R -p 适合查看 ACL；getfattr -R 需要明确匹配范围，避免把不存在的属性误当成失败：

getfacl -R -p /srv/share > /tmp/share.source.acl
getfacl -R -p /var/tmp/share-restore/share > /tmp/share.restore.acl
diff -u /tmp/share.source.acl /tmp/share.restore.acl

getfattr -R -d -m- /srv/share > /tmp/share.source.xattr 2>/tmp/share.source.xattr.err
getfattr -R -d -m- /var/tmp/share-restore/share > /tmp/share.restore.xattr 2>/tmp/share.restore.xattr.err
diff -u /tmp/share.source.xattr /tmp/share.restore.xattr

两端的目录前缀不一样的话，直接diff会产出大量完全无关的差异内容，可以在对比前统一两端的路径，或者直接针对业务的单个关键文件逐个检查。验收环节至少要覆盖：目录默认ACL、命名用户的访问条目、服务依赖的安全属性、文件内容摘要和恢复后的属主属组配置。

跨机器恢复时的四个边界

文件系统能力不一致

目标端的文件系统可能不支持源端的全部xattr名称空间，容器内部、网络文件系统和受限挂载点这类场景尤其要提前做验证。先恢复到临时目录仔细查看命令输出的报错，不要直接在生产路径上反复试命令，避免误改业务运行数据。

UID/GID 相同不代表用户名相同

带上 --numeric-owner 后，tar 按数字身份恢复；如果目标机没有对应账号，ls -l 显示的名字可能变化。对服务目录，应把 UID/GID 映射和服务账号检查放进发布前清单。

ACL 的 mask 会影响最终权限

ACL 中的 mask 约束命名用户、命名组和所属组的有效权限。看到条目存在，不等于它实际拥有条目文字显示的全部权限，验收时要一起看 effective 注释。

不要把 xattr 全部当成可复制业务数据

有部分属性是和当前机器的安全策略或者挂载环境绑定的。做备份规划的时候就应该记录清楚哪些属性是必须强制保留的，哪些属性跨环境恢复时只需要记录差异、之后在目标端重新生成即可。

一份够用的最小验收清单

• 归档命令包含 --acls --xattrs，恢复命令也包含这两个选项。
• 源目录与临时恢复目录均保存了 getfacl 和 getfattr 输出。
• 抽查目录默认 ACL、命名用户规则、服务账号 UID/GID 和关键 xattr 是否和源端一致。
• 确认目标挂载点支持需要用到的所有属性；不支持的话要把差异明确记录下来，不能静默跳过直接上线。
• 确认所有关键文件的内容摘要完全一致之后，再执行目录切换或者重启业务服务。

相关问题

只用 tar -p 能保留 ACL 吗？

不能。-p 主要处理基本权限保留，ACL 与 xattr 需要各自的显式选项。

恢复后 ACL 少了一条，应该先改权限吗？

如果发现属性缺失，先确认归档文件里是不是真的正确保存了该条目，再排查目标文件系统和挂载参数的能力限制。不要直接用chmod命令覆盖权限，很容易把“元数据缺失”的小问题，变成全目录权限被误改的更大故障。

小结

tar 归档的可靠性不只由文件名和内容决定。对包含共享访问、服务账号或安全标记的 Linux 目录，--acls --xattrs 是起点，临时恢复和 getfacl/getfattr 对比才是闭环。把这些检查固化进备份脚本的验收阶段，迁移时才不会等到权限异常出现后再追溯。