☰

mac tmutil 比较是否成功取决于 bundle 的安装位置

tag-icon • tag-icon mac backup mount comparison
mac tmutil 比较是否成功取决于 bundle 的安装位置

使用 Time Machine 到 Time Capsule - 备份工作顺利。问题是尝试使用“tmutil compare”来查看 2 个备份之间的差异。MacOS Mojave 10.14.5（以前的操作系统版本也有同样的问题）。

应用程序

使用 Time Machine 将网络上的多台 Mac 备份到多个备份驱动器。目的是定期运行“tmutil 比较”操作以查看正在备份的内容、有多少文件、有多少数据等。

像 BackupLoupe 这样的应用程序会提供 GUI - 这很好 - 但您必须手动安装每个 sparsebundle。（顺便说一句，它似乎已经停止与 Mojave 合作了。）

因此我们的目的是使这个过程自动化：

  1. 使用 tmutil destinationinfo 确定备份驱动器的列表。
  2. 挂载所有驱动器（到单独的挂载点）
  3. 检查每个驱动器以获取 Mac 列表（即 mymac1.sparsebundle、mymac2.sparsebundle，...）
  4. 对于每台 Mac、每个驱动器（该 Mac 具有一个 sparsebundle），安装 sparsebundle，确保它有一个 Backups.backupdb 节点，列出所有备份（2019-05-22-111213），在每个条目和后续条目之间运行“tmutil compare”。

缓存会自动维护，因此“tmutil 比较”步骤仅针对新备份运行。

由于“tmutil compare”可能需要很长时间，因此步骤 (4) 的设计是处理每台 Mac，并启动单独的线程（每个磁盘一个线程）以并行运行。假设为其他 Mac 启动更多线程只会造成对相同驱动器的访问竞争瓶颈。

这有效

使用 Finder 连接到 Time Capsule（在后台创建 /Volumes/mydisk）。在 Finder 中，找到感兴趣的 mymac.sparsebundle 并使用 DiskImageMounter 打开它（在后台创建 /Volumes/Time Machine Backups）。

进入终端并：

   cd "/Volumes/Time Machine Backups/Backups.backupdb/mymac"
   tmutil compare 2019-05-19-034451 2019-05-18-220446

输出完全符合预期。

失败了

创建 2 个目录 - ../mytemp/mount 和 ../mytemp/bundle（作为挂载点）。运行 tmutils destinationinfo 以获取挂载字符串。

执行：mount_afp -o rw "afp://tc:pwd@tc._afpovertcp._tcp.local./diskname" ../mytemp/mount

执行：hdiutil attachment ../mytemp/mount/mymac.sparsebundle -readwrite -mountroot ../mytemp/bundle

执行：cd“../mytemp/bundle/Time Machine Backups/Backups.backupdb/mymac”

这些都按预期工作。mymac.sparsebundle 已安装到 ../mytemp/bundle。可以“cd”进入已安装的 sparsebundle。“ls”按预期列出所有备份文件。

但再次执行：tmutil compare 2019-05-19-034451 2019-05-18-220446 并得到以下结果：

Must specify at least one item inside a backup.

实际上可以“cd”到 2019-05-19-034451 备份或其他，“ls”显示的内容正是预期的内容。可以“cd”向下几层，“cat”一些文件到控制台等。

在两种方式安装后都下降到相同的级别，并发出“touch dummy.file.txt”以实际创建文件。此操作失败，但添加“sudo”成功 - 在两种安装情况下均如此。（在给定的备份中，此操作在任一设置下均失败。）

如果出现授权问题，还尝试了“sudo tmutil ...”，但结果相同。还在不同级别执行了一些“ls -la”命令，但分配给任何内容的“rwx”没有明显差异。

将 tmutil 添加到系统属性中的完整磁盘访问列表中。

运行：log show--predicate'process=="tmutil"'

但成功和失败的情况都显示相同的输出。

束手无策！有什么区别 - 上下文、权限、??? Finder 和 DiskImageMounter 与 mount_afp 和 hdiutil 有什么不同？某种级别是只读的，而 tmutil 正在尝试更新日志吗？

非常感谢任何帮助或建议！

更新

分为两个步骤 - 安装驾驶使用 mount_asp，然后挂载捆使用 DiskImageManager - 并且可行。因此问题在于使用 hdiutil 还是 DiskImageManager。

更新 2

仍在开发中，但显然是“tmutil”需要该捆绑包被安装在/Volumes 内！

尝试通过创建符号链接来欺骗它：

/Volumes/Time Machine Backups -> my mount point

但仍然失败。尝试其他解决方法。

有人知道这是否是 tmutil 的真正要求吗？有记录吗？

已解决（但是是黑客行为！）

尝试将根挂载点添加到 /Volumes，然后在下面挂载多个稀疏包 - 但这也行不通。显然，“tmutil”希望将包挂载为 /Volumes 的直接子项。

最终破解如下：

  1. 为驱动器创建挂载点：../mycache/drives
  2. 装载此节点下的所有驱动器
  3. 全部装载捆绑在 /Volumes 中使用正常默认名称 - Time Machine Backups [n]
  4. 在内部，通过列出所有类型的 Time Machine Backups [n] 来确定哪个挂载与每个驱动器匹配，然后挂载捆绑包，再次获取 Time Machine Backups [n] 列表以确定哪个是新的挂载。
  5. 然后运行 ​​tmutil 比较 /Volumes/Time Machine Backups 2/Backups.backupdb/mymac/...

这工作得相当好。如果其他进程装载了带有 Time Machine Backups 条目的稀疏包，则会失败 - 会混淆上述逻辑。

相关内容