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

15

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

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

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

ОБНОВИТЬ

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

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

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

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

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

  • С опцией «Удалить назначение» снимите флажок: восстановление не начинается, и я получаю:
    Не удалось восстановить - операция не разрешена
milesmeow
источник
2
Я думаю, что это хорошо - другой вопрос касается нагрузки ввода-вывода при копировании жестких ссылок, но обернут в сеть и оболочку временной капсулы, так что это частный случай общей проблемы, задаваемой здесь.
bmike
Если вы можете обновиться до MacOS 10.13.4+, то ошибка, которая препятствовала копированию псевдонимов / жестких ссылок в Finder, была исправлена. Я попробовал сам скопировать резервный диск Time Machine на другой, и он работал отлично (и это было довольно быстро). Более подробная информация здесь: apple.stackexchange.com/a/323691/261070 .
youngrrrr

Ответы:

13

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

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

user151019
источник
1
Со страницы руководства ditto: «ditto сохраняет жесткие ссылки на файлы (но не жесткие ссылки на каталоги), присутствующие в исходных каталогах», так что здесь не поможет. Это либо Дисковая утилита, либо такой инструмент, как SuperDuper или CCC.
холме
@patrix Спасибо - на веб-странице руководства ничего не сказано об этом - CCC использует ditto или rsync для копирования, поэтому будет делать это только в том случае, если он выполняет блочное копирование help.bombich.com/kb/trou устранения/…
user151019
Мой исходный диск содержит только резервную копию Time Machine. Мой целевой диск содержит другие файлы. Я не хочу клон моего исходного диска. Я просто хочу скопировать файлы Time Machine на целевой диск.
мильсмэу
3
После многих попыток скопировать мои файлы TM на новый диск, Disk Utility и Carbon Copy Cloner оба НЕ сделали этого. SuperDuper сделал это отлично при первом запуске и не уменьшил размер моего целевого раздела!
мильмей
2
Еще один голос за SuperDuper! Вот. v3.2.4 успешно скопировал большую резервную копию папки Time Machine на новый диск под macOS 10.14.2 Mojave, не занимая больше места. (Что Finder не смог сделать…) Time Machine с радостью продолжает использовать новый диск, как если бы он был старым.
Gidds
5

При переносе полностью зашифрованного диска 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 решит, что это новый диск, попытается выполнить резервное копирование и начнет удалять старые резервные копии, чтобы освободить место для новых. Это кажется хорошим подходом для перемещения данных на больший диск, где старый диск меньшего размера будет затем стерт.

Андрей
источник
Привет Андрей! Спасибо, что нашли время напечатать это пошаговое руководство (и я надеюсь использовать его для переноса моей резервной копии объемом 1 ТБ на диск объемом 4 ТБ, что до сих пор не удавалось, поскольку папки и файлы, скопированные программой Finder) занимают намного больше места на новом диске, чем на оригинальном). У меня к вам вопрос: могу ли я выполнить эти шаги без cs включенной поддержки corestorage? Включение основного хранилища представляется потенциально ненужным PITA , но это может быть необходимо из-за шага 3
руководства.
@MichaelDautermann Core Storage необходим для FileVault, который чрезвычайно рекомендуется для резервных дисков, чтобы защитить вашу конфиденциальность в случае потери, кражи или неправильной утилизации.
Андрей
Я хотел бы добавить, что я не смог скопировать с помощью упомянутого метода. Причина была в том, что система подсказала, что «операция не разрешена». После короткого поиска я обнаружил, что мне нужно отключить все функции SIP. Это можно сделать, перезапустив macOS, удерживая команду + R и открыв терминал. Здесь вам нужно отключить, набрав "csrutil disable". При следующем перезапуске я смог скопировать резервную копию TM
Оливер Келер,
@ andrew моя версия 10.14.6, и я полностью понимаю риск, который вы упомянули. Однако я не смог выполнить резервное копирование TimeMachine - dd или pv без отключения SIP. Если есть другой способ, я был бы рад услышать.
Оливер Келер
Я продолжаю получать «pv: write failed: Ошибка ввода / вывода» на 99% (через 30 часов, 3 попытки - так что действительно 90 часов). Диски размонтированы. Функции SIP отключены. Погуглив ошибку, ничего не придумаешь. Аналогично исходной ситуации (3 ТБ -> 8 ТБ). sudo sh -c "$(which pv) --buffer-size 50M -s 3000249008128 < /dev/rdisk3 > /dev/rdisk5"- 8Tb ранее был успешно измененResized Core Storage Logical Volume to 3,000,249,008,128 bytes
ks
2

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

