Pull to refresh

Comments 100

Пользователи VirtualBox должны страдать.

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

Просто посидев некоторое время (пару лет) в всяких сисадминских и около того пабликах тг, заметил некоторую предрасположенность пользователей вбокса к проблемам. (И микротоводов кстати тоже).

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

З.Ы. и микрот не ломается. Что в бранч офисах, что у нас вводной провайдера, что у меня дома.

Как говорится, это была реклама бэкапов. :)
Образ диска для экспериментов желательно было сделать с самого начала.
Но желание ничего не записывать на диск с потерянными данными — совершенно правильное.

Да, Вы правы)

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

Бэкапы нужно делать до того, как всё слетело. А ещё их периодически стоит проверять на восстанавливаемость.

Бэкапы нужно делать. Просто делать. Проверять тоже полезно, но если не делать — проверять нечего будет.
А если всё слетело как у автора статьи — то начинать надо было с того, чтобы сделать бэкап слетевшего — образ диска. Чтобы во время попыток восстановления не запороть остатки.

Вы упустили то, что "восстановленные" данные теперь не все целиком живы. Потому, что: ext файловые системы придумал больной мозг, и они равномерно "размазаны" по всей площади носителя. Соответственно, при форматировании диска с данными под ext - мы получаем равномерно перезаписанные в определенных местах данные вновь созданной метой свежей ФС.

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

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

А разработчики extX должны гореть в аду {мнение рекавери-сообщества}

> Потому, что: ext файловые системы придумал больной мозг, и они равномерно «размазаны» по всей площади носителя.

А какие разработаны правильно по этому параметру? Существует ли эта проблема у UFS?

Существует. Предназначение у этой программы немного не то.

> Предназначение у этой программы немного не то.

Я ни про какую программу не спрашивал. Так у каких файловых систем нет описанной проблемы?

NTFS, HFS+, exFAT, FAT32(с оговоркой, тут каталоги по всему диску размазываются, но после быстрого формата в FAT32 перезаписано будет очень немного и только вначале диска).

а что насчет ReFS?

Очень люблю клиентов-любителей экзотики. Когда она (экзотика) ломается - начинаются мучительные поиски метода восстановления (их нет). Как раз на днях ZFS был... Зачем? Какую задачу вы не можете решить на классических откатанных ФС?

А какие претензии к OpenZFS-то? Вполне зарекомендовавшая себя ФС, которая широко используется в 'продакшыне'. И имеет множество фич, недоступных традиционным ФС и традиционным программным RAIDам например.

Если делаете бекапы - никаких претензий. Но когда оно ломается - инструмент для рекавери приготовьтесь писать своими руками. Люди в основной своей массе беспечны. Бекапы особо никто не делает. Тем и живем.

PS: кстати, насчет "продакшына". Рубаните питание серверу на горячую. Если выживет - повезло

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

Ну вроде как механизмы CoW и логгирования (в ZFS-спике -- ZIL) как раз и позволяют иметь консистентную FS при любом 'рубаните питание'. При условии конечно, что железо работает как положено -- не портит записываемые данные и данные в памяти, а диски не врут насчёт завершения синхронных записей.

диски не врут насчёт завершения синхронных записей

как раз zfs должно (должна?) откатываться на консистентное состояние и в том случае, если диски врут

Вот уж рубание питания ZFS'у вовсе не страшно. Да, потери будут, в том, что до пластин не долетело + ещё чуть-чуть, но FS будет жива и консистента. В случае с raidz[23]/mirror надо будет ресильвер запускать, ну так это у любого RAID без батарейки надо будет, только ZFS это сделает в разы быстрее.

Не раз проверено на практике, я живу так или иначе с ZFS с 2010 года. Я терял отдельные диски, целико и частично, я терял контроллеры, у меня случались смерти нерезервированных БП — никаких проблем (кроме потери самых свежих данных) ни разу не было. Нет, конечно, потеря двух дисков в radiz (трёх в radiz2, четырёх в radiz3) смертельна, чудес не бывает, но если этого не случилось — головняка куда меньше. До этого я года с 2000 жил со всякими аппаратными и софтовыми RAID'ами и UFS2 поверх — и имел куда больше головной боли.

