Очищаем информацию от ошибок

Часть первая. Философия борьбы с ошибками в цифровых данных — общие понятия и примеры

Ни для кого не секрет, что порча данных — всегда неприятное событие. Превентивные меры, направленные против такого класса проблем, мы в этой статье рассматривать не будем и поговорим немного о другом. Итак, что же можно предпринять, если порча данных уже произошла? Как ни странно, но ответить на этот вопрос без конкретных вводных невозможно. Необходимо понимать, где именно произошли искажения данных (внутри носителя, в буфере, в канале связи и так далее), на каком этапе (во время чтения непосредственно с носителя, во время записи, хранения или во время передачи по интерфейсу и т. п.), каков масштаб повреждений, каков их характер, были ли данные защищены корректирующим кодом и так далее. Но, если случилось так, что ни один из известных методов не помог, — можно ли что-то сделать самому? Пусть интрига сохранится подольше, поэтому для начала —

Как «ошибаются» данные и что с этим делать

Алгоритмических вариантов поведения при детектировании разного рода ошибок существует довольно много. Но, если присмотреться повнимательнее, окажется, что чуть ли не единственным методом, способным привести искажённые данные к стопроцентному исходному виду, является технология на основе корректирующих кодов (ECC), широко известная в IT вообще и в теории кодирования в частности. Не менее широко и её применение — от накопителей данных (практически любых) до некоторых механизмов как проводной, так и беспроводной связи (яркие примеры — мобильная связь GSM, цифровое телевещание DVB-T2). Технология эта достаточно «строгая» — в том смысле, что на выходе не может быть частичного результата: метод либо отрабатывает полностью, либо не отрабатывает вовсе. Исключения из этого правила бывают, но крайне редко, так как коды, позволяющие исправить ошибки частично, крайне мало распространены. Неудачный же результат работы кода бывает, в основном, при превышении определённых лимитов ошибок на защищаемый кодом блок данных. Применяемые алгоритмы довольно сложны и основаны на математических законах, существующих в определённых разделах высшей (линейной) алгебры, а непосредственная обработка данных происходит обычно на уровне аппаратуры (каналов приёма и передачи, либо внутри самого носителя данных как отдельного устройства). Естественно, имеются в виду только битовые ошибки, природа возникновения которых самая «низкоуровневая» и непосредственно связана с дефектами самого информационного носителя (магнитный слой, транзистор в кристалле микросхемы памяти и прочее). Распределение таких ошибок близко к нормальному в той или иной мере. Понятно, что никакой корректирующий код не спасёт, к примеру, от «пропажи» целого блока данных (обнуления или искажения непрерывного битового массива относительно большой длины), но таких ситуаций обычно не бывает, когда накопитель функционирует в штатном режиме.

О чём это мы? Дело в том, что если корректирующие коды не дали нужного результата (а именно их помощь и пытаются использовать в первую очередь), то вариантов остаётся совсем немного. А широко применяются из них вообще только два. Основной из них, как ни странно — банальная попытка повторить запрос в приёмо-передающий канал источника или в его декодер, с целью получить (перечитать) «неудачный» блок данных ещё раз в надежде, что теперь-то он «долетит» в бо́льшей целости и сохранности, а то и вообще «в идеале». Иногда одновременно с повторным запросом может изменяться настройка параметров канала для оптимизации, что также может дать свои плоды. Ярчайшим примером может служить поведение практически любого HDD (за исключением, разве что, совсем старых «кирпичей», с интерфейсом MFM и объёмом до 20 Мегабайт) при чтении сектора, которое возвратило ошибку UNC. Возьмём и другой пример — обмен данными между HDD и host-контроллером в режиме UDMA (это основной «рабочий» протокол для накопителей, использующих подключение IDE или SATA кабелем). Там точно так же, в случае приёма ошибочного блока, хост может запросить данные повторно, если возникла какая-то разовая помеха (не совпала CRC очередного пакета данных). И накопитель честно «отдаст» этот блок ещё раз, причём из своего буфера; перечитывать данные непосредственно с носителя в этой ситуации не требуется. Что-то похожее, причём, с подстройкой параметров для чтения, — используется и внутри микросхем NAND-Memory многих типов, на основе которых функционируют карты памяти, USB-флэшки, SSD накопители и так далее. В общем и целом, используется этот метод и в некоторых видах радиосвязи, и в сетевых технологиях, и много где ещё. Эффективность его достаточно высока, но только в случае, если сам носитель или канал передачи данных не деградировали достаточно сильно. Ну и сто́ит, на всякий случай, уточнить, что в приоритете применяются, всё-таки, корректирующие коды (если они изначально реализованы в рассматриваемой системе), и только потом, если исправление ошибок не дало результата, производится повторный запрос блока данных.

