1

У меня есть резервная копия rsnapshot которую мне нужно удалить из поврежденной файловой системы Linux. Мне нужно сохранить внутренние жесткие ссылки. Я пробовал rsync -H и использовал более новую rsync и ни одна из них не сохранила жесткие ссылки в OS X.

Я попытался заставить работать rsync -H и изолировал его от файловой системы. Я могу сохранить жесткие ссылки, копируемые локально (HFS в HFS), но это не сохраняется, когда я пытаюсь rsync отключить монтирование файловой системы SMB или монтирование файловой системы AFP. Есть ли какое-нибудь решение для монтирования, чтобы заставить OS X rsync подчиняться -H?

Любой совет будет принята с благодарностью.

|источник

2 ответа2

1

Поскольку проблема, по-видимому, заключалась в том, что rsync в OSX не идентифицирует и не сохраняет жесткие ссылки из смонтированного источника EXT2, вместо этого мне удалось запустить демон rsync на исходной коробке linux и использовать rsync на моем Mac для подключения к этому демону. Кажется, что правильно сохранить внутренние жесткие ссылки таким образом.

  • Для этого на обеих машинах должен быть установлен rsync, причем один из них работает в режиме демона. В моем случае это был источник.

  • Вам также нужно отредактировать rsyncd.conf на стороне демона, чтобы определить «модуль» (причудливое имя для «пути»), который будет источником или целью.

  • Наконец, вы используете измененный синтаксис со стороны, не являющейся демоном, для ссылки на демон: user @ host:: module. Таким образом, копирование из демона может быть следующим: rsync -r user @ host:: module ~/foo

Для более подробной информации, Google 'rsync' и / или 'rsync daemon'

|источник
0

Я, конечно, надеюсь, что есть более легкий путь. Тем не менее, если ничего не помогает:

Я никогда не использовал его, но скрипт Python timecopy (для использования с ошибочными резервными копиями Time Machine) может помочь. Это длинный сценарий, но кажется, что он не только такой длинный из-за Time Machine. И особенно его поддержка неисправных дисков может быть полезна и для вашей поврежденной файловой системы. С его сайта:

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

Он поддерживает --dry-run и --verbose выводит хорошие команды mkdir , cp , ln и ln -s .

Сценарий принудительно использует файловую структуру Time Machine Backups.backupdb . Мне кажется , что изменение srcdb = os.path.join(srcbase, 'Backups.backupdb') в srcdb = srcbase , а также изменение dstdb = os.path.join(dstbase, 'Backups.backupdb') в dstdb = dstbase , может сделать это пригодным для источников не ТМ.

Затем он обрабатывает каждую подпапку исходной папки, ожидая, что каждая из них будет именем машины, являющейся корнем всех резервных копий для этой машины (обычно одной, если диск не используется для нескольких компьютеров). В каждой подпапке он обрабатывает все, кроме именованных файлов .DS_Store , Latest или заканчивающийся на .inProgress . Но: он не ожидает, что подпапки исходной папки сами будут жесткими ссылками. Если у вас есть жесткие ссылки в исходной папке, то, возможно, вы можете смонтировать диск с дополнительным именем папки. Например: используйте /Volumes/my/mount вместо /Volumes/mount , а затем запустите timecopy для исходной папки /Volumes/my .

Наконец, он также создаст символическую ссылку с именем Latest , как и диск Time Machine, для самой последней подпапки. Конечно, вы можете удалить это потом.

Затем вы все равно можете выполнить --dry-run , или, может быть, вывод --verbose --dry-run поможет получить скрипт, который вы можете использовать другим способом?

|источник

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