Попалась ситуация у клиента, где в результате действия вредоноса (проникновение и сбор информации с последующим шифрованием данных) оказались зашифрованными актуальные данные и бэкапы.

Клиент сначала попытался заплатить выкуп вымогателю, но закончилось всем тем, что оплату произвел, а декриптор не получил, а получил лишь предложение заплатить еще столько же. (речь шла вроде об 0,1 BTC).

Исследовав ситуацию удалось обнаружить, что автор вредоноса стремился сделать атаку максимально быстрой и потому большие файлы шифрованы частично. Немного от начала, если вкрапление в середине и в конце.

Удалось среди удаленных файлов обнаружить тело вредоносное и разобрать его алгоритм выборки данных для шифрования. т.е. доподлинно известно, что в файла шифровано, а что нет.

для VBK архивов порча начала - это как правило уничтожение header (который совсем не уникален), обеих копий shapshotslot(где Snapshot Desc., Banks Desc.)

Наиболее важна таблица Metabanks которая в таблице банков. Именно она определяет «маршрутизацию» по файлы архива, чтобы взять все важно для формирования деревьев для извлечения данных.

На текущий момент удалось решить задачи: 1.Поиск метабанков с отсевом мусорного 2.Поиск блоков данных без опоры на мету, с определением, где блок сжат, а где нет. 3.Проверка CRC32 объектов. Удалось установить что и где включено в расчет. Хотя остались некоторые вопросы по несжатым блокам.

Сейчас пока решение видится в виде создания новых Snapshot slot с внесением в них метабанков (с разложением по копиям и подсчетом CRC)

Но также интересна задача автономной распаковки данных по метабанкам. Интересует есть ли где опубликованная информация по устройству метабанков? В частности интересны записи по 32 байта в банках с флагом 1, где постранично записи блоков принадлежащих деревьям.

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

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

Недавно мне довелось столкнуться с задачей, когда клиент случайно удалил важный Zvol, содержащий множество документов пользователей, но его отсутствие заметили, только через на следующий рабочий день + время на ожидание обслуживающего персонала, кода пул активно эксплуатировался (прошло близко к 100 000 транзакций).

Классическое решение с анализом MOS, поиском объектов не увенчалось успехом. Проверка связок UB/MOS также была безрезультатной и фактически отражало лишь последние 20 минут жизни пула. При этом часть связок уже имела явные проблемы неполноты древа из-за перезаписанных блоков с метаданными.

Все осложнялось используемым сжатием LZ4. Коммерческие продукты такие как PC3000Express, UFS Explorer, Klennet Recovery в данной ситуации также ничем не помогли.

Пришлось рассмотреть задачу иначе: написать анализатор объектов ZFS (поиск сжатых и несжатых DMU и Indirect blocks). Собрать информацию с пула и проанализировать осиротевшие метаданные, которых в результате поиска обнаружилось заметно больше, чем через MOS.

Дальнейший метод строился на определении особенностей нужного Zvol, чтобы понять какого рода древо нас ожидает и сколько уровней. Для Zvol с заявленным размером 300ГБ и около 200Гб занятого (фактические в аллокации) и блоке в 64кб нас ожидает структура L3-L2-L1 - L0 (данные).

После того как появилось понимание чего ждать в древе, то был проведен анализ все связок L3-L2 (как приближенная оценка с высокой гранулярностью) чтобы отбросить все то, что не является структурами искомого Zvol.

Дальше выяснилось, что из-за принципа CoW ZFS за 100 000 транзакций уже успела переписать немало. Отдельно целого объекта уже не существует ни в одной копии. Сбор из сотен обрывков в итоге дал результат, что удалось собрать виртуальный диск, который уже содержал около 75-80% живых файлов.

Подробнее я изложил на хабре в публикации «Восстановление данных с ZFS: задача со звёздочкой об удалённом Zvol»

К сожалению там с аудиторией не получилось диалога (он отсутствовал, вероятно сильно специфическая тема). Хотелось бы обсудить с профильным сообществом перспективы развития подобных методов восстановления данных и какие реальные потребности пользователей возникают.