Time Machine を使用して Time Capsule にバックアップすると、バックアップはスムーズに機能します。問題は、2 つのバックアップの違いを確認するために 'tmutil compare' を使用しようとしていることです。MacOS Mojave 10.14.5 (以前の OS バージョンでも同じ問題)。
アプリケーション
Time Machine を使用して、ネットワーク上の複数の Mac を複数のバックアップ ドライブにバックアップします。その目的は、定期的に「tmutil compare」操作を実行して、バックアップされている内容、ファイルの数、データの量などを確認することです。
BackupLoupe のようなアプリは、これの GUI を提供しますが (これは便利です)、各スパースバンドルを手動でマウントする必要があります。 (ちなみに、Mojave では動作しなくなったようです。)
したがって、プロセスを自動化することが目的でした。
- tmutil destinationinfo を使用して、バックアップ ドライブのリストを確認します。
- すべてのドライブをマウントする（マウントポイントを別々にする）
- 各ドライブを調べて Mac のリストを取得します (例: mymac1.sparsebundle、mymac2.sparsebundle、...)
- 各 Mac の各ドライブ (その Mac 用の sparsebundle がある) に対して、sparsebundle をマウントし、Backups.backupdb ノードがあることを確認し、すべてのバックアップ (2019-05-22-111213) を一覧表示し、各エントリと前のエントリの間で 'tmutil compare' を実行します。
キャッシュは自動的に維持されるため、「tmutil compare」ステップは新しいバックアップに対してのみ実行されます。
「tmutil compare」は長時間かかる可能性があるため、ステップ (4) は各 Mac が処理され、ディスクごとに 1 つずつ個別のスレッドが開始されて並列実行されるように設計されています。追加の 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 にマウントされます。マウントされた sparsebundle に 'cd' できます。'ls' は、期待どおりにすべてのバックアップ ファイルを一覧表示します。
ただし、再度 tmutil compare 2019-05-19-034451 2019-05-18-220446 を実行すると、次の結果が得られます。
Must specify at least one item inside a backup.
実際に 2019-05-19-034451 バックアップまたは他のバックアップに 'cd' することができ、'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 はログを更新しようとしているのでしょうか。
ご協力やご提案をいただければ幸いです。
アップデート
2つのステップを分解して、ドライブmount_aspでマウントし、バンドルDiskImageManager を使用すれば、動作します。問題は、hdiutil と DiskImageManager の使用にあります。
アップデート2
まだ作業中だが、どうやら「tmutil」のようだ必要バンドルが /Volumes 内にマウントされるようにしてください。
シンボリックリンクを作成して騙そうとしました:
/Volumes/Time Machine Backups -> my mount point
しかし、まだ失敗します。他の回避策を試みます。
これが tmutil の真の要件であるかどうか知っている人はいますか? どこかに文書化されていますか?
解決しました（ただしハッキングです！）
/Volumes にルート マウント ポイントを追加して、その下に複数のスパースバンドルをマウントしようとしましたが、これも機能しませんでした。明らかに、'tmutil' はバンドルが /Volumes の直接の子としてマウントされることを想定しています。
最終的なハックは次のとおりです。
- ドライブのマウントポイントを作成します: ../mycache/drives
- このノードの下のすべてのドライブをマウントします
- すべてをマウントバンドル/Volumes 内で通常のデフォルト名を使用 - Time Machine バックアップ [n]
- 内部的には、Time Machine バックアップ [n] のすべての種類をリストして各ドライブに一致するマウントを見つけ、バンドルをマウントし、Time Machine バックアップ [n] のリストを再度取得して、新しいマウントを見つけます。
- 次に、tmutil compare /Volumes/Time Machine Backups 2/Backups.backupdb/mymac/... を実行します。
これはかなりうまく機能します。他のプロセスが Time Machine バックアップ エントリを含む sparsebundle をマウントすると失敗し、上記のロジックが混乱します。