А что же второй вариант? А под ним мы имели в виду совершенно другую сущность, с другой «философией», которая, на сей раз, не зависит от аппаратуры, да и вообще не связана ни с носителями, ни с каналами передачи информации, — по крайне мере, не связана напрямую. Речь идёт про коррекцию логической структуры данных — то есть не «физических» проблем, связанных с их (де)кодированием, трансфером и особенностями хранения, а структуры упорядоченного набора данных определённого формата. На «айтишном» сленге это как только не называют — «прочекать», «пофиксить», «отрепайрить», «прогнать через лечилку» и так далее. Есть и другая вариация этой технологии, когда никакая коррекция не применяется (то есть нет цели заставить «работать» сам повреждённый файл), но в процессе анализа извлекаются необходимые уцелевшие данные. Назовём такие данные «объектами» — ведь это может быть всё что угодно: изображения, записи базы данных и даже отдельные фрагменты текста или наборы переменных. Именно такой процесс, как более наглядный и достаточно разносторонний в своих проявлениях и возможностях, мы и обсудим детальнее. Но для начала — небольшое отступление, связанное с ошибочным мнением касательно «волшебных» возможностях таких процедур. Для того, чтобы у успеха в этом начинании появился хотя бы шанс (уж не говоря про какие-то гарантии), совершенно необходимо соблюдение, как минимум, одного главного условия — нужные данные должны быть в наличии! С нуля, из ничего — информацию воссоздать нельзя. Из мусора, который к целевым данным не имеет никакого отношения — тоже. И когда к нам обращаются пользователи с просьбой восстановить или «как-то поправить» некий файл, который либо «криво» восстановлен с исходного носителя самостоятельно, либо не содержит нужных данных ввиду того, что они уже перезаписаны (такое часто бывает, когда файл удалили, а спохватились не в первые же минуты) — в этом и заключается их ошибка и ложная надежда. Серьёзную роль играет и общий объём повреждений (их процентный вес), распределение ошибок или отсутствующих блоков данных и многое другое.

Продолжим. Итак, существует бесконечное множество различных форматов (для разных типов данных), и их уникальность определяется непосредственно программным пакетом, который их генерирует. То есть вполне можно сказать, что определённое ПО создаёт данные определённого предназначения со своей структуризацией. На метафизическом уровне обычно рассматривают, конечно, не «просто данные», а определённый файл на каком-либо носителе. Иногда это может быть даже не файл в привычном понимании, а, например, метаданные файловой системы, различная служебная информация и т. п.

Так вот, однажды содержимое файла может оказаться испорченным. Спешим успокоить напуганного читателя и отметим, что происходит это, на самом деле, довольно редко. Ну а сама суть повреждений может оказаться довольно разнообразной: могут измениться как единичные биты или байты, так и целые блоки данных внутри файла. Также может произойти смещение части данных. Основные причины описываемых нами изменений — это аппаратные сбои случайного характера или деградация носителя, а иногда и сбои в ПО. Мы уже немного писали об этом и отдельно хотели бы уточнить, что в контексте данного материала мы будем подразумевать именно такой испорченный файл, с которым нет проблем ни на уровне чтения с носителя, ни на уровне драйвера файловой системы. Про такой файл говорят примерно так: «читается полностью корректно, но данные в нём не валидны».