Да, я могу собрать UFS2 изобломоков в шестнадцатеричном редакторе, за ZFS я даже браться не буду, но, знаете, и не приходлось. А вот с UFS2 бывало, бывало.

Первое, что я делал в экспериментах с ZFS, когда она появилась на фре - это "рубил питание" тестовому news-серверу (100500 мелких файлов и куча записей) и питание при записи большого файла - ничего "непредсказуемого". Второе - запись случайных данных в случайные места на дисках.

Лажа встретилась дважды: физическое искажение данных при передаче через IDE-шлейф (впорть до стука голов, "карманы" все помнят?) - пришлось потрудиться, чтоб пул смонтировать, с SATA - проблемы похожие могут быть - пластик разъёмов :(. Второй раз - выключил подсчёт контрольных сумм на пуле, далее замена диска на "пустой" и глюк соляриса с восстановлением данных с "пустого" диска на оставшиеся, вместо "наоборот" - катастрофично. Код gzip крэшил ядро при попытке распаковать результат.

Линукс вообще не особо дружелюбен к восстановлению данных. Даже просто удалённых.
Ладно ещё тут на жестком диске всё происходило, а не на SSD.

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

вроде с ССД вообще ничего не восстановить

Я это и имел ввиду. Данные есть шансы восстановить, пока до них не добрался trim.
Только процедура удаления файлов на extX тоже, такое ощущение, что файлы затирает — слишком она долго продолжается для простой пометки на удаление.

Ого, вы правы. Сейчас прошелся по SSD testdisk-ом. Он не видит ни одного "удаленного" файла. Ни одного вообще. На HDD они красным подсвечиваются и их иногда восстановить можно.

Правильно, если вы указали в fstab параметр discard, то после такого удаления ФС посылает на SSD команду TRIM (да, не сразу но всёравно), что вызывает пометку «сектор свободен» в трансляторе, ну а далее по алгоритму выравнивания износа на место удаленного сектор встаёт какой-то другой, ранее удалённый. Не хотите такого поведения — используйте ФС и ОС, которые не могут в TRIM, но SSD за такое на вас будет сильно обижен как по скорости работы, так и по ресурсу.

А если SSD EXT4 отформатировать "быстрым" способом, все данные так же будут полностью удалены? Или это будет зависеть от ФС в которую он будет отформатирован?

Это будет зависеть от того, будет ли послана ssd команда trim и от прошивки. Скорее всего будет убито всё, куда была запись из-за алгоритмов выравнивания износа, ну а если при форматировании будет послан TRIM на весь раздел, то увы, скорее всего вообще ничего не останется.

Если mke2fs видит, что сидит на ssd или thin-provisioned хранилищах (и те, и те умеют в TRIM), то пошлет на весь диапазон блоков раздела TRIM.

Тоесть да, удалит.

Ладно ещё тут на жестком диске всё происходило, а не на SSD.

А сейчас вспомните, как вы меня хаяли. Я кстати ту публикацию удалил, её обсуждали не очень дальновидные люди по всей видимости.
Так всё таки, что лучше, HDD или SSD?
Лучше ссд и бэкапы. В несколько мест.
Ибо запороть удалённое можно и на жестком диске. Просто ссд это делает в силу собственной конструкции совершенно автоматически.
А у них вообще разное предназначение. SSD — эфемерное быстрое хранилище (потому, что может умереть непредсказуемо в любой момент), HDD — более медленное классическое. Умереть тоже может, но более предсказуемо, ну и данные, как правило, можно восстановить.

Бэкапы лучше делать в любом случае, но SSD без бэкапов это примерно, как на рам-диске всё хранить…

на рам-диске всё хранить…

Но это, наверное, для серваков каких нибудь, не для простых смертных компов

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

И чем же эти конторы пользуются, наверное секретными программами Которые-Нельзя-Называть?

AceLab PC3000, DeepSpar какой-нибудь, MRT. Решение не одно. Ключевое почему нельзя сделать ни в УФС, ни в тестдиске - невозможность работы с субкартами.

Чем вам помогут субкарты, которые создаются программами низкоуровневого досутпа, в случае абсолютно живого HDD? Даже не SSD с его FTL, а старой-доброй вращающейся ржавчины? Конечно, когда диск помирает, то спецы с этими программно-аппаратными комплексами смогут куда больше — в том числе, и пометить подозрительные на поврежедения файлы, которые так просто не определит пользователь со стандартным SATA-контроллером. Но тут же совсем другой случай, железо живо.

Задача совершенно логическая, можно делать по образу диска, снятого стандартным оборудованием. Найти по сигнатурам обломки структур старой файловой системы, найти все блоки и inode, от этих спрятанных «корней», найти где они поблочно пересекаются с видимой (новой) файловой системой и таким образом понять где повреждения. Никакие субкарты не нужны, это софтовая задача.

UFO just landed and posted this here

Для критичных - тоже норм, если на поддерживаемых ФС. Он сделан на основе ядра от UFS Explorer, без какого либо урезания помимо упрощения интерфейса и ограничения списка ФС, которые может реконструировать. Список ФС с которыми работает на просмотр/чтение такой же.

За старания 5

За исполнение 4

За тех.подготовку 3

За отсутствие бэкапа неуд.

Спасибо. После такого "экзамена" бэкапы начинаешь воспринимать совершенно иначе)

