Размер Time Machine взрывается при копировании на новый диск

Question

Я пытаюсь заменить накопитель USB2 емкостью 640 ГБ, который я использую в качестве устройства резервного копирования Time Machine, на накопитель FireWire 400 емкостью 1 ТБ без потери текущей истории резервного копирования. Учитывая, что диск 640 ГБ почти заполнен и лимит передачи 400 Мбит / с этой комбинации, я понял, что этот процесс может занять довольно много времени и может быть прерван в середине. В результате я решил попробовать сделать это с помощью rsync вместо Finder (как предлагает Apple). После нескольких неудачных попыток поиска и поиска в Интернете я остановился на следующей команде rsync :

rsync -aHXSvPh --hfs-compression --protect-decmpfs /Volumes/Macintosh\ BK/Backups.backupdb /Volumes/Untitled

Однако эта команда по-прежнему вызывает значительный переполнение на целевом диске (до такой степени, что я не ожидаю, что содержимое старого диска поместится на новом, несмотря на то, что новый диск примерно в 1,5 раза больше). Существуют ли какие-либо опции rsync , которые я пропускаю, чтобы устранить этот недостаток (я использую версию 31 протокола v3.1.2)?

Мне также пришло в голову, что, возможно, я использую не тот инструмент для работы. Будет ли более подходящим инструмент для копирования блоков, такой как dd ? Если да, то как мне настроить это так, чтобы процесс возобновлялся в случае прерывания (например, из-за полного сбоя системы, что случилось со мной дважды при выполнении команды rsync )? Я никогда раньше не использовал dd и поэтому не знаком с его возможностями (но у меня есть доступ как к версии, которая поставляется в комплекте с Mac OSX, так и к GNU версии 8.25).

Answer 1

dd не корректирует различные структуры данных тома на основе размера целевого объема, так что это только уместно , если объемы источника и назначения точно такой же размер. Как правило, я рекомендую вместо этого asr , но у него нет хорошего способа продолжить работу после сбоя.

Таким образом, одной из возможностей может быть сокращение целевого тома в соответствии с источником, использование dd для копирования необработанного тома, а затем расширение целевого тома до 1 ТБ. Я не проверял это, но я думаю, что этот процесс вам понадобится:

1. diskutil list будут перечислены идентификаторы устройств тома (например, disk2s3 - третий фрагмент (раздел) физического диска № 2)
2. diskutil info <sourcevolumeid> перечислит размер исходного тома в байтах (вместе со множеством другой информации)
3. diskutil resizeVolume <targetvolumeid> <sourcevolumesize>B ("B" означает "байты" - см. раздел "SIZES" на странице руководства по diskutil ).
4. diskutil unmount <sourcevolumeid> и diskutil unmount <targetvolumeid> - не используйте dd на подключенных томах!
5. sudo dd if=/dev/r<sourcevolumeid> of=/dev/r<targetvolumeid> чтобы сделать копию. Обратите внимание на префикс "r" в именах устройств - это обходит дисковые буферы ОС и, по моему опыту, заставляет dd работать намного быстрее. Будьте очень осторожны, чтобы правильно идентифицировать тома, иначе вы можете скопировать пустой том поверх своей резервной копии!
6. Наконец, используйте diskutil resizeVolume или Disk Utility, чтобы расширить целевой том до полного размера диска.

Да, и предупреждение: этот процесс предполагает, что ни источник, ни место назначения не управляются Core Storage. Если они (например, если они зашифрованы), все становится немного сложнее.

Answer 2

Короткий ответ заключается в том, что Time Machine активно использует жесткие ссылки, когда один базовый файл - один поток байтов - отображается в виде нескольких имен файлов в нескольких каталогах файловой системы. Если вы сделаете копию, которая не очень удобна в отношении жестких ссылок, то этот базовый файл будет скопирован несколько раз (по одному разу для каждой жесткой ссылки).

Допустим, у вас есть файл образа диска объемом 1 ГБ, который был там с самого начала, поэтому он отображается как жесткая ссылка во всех ваших периодических резервных копиях Time Machine, и у вас есть 100 резервных копий Time Machine. Если вы копируете это, не разбираясь в жестких ссылках, вы получите 100 копий этого файла объемом 1 ГБ, всего 100 ГБ, вместо 1 ГБ со 100 жесткими ссылками, указывающими на него.

Я уверен, что Apple знает, что их совет по поиску копий правильно сохранил жесткие ссылки. Я ожидаю, что функциональность "Восстановления" Дисковой утилиты также работает. Не позволяйте имени "Восстановить" обмануть вас, это не только для восстановления из резервных копий; это утилита Disk Utility для создания блочной копии с одного тома (или образа диска) на другой.

Обновлено, чтобы добавить:
Хм, rsync -H должен был сохранить жесткие ссылки. Вы уверены, что целевым томом является HFS+ или другая файловая система, которой OS X доверяет с жесткими ссылками?