web-dev-qa-db-ja.com

ディスクを交換した後のTimeMachine「イベントストアのUUIDがボリュームと一致しません」

私の新しいハードドライブは先週死に、古いドライブのバックアップをSnowLeopardを実行しているMacMiniに入れなければなりませんでした。その後、最新のTimeMachineバックアップを復元することができました。

数か月前にアップグレードしたとき、カーボンコピーを使用しましたが、権限に問題がありました。

そのため、現在、システムに古いドライブがありますが、Time Machineバックアップを実行しようとすると、非常に遅くなります。以前と同じ設定/場所を使用しています。ダウンロードします TM Buddy 、つまり...

Starting standard backup
Backing up to: /Volumes/Mac Time Machine/Backups.backupdb
Event store UUIDs don't match for volume: Macintosh HD
Waiting for index to be ready (100)
Waiting for index to be ready (100)
Node requires deep traversal:/ reason:must scan subdirs|new event db|
No pre-backup thinning needed: 109.39 GB requested 
      (including padding), 121.15 GB available

先週と同じように、別の新しいドライブを挿入できるようにバックアップを作成して、TimeMachineの復元を実行しようとしています。

この問題を解決するにはどうすればよいですか?

4
Jules

これを修正するには:待ちます。

  • 完全復元を実行した後、TimeMachineは設計上常に完全バックアップを作成します。 whyAppleはこれが必要だと考えているので、時間とディスク容量を超えた信頼性の高いバックアップをお勧めします。を参照してください。また、Appleの Mac OS X 10.5:TimeMachineは完全復元後に完全バックアップを実行します

  • 他のすべての場合:Time Machineは、バックアップに何があるか、何がないかを判断できないことを検出したため、両方を比較する必要があります。おそらくNode requires deep traversalも表示されています。

これは、ディスク(ハードウェア)自体のIDとは関係ありません。 TMは、最後のバックアップに使用した FSEvents ID をディスク上に保持します "拡張属性"com.Apple.backupd.SnapshotVolumeLastFSEventID。通常、何が変更されたかを判断するために必要なのは、その値をOS Xが認識しているIDと比較することだけです。ただし、何らかの理由でOS X FSEventsデータベースが信頼できなくなった場合は、新しいデータベースが作成され、一意のデータベースが変更されます。 UUID。 TMは、その一意のUUIDをバックアップとともにcom.Apple.backupd.SnapshotVolumeFSEventStoreUUIDに格納されているUUIDと比較することにより、FSEventsデータベースを特定のバックアップディスクに使用できるかどうかを確認します。したがって、新しいFSEventsデータベースが作成された後、これらのUUIDは一致しなくなり、TMはハードディスクをバックアップと比較する必要があるか、完全バックアップを作成する必要がある場合があります。

9
Arjan

UUIDの問題が解決され、次のような多くのメッセージの後にバックアップが続行されることがわかりました。

3/15/12 1:49:35.010 PM com.Apple.backupd:インデックスの準備ができるのを待っています(100)

ただし、バックアップドライブに十分なスペースがある場合のみ。私のドライブは非常にいっぱいで、この「インデックスの待機」は、ドライブのスペースを取り戻すまで永遠に続きました。

1
Jack