Существует ли более быстрый способ копирования файлов машины времени с одного диска на другой?

Я пытаюсь переместить все файлы резервных копий моей машины времени в Backups.backupdb на другой диск. Я инициировал копирование файла в одночасье (ч / б я увидел, что OSX потребовалось целую вечность, чтобы подготовиться к копированию ... он в основном считал файлы часами). Утром я увидел, что копируются только определенные резервные копии (папки с датами). Затем я попытался скопировать те, которые не были скопированы ... но ОС не позволила мне это сделать. Я получил сообщение об ошибке: «Операция не может быть завершена, поскольку элементы резервной копии не могут быть изменены». Поэтому я планирую удалить неполную копию на новом диске, а затем снова попытаться скопировать ее в папку Backups.backupdb.

Довольно расстраивает. Есть ли более быстрый способ скопировать эти файлы с помощью команды терминала, чтобы он не выполнял всю подготовку к подсчету файлов?

Я, вероятно, могу скопировать всю папку, а затем сделать копию, но будет ли это мешать любому из прав доступа к файлу и т. Д.? Одна вещь с этим подходом состоит в том, что у меня нет больше места на моем исходном томе для tar.

ОБНОВИТЬ

Я попробовал некоторые из методов, которые люди предложили ниже, в частности, используя функцию восстановления Дисковой утилиты, и она дает мне некоторые сообщения об ошибках и неожиданные результаты (по крайней мере для меня). Я попытался сделать восстановление двумя способами:

• С установленным флажком «Удалить назначение»: каждый раз (я пытался дважды), когда восстановление завершено, я вижу сообщение «Не удалось восстановить - недопустимая операция» и «Не удалось восстановить - недопустимый аргумент». Тем не менее, мой целевой диск действительно получает копию моих файлов TM. Странно то, что мой целевой диск ТОЧНО похож на мой исходный диск ... даже его размер. Мой целевой диск на самом деле составляет 1 ТБ, но после восстановления он показывает 200 ГБ, когда я получаю информацию из поиска. Но в Дисковой утилите он показывает раздел размером 1 ТБ!

Затем я попытался проверить / восстановить диск и получил:

    Неверный размер узла B-дерева
    Проверка журнализированного объема HFS Plus.
    Неверный размер узла B-дерева
    Объемный ремонт завершен.
    Обновление разделов поддержки загрузки для тома по мере необходимости.
    Ошибка: Дисковая утилита не может восстановить этот диск. Создайте резервные копии максимально возможного количества файлов, отформатируйте диск и восстановите резервные копии файлов.

Не знаю, если я даже предположить, чтобы проверить / восстановить диск TM ...

• С опцией «Удалить назначение» снимите флажок: восстановление не начинается, и я получаю:

    Не удалось восстановить - операция не разрешена

Обычная копия (или копия с помощью rsync или ditto) не будет полностью реплицировать Time Machine, поскольку она преобразует две связанные директории (как это происходит в последовательных резервных копиях TM без изменений) в две отдельные директории.

Лучший способ - скопировать весь диск с помощью Дисковой утилиты или блочной копии Carbon Copy Cloner и, вероятно, аналогично SuperDuper .

При переносе полностью зашифрованного диска Time Machine объемом 3 ТБ на новый 8 ТБ в macOS 10.14 я столкнулся с множеством проблем. При попытке выполнить восстановление в Дисковой утилите произошла ошибка «невозможно проверить источник» или «Операция не разрешена». Пробуя некоторые другие предложения в этом и других постах, я смог получить новые захватывающие сообщения об ошибках типа «Файл каталога на изображении / томе слишком сильно фрагментирован», но без копии.

Что сработало в итоге на терминале:

1. Сотрите новый диск с помощью Дисковой утилиты, соответствующей формату исходного диска: MacOS Extended (Journaled, Encrypted)
2. Используйте diskutil cs listв терминале, чтобы получить точный размер байта логического тома на старом диске и GUID нового логического тома, а также номера дисков для обоих, например disk4.

3. Используйте точный размер байта из шага 2 в качестве размера нового тома. В моем случае с диском объемом 3 ТБ это было 2,999,772,905,472 байта:

   sudo diskutil cs resizeVolume $new_lv_guid 2999772905472
   

4. Используя pvкоманду из homebrew, сделайте низкоуровневую блочную копию дисков. Это очень похоже на использование dd, за исключением того, что вы получаете индикатор прогресса с ETA.

   Вам нужно получить номера дисков с diskutil cs listвыхода. Быть осторожен. Здесь очень легко случайно перезаписать ваш полный резервный диск новым пустым.

   sudo sh -c "$(which pv) --buffer-size 50M -s 2999772905472 < /dev/rdisk${source} > /dev/rdisk${target}"
   

   Если вы получили ошибку «Отказано в разрешении / операция запрещена», перейдите в «Настройки безопасности и конфиденциальности» и добавьте «Полный доступ к диску» для Terminal.app.

   Для меня это заняло около 10 часов - я позволил ему работать в течение ночи - но pv, по крайней мере, вы получаете индикатор прогресса с ETA.

5. Теперь увеличьте громкость, чтобы занять все оставшееся место на диске:

   sudo diskutil cs resizeVolume $new_lv_guid 0
   

   Это заняло у меня ~ 3 часа, с резервным копированием около 5 лет. Большая часть этого времени была потрачена на MacOS fsck.

Теперь вы можете наслаждаться новым, более просторным дисководом Time Machine. Вы можете переназначить старый или убрать его в безопасное место на случай, если что-то случится с новым диском.

Шаги изменения размера кажутся важными; в результате их пропуска была получена 10-часовая копия файла с объемом тома 8 ТБ, содержащим файловую систему 3 ТБ, которую я не мог понять, как изменить размер.

