4

Мой новый жесткий диск умер на прошлой неделе, и мне пришлось поместить резервную копию моего старого диска в мой Mac Mini, на котором установлен Snow Leopard. Затем я смог восстановить свою последнюю резервную копию Time Machine.

Когда я обновил несколько месяцев назад, я использовал Carbon Copy, и у меня были проблемы с разрешением.

Итак, в моей системе сейчас находится мой старый диск, но когда я пытаюсь сделать резервную копию Time Machine, это ОЧЕНЬ медленно. Он использует те же настройки / местоположения, что и раньше. Я скачиваю ТМ 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

Я пытаюсь сделать резервную копию, чтобы я мог вставить другой новый диск, чтобы я мог восстановить Time Machine, как я делал на прошлой неделе.

Что я могу сделать, чтобы решить эту проблему?

|источник

2 ответа2

9

Чтобы это исправить: подождите.

  • После выполнения полного восстановления Time Machine всегда создает полную резервную копию. Не зная, почему Apple считает, что это необходимо, я бы предпочел надежную резервную копию со временем и дисковым пространством. См. Также Apple Mac OS X 10.5: Time Machine выполняет полное резервное копирование после полного восстановления.

  • Во всех других случаях: Time Machine обнаружила, что не может определить, что находится в вашей резервной копии, а что нет, и должна сравнить оба. Вы, вероятно, также видите, что Node requires deep traversal .

Это не связано с идентификатором самого диска (оборудования). TM хранит идентификатор FSEvents, который он использовал для последней резервной копии, в "расширенном атрибуте" com.apple.backupd.SnapshotVolumeLastFSEventID на диске. Обычно все, что требуется для определения того, что изменилось, - это сравнить это значение с идентификатором, известным в OS X. Однако, если по какой-то причине базе данных OS X FSEvents больше нельзя доверять, она создает новую, которая меняет свою уникальную UUID. TM проверяет, можно ли использовать базу данных FSEvents для конкретного резервного диска, сравнивая этот уникальный UUID с UUID, который хранится вместе с резервной копией, в com.apple.backupd.SnapshotVolumeFSEventStoreUUID . Таким образом, после создания новой базы данных FSEvents эти идентификаторы UUID больше не совпадают, и TM необходимо сравнить жесткий диск с резервной копией или создать полную резервную копию.

|источник
1

Я обнаружил, что проблема UUID решена, и резервное копирование продолжается после многих сообщений, подобных этому:

15.03.12 1:49: 35.010 PM com.apple.backupd: Ожидание готовности индекса (100)

НО, только если на резервном диске достаточно места. Мой диск был очень заполнен, и это «ожидание индекса» продолжалось до тех пор, пока я не освободил место на диске.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .