LINUX.ORG.RU

надежность partclone

 ,


0

2

partclone умеет для XFS «умное» копирование раздела. Понятно, что по сложности (т.е. надежности) такой подход уступает dd. Но всё же вопрос веса получающегося бекапа актуален, речь о домашнем десктопе (он же для работы). С одной стороны разработчики молодцы: проделали большой труд, и позволили пользоваться, с другой стороны есть недоверие. Xотя понятно, они опираются на библиотеки, в частности, как заявлено, на xfslibs.

Вопрос: сталкивался ли кто-то на практике (или слышал) о проблемах с partclone-бекапами xfs разделов? Вы доверяете этой программе и вообще подходу копирования только используемых блоков?



Последнее исправление: pbsvo84 (всего исправлений: 1)

Ответ на: комментарий от anonymous

В корректности создаваемых xfsdump бекапов сомнений-то нет.

partclone вероятно делает для файлов вызовы, аналогичные xfs_bmap, после чего читает по карте нужные куски. При обратной сборке, понимание структуры ФС ему уже и не нужно. Ошибка может быть 1. в этапе запроса к оригинальной xfs-либе и формировании карты 2. в чтении по карте 3. в обратной сборке.

Вопрос именно в partclone (вместо прямого xfsdump) из-за того, что вокруг partclone построена clonezilla, которая собирает разделы при любой комбинации типов. На одном ext3, xfs, ntfs, на другом - другой набор. Удобство в том, что это копия как бы всего устройства (хотя фактически россыпь файлов), полученная интеграцией результатов разных программ. Второе удобство в том, при восстановлении она же потом соберет это обратно в диск (откажет-то диск, а не раздел). Альтернатива же clonezill'е - свои скрипты к которым еще надо писать обратные скрипты.

pbsvo84
() автор топика

Сейчас внимательнее посмотрел в changelog partclone.

2011-08-30 fix bug for xfs bitmap malloc from Paul
2011-01-25 Better XFS clone (algorithm from xfs_copy)
2010-06-09 Bug fixed: xfsclone type error for amd64
2010-06-09 Bug fixed: new xfsclone
2009-09-18 Bug fixed: XFS clone failure was fixed.

С одной стороны вроде как последние годы ничего про XFS нет, видимо всё работает.

С другой стороны уверился в том, что как я и предполагал, всё это «умное» копирование раздела - стремная в общем-то идея, если исходные диски не очень большие и место под нормальные dd-шные бекапы всё же можно найти. Тем более если discard действительно работает (это надо будет еще убедиться напрямую) то после gzip весить будет наверное столько же.

pbsvo84
() автор топика
Ответ на: комментарий от greenman

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

Так-то постоянно пользуюсь таром в т.ч. для некоторых бекапов (серверный репозиторий с кодом, какая-то другая важная директория, иногда /etc/), заскриптовано, отлажено и однажды именно tar.xz меня очень сильно выручил.

pbsvo84
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.