Причин, конечно может быть много, но в тему статьи подходит такая: подвисание происходит из-за перестроения какого-нибудь дерева:
— каталог с большим числом файлов в XFS — это дерево
— свободное место отслеживается с помощью 2х деревьев: одно упорядоченно по смещению, а второе по размеру свободных (или занятых, не помню точно) областей.
Если работать напрямую с диском (на сколько это позволяет ОС, конечно), то последовательная запись/чтение 256КБ по одному сектору будет значительно медленней, чем запись одного пакета в 256КБ. Определяется это тем, что диск — это тоже «компьютер» и у него внутри тоже есть накладные расходы на совершение операций. Есть также и волшебная величина, после которой рост скорости почти не происходит, она определяется максимальным размером буфера, который можно передать накопителю на запись (maximum transfer length). Эту величину можно запросить у накопителя, в том числе через API ОС. Очень популярная величина — 128КБ, но современные накопители могут и больше, например, 2МБ.
Безусловный плюс этого подхода в его необычности. На практике задача восстановления файла без заголовка встречается крайне редко, либо шансы чрезвычайно малы, т.к. поврежденный «заголовок» — это половина файла. Поэтому стандартные инструменты не заточены под такой тип проблемы. И человек который будет разбираться с диском вряд ли будет предполагать такой алгоритм порчи данных. И еще важный вопрос от кого защищаемся?
От покупателя с авито такой подход сработает на отлично. Но если рассматривать серьезного противника и если ему стал известен алгоритм работы утилиты, то тут не все так хорошо.
Самое слабое место ваших рассуждений — это преувеличение важности заголовка. Поиск по заголовку — это просто наиболее простой и быстрый способ, но не единственный. Конечно есть типы для которых начало содержит критически важные данные, но я не уверен, что таких типов большинство.
Например. Вы правильно заметили, что современный документы вроде docx, pptx, odt, и тд — это zip архивы, В них хранятся какие-то «под-файлы»: стили, связи, сам текст и еще что-то. Каждый под-файл сжат отдельно и перед ним есть сигнатура 0x04034b50.
Я провел эксперимент, взял несколько документов docx, текст там хранится в под-файле /word/document.xml (и это тоже сигнатура для поиска). В одном файле смещение этого под-файла было около 1700 байт, в другом около 3000. Я удалил все что было до этого смещения и сохранил это как новый zip архив. WinRAR прекрасно распаковал все оставшиеся под-файлы.
Вывод: если размер уничтожаемого заголовка будет небольшим (1Кб например), то элементарный сигнатурный поиск и подручные инструменты позволят увидеть текст всех ваших документов. И не нужно тут статистических методов и машинного обучения.
К другим типам файлов тоже можно найти свой подход, хоть и не ко всем. Можно конечно портить больше чем 1Кб, но это скажется на скорости.
Алгоритм кажется мне излишне сложным, с учетом возможности просто зашифровать диск или раздел. Но в качестве мысленного упражнения попробую найти в нем несколько недостатков:
Чтобы перетереть заголовки и тела файлов, вам нужно знать где эти файлы начинаются, а для этого вам нужна таблица MFT, которую вы удалили на предыдущем шаге. Не забудьте закэшировать размещение файлов =)
Поточные видео и аудио будут очень устойчивы к стиранию заголовка и мелким пакостям внутри, потому что они поточные и формат файла предполагает воспроизведение с любого места и возможные потери. Это, например, относится к mp3 и mpeg. Попробуйте испортить файлы и воспроизвести их потом.
Если ваши jpeg'и с одной фотокамеры, то очень вероятно что будут использовать одни и те же настройки сжатия (таблицы квантования и т.д.). Т.е. можно «пересадить» заголовок (область от начала до маркера SOS) от любого другого живого файла. Более того, в начале фото-jpeg'а обычно лежит бесполезный для распаковки exif, который занимает несколько килобайт, т.е. есть высокий шанс найти «свои» ключевые структуры.
Т.е. надо из всех jpeg'ов поудалять exif и пережать их с включенной оптимизацией таблиц Хаффмана, в этом случае перезапись первого килобайта будет очень эффективна.
Мусорить тоже надо уметь. Картинки можно отсортировать по дате и модели камеры (если вы не убрали exif). По документам можно выполнить текстовый поиск по ключевым фразам. Целостность многих файлов можно проверить и отбросить битые.
Это я все к чему. Если параноить по-настоящему, то шифрование выглядит надежней. Но только помните про обратную сторону этой «надежности», если что-то сломается, то шансы потерять данные насовсем значительно возрастают.
Если нет бекапов, а все сломалось, то перед тем как заниматься лечением хорошо бы сделать бекап текущего состояния (т.е. полную копию диска). Полно ситуаций, когда лечение наносит несравнимо больший вред данным, чем болезнь от которой лечили.
Но этот совет неприменим, если проблема связана с неисправностью диска.
Описанная выше задача не является чем-то особенным для серьезных сервисов восстановления данных. В принципе, если помните параметры массива, то mdadm + photorec вытащат все фотографии.
А в плане получения опыта и знаний работу проделали, конечно, очень серьезную.
Можете уточнить точный сценарий, при котором ZFS сложнее восстановить?
Есть целая куча сценариев, которую можно отнести к человеческому фактору. Сюда относятся всякие переформатирования, переинициализации, удаление файлов по ошибке и тому подобное.
Преимущество NTFS в таких сценариях в том, что она хорошо изучена и ее поддерживают все основные инструменты для восстановления данных (кто-то хуже, а кто-то лучше, но поддерживают), а у специалистов по восстановлению данных уже скопился большой опыт. А вот с ZFS все сейчас находится только в развитии.
Если проводить очень грубую аналогию с автомобилями, то NTFS — она как жигули, а ZFS — как тесла. Тесла вроде как должна быть надежней, заранее сообщать о поломках и прочее. Но если вы дадите ее погонять подросткам в деревню, они точно найдут способ ее сломать. И починить ее сможет один лишь Илон Маск. А вот жигули вам вам смогут починить в той же деревне и за дешево.
Проблемный диск может быть как относительно стабильным, так и сам себя убивающим. Поэтому если запаса по избыточности уже нет, то читать с такого диска данные — это риск.
Хотя никто не запрещает держать обычную ZFS на RAID-5.
Не запрещает, но сильно не рекомендовалось, насколько помню.
Видел такие «нерекомендованные» конфигурации в природе: RAID-5 на mdadm, на нем lvm2, а там ZFS. В метаданных проскакивало название NASdeluxe.
Аналог RAID-Z — это RAID-5. Если в нем один диск умер совсем (и первым), а на еще одном несколько бэдов, то специалисты по восстановлению данных вернут вам все те же 99% данных. Правда, у ZFS все же есть преимущество — это дублирование метаданных, которого нет у «нормальных» файловых систем. Хотя никто не запрещает держать обычную ZFS на RAID-5.
Еще вопрос.
Обычно raid контроллеры используют полином 0x11D и коэффициенты 1, 2, 4, 8,… для подсчета блока Reed-Solomon. Но есть исключения. Как вы думаете с чем это связано? Другой полином и/или другие коэффициенты могут дать какой-то выигрыш при расчете?
В случае классических RAID информация о контроллере дает не так уже и много. В лучшем случае вы найдете метаданные на дисках и по ним узнаете конфигурацию. Однако есть еще очень много других проблем:
— умирающие HDD
— неактуальные участники (относительно «живые» диски, которые были давно исключены из массива)
— всякие попытки «самолечения» из-за которых образуется каша в данных
Вот и у меня, честно говоря, не получилось такого добиться. C Hyper-V дела не задались, а новый VirtualBox пишет новые данные в разностный диск (как на картинке в статье). Такая же ситуация была и нескольких случаях при восстановлении данных, но в поломанных данных может случиться все, что угодно.
— каталог с большим числом файлов в XFS — это дерево
— свободное место отслеживается с помощью 2х деревьев: одно упорядоченно по смещению, а второе по размеру свободных (или занятых, не помню точно) областей.
От покупателя с авито такой подход сработает на отлично. Но если рассматривать серьезного противника и если ему стал известен алгоритм работы утилиты, то тут не все так хорошо.
Самое слабое место ваших рассуждений — это преувеличение важности заголовка. Поиск по заголовку — это просто наиболее простой и быстрый способ, но не единственный. Конечно есть типы для которых начало содержит критически важные данные, но я не уверен, что таких типов большинство.
Например. Вы правильно заметили, что современный документы вроде docx, pptx, odt, и тд — это zip архивы, В них хранятся какие-то «под-файлы»: стили, связи, сам текст и еще что-то. Каждый под-файл сжат отдельно и перед ним есть сигнатура 0x04034b50.
Я провел эксперимент, взял несколько документов docx, текст там хранится в под-файле /word/document.xml (и это тоже сигнатура для поиска). В одном файле смещение этого под-файла было около 1700 байт, в другом около 3000. Я удалил все что было до этого смещения и сохранил это как новый zip архив. WinRAR прекрасно распаковал все оставшиеся под-файлы.
Вывод: если размер уничтожаемого заголовка будет небольшим (1Кб например), то элементарный сигнатурный поиск и подручные инструменты позволят увидеть текст всех ваших документов. И не нужно тут статистических методов и машинного обучения.
К другим типам файлов тоже можно найти свой подход, хоть и не ко всем. Можно конечно портить больше чем 1Кб, но это скажется на скорости.
Что касается живых документов, то их анализ сложный труд для разработчиков алгоритмов анализа, но не для экспертов криминалистов со специальным ПО.
Чтобы перетереть заголовки и тела файлов, вам нужно знать где эти файлы начинаются, а для этого вам нужна таблица MFT, которую вы удалили на предыдущем шаге. Не забудьте закэшировать размещение файлов =)
Поточные видео и аудио будут очень устойчивы к стиранию заголовка и мелким пакостям внутри, потому что они поточные и формат файла предполагает воспроизведение с любого места и возможные потери. Это, например, относится к mp3 и mpeg. Попробуйте испортить файлы и воспроизвести их потом.
Если ваши jpeg'и с одной фотокамеры, то очень вероятно что будут использовать одни и те же настройки сжатия (таблицы квантования и т.д.). Т.е. можно «пересадить» заголовок (область от начала до маркера SOS) от любого другого живого файла. Более того, в начале фото-jpeg'а обычно лежит бесполезный для распаковки exif, который занимает несколько килобайт, т.е. есть высокий шанс найти «свои» ключевые структуры.
Т.е. надо из всех jpeg'ов поудалять exif и пережать их с включенной оптимизацией таблиц Хаффмана, в этом случае перезапись первого килобайта будет очень эффективна.
Мусорить тоже надо уметь. Картинки можно отсортировать по дате и модели камеры (если вы не убрали exif). По документам можно выполнить текстовый поиск по ключевым фразам. Целостность многих файлов можно проверить и отбросить битые.
Это я все к чему. Если параноить по-настоящему, то шифрование выглядит надежней. Но только помните про обратную сторону этой «надежности», если что-то сломается, то шансы потерять данные насовсем значительно возрастают.
Но этот совет неприменим, если проблема связана с неисправностью диска.
А в плане получения опыта и знаний работу проделали, конечно, очень серьезную.
Еще из «альтернативных RAID 6» однажды попался массив с такой схемой:
Собран был на старом adaptec.
Есть целая куча сценариев, которую можно отнести к человеческому фактору. Сюда относятся всякие переформатирования, переинициализации, удаление файлов по ошибке и тому подобное.
Преимущество NTFS в таких сценариях в том, что она хорошо изучена и ее поддерживают все основные инструменты для восстановления данных (кто-то хуже, а кто-то лучше, но поддерживают), а у специалистов по восстановлению данных уже скопился большой опыт. А вот с ZFS все сейчас находится только в развитии.
Если проводить очень грубую аналогию с автомобилями, то NTFS — она как жигули, а ZFS — как тесла. Тесла вроде как должна быть надежней, заранее сообщать о поломках и прочее. Но если вы дадите ее погонять подросткам в деревню, они точно найдут способ ее сломать. И починить ее сможет один лишь Илон Маск. А вот жигули вам вам смогут починить в той же деревне и за дешево.
Видел такие «нерекомендованные» конфигурации в природе: RAID-5 на mdadm, на нем lvm2, а там ZFS. В метаданных проскакивало название NASdeluxe.
Обычно raid контроллеры используют полином 0x11D и коэффициенты 1, 2, 4, 8,… для подсчета блока Reed-Solomon. Но есть исключения. Как вы думаете с чем это связано? Другой полином и/или другие коэффициенты могут дать какой-то выигрыш при расчете?
— умирающие HDD
— неактуальные участники (относительно «живые» диски, которые были давно исключены из массива)
— всякие попытки «самолечения» из-за которых образуется каша в данных