> Восстановим из проверенных бэкапов, которые уже есть в связи с наличием увлекательного
> опыта по восстановлению данных.Рояль в кустах это отлично, но во первых это не достоинство файлухи и решения. Во вторых, существование дата рекавери лаб и цены на их услуги как бы намекают что это работает не для всех и не всегда. "Теоретически, Петька, мы с тобой миллионеры...". Так что запасной план не такая уж плохая идея. Как и ряд фич ФС на такие случаи, типа аж 3 копий суперов в очень разных логических смещениях. Или склонность ФС юзать DUP или RAID1 на метаданных, что сильно повышает их шансы при отклонении от идеала. Без метаданных все гораздо печальнее, сами понимаете.
>>> Заодно и покажете мастеркласс как раз. Если сможете
> Да, для не критичных небекапленных данных лежит виртуалка с установленными _кощунственными_
> _коммерческими_ решениями r-studio
Это все может и является достоинством r-studio но уж точно не достоинство решения и штатных тулсов файлухи. Соответственно о чем мы говорим? О том что можно развестись на бабки в польщу виндовых комерсов? Предпочту чтобы мои бабки получали более дружественные чем ЭТО персонажи.
> и ufs explorer.
Это то-то покупает? Интересно на...я? Я бы такой ФС пользоваться не стал даже если б мне доплатили за это. На данный момент это просто мамонты.
> Потому, что опыт, релевантный на момент 3-4 года назад, показал, что свободно
> доступные решения не позволяют получить результат, лучше массовых коммерческих
> решений, а результат лучших (по моему скромному мнению) из них (r-studio и
> ufs explorer) вообще не достижим.
Хызы, я народу доставал "почти все" даже с основательно ушатанных дисков, откровенно сыпящихся. В лине есть вполне приличные туслы для отстройки образов, а WHDD так еще и через команды умеет работать в обход интерфейсов ядра. Ну а я умею в системную механику, более-менее понимаю как это все работает и знаю основные DOS и DONTS.
А потом ... потом вот знаете ли гибкость btrfs очень крута, когда и стораж можно под разовую задачу отрастить до небес, а закончив действо можно и вынуть из него девайсы. И рефлинки очень рулят, когда у меня штук пять чушек по якобы эн терабайта каждая, с прогрессивным восстанвлением/фиксом и возможностью передумать/откатить это все если лажа вышла, при том что суммарный жор места "копий" лишь чуть более 1 образа. Итеративненько то потусоваться в образах без ломовых требований к месту и быстро - вполне.
> Возможно, на текущий момент, действительно встроенная в btrfs-utils офлайн читалка рвет
> лучших коммерческих представителей для fat, ntfs, ext2-4 + LVM2(только LV) или
> появилось _качественое_ коммерческое решение по восстановлению данных с btrfs
По крайней мере мне очень импонирует когда разработчики ФС сразу в тулкит кладут такие вещи вместо того чтобы делать рожу кирпичом что это не их проблемы. И в дизайн файлухи закладывают ряд вещей чтобы там были шансы потрепыхаться даже в заковыристых случаях.
Ну вот например на эмбедовке часто только 1 девайс. А штучный бэд под libc - жутко обидный сценарий. Потому что разэмбедовать одноплатник где-то в ж... дорого, долго и гиморно может быть. Btrfs на это можно с схемой DUP разложить. Он и скажет - csum failed .... corrected, а природа CoW такова что это все и к ремапу довольно дружественно. Т.е. эти данные более не нужны - и туда можно запись сделать. Накопитель сможет ремап без потерь вообще. Даже если сектор и не читался. Конечно можно LVM похожего франкенштейна скроить, но опять же - без чексум мы не узнаем какая копия правильная. И все становится сложно. А в btrfs это 1 командой делается. Можно даже в рантайм решения переиграть. Быстро, просто, ненапряжно.
>> Ну во первых, бизнес намного лучше когда он не прогоревший.
> У вас точно имеется увлекательный опыт восстановления данных?
Иначе я бы имхо вообше не знал про вещицы типа whdd ;). Самым интересным (и опасным) было ремотно, по ssh вот это самое сделать. Крайне не рекомендуется к повторению, вы наверное и сами понимаете почему. Но иногда выбора просто нет. Даже прокатило, хоть и пришлось понервничать.
> Оно то понятно, что быть богатым и здоровым намного лучше, чем бедным и больным
А я таки делал датарекавери эн линуксоидам, а до кучи и нескольким маздайцам с NTFS. Благо в FUSE или ntfs драйвере линя парсинг более другой и на этом можно сыграть. А в тяжких случаях testdisk и phororec даже с совсем убитого нечто много чего достают без кивания на фс вообще. А потом я вот как-то корябнул забавные скриптики, посмотрев что юниксвэй может предложить. Ну, например, может DCIM/ юзеру вернуть из трухи в нормальном виде - "достав" имена файлов из... тегов файлов, спасибо камерам за это, сделал из гамна и палок анализатор, он за 10 минут не только имена вернул но и по годам по папкам раскидал.
Ну и да - я свои лимиты знаю, всякий перелив фирмварей/служебок/etc конечно к профи уже. Но там и цены и времянки другие будут.
> да, есть люди которые не делают бекапы, и я их прекрасно понимаю:
Вы как бы имеете определенный пойнт. И все же...
> нафиг упаднические настроения и фэйловый миндсет, я буду жить вечно, ведь,
> пока что, все идет по плану
Лучший бэкап - который никогда не понадобился. А то я разок на почтовую базу отхреначил старый бэкап. А более нового и не было. Ну и продолбал мегов 200 почты. Обидно было. На самом деле назначением лоханулся, должно было в альтернативное пойти, чтобы вынуть вооон то. А попало в исходное - и это был фэйл. А поскольку тогда я магию снапшотов и cow не практиковал еще, оно in-place базы перетерло, и вот это - таки облом! Конечно кому было что-то сильно надо - письма перепослали еще разок, но... снапшоты не замена бэкапов. А бэкапы не замена снапшотов.
> К тому же, действительно, часто данные не так уж и важны,
> и на длинном промежутке времени суммарные усилия по их бекапу будут превышать
> усилия по маловероятному восстановлению данных
Самое странное во всей этой истории то что я достаточно хорошо понимаю как это работать и попадаю "в десятку". Т.е. рекавери обычно очень близок к 100% плюс-минус то что вынесено бэдами или дестроем невосстановимо. Ну т.е. я в курсе как правильно строить образа, итеративным чтением, и в лине для этого тулсы есть, а потом итеративно догоняю образ до кондиции. И btrfs в этом оказался полезен.
> Но механизмы, вроде CoW, dedup, сжатие - только увеличивают область повреждения _данных_.
Когда как. А возможность сунуться в разные состояния - пока их GC не подгреб - повышает шанс что хоть одно из - прокатит. Тогда таки распарсится на автомате. И все сильно проще. В обычной ФС все хуже - если куска метаданных нет, его уж нет. И мы идем медленно и печально юзать testdisk+photorec. Оно, конечно, зачастую катит, и даже очень здорово, но, времени требует дочерта а имен файлов можно и не получить, раз уж метаданных вон там нету.
> К тому же у нас разногласия по термину данные. Вы в данные
> по видимому включаете также метаданные файловой системы.
До некоторой степени. Там 1) размеры, имена. 2) В случае btrfs мелкие файлы. Так что такой взгляд на вещи имеет определенные причины.
> btrfs действительно имеет множество механизмов для сохранности и восстановления метаданных.
Btrfs примерно одинаково трактует блоки данных и метаданных. Это забавно но там нет глобальных отличий. Что так chunks с энной схемой, что так. Специфичный дизайн деревьев позволяет ему cow'ать и данные, и метаданные, в конце концов это одна и та же механика ворочает. Схемы хранения могут быть разные (очевидно что выживание метаданных критичнее, из соображений масштаба урона, а т.к. они не очень большие, DUP или RAID1 можно позволить для них много где). Более того - могут быть чанки с типом хранения отличным от того что ща юзают данные и метаданные. Как продукт "частичной конверсии схемы" или "новой дефолтной схемы хранения". Сам по себе этот дизайн мог бы назначать разные схемы хранения разным файлам если бы кто-то логику решений аллокатору накодил. Кроме всего прочего он в результате прекрасно переживает крах при конверсии схемы райда. Просто продолжает конвертить формат чанков дальше после перезагрузки. Попробуйте так вообще с вашим LVM, кули.
> И у LVM есть множество недостатков относительно btrfs, которые приведут к потере
> метаданных
У него 1 ключевой недостаток: В ВОПРОСАХ МЕНЕДЖМЕНТА ЭТО - БРЕЙФНФАК. В btrfs я просто добавлю или выну девайс. Увеличу или убавлю ФС. Сменю схему хранения. И проч. Нонстоп. А еще вот снапшот ОС и хомяка на случай фэйлов. И если мне апгрейд системы не понравился, вот моя машина времени. Которая на минималках заводится аж из grub, указанием другого назначения монтирования.
Это менеджмент систем XXI века. А вон то - #$%ный стыд и миндфак. И именно по этой причине bcachefs тоже следует этим паттернам дизайна. В отличие от такпривыкших дино кентушка в состоянии понять что так рулить ФС и ОС намного круче и неизмеримо эффективнее. Это как пересесть с кукурузника на небольшой звездолет с гипердвигателем и машиной времени. Вместо десятков циферблатиков и дергания ручек - указываешь назначение - опа - уже там. Да, если аллоцировано 100 мегов из 10Тб - ворочать будет 100 мегов. И тайминги операции будут - вот такие.
> - можно наворотить вложенных LVM, тонких снимков так, что будет аналогично или
> хуже, чем в btrfs (относительно восстановления _данных_).
Моя основная претензия ко всему этому - в том что оно многократно сложнее по уровню менеджмента прежде всего. Интегрированный с машиной времени и гипердрайвом звездолет навигирует в 4 измерениях нативно, совершенно прозрачно гоняя между разными вариантами развития событий и не делая мозг. Кукурузник для этого не сохдавался. И попытка сделать что-то такое на нем - весьма болезненный экспериенс.
> - по умолчанию LVM не хранит несколько копий своих метаданных
> - сложннее настройка, где неосторожным движением кривых рук можно все поломать
Имерно поэтому его место там же где ipsec когда уже есть wireguard :). Именно поэтому кент дизайнит свой некстген так как дизайнит. Мир никогда уже не будет прежним. И я не буду скучать по вон тому жуткому трешу. Вообще совсем.
> К тому же, как вы понимаете слабые компетенции (о которых я специально упомянул)?
> Доступно ли слабым компетенциям:
1) Слабые компетенции всегда будут искать помощь сильных.
2) Меня прежде всего волнуют мои проблемы, а я наверное скорее уже взял средний уровень или выше среднего.
3) Для знакомых и друзей я обеспечиваю некий саппорт на минималках как респект технологии и "спасибо" ее создателям.
А вот LVM пусть его фанаты трахаются. И его уродливые недо-снапшоты тоже для них. А чтоб еще чексумы там были? И починить фэйлящую копию из исправной? В btrfs оно само это сделает. А в LVM что-то такое добиться - убьешься нахрен.
Поэтому у меня на одноплатниках btrfs с схемой DUP. Прозрачно. Просто. Минимум допущений и мануальщина. А таки переживает редкие единичные бэды. Под хоть чем. Ему не важно данные там или метаданные, если схемой хранения и тем и другим DUP сделан. Так теорвер намного лучше. Если бэд раз в месяц, какая вероятность что две разные копии получат бэд одновременно? И вот так теорвер намного лучше ощущается. А с LVM вы его так в свою сторону вообще осилите крутануть? Поэтому у меня оно будет работать до последнего. А вы можете если хотите разэмбедовывать и бэкапы накатывать, объясняя кастомеру что нагибон его техпроцессов которыми эта штука рулила - ничего так, нормально.
У меня на этот счет иные идеи как-то. Лучший data recovery это тот который делать не пришлось.
> Я, для слабых компетенций, максимум допускаю
>> у btrfs в ее утилсу встроена офлайн-читалка типа того что для нтфс в коммерческом
>> софте бывает, которая _умеет сама_ парсить ФС без монтирования и скидывать
>> найденое файло на другой носитель
Слабым компетенциям лучше всего 1) RTFM 2) прийти к девам. Они подскажут что и как в нетривиальных случаях. Или если не получается, 3) нанять кого-то или дать денег кому-то кто не настолько лох и таки решит системные аспекты нормально. По этой причине интеграторы и образовались как направление.
> При этом команда для ее запуска будет скопирована из какого-то форума, без
> внятного понимания, что она сейчас будет делать.
Если кто-то решил включить режим идиота на своих данных, занявшись тем чем не умеет, чтож, все уважающие себя эксперты по восстановлению данных не забудут вкатить поправочный коэффициент на самодеятельность.
Но вон та читалка, если что, подразумевает чтение на ДРУГОЕ назначение - с немонтированой файлухи. Поэтому записать что-то на оригинал и попортить его сильнее таки у казуала врядли получится вообще. Так что если он смолчит в тряпочку - даже избежит вон той участи. Потому что оригинал не пострадает.
> А понимание структур данных файловой системы и методов их хранения и распределения
> в них не входит
Ну как бы в случае btrfs лучше основные концепции понять. Пилотирование звездолета с машиной времени и гипердрайвом подразумевает что вы таки в курсе азов этих концепций и не будете охреневать от альтернативных таймлайнов, параллельных историй развития событий и даже ОК с перспективой встретить "почти самого себя, но чуть другого". Со временем мир становится сложнее, а концепции CoW и альтернативных реальностей, размеров дельт и проч - актуальны и для допустим виртуализаторов. Без понимания этого вы и снапшотами в VM осмысленно ворочать не сможете. И компетенция оказывается уже не низкой - а пробивающей дно по современным меркам, когда вы и виртуализаторы нормально юзать тоже не умеете. Первыми кто всерьез полюбил CoW, снапщоты и проч - были они. А теперь так и на железе вот можно. Но если кто смотрел sci-fi, он давно понимает как это работает. Это именно оно.