"Люди делятся на две категории: которые делают бэкапы, и которые будут делать бекапы"

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

"На тех кто не делает бэкапы и тех кто уже делает бэкапы )"

На три. 1) Кто не делает бэкапы, 2) Кто уже делает, и 3) Кто бэкапы делает и проверяет их целостность.

...вот не укладывается в голове - как можно быть в ИТ и не использовать бэкапы? У меня даже пет-проекты живут в гите (рабочие наброски всегда хранятся локально + на тестовых/продуктовых серверах, если очень не хочется гиту доверять).

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

А по содержанию статьи - редко, очень редко, мне приходилось так глубоко погружаться в процесс восстановления - обычно на этапе "потеряна структура каталогов" я провозглашал: - "Или за деньги к [название фирмы на Китай-Городе], или забыть". Вам повезло восстановить основную часть данных, но как выше заметили, не факт, что всё восстановилось корректно, ну и "для себя" - это приемлемо (в конце концов, "сделал всё, что мог"), а для "тыжпрограммистов" - не, не люблю краснеть за оплаченный результат.

Нужно просто никогда не откладывать бэкапы. А когда ни разу не попадал в такую ситуацию, то к бэкапам возникает легкомысленное отношение. Я так же использую bitbucket, сервер и usb-hdd. Но оправдания собственной лени найти несложно: "Дождусь конца года и сделаю бэкап", "Допишу компонеты и тогда закомичу" и т.д. И в итоге все это копится.

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

Проекты восстановить получилось кажется полностью. Битые файлы были, но git подсветил их как измененные, и найти их труда не составило. Вообще git просто спас в этом плане.

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

«10 долларов за мегабайт, без гарантии целостности»

Так это еще и "недалеко от правды" получается. Реально так дорого может быть?

А это ценник клинических вариантов, когда остаётся только звонить в Seagate или Ontrack. «Дешевый» вариант, на котором можно потренировать свою устойчивость к инфарктам — RAID5 массив из 4 дисков, все посыпались, у одного запилы пппц, у прочих не очень, но видны, головы менять всем, а у четвёртого ещё и шпиндель заклинило. Если с таким запросом обратиться в нормальную фирму, ценник будет тоже нормальным.

Это уже примеры, когда диск фактически сломан. Т.е. на уровне оборудования. А вот если просто нужно данные восстановить...

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

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

Мне не очень понравилась фирма на Китай-городе - дорого, долго и не хватает организации процесса. Фирма на Новокузнецкой оставила лучшее впечатление.

А как быть если далеко не в default-city живешь? Мне, например, до ближайшего города-миллионника еще доехать нужно.

Не в тему, но расскажу:

Два года назад на ноуте начал жутко гудеть кулер. И ноут грелся, разумеется. Пошел в сервис, отдал 1500, сказали - "все починят". Прошло, реально, неделя, может две, и он опять гудеть начал. Я к ним снова прихожу, мне говорят, что тогда только под замену всю систему охлаждения, типа иногда их можно расклепать, но не все - моя сделана так, что только под замену. Под заказ такой системы охлаждения нет. Сказали, можете заказать на алиэкспресс китайскую поделку, принести им и они ее заменят. Я позвонил еще в несколько контор, объяснил, все говорят "все сделаем, вы только приезжайте", но новой системы охлаждения ни у кого нет.