Нетрудно догадаться и о последствиях: файл перестанет открываться. Хотя именно такую терминологию — «открываться» — в данном случае следует использовать очень осторожно. Ведь существует множество форматов, в которых данные представляют собой набор неких значений, на которые не наложены какие-либо ограничения, а сами данные хранятся в несжатом виде, да и, вдобавок, не защищены ни CRC, ни какой-либо контрольной суммой вообще. И, если повреждения не затронули служебную информацию (которой, кстати, может и не быть — это не всегда обязательно), то такой файл, формально, должен «открыться». Естественно, — с соответствующими повреждениям артефактами. Первое, что приходит на ум в качестве примера — графический формат Windows Bitmap (его классическая версия без сжатия, файл с расширением BMP). Характер и масштаб повреждений в нём не важен для собственно открытия и показа результата на экране, просто цвет соответствующих пикселей будет изменён. Разумеется, это при условии целостности служебной информации, которая содержит сигнатуру файла и набор параметров графической конфигурации — цветовой модели, разрешения и прочего. Занимает этот блок всего-лишь 54 байта в начале файла, все остальные байты кодируют непосредственно графические данные.

Существуют и ещё некоторые случаи, в которых файл может открыться, будучи повреждённым, — особенно при крайне незначительных изменениях. Например, инвертирование одного произвольного бита в кодовом потоке файла JPEG визуально вообще может быть незаметно. Или, к примеру, повреждение может затронуть «пустые» места в файле, то есть такие, которые внутри файла нигде не используются — попросту говоря, программа, работающая с таким файлом, в это адресное пространство просто пока не обращается, хотя место и зарезервировано. Про такой формат говорят, что данные в нём «разрежены», и это довольно частая ситуация, когда речь идёт про некоторые базы данных. К тому же, в файле могут существовать области, содержащие нулевые байты (и эти области могут именно использоваться, то есть нулевые значения в этих диапазонах могут что-то значить или на что-то влиять). Однако если на такие участки попадут нечитаемые секторы, то это даже нельзя будет назвать повреждением — при восстановлении непрочитанные места заполняются, как правило, тоже нулём, поэтому на выходе восстановленный файл будет полностью совпадать с оригиналом. Также довольно толерантны к небольшим повреждениям и многие потоковые видеоформаты — MPG, MTS и пр.

Но в целом, если данные в файле оказались повреждены (искажены, обнулены, «зашумлены» и т. п.), то, при попытке его открыть, вы увидите сообщение об ошибке. Вот тут-то помощь метода, который восстанавливает логическую целостность данных определённого формата, окажется как нельзя кстати. К сожалению, реализовать такое можно только для ограниченного числа форматов. Для этого необходим программный инструментарий (чаще всего это отдельная утилита, либо соответствующий функционал, встроенный в программный пакет, в котором создавался файл), но незадача в том, что наличие такого программного средства зависит, в основном, только от программистов, создавших продукт (входящих в команду разработчиков или имеющих доступ хотя бы к части исходного кода программного пакета). Почему «незадача»? Да потому, что очень мало кто будет тратить свои ресурсы ради вот такой «заботы о пользователе», и тут не играет никакой роли «серьёзность» или «величина» продукта. Как следствие, в распоряжении пользователей подобные инструменты присутствуют только в составе ограниченного количества ПО (да и то, ПО из разряда «популярных» или «повседневных»). Ну и, конечно, функционал по восстановлению целостности встраивают иногда и в ПО для специфичного применения. Если же для какого-то формата данных штатные программные средства восстановления производителем ПО не предусмотрены, а на само восстановление существует повышенный спрос у пользователей, то такую «нишу» иногда занимают сторонние компании, разрабатывающие соответствующие инструменты на коммерческой основе.

