记录一下那天晚上的排查过程。共享目录用 setfacl -Rm g:dev:rwx 给开发组开了写权限，每天凌晨用 rsync 做一次备份，恢复演练时发现备份里 getfacl 的输出是空的，权限全变成了默认的 755。
刚开始盯着「目标文件系统的挂载选项里没有 acl」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。rsync 的 -a 不带 ACL，需要显式加 -A。还有一种是备份脚本用的是 tar，打包时没有加 --acls。
少数情况下是源目录的 ACL 是继承来的，新建文件时 default ACL 没同步。
动手时先看源和目标的 ACL 差异
getfacl -R /data/share | head -30 && getfacl /backup/share随后确认挂载是否支持 acl
findmnt -T /backup -o OPTIONS带 -A 参数重新同步并保留扩展属性
rsync -aHAX --numeric-ids /data/share/ /backup/share/剩下的就是把默认 ACL 一起补上
setfacl -Rm d:g:dev:rwx /data/share怎么算真的好了，看的是同一批现象。getfacl 在备份目录里能看到与源一致的条目，开发组用户对备份目录的写权限正常，恢复演练通过。
这里还有个坑。ACL 只是权限的一部分，SELinux 上下文也要用 -X 同步；脚本里加上 -HAX 之后记得定期做一次恢复演练。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。