cp -RnpP Backups.backupdb
  • -R рекурсивный
  • -n не перезаписывать (если существующие копии остаются от предыдущей попытки)
  • -p сохранить ACL, разрешения, даты создания / модификации и т. д.
  • -P сохраняйте жесткие ссылки, не переходите по жестким или символическим ссылкам.
chaseholden
источник
Это неправда. Читайте man cpдля macOS. Обычная cpкоманда, поставляемая с macOS , не копирует жесткие ссылки с -P. На странице руководства написано: «Обратите внимание, что cp копирует жестко связанные файлы как отдельные файлы. Если вам нужно сохранить жесткие ссылки, рассмотрите возможность использования tar (1), cpio (1) или pax (1) вместо этого».
Chmac
0

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

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

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

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

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

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

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

Ганц
источник
0

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

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

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

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

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

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

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

Дэвид Андреолетти
источник
5
Я, например, смотрю на этот вопрос, потому что, следуя этому руководству (которое предлагает скопировать папку резервной копии с помощью Finder) и оставляя его работающим на ночь, он закончился из-за проблемы с разрешением около 500/940 ГБ. Я тогда делал sudo rsyncпрошлой ночью, но этим утром нашел, ERROR: out of memory in flist_expand [sender]и моя копия теперь ~ 600 ГБ. Я еще не решил, что делать дальше, но подозреваю, что большинство читающих уже знают официальный учебник.
PeterT
@PeterT Я тоже попробовал туто и получил ту же проблему, что и ты. Я не уверен, что кто-то знал об учебнике, иначе кто-то упомянул бы его здесь и его результаты. Теперь люди знают, что не стоит пытаться.
Дэвид Андреолетти
1
Использование искателя для копирования папки занимает много времени, чтобы создать список файлов, а затем все равно дает сбой из-за недостатка места на диске, поэтому он должен быть просчитан.
Малхал
1
Это именно моя проблема. Оригинальный объем ТМ составляет 550 ГБ, новый - 600 ГБ. Тем не менее Мохаве жаловался на недостаток места на томе. Я пользуюсь сейчас SuperDuper! в режиме «Резервное копирование - все файлы».
Маркус Рудель
1
Учебник Apple для меня не удался , в MacOS Mojave 10.14.2. Я попытался скопировать архив резервных копий объемом 3 ТБ на диск объемом 8 ТБ; Finder потратил почти 5 дней на копирование (в большинстве случаев говоря «осталось 5 секунд»), а затем сдался и пожаловался на переполнение диска! И это было - даже при том, что это только скопировало приблизительно 2/3 резервных копий. Понятно, что это не сохранение жестких ссылок, а создание новых копий каждого. Так что этот ответ в настоящее время не верен.
Gidds
0

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

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

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

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

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

Парацетамол
источник
0

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

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

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

Харв
источник
5
rsync не поддерживает жесткие ссылки на каталоги. Копирование
временной
1
@patrix - я могу это подтвердить. Я попробовал это. Жесткие ссылки на каталоги почти уникальны для HFS +, и rsync их не понимает.
Фальшивое имя
3
-H, --hard-links сохраняют жесткие ссылки
Пит Эшдаун,
-2

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

Джейк Томас
источник
2
Как это отвечает на вопрос ОП?
ФСБ