Приведём немного примеров ПО со встроенными средствами восстановления. Архиваторы — ZIP и RAR, офисные пакеты — Microsoft Outlook и Excel (у последнего — только базовый функционал), базы данных — 1С-бухгалтерия и менеджер баз SQL. Есть и «лечилки» не собственно файлов, а метаданных многих файловых систем. Для Windows (FAT, ExFAT и NTFS) это неоднократно упоминаемый ранее в других наших обзорах пресловутый CHKDSK.EXE, для Linux-систем (Ext2, Ext3, Ext4) — утилита FSCK. Для того, чтобы была возможность «отката», следует «лечить» только копию файла. Про метаданные — отдельный разговор: там всё сложнее, и их лучше не начинать лечить вовсе, пока не сделано резервирование всех важных данных с обрабатываемого раздела любым из доступных способов, вплоть до создания полного физического «клона» носителя (его посекторного образа).

Функционал этот, безусловно, не только интересен, но и полезен — результаты его работы уже пригодились сотням наших клиентов, да и вообще очень многим пользователям, столкнувшимся с порчей своих файлов или файловых систем. Возможно, хоть раз такими возможностями восстановления логической целостности пользовались и вы. Однако далеко не все задумывались над тем, как это работает. А ведь если исследовать эту тему более детально, то можно заметить интересную особенность. Дело в том, что, за редким исключением, непосредственно сами повреждённые данные эти программные средства не восстанавливают! Более того, вообще норовят от них избавиться — выкинуть, отбросить куда подальше, вырезать из файла, «чтобы не мешались». Как же так? В чём же тогда заключается repair-функция? — спросите вы. А заключается она в том, чтобы привести ту самую структуризацию, про которую мы говорили выше, в порядок. В соответствие формату. Да, что-то придётся принести в жертву, но только ради того, чтобы остальные данные стали открываться и обрабатываться — в виде потока, мини-объектов или базы данных, не важно. Арсенал для этого имеется внушительный: это и пересчёт неверных контрольных сумм, и коррекция внутренних ссылок, и приведение значений к дефолтным, и поиск «бесхозных» (не адресуемых внутренними индексами) объектов, и многое другое. В более «продвинутых» алгоритмах может применяться и расчёт значений на основании других данных (причём, не обязательно из этого же файла), либо даже их подбор — но это редко.

Примечательно, что эффективность всех этих возможностей весьма проблематично оценить — слишком много факторов на это влияет, в том числе и случайных (не зависящих как от создателя файла или оператора, так и от программиста, разработавшего ПО для восстановления). Действительно, форматов существует очень много, и, даже если рассматривать только наиболее «употребительные», лишь малая их часть позволяет реструктуризацию на таком уровне, чтобы это имело функциональный смысл. И соответствующие программные средства разработаны на настоящий момент далеко не для всех. Для многих форматов разработками в этой области пока не занимался никто — ни энтузиасты, ни коммерческие девелоперы. Таким образом, количественный показатель эффективности описываемых методов восстановления определить затруднительно. Ситуация с качественным показателем ещё интереснее: кроме, казалось бы, очевидных факторов (сам формат, характер и степень повреждений, уровень сложности recovery-алгоритма), имеет значение не что иное как важность восстановленных данных для конкретной задачи. И если из «битого» файла табличного документа после восстановления удалось спасти только один лист с текстовой колонкой и числовыми значениями, то для какого-то пользователя результат можно назвать «качественным», а для другого пользователя — нет. А всё потому, что первому были важны только суммы в строительной смете (и они уцелели), а второму — форматирование, сложное цветовое оформление или макросы, код которых он отлаживал долго и муторно...

На основании вышесказанного можно сделать вывод о том, что программные алгоритмы восстановления целостности восстанавливают, как правило, только служебную информацию внутреннего «устройства» файла, а сами испорченные данные либо не трогают совсем, либо удаляют. Термин «данные» применён здесь именно как «контент», потому что служебная информация, если судить строго, тоже является некими данными: ведь это тоже набор определённых байтов и битов. И, говоря про игнорирование проблем «в самих данных», мы подразумеваем именно какие-то «полезные данные», а не данные, необходимые для их обслуживания и для функционирования формата в целом и конкретного файла в частности. Это понимание достаточно важно для текущего контекста.

