(首发地址:学习日记 https://www.learndiary.com/2024/06/bsdtar-numeric-owner/)
朋友们,大家好!我是来自淘宝网学习日记小店的 learndiary,专注于 Linux 服务领域。今天,我想和大家分享一次我在进行 Linux 全系统迁移时所遇到的问题,以及如何解决这个问题的经历。视频演示:【Linux 系统迁移中的 bsdtar 备份陷阱与解决方案】https://www.bilibili.com/video/BV14T421e7rB/
几天前,我正在进行一个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