（首发地址：学习日记 https://www.learndiary.com/2024/06/bsdtar-numeric-owner/）
朋友们，大家好！我是来自淘宝网学习日记小店的 learndiary，专注于 Linux 服务领域。今天，我想和大家分享一次我在进行 Linux 全系统迁移时所遇到的问题，以及如何解决这个问题的经历。视频演示：【Linux 系统迁移中的 bsdtar 备份陷阱与解决方案】 https://www.bilibili.com/video/BV14T421e7rB/
Linux 系统迁移中的 tar（bsdtar）备份陷阱与解决方案
几天前，我正在进行一个Linux系统的迁移项目，使用的正是我之前在日记“用 bsdtar 做 Linux 全系统迁移”https://www.learndiary.com/2024/03/migrate-linux-with-bsdtar/中提到的 bsdtar 工具。这次迁移的源系统是 CentOS 7.5，而在原系统上完成了系统压缩备份后，我选择了一个不同的环境——CentOS 7.8 的 LiveCD——来进行备份的恢复。这种不同环境下的恢复操作导致了一个与 /etc/ssh 目录下的文件相关的问题。
问题的核心在于，sshd 服务在恢复后无法启动，因为原本属于 ssh_keys 组的文件，在恢复过程中被错误地映射到了数字 992 的组，而这个数字在目的系统中并不存在对应的组名。结果，sshd 服务在启动时遇到了权限问题，导致失败。
那么，为什么会出现这样的问题呢？这与 bsdtar 或 tar 这类备份工具的一个关键参数 --numeric-owner 有关。当使用这个参数时，工具会始终采用数字用户和数字组来恢复文件，而不是依赖于字符名称。为了更好地理解这一点，我决定在虚拟机中进行实操演示。
在演示中，我首先在运行的 CentOS 7.9 系统上用 bsdtar 创建了一个 /etc/ssh 的备份，注意到了其中ssh_keys组的数字ID是999。创建备份的命令为“sudo bsdtar -cvf ssh_test.btar ssh”。
然后，用 CentOS 7.8 LiveCD 启动系统，这里作为对比，我使用了两个不同的方法来恢复这个备份：一个是默认的恢复方法，命令为“sudo bsdtar -xvf ssh_test.btar -C ssh_test”；另一个则加上了 --numeric-owner 参数，命令为“sudo bsdtar -xvf ssh_test.btar -C ssh_test2 --numeric-owner”。
结果表明，当不使用 --numeric-owner 时，恢复后的组名虽然在 CentOS 7.8 LiveCD 保持了 ssh_keys，但其数字 ID 在 LiveCD 系统和目的系统中被错误地改变为 992，导致了权限问题会使 sshd 服务无法启动。而使用 --numeric-owner 后，在 LiveCD 和目的系统中数字 ID 保持为 999，恢复的组名在目的系统中也正确地对应上了 ssh_keys，保证了 sshd 服务的正常启动。
总结来说，当我们使用 bsdtar 或 tar 进行系统迁移时，尤其是在不同环境间进行备份恢复的情况下，务必记得使用 --numeric-owner 参数。这将确保数字用户和组的准确恢复，避免因环境差异而引起的权限问题。希望我的经验分享能帮助大家在进行类似的迁移任务时少走弯路。
最后，如果我对这一机制的理解有任何不准确之处，欢迎大家指正。感谢大家的观看，我们下次分享再见！
参考网址：
Backup Your System with TAR：https://help.ubuntu.com/community/BackupYourSystem/TAR
)