И, в самом деле, — что может сделать алгоритм восстановления, например, с повреждённым файлом архива RAR, в котором содержался один запакованный произвольный файл? Для полноценного восстановления — ровным счётом ничего! Максимум, можно поправить контрольную сумму, чтобы сам архиватор, хотя бы, не «ругался» при входе в архив, а также смог распаковать начальный блок данных до места повреждения (мало ли, иногда и такой «обрубок» может быть полезен, например фотография с обрезкой внизу, на которой уцелело большинство важных объектов в снимаемой сцене). Если же файлов было два или более, то не распакуется только тот файл, на область сжатых данных которого попало повреждение. И это ещё не все нюансы. Если мы сжимаем два или более файлов, то на распаковку повреждённого архива влияет ещё и принцип их сжатия. По умолчанию, на каждый файл формируется свой набор встречающихся отрезков различных последовательностей битов и байтов, впоследствии внедряемый в сжатый кодовый поток. Набор этот носит незатейливое название «словарь». При таком способе (то есть на каждый файл внедрён свой собственный словарь) не распаковываются только повреждённые файлы, порядок их следования и хранения в самом архивном файле не важен. На примере это выглядит так: допустим, мы сжали 10 файлов с фотографиями, и получился один архивный файл. Носитель данных впоследствии вышел из строя с механическими повреждениями, и при восстановлении такого файла возникли ошибки, а именно — два «бэд-блока» (непрочитанных сектора по 512 байт, на месте которых в файле пришлось произвести заполнение нулями), один из которых находится по смещению приблизительно 5 % от файла, а второй — примерно в середине файла. При распаковке мы получим ошибки в контрольных суммах на первом файле и в шестом, а все остальные восемь файлов распакуются без проблем, — причём для этого, возможно, даже не потребуется применение функции «ремонта» архива, если используется современная версия ПО.

А вот в альтернативном варианте сжатия словарь может быть общим для всех файлов, содержащихся в архиве. Задаётся это опцией "Solid archive" или просто "Solid", что в переводе звучит как «сплошной», «цельный» (в русской версии WinRAR эта опция называется «Создать непрерывный архив»). В этом случае результат зависит уже от метода сжатия. Если он установлен как «Обычный», то, несмотря на общий словарь, каждый файл всё равно при сжатии заново синхронизирует поток. Другими словами, этот поток не представляется как единый целый, из предварительно «виртуально склеееных» файлов. Тогда, если продолжать рассматривать пример выше, при распаковке пока ничего не меняется. А вот если мы включаем опцию "Solid" и устанавливаем метод сжатия как "Good" или "Best" (в русской версии это «хороший» и «максимальный», соответственно), то распакуется только часть самого первого файла в архиве, а все последующие распаковать, к сожалению, невозможно. Из этого следует, что «лишний раз» эту опцию лучше не использовать. На практике она полезна только в случае, когда в один архив добавляются много файлов, имеющих однотипное содержимое, которое поддаётся сжатию хотя бы в умеренной степени. То есть имеется в виду ситуация, когда много блоков данных (пусть и различных между собой) повторяются в разных файлах. В таком случае можно получить значительный выигрыш в сжатии. Лучше всего это заметно при сжатии множества текстов или несжатых изображений, иногда и на некоторых других форматах (например, исполняемые файлы, исходный код программ, скрипты).