В итоге решил посмотреть сам, думал, если что, то закажу китайскую. Купил масло, снял крышку с ноута. Там, между вентилятором и роторной частью, зазор 1мм не больше, даже иголка не входит. Как они его смазывали - великая тайна. Я, в итоге, капал это масло, размазывал его иголкой по зазору, а потом вдувал феном, холодным воздухом, чтобы оно хоть как-то туда проникло. Весь день так просидел.

Вот уже два года прошло, кулер работает идеально. Даже лучше чем новый)

Отправить курьерскими службами - половина "ремонтных мастерских" так работает, когда на месте только принимают товар, а чинят совсем другие люди.

Спасибо, что поделились.
Зы. Бэкаплю в нес-ко мест
Я не знаток Linux, но общий порядок действий такой
преобразовать рабочий диск из базового в динамический
тупо отзеркалить разделы с HDD на SSD
преобразовать SSDшник в базовый
Вместо того, чтобы устанавливать с чистого листа и возможно с потерей данных
Я так делал в Windows PE, через Acronis
Как вам такой вариант?

Вы про то, чтобы не ставить систему нуля, а просто скопировать существующую? Так, наверно, можно было сделать. Но старая система уже большая и тяжелая. А новую ставишь - и как с чистого листа.

У Linux в этом плане есть интересная возможность. Можно установить новую систему, поставить все нужные программы. А потом сохранить ее на флешку как LiveUSB с возможностью полной установки со всеми программами.

Будьте добры, дайте инструкцию как такое сделать.

Посмотрите здесь: Creating A Custom Kali ISO

Сейчас, кажется, многое изменилось. Раньше у кали была абсолютно чистая сборка, а сейчас ее нет. И "дока" была другой. Когда-то я делал себе "Linux для web-девелопера", с готовым набором всех нужных программ, на этой базе.

У Linux в этом плане есть интересная возможность. Можно установить новую систему, поставить все нужные программы. А потом сохранить ее на флешку как LiveUSB с возможностью полной установки со всеми программами.

Как это называется?
Упд. Не обновил страницу, игнор

Статья - описание последствий стрельбы в коленку и советы по первой помощи при стрельбе в коленку (не будем обсуждать - правильные или нет). А правильная статья по стрельбе в коленку - это как не стрелять :)

  1. Если уж работаете с блочными устройствами, никогда не обращайтесь к ним по имени (/dev/sdaили /dev/sda1 ), используйте, например, обращение по uuid (Persistent block device naming). И уж трижды никогда нельзя ссылаться по именам в постоянных ссылках (как например в ВМ)

  2. Как можно меньше делайте из-под рута. Не уверен, можно ли было избежать именно в вашем случае, но насколько я помню, писать напрямую в блочное устройство без root невозможно в большинстве случаев.

  3. Собираетесь установить ОС на железку - сделайте копию основного диска. И отложите его нафиг из компьютера, пока не станет понятно, что всё установилось.

  4. П.3 не отменяет регулярной системы резервного копирования.

Не все такими умными рождаются и полагаются на личный опыт. Советы давать задним умом все горазды.

Я потому и написал комментарий, что пары ключевых моментов не увидел. И, нет, я умным тоже не родился. Пару раз я не тот /dev/sdb (или sdc) командой dd заливал. Спасло только то, что в одном случае бэкап важных данных (но не всего) был, а в другом случае я предварительно самый ценный диск из ПК убрал.

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

Про рут вы правы. Чтобы это сделать нужно запускаться из под рута.

Третий совет не менее ценен. Когда что-то делаешь с системой - отключай (если возможно - ФИЗИЧЕСКИ) накопители, которые ни в коем случае не должны пострадать

Такая эмоциональная подача хорошо чтобы советы запомнились тем, кто пока что не столкнулся с проблемой и не наворотил непоправимого :)

А правильная статья по стрельбе в коленку - это как не стрелять :)

Когда уже сидишь с прострелянной коленкой, такие статьи уже не актуальны))

Сколько людей - столько и историй почему нужно делать бэкапы.