ОБНОВЛЕНИЕ Один потенциальный недостаток этого подхода состоит в том, что, поскольку это битовая копия, идентификаторы одинаковы между старым диском и новым диском. Если я подключу старый полный диск, Time Machine решит, что это новый диск, попытается выполнить резервное копирование и начнет удалять старые резервные копии, чтобы освободить место для новых. Это кажется хорошим подходом для перемещения данных на больший диск, где старый диск меньшего размера будет затем стерт.

Почему бы просто не использовать терминал:

cp -RnpP Backups.backupdb

• -R рекурсивный
• -n не перезаписывать (если существующие копии остаются от предыдущей попытки)
• -p сохранить ACL, разрешения, даты создания / модификации и т. д.
• -P сохраняйте жесткие ссылки, не переходите по жестким или символическим ссылкам.

Этот ответ не поможет сделать это быстрее, но я нашел способ правильно копировать данные, сохраняя дедупликацию (жесткие ссылки) и разрешения. В качестве дополнительного бонуса я использую это для создания сжатого dmg конечного продукта для архивирования.

1. Используя Дисковые утилиты, создайте образ диска, который будет больше, чем каталог Backups.backupdb. Я бы также предложил вам использовать образ диска с разреженным комплектом для формата изображения и жесткого диска для разделов. После того, как этот образ смонтирован, получите информацию о нем и снимите флажок Игнорировать владение этим томом.

2. Теперь выключите Time Machine и с помощью искателя скопируйте папку Backups.backupdb в смонтированный образ. Нашедший попросит у вас разрешения суперпользователя на копирование данных. Выпить или сделать что-нибудь еще на некоторое время.

3. Когда копия будет готова, убедитесь, что все в порядке, и размонтируйте изображение. В Дисковой утилите выберите «Преобразовать» и превратите изображение разреженного пакета в сжатое изображение. Опять же, это может занять некоторое время.

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

Одна вещь, которую я не пробовал с этим, это выполнить восстановление системы из dmg, но я подозреваю, что оно должно работать, моя цель была больше для архивации инкрементальных изменений машины времени и сохранения структуры жестких ссылок.

Я также пробовал rsync и cp, но они, похоже, не сохранили структуру жестких ссылок, которая в конечном итоге делала бы х раз больше, х - количество дат, которые вы имели в прошлом. Этот метод работал хорошо, но опять же не может получить скорость решения блочного копирования.

У Apple есть официальное руководство по этому вопросу: « Машина времени: как перенести резервные копии с текущего резервного диска на новый резервный диск ».

Шаги высокого уровня с этой страницы:

1. Проверьте формат вашего нового резервного диска
2. Установите разрешения на новый резервный диск
3. Временно выключите Time Machine
4. Скопируйте данные резервной копии с исходного диска на новый диск
5. Настройте Time Machine на использование вашего нового диска

Вот как страница рекомендует выполнить шаг копирования:

Скопируйте данные резервной копии с исходного диска на новый диск

1. Откройте новое окно Finder. На боковой панели Finder щелкните значок исходного резервного диска.
2. Откройте новое окно Finder. На боковой панели Finder щелкните значок нового резервного диска.
3. Перетащите папку «Backups.backupdb» с исходного резервного диска на верхний уровень нового резервного диска.
4. Введите имя администратора и пароль, затем нажмите OK, чтобы начать процесс копирования.

Копирование данных резервной копии может занять некоторое время, в зависимости от размера резервной копии.

+1 для дисковых утилит, слишком долго для комментариев:

Оценено 12,250,329 файлов, скопировано 10,408,594 файлов. Эффективная скорость копирования 8,68 МБ / с.

для клонирования магнитного накопителя на 2 ТБ с резервным копированием на несколько лет через SuperDuper! этот год.

В общей сложности это заняло 63 часа (SuperDuper сбрасывал свои часы каждые 24 часа, поэтому в итоге показывалось 15:04:43), в отличие от копии Finder, которую я отменил примерно через 4 дня и четверть файлов.

Очевидно, что магнитный диск не был причиной того, что это заняло так много времени. Причиной того, что Finder копирует стойло на резервных дисках, работающих в течение длительного времени, является огромное количество каскадных символических ссылок на неизмененные файлы, особенно для многих небольших файлов, таких как индексы Git.

rsync - отличная утилита для подобных вещей. Я обычно использую это для подобных вещей. В этом случае я мог бы использовать флаги -aP. Я думаю, что часть -a («архив») также предназначена для сохранения разрешений, ACL и т.п., но я не уверен.

Во IIRC есть также опция --delete, которая позволяет вам удалить исходный файл после его успешного копирования в место назначения. Хотя я бы с осторожностью использовал это - обычно я делаю полное зеркало без опции --delete, затем я снова запускаю команду с опциями -c и --delete. -c - это контрольная сумма, поэтому она проверяет все файлы, которые вы скачали, по сравнению со всеми файлами в источнике с помощью контрольной суммы, а затем удаляет источник, если есть совпадение, в противном случае он повторно копирует или возобновляет копирование в зависимости от обстоятельств.

РЕДАКТИРОВАТЬ: пожалуйста, используйте флаг -H в этом случае в соответствии с комментариями, чтобы сохранить жесткие ссылки.

На жестких дисках, когда вы перемещаете несколько файлов с одного диска, считыватель перемещается назад и вперед с пугающим шумом щелчка, и это значительно замедляет скорость передачи, например, - один файл с usb 2.0 перемещается со скоростью 30 Мбит / с на моем компьютере из 2 внешние жесткие диски, но 2 файла перемещаются со скоростью 11 Мбит / с. и 3 файла перемещаются со скоростью 6 Мбит / с. и т.д. и т.п. почтовые файлы будут перемещаться быстрее, чем файлы.