Раз уж так получилось, что мы подробно решили проанализировать этот архиватор (вполне заслуженно популярный, надо сказать), то необходимо упомянуть ещё про одну важную возможность встроенной функции «ремонта», которая проявляется при количестве файлов в архиве более одного. Алгоритм умеет именно искать потерянные объекты. Это может быть незаменимым при обширных повреждениях (зануления или замусоривания относительно большой области внутри архива) и при смещении данных. Последнее, правда, случается крайне нечасто. Но если, предположим, в середине архива с несколькими файлами с примерно одинаковым исходным размером и сжатием взять да и вырезать один байт (или, наоборот, проявить неслыханную щедрость и добавить лишнего), то после этой точки все последующие данные «уедут» назад либо вперёд, соответственно. Так как имя очередного файла и параметры собственно сжатой информации (включая её размер) внедрены непосредственно в объект, а не содержатся в каком-то отдельном каталоге, то при любых смещениях архиватор даже не сможет показать дальнейший список файлов. Хотя бы потому, что по размеру и расчитываются начала объектов — ведь архиватор для показа списка ещё ничего не разархивирует, а только «пробегает» по всему архиву до конца, собирая имена и прочую информацию. Получается, что всё «завязано» в единую цепочку, и при первом же «промахе» остальные звенья уже не получить. Здесь алгоритм поиска, использующий определённые признаки и сигнатуры, просто незаменим — спасибо разработчикам. Впрочем, именно тот файл, на котором произошло смещение, всё равно не «соберётся» (алгоритму не хватает вводных данных), но зато все остальные файлы найдутся и будут перепакованы в другой архив заново. К имени файла архива при этом добавляется слово "rebuilt" («перестроенный»).

В целом, поиск потерянных объектов — это один из основополагающих принципов восстановления, и не только внутреннего содержимого файлов, но и самих файлов на разрушенной файловой системе и т. д. Из популярного ПО хочется отметить Outlook: утилита восстановления почтовой базы также задействует методы поиска, а её алгоритм является, пожалуй, одним из самых сложных и использует многопроходовый анализ. Это и не мудрено — сама структура и формат этой базы сложнее даже формата базы 1С версии 8, а уж если сравнивать с тем же RAR, то сложность выше на порядки. А вот тот же Excel 97–2003 почти всегда поступает по принципу «что-то не так — пропустим обработку». И это связано, как правило, именно со спецификой формата и непростой организацией хранения данных в нём (реализован даже аналог таблицы FAT), нежели с ленью программистов. Более того, эта самая сложность предписывает пониженную толерантность формата к ошибкам — серьёзные повреждения он «не переваривает». А небольшие проблемы — в зависимости от того, куда попадут. Если только в область одного из листов — то Excel постарается показать, хотя бы, остальные листы. Если в область блоков данных, определяющих форматирование или оформление текста (эти блоки могут находиться совершенно в разных местах файла) — то, возможно, что удастся показать хотя бы «голый» текст, а уж с форматированием и цветом пользователь как-нибудь разберётся и так далее. Тем не менее, даже такой подход к восстановлению часто оправдывает себя, потому что лучше хотя бы так, чем при малейшей проблеме выводить сообщение об ошибке и не пытаться ничего делать: это подсказывает элементарная логика, да и практических примеров предостаточно.

...Иногда кажется, что данную тему можно развивать бесконечно. Тысячи форматов цифровых данных, огромнейший пласт алгоритмов, способов, методов, процедур и их комбинаций — обо всём этом специалист по восстановлению данных может рассказывать действительно долго. Ведь анализ данных и структур, изучение форматов и способов кодирования — неотъемлемая часть нашей работы. Но «нельзя объять необъятное», да и информационная перегрузка читателя не сулит ничего хорошего. Поэтому, медленно но верно мы подводим наше изложение к заключительной фазе в рамках первой части материала. Рассмотрев базовые принципы борьбы с искажениями в данных и их последствиями, мы обошли стороной только одно направление, которого вполне можно было бы коснуться — это внутреннее функционирование массивов RAID. Сделано это намеренно, по разным причинам — начиная от большого количества материала в Сети и литературе, заканчивая тем, что это, всё-таки, отдельная ипостась, да и ошибки в этой системе имеют специфическую природу.

Тематика восстановления логической целостности данных и структур пока рассматривалась исключительно в контексте наличия соответствующих программных инструментов в распоряжении пользователя или оператора (в качестве последнего нередко выступает специалист по восстановлению данных). В то же время многие наши клиенты не раз задавались вопросом: «А есть ли хоть какие-то шансы на успех, если необходимого программного обеспечения «в наличии» нет или в принципе не существует?» Размышления об этом — во второй части.