Заговор от битых кластеров (добавляем информацию для восстановления архивов с помощью par2)
В этой заметке я предложу способ чтения данных с поцарапанных, погрызанных собакой или обработанных шредером компакт-дисков.
Итак, к делу: регулярно, при записывании данных на диск, остается некоторое количество свободного места. Лет 5 назад можно было положить диск на полочку, пометив, что еще 30 мегабайт можно забить каким-нибудь хламом, но сейчас стоимость болванки – 10 рублей, такой аргумент не действует. И, соответственно, привычку оставлять место “на потом” надо искоренять. Мне кажется, наиболее разумным было бы добавить на диск данные для восстановления – т.н. корректирующие коды Рида-Соломона, которые могут пригодится в случае, если диск будет поврежден.
Собственно весь заговор выглядит следующим образом:
#sudo aptitude install par2
#man par2
#cd backups
#ls
dump.sql.gz
#par2 create -v -r10 -n1 -m500 dump.sql.gz
#ls
dump.sql.gz dump.sql.gz.par2 dump.sql.gz.vol000+100.par2
Эта команда добавит 10% избыточной информации к данным, запишет все это в один файл, при этом программе par2 разрешено использовать 500 мегабайт оперативной памяти. Файлы *.par2 следует записать на диск вместе с дампом.
Мне эта программа понравилась, я захотел ее проверить в боевых условиях. Сделал архив размером около 400 Мб, добавил данные для восстановления – еще 200Мб – *.par2 файлы (50% избыточность, по умолчанию – 5%). Все это я записал на CD-RW, в котором потом сделал, простите, дырку. В итоге стандартными средствами удавалось прочитать только первые 150 Кб данных. Чтобы восстановить файл нужно сначала все считать пускай с ошибками – для этого есть программа dd_rescue, которая является практчески полным аналогом dd с одним исключением – она умеет игнорировать ошибки чтения:
#sudo dd_rescue -Av -b 1048576 -B 1048576 /dev/scd0 brokencd.iso(-A – заполняь нулями те участки файла, которые считать не удалось, v – verbose, -b – размер блока данных, -B – размер блока данных для проблемных областей диска)
# sudo mount -o loop brokencd.iso mnt # монтируем получившийся образ диска
# cp mnt/* dump; cd dump # копируем содержимое
# par2 r archive.par2 # приводим в изначальный вид
На этом эксперимент завершился – все данные с диска восстановлены. Даже скучно.
Но пример, мне кажется, весьма красноречив :)
Блеск, та самая неосознанная необходимость, которой многим не хватало! Стоит добавить, что это кроссплатформенная утилита, на сайте наравне с исходником есть бинари под windows и osx.
Потрясающе! Я подозревал, что такое возможно :) Спасибо!
Очень здорово! И оказалось вполне универсально и несложно. Спасибо за рассказ.
А без *.par2 файлов никак нельзя?
Что будет если беда случится именно с ними?
Всё, понял :)
Неправильно понял работу программы… Думал она основной файл “раздувает” (навроде сжатия наоборот).
Так вроде даже удобнее – никакого доп. ПО не нужно если всё впорядке, ну а коль беда – ставишь par2 и пытаешься восстановить.
Ещё нужно подумать о минимальном проценте избыточности – ИМХО он должен быть не меньше чем у носителя по стандарту (~15% для CD-ROM) иначе бесполезно будет.
юникс-вей :)
Только что проверил – если бьется par2-файл, то просто некоторые блоки данных для восстановления теряются (но не все). Таким образом, чтобы окончательно потерять какую-либо часть файла, нужно чтобы вместе с ней побился соответствующий блок данных в *.par2-файле (кстати, таких блоков там может быть несколько). Вобщем, в моих искуственных тестах (сверление дисков, sed) окончательно убить файл было сложно.
Про процент избыточности – мне кажется, что тут нужно ориентироваться только на минимальный размер блока данных. который можно потерять. Для диска – это потери от одной глубокой царапины, для винчестера – это два-три кластера ФС или сектора диска (в зависимости от того, что больше).
Ну и умножить эту цифру на количество возможных повреждений.
Избыточность на самом диске – это, имхо, совершенно другая история. На диске данные и информация для восстановления хранятся в пределах одного сектора. Секторов на диске – 300 тысяч, поэтому одной царапиной легко можно унчитожить десять секторов вместе с данными для восстановления. Так что это может спасти только от мельчайших царапин или микротрещин. А par2-файлы могут быть физически расположенными в другом конце диска, и это уже совершенно другая степень защиты.
> А par2-файлы могут быть физически расположенными в другом конце диска, и это уже совершенно другая степень защиты.
Вот тут тогда ещё одна интересная фича может вылезти :)
А что будет если “размазывать” данные par2 файла по диску, вперемежку с данными оригинала?
Т.е. записывать фрагмент оригинала, потом случайный фрагмент восстановления, потом опять оригинал, и т.д.
Это позволит уменьшить размер непрерывной области теряемой в случае повреждения и также уменьшит вероятность потери данных для восстановления :)
Да, наверное, это идеальный вариант. Можно даже изобразить что-нибудь такое с помощью split и tar, но это уже немного попахивает параноей :)
Но.. цитирую:
неее :)
файлы фрагментировать не путём разрезания на части, а путём записи на диск в фрагментированном ввиде в перемешку с фрагментами pak2.
Для обычного пользователя логическая структура диска окажется такой же – файл оригинал и pak2 – фрагментирование нужно на уровне ISO-9660 осуществлять (там в 3ем слое есть такая возможность).
Вот только чем образ готовить :)
Пока кажется нечем.
И все-таки, при наличии фрагментированных файлов возрастает роль метаданных диска. Повредили какую-нибудь системную таблицу и все, прощайте, файлики.
А если писать файлы по порядку, как это делается сейчас, то всегда можно с помощью dd прочитать то, что читается и затем уже думать, что делать с недостающими частями.
Так что это тоже палка о двух концах.
если метаданные повредятся диск может не восприниматься приводом, так что конкретные выводы можно сделать лишь досканально изучив доки…
но в целом уже прикольно получается, если после таких дыр выживает, то это уже РЕЗУЛЬТАТ :)
согласен :)
Программы типа isobuster могут читать диск и при (по крайней мере частичном) повреждении таблицы метаданных. Так что аргумент насчет пользы непрерывности остается в силе.
Испытал с помощью hexedit – хаотично прописывал блоки нулей во все 3 файла. Когда брал маленький исходный файл – всё было нормально. Взял большое видео (887Мб), сделал par2 c -m100 -n1 -r10 -b10000 видео
Потом потрудился hexedit-ом, запустил par2 v – говорит, всё нормально, из 10000 9997 нормальные, могу восстановить. par2 c – восстанавливает, проверяет – говорит, обшибся, 9996 нормальных куска только у меня получилось…
Хотя при проигрывании вроде ошибки исправились. Проверять контрольную сумму я не стал – очевидно, что она не совпадёт.
Что интересно – пробовал запускать циклично – ещё раз применять к файлу результатов – в одном из проходов 9999 целых кусков нашла. Но в следущем снова 9996.
Похоже, пора сдавать баг разработчику.