Восстановление ZFS. Поиск удаленного Zvol 4 дня спустя.

Профильное сообщество рекомендует регулярные бекапы по расписанию на дисковые СХД или ленточные библиотеки.

Нет, вы конечно сделали маленькое чудо, но по факту – нужда в нем возникла только от сломанных процессов у вашего заказчика.

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

Если klennet не помог, то скорее всего, данные уже давно ушли в небытие и были переписаны нахрен. Но так как ты написал что-то что помогло больше, чем кленнет, то тут тебе вряд ли кто вообще что-то сказать может. Таких мало, кто настолько глубоко сможет разобраться в устройстве ZFS, ты крут, чувак. Поэтому и диалога не будет - просто на этом уровне никого нету.

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

Если бы везде были правильные бекапы, то отрасли восстановления данных с хранилищ бы не существовало. Но данная тема как раз о ней.

Не в драйвере а в структуре хранения.

А какова цена вопроса для клиента получилась, если не секрет?

Хотелось бы обсудить с профильным сообществом перспективы развития подобных методов восстановления данных и какие реальные потребности пользователей возникают.

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

Структура хранения описана в драйвере ФС. И документация охватывает далеко не всё к этой ФС. Ты какой-то клоун, что-ли до слов докапываться? Людей, способных настолько низкоуровнево работать с ZFS крайне мало. И вряд ли они сидят на хабрах и ЛОРах.

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

Структура хранения описана в драйвере ФС

А мы то и не знали.

Ты какой-то клоун

Нет, ты.

Дело не в лени, а в ответственности.

Восстановление данных – всегда без гарантий, даже у ТСа в описанном случае не все восстановилось.

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

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

Потому безопаснее не делать оговорок, а просто говорить «Нет, нужна нормальная СРК».

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

Скорее всего как раз напрямую и читал и парсил своим кодом, это проще. Может быть он сам ответит.

Заказчики могут думать что угодно, главное чтобы условия договора соблюдали. Оправдывать мыслями каких-то глупых заказчиков свою недобросовестность это крайне сомнительная позиция.

Хотелось бы обсудить с профильным сообществом

Так вам сюда: https://openzfs.org/wiki/Mailing_list

Прочтите публикацию. Именно полный анализ сырых данных с определением сжатого и несжатого. Это несколько более сложный путь, но более эффективный в тяжелых случаях, чем ходить по ZFS пулу через MOS с доступом к ограниченному числу метаданных.

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

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

Исследовательская работа и разработка программного обеспечения не перекладывала на плечи клиента. Потому цена весьма обычная для DR лабораторий. Точная цена не может быть озвучена по условиям договора с клиентом.

Что-то мне кажется, что мне не совсем туда, учитывая мой профиль деятельности.

В публикации на хабре как раз подробно и изложено как велась разборка сырых данных на пуле и не использовались никакие драйвера. Только прямой доступ к диску с полностью самостоятельным анализом.

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

А порядок цен сейчас хоть какой?

После того, как я уже стал делать бэкапы и потом их проверять, вообще не в курсе цен за 20 лет стал :))

порядок

Думаю 6-значное число (с учётом того что клиент - юрлицо).

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

от эквивалентна 300$

Офигеть, 20 лет прошло, а цена всё та же :))

Офигеть, 20 лет прошло, а цена всё та же :))

Но работы объективно стали сложнее, чем 20 лет назад.

Ну учитывая статью - да :)

Тогда на меня с моей ext3 посмотрели как на дурака, сказали, если бы я хотя бы lvm туда накрутил, то точно бы сразу развернули.

Тогда на меня с моей ext3 посмотрели как на дурака,

Уже в те времена много для кого Ext2/3 не были проблемой.

сказали, если бы я хотя бы lvm туда накрутил, то точно бы сразу развернули.

Как и LVM при первом столкновении было что-то непонятное, но после нескольких минут в дисковом редакторе стало уже все относительно понятным без чтения документации.

Как обычно играет человеческий фактор. Кто-то действует в рамках доступных инструментов, кто-то выходит за границы их возможностей.

Тут аудитория ещё менее адекватная, начиная с модераторов, хамящих под анонимами, ну а про обычных можно молчать… Максимально токсичный сайт. Лучше напиши статью на английском и выложи… я сайт забыл, там индусы постоянно статьи пишут, так как он деньги платит

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

Но вот в мэйл-листах впринципе имеет смысл пообщаться. Так или иначе се, тесто связанные с ZFS - там присутствуют.

Вопрос есть.

Пытаясь восстановить только что удалённый файл с XFS, нашёл программу xfs_undelete, написаную на tcl.

Она пользуется некоторыми особенностями XFS для нахождения места расположения блоков удалённых файлов и восстанавливает их.

В моём случае это не помогло, т.к. есть ещё одна особенность: если удалённый файл был последним в своём каталоге, то длинна опустевшего каталога зануляется, и найти его предыдущую непустую версию во всём формально свободном пространстве становится просто нереально, т.е. метаданные только что удалённого файла становятся недоступны.

Так вот вопрос про ZFS: у него такое же поведение?

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

Кстати, сами каталоги в ZFS тоже жмутся lz4 при использовании сжатия?

Нет. zfs сохраняет все транзакции и при правильной его настройке ты можешь в тупую откатить любую транзакцию в разумных пределах. Он и пишет каждый раз в новое место, не занятое данными предыдущих транзакций.

То есть если ты удалил файл «вот прям щас» - обычно добыть его становится не то, чтобы сложно. Даже если ты удалил весь каталог, последний файл в каталоге, тупо затер содержимое файла не теми данными и т.д.

при включенном сжатии на пуле будут сжиматься и DMU и Indirect. Несжатыми гарантированно будут vdev+UB и некоторые DMU.

В моем исследовании в случае восстановления Zvol на ZFS нас совершенно не волнуют структуры DMU, которые предшествуют непосредственно 23_DMU_OT_ZVOL, 24_DMU_OT_ZVOL_PROPS, где уже непосредственно начинается описание самого Zvol и далее идёт отсылка к дереву, описывающему размещение.

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

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

Ну так это логично. Если исчерпалось свободное пространство - то ой. Я когда попал на восстановление данных - выяснил, что там по хорошему надо делать магию если блоки 4k. У меня вроде хранилось последних 6 суперблоков, а должно было быть 32 по документации (и мне этого бы хватило, там после записи дичи хоть и в больших объемах прошел час). Из-за этого не смог отревиндиться штатными средствами на нужную транзакцию, ну и пришлось выколупывать данные через klennet. Мне повезло.

в том то и дело, что не исчерпалось. Пул на 2 ТБ, а занято только 0,4 ТБ. Но учитывая как оно вразнобой пишет (мигрируя по диску, то за 100к транзакций в моей задаче похоже перезаписало не один десяток гигабайт, что в итоге проредило как старые метаданные, так и данные. Увы но CoW принцип он и прелесть и проклятье.

На диске с какой NTFS, где бы допустим лежали бы VHD файлы и был один улален, за такое время были бы реальные шансы получить удаленный виртуальных диск без повреждений или с заметно меньшими повреждениями, учитывая что реальных данных записано было намного меньше, чем перезаписано из-за принципа CoW на ZFS томе. Но справедливости ради стоит отметить, что при перезаписи одного единственного контейнера MFT могла бы быть утеряна разом вся мета, описывающая удаленный виртуальный диск.

Потому однозначно нельзя сказать, что например с NTFS потери были бы меньше.

Круто, конечно, но никто особо не оценит +). Походишь героем недельку и все забудут +). Проходили - знаем +)