我使用过许多 OSX 客户端计算机，它们通过时光机器到 Ubuntu Linux 文件服务器上的 AFP 共享，由 netatalk/afpd 导出。这些客户端每天在一天中的任意时间备份。服务器上还有其他重要的非 TimeMachine AFP 共享。
在服务器上，TimeMachine 备份表示为稀疏束- 一种涉及许多“带区”的数据存储格式 - 存储在标准 EXT4 文件系统中。此稀疏包中隐藏着一个磁盘映像，其中包含 TimeMachine 使用的 HFS+ 文件系统，但从服务器端来看，它只是带区文件和一些顶级元数据的集合。
快照每 4 小时在服务器上运行一次，并将稀疏束带文件和元数据备份到可移动媒体上（用于异地存储）。因此，rsnapshot 也会在一天中的任意时间备份这些稀疏束带。rsnapshot 使用 rsync 执行复制。
问题是，如果在客户端机器安装其稀疏束时运行 rsnapshot，我担心 rsnapshot 可能会捕获稀疏束的不一致状态，因为在备份过程中频带可能会发生变化。显然，这不利于保证可恢复的备份！
我正在想办法解决这个问题。看来重要的是，rsnapshot 尝试进行备份时不要安装 sparsebundle。从服务器端来看，目前我能想到的唯一方法是关闭 aftp 守护进程，可能要等待 OSX 客户端卸载 sparsebundle。这样做的缺点是，它还会使其他非 TimeMachine AFP 导出也脱机，这对用户来说是不可接受的。据我所知，afpd 不提供（轻松）添加或删除导出的方法 - 虽然一种选择可能是自动重写 afpd 的配置文件以在 rsnapshot 备份期间禁用 TM 导出，但这仍会在短时间内关闭 AFP 共享。
有没有更好的办法？
答案1
对于一组 Mac 电脑，我会避免使用 Time Machine。它存在太多问题，包括稀疏的捆绑包和备份损坏。
当遇到类似的情况时，我发现 Time Machine 方法不适合生产，因此选择了 CrashPlan。
答案2
想法。
在 Mac 设备上运行快照进行实际备份，Time Machine 备份将作为补充。
是的，最好有一个 Time Machine 映像来进行恢复，但是使用 rsnapshot 来恢复文件也是一个好主意。
我正在使用使用 Jungle Disk 的亚马逊 S3 安装驱动器来存储 rsync 或快照图像。