Демка easeus data recovery бесплатно покажет то,что ей удается восстановить с сохранением папок.мне только она помогла несколько раз

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

  1. Сначала сделать полную копию (побайтовую) всего диска в файл или другой диск и работать с этой копией. А лучше 2 копии. Чтобы оригинал не трогать до последнего, а если что накосячил - можно было начать сначала.

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

Почему-то не увидел, что пробовали DMDE - даже бесплатной версии хватает, чтобы сделать полную копию или вытащить файлы (только это неудобно и значительно больше вручную сохранять по сравнению с платной). По функционалу поиска разделов или файловых систем, или просто данных, когда ФС уже разрушена вполне сопоставима с r-* и с photorec/testdisk. Но кроме того, имеет возможности для работы с неисправными дисками, гибкие настройки пропуска битых секторов, выбора разных драйверов для доступа к дискам, и т.д. Не раз выручала меня (хорошо хоть не свои данные вытаскивать пришлось).

Ну а бэкапы - наше всё )

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

Я много всего перепробовал за ту неделю, просто не хочу никого рекламировать и, тем более, анти-рекламировать.

Про DMDE напишу - т.к. она встречалась буквально в каждой статье. Я пробовал DMDE FreeEdition для Linux, кажется, следующей после R-Linux и R-Studio. Но мне она не помогла. Прямо сейчас, кстати, я включил ее и загрузил образ раздела, полученный через testdisk (тот самый, с которого я смог все восстановить через R-Linux). Прямо сейчас она показывает мне файлы ошибочно поставленной операционной системы и миллиард удаленных каталогов с названием "$F0000...". В тот раз, кажется, было точно так же. И здесь вообще невозможно найти нужные данные.

Если вы в ней хорошо разбираетесь, будем признательны за рекомендации)

Я не настолько часто ей пользуюсь (ну раз 10-15 может пользовался всего), на память и не вспомню как вытаскивал при потерянных ФС. Но тут в Вашем случае всё несколько сложнее - и не факт, что она тут бы помогла. Не слежу на новыми версиями, т.к. несколько отошёл от таких дел, надобности нет.

Тут ещё проблема, что у ext3/4 есть суперблок в начале, и через определённые промежутки по разделу есть его копии. А поверх была ещё ОС установлена, со своей ФС, и она записала тоже свой суперблок, и тоже копии. Весь вопрос, насколько софт может найти и распознать эти копии и может ли отличить одну от другой, если это от фактически разных файловых систем (старая и новая).

Не совсем понятно как вы упустили из поля зрения UFS Explorer. У него есть версия под Линукс, довольно популярный продукт вообще-то. По нашему опыту - лучший вариант для восстановления с ext4. (На всякий случай обозначу конфликт интересов - я знаком с разработчиком лично.)

Если данные лежали в другой области, то там что не выбери (в рамках разумного конечно) всё восстановит. А если лежали в той, то без вариантов.

"И только одно твердит Айболит: "Бэкап, бэкап, бэкап!""

Может, проще всё же делать резервные копии, чтобы потом крепко спать?

GetDataBack не увидел. Она меня выручила здорово в году этак 2004. Есть версии под восстановление фс fat и ntfs.

Похожий путь проделал, отформатировал не тот диск при установке, но вовремя обнаружил ошибку, до копирования файлов ОС. Деталей не помню т.к. было давно, использовал софт под винду. В первые минуты было принято верное решение — выключить машину, не пытаться спасать файлы сгоряча. Поспать, успокоиться, почитать мануалы, купить дополнительный HDD.

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

Хорошо и приятно оформленная статья получилась, спасибо.

Благодарю)

В интернете эта тема, реально, - "темный лес". Спасибо сообществу, что делитесь опытом и знаниями)

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

А как это можно узнать? И каким образом это можно собрать?

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

Да, это хорошо объясняет эффекты.

Пойду-ка проверю свои бэкапы/архивы :)

Была похожая ситуация лет 12 назад. "Командировка", отлучился на пару дней. Коллеге срочно понадобился ноутбук, был только мой под рукой, пароля нет, логичное решение (нет) установить поверх ОС... Опыта почти не было, бэкапы делал редко, на DVD :). Долго восстанавливал, вроде с помощью R-Studio. Рабочая ОС - Windows. Основной проект (несколько недель усиленной работы), так и не восстановил.

В общем пошло на пользу. До сих пор прокачиваю навыки связанные с резервированием/архивированием данных. Потерянную работу сделал по новой и намного лучше (хотя была "ломка").

Спасибо, нормальная статья и полезные комментарии к ней. Всем удачных бэкапов!

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

Странно, что ни кто не упомянул такую программу как DMDE. Есть и под винду и под Линукс. Весьма неплохая прога для восстановления повреждённых структур разделов и файловых таблиц. Да и просто данные может поискать и вытащить (как RStudio). Уже множество вещей было восстановлено с её помощью, хотя минимальные знания нужно иметь.

Про DMDE упоминалось выше в комментариях.

Вот скрин того, что ей удалось найти:

Во вкладке "$Root" она показывает файлы ошибочно поставленной операционной системы, а дальше действительно идут "потерянные" каталоги и их просто огромное количество. Но 99.99% из них это каталоги из node_modules (это "технические" файлы и каталоги для web-разработки). А найти среди них действительно нужные данные просто нереально.

Есть диск MBR на 3Tb, когда-то давно стояла программа asus disk unlocker, создавала виртуальный диск для использования всего объёма. Потом сменилась материнская плата, система. Сейчас видит только раздел на 2 tb, можно восстановить оставшийся раздел на 750 гб?

Как я понял, вам нужно не данные восстановить, а просто сделать 750GB снова доступными для чтения и записи?

В интернете пишут, что это можно сделать только на другом компе, где стоит материнская плата с UEFI. Преобразовать диск из MBR в GPT. Создать и отформатировать разделы, а после преобразовать обратно. Пишут, что можно сделать через утилиту fdisk.

Как раз нужно восстановить данные, пробовал установить снова asus disk unlocker, не ставится, т.к. другая материнская плата.

Было бы интересно узнать, что testdisk показывает в этом случае

Кажется, что testdisk видит все сектора жесткого диска (их 364801, а последний раздел заканчивается сектором 267349).

Мой план действий был бы такой (можете последовать, но под вашу ответственность):

1. Нажать [Quick Search] и посмотреть - найдется ли раздел (скорее всего, там не будет вашего раздела).

2. Нажать [Deeper search]. Нужный раздел будет в конце диска, поэтому придется ждать до конца. 3TB - это примерно 10-15 часов ожидания. Когда дойдете до этого этапа, пройдетесь по найденным разделам клавишей [p] (будьте аккуратнее с выходом из разделов, иначе придется сканировать заново). Если найдете Ваш раздел и там будут файлы и каталоги, можно сохранить данные с помощью клавиши [s]. Если нужного раздела нет, то тогда шаг 3.

3. Если testdisk сможет досканировать Ваш диск до самого конца, значит можно попробовать другие программы (к сожалению, кроме R-Studio и DMDE посоветовать больше ничего не могу). Если нет - значит это уже ограничение на "уровне оборудования" и, врят ли, найдется программа, которая пробьет барьер в 2.2TB. Тогда только только один вариант - доставать жесткий диск и искать знакомых с нужной материнской платой, либо в сервис.

Как сходить пописать не напишешь? А то просто совсем кладезь новой инфы! Может новое узнаю...

@rease а можно чкть подробней как вы ОС ставите через VBox на физ носитель?

Сначала нужно подключить к VBox физический диск, как в этой инструкции: Использование физического диска в VirtualBox

А далее можно поставить на него систему. Только это придется делать с root правами, например, запустив VBox через терминал так:

$ sudo virtualbox

Наверное каждый должен пройти через этакое чтобы очень осознанно понимать что такое надежность хранения данных и понимания какие данные критичные и требуют защиты, а какие нет. У меня просто всё это было ещё в совсем молодые времена, когда действительно критичные данные нажиты ещё не были, но всё равно была такая же дикая неделя по восстановлению своих сокровищ. Зато теперь у меня пул из двух параллельных дисков, непериодичный бекап на NAS и годовой холодный бекап на «хард на полочке». И несмотря на то, что оперируемый объём исчисляется терабайтами, денег совсем не жалко на «избыточные» диски к покупке которых относишься просто как к сому собой разумеющемуся)
Sign up to leave a comment.