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

Коротко о том как «всё упало»:

Я купил себе дополнительный диск (SSD 240GB). Первым делом нужно было поставить на него операционную систему. И если бы я сделал всё как в «доке»: скачал образ, создал флешку Linux LiveUSB, перезагрузился, переустановился — этой статьи бы не было. Но, последние пару лет, я использовал VirtualBox и VBoxManage для установки операционных систем на различные носители. Через VBoxManage я создал «образ-ссылку» на свой новый SSD. А потом мне пришлось перезапустить комп. После этого я, ничего не перепроверив, запустил VirtualBox. Установщик показал мне диск в 240GB. Я благополучно создал разделы (150 GB — fileSystem, 10GB — swap, 80GB — data) и продолжил установку. Установщик успешно создал разделы, отформатировал их и установил систему в раздел fileSystem. Но оказалось что «образ-ссылка» вела на мой старый рабочий HDD.

Итак, диск HDD 750GB. Структура диска раньше:

  • ~600GB — EXT4 — Раздел со всеми моими данными и проектами (метка тома «data»)
  • ~15GB — SWAP — Подкачка (это раздел специально для Linux)
  • ~135GB — EXT4 — Раздел с операционной системой Linux

Структура диска после моей ошибки:

  • ~150GB — EXT4 — Раздел с операционной системой Linux
  • ~10GB — SWAP — Подкачка (это раздел специально для Linux)
  • ~80GB — EXT4 — Раздел для данных (метка тома «data»)
  • ~510GB — неразмеченная область

Мои инструменты:

  • USB-FLASH — 8GB. Это загрузочная флешка с Kali Linux LiveUSB
  • USB-HDD — 2TB
  • SSD — 240GB. Это мой новый дополнительный диск


День первый. testdisk


testdisk — пожалуй, лучшая программа для восстановления файлов и таблиц разделов. Она есть и на Windows и на Linux.

Это самая первая программа которой я воспользовался. Я уже работал с ней пару раз, когда «безвозвратно» удалял то, что требовалось «возвратить». И сначала я даже был уверен в том, что смогу всё легко исправить, используя testdisk. Ведь диск был отформатирован «быстрым способом». Да, на него была установлена новая система, но она весит примерно ~5GB. Т.е. ~745GB могут быть вообще не тронуты.

Запускаю Kali Linux LiveUSB и открываю терминал:

sudo -i
fdisk -l


На экране видно:

  • Disk /dev/sda — это моя флешка. С неё сейчас запущен Kali Linux.
  • Disk /dev/sdb — это мой «повреждённый» HDD
  • Disk /dev/loop0 — это что-то типа файловой системы LiveUSB, запущенный с флешки

Для тех, кто не знает что такое GiB, кратко: MB, GB, TB… — это величины байтов кратные 1000, а MiB, GiB, TiB… — величины кратные 1024. Обычно принято указывать величины кратные 1000, т.к. они более «человекопонятно» передают размер. Именно их вы видите чаще всего. В данном случае число 698.64GiB — это примерно 750GB, что видно по числам дальше 750156374016.

Таблица разделов на диске:

  • /dev/sdb1 — здесь сейчас стоит ошибочно поставленная система Linux
  • /dev/sdb2 — грубо говоря — это /dev/sdb5 + /dev/sdb6
  • /dev/sdb5 — это swap. Это раздел подкачки для Linux
  • /dev/sdb6 — это просто раздел, созданный для хранения данных

Далее пишу в терминале:

testdisk


После нажатия ENTER появляется следующее:


Нажимаю [No Log] — т.к. никаких логов мне не нужно:


Выбираю свой старый HDD /dev/sdb и нажимаю [Proceed]:


Это типы таблиц разделов. Кстати, testdisk не случайно подсветил тип [Intel] — почти всегда testdisk сам знает нужный тип. Для разделов FAT, NTFS, EXT2/3/4 нужно выбрать тип [Intel]. Выбираю и вижу это:


Мне нужен анализ диска. Нажимаю [Analyse]:


Здесь сразу видно, что ничего не понятно. Нажимаю [Quick Search] и…


… и testdisk сразу же показал мне мои старые разделы. Внизу есть подсказка — "P: list files". Я спускаюсь на третий раздел и нажимаю [P]:


Это моя старая файловая система. Для программы testdisk этот раздел «цел и невредим». Внизу есть дополнительные подсказки, где вполне понятно, что я без труда могу скопировать данные отсюда. Действительно, я подключил свой USB-HDD и скопировал на него пару нужных мне конфигов.

Нажимаю [q] для возврата.


Выбираю свой первый раздел, где содержится «вся моя жизнь». Нажимаю [P] и…


и вижу это: Can't open filesystem. Filesystem seems damaged

Нажимаю [Quit], чтобы вернуться к списку разделов (предыдущая картинка), далее жму [Enter]:


Я бы мог нажать [Write] и записать эту таблицу на диск, т.е. эти разделы восстановятся. И я бы сделал это, если бы testdisk показал мне файлы в разделе «data». Но этот раздел повреждён.

Я пытаюсь думать. Может быть testdisk немного неправильно распознал этот раздел? Нужно выполнить глубинный поиск. Это то, что необходимо сделать, если testdisk не показал вам нужных разделов. Глубинный поиск. Я нажимаю [Deeper Search].


Итак. Пошёл глубинный поиск. Через несколько часов я вижу это:

(Терминал изменился потому, что эти скрины я сделал вам со своей «новой» системы, т.к. LiveUSB вырубился. Не из-за testdisk. Вывод 100% идентичный. Просто не обращайте внимания.)


На самом деле — выбирать здесь нечего. Единственное что можно сделать это нажать [Continue]. Нажимаю:


Все, что я понял в результате «гугления» — это сообщение можно смело проигнорировать. Игнорирую это. Нажимаю [Continue]:


Раньше, на моём HDD и правда был раздел NTFS — пару лет назад. Раньше у него была другая структура и именно поэтому раздел «data» стоит вначале, а fileSystem — в конце. На самом деле всё это неважно. Важно то, что нигде, кроме раздела с операционной системой (файлы в котором я вам уже показывал), никаких данных нет.

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


Нажать [Enter] и…



и нажать [Write]. Я поставил «Звёздочку» на нижний раздел. Вроде бы так правильней, т.к. этот раздел загрузочный, но если что — testdisk сам разбёрется и сделает всё правильно.

Но я не нажимаю [Write], т.к. раздел «data» всё так же повреждён. Я не знаю что делать дальше и начинаю «гуглить».

Почти все инструкции, которые я нашёл — это чуть ли не «копипаст» одной и той же «доки» по testdisk, которую вы найдёте без труда. В двух словах это:

  • Запускаем testdisk
  • Нажимаем [Quick search]
  • Нажимаем [Deeper search]
  • Выбираем разделы с целыми данными
  • Нажимаем [Write] и хеппи-энд. Ваши данные восстановлены.

А что делать, если я вижу это: Cant't open filesystem. Filesystem seems damaged?

Я потратил какое-то время, чтобы найти точную инструкцию, чёткий план — как действовать в этой ситуации, но, рекомендации на форумах часто отличались. Вообще, казалось, что «все потеряно». Я начал искать другие программы по восстановлению данных. Лучшая рекомендация, которая действительно внушала доверие, звучала примерно так:
Если вы уже уничтожили вашу систему, самое худшее что вы можете сделать — это попытаться исправить ситуацию, не понимая, что именно вы делаете. Единственное, что вам нужно сделать — это оставить всё как есть и доверить восстановление данных специализированному ПО. Только так, но никак иначе.
Именно этому совету я и последовал. Я так и не нажал [Write] в программе testdisk и просто закрыл её. Просто закрыл терминал.

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

Её интерфейс, вначале такой же как и у testdisk.

Пишу в терминале:

photorec

Выбираю свой старый HDD и вижу это:


Первый раздел — это весь жёсткий диск, он мне и нужен. Выбираю. Далее действую по инструкции. И процесс пошёл.


Этот скриншот наглядно показывает то, что делает photorec. Она просто восстанавливает всё что найдёт (из того что вы указали в опциях). Без каталогов и без правильных названий. Если вам будет нужно восстановить картинки или видео, то эта штука точно выполнит свою задачу. Но для меня она была бесполезна. Через пару минут работы она нашла сотни тысяч текстовых файлов, которых будет несколько миллионов в дальнейшем. Из-за каталогов node_modules. Будет «нереально» восстановить структуру проектов среди всего этого «добра». Закрываю её.

День второй. R-Linux


Единственная «свежая» программа, под Linux, для восстановления структуры данных, которую я нашёл, была R-Linux (это бесплатная версия R-Studio, которая работает только с файловыми системами EXT/2/3/4). Всё так же, из-под Kali LiveUSB, я установил её и запустил сканирование. И через десять минут меня ждал чёрный экран.

Как я понял, программе R-Linux, для анализа диска 750GB, нужно ~2.5GB оперативной памяти и ~1.5GB — swap. Походу из-за этого она «роняла» LiveUSB. Но тогда я этого не знал — этого нигде не написано. Я не знал что мне делать, но точно решил одно — мне нужна стабильная рабочая система, для дальнейшего поиска решений.

Я отключил свой старый «повреждённый» HDD (на всякий случай), снова поставил новый SSD и установил на него Kali Linux, стандартно, через свою загрузочную флешку. Немного «причесал» систему, чтобы в ней было комфортно работать, установил нужные мне программы. После чего, снова подключил старый «повреждённый» HDD.

Далее, я снова поставил R-Linux и запустил её. Я выбираю свой HDD (ST975042OAS) и нажимаю [Сканировать]. Несколько часов ожидания, и на экране появились «новые разделы» c названием «Распознанный/4/5/6/7»:


Мне нужен «Распознанный4». Выбираю его и нажимаю [Показать содержимое диска]:


Не верится. Кажется, что программа нашла всё что раньше было на диске. Действительно, мне удалось восстановить и разную документацию, и музыку и, даже, iso-образы — всё это находилось, как бы, «неглубоко» внутри каталогов. Но счастье было недолгим. Каталоги с моими «рабочими» проектами содержат сотни файлов и подкаталогов и там оказалось всё очень печально:


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

Я был уверен, что если программа смогла восстановить хотя бы эту структуру, то всё то, что потеряно — потеряно навсегда. Просто уничтожено. Но, безуспешно перемещаясь по каталогам с названием "$InodeDir...", я наткнулся на каталоги с логами. Файлов с логами, в каждом каталоге, должно было быть около трёхсот. Но R-Linux восстановила, в каждом каталоге, ровно 100! Это важно — в каждом каталоге их было ровно 100 штук, не больше. Это же не совпадение! И тут я подумал, что если алгоритм программы имеет какую-то «глубину» восстановления и что, на самом деле, ещё не всё потеряно — просто нужно больше этой самой «глубины». Но в параметрах программы ничего такого не было.

В общем, я решил что попробую поставить платную R-Studio и посмотреть что будет. Итак, я установил её, запустил и нажал [Сканировать]:


Она нашла гораздо больше разделов, чем её «бесплатная» версия. В том числе разделы FAT и NTFS, которые были на диске раньше. Но меня интересует только раздел [Распознанный102]. Выбираю его и нажимаю [Показать файлы]. К сожалению, результат оказался таким же. Т.е. структура файлов и каталогов была, кажется, такой же, как и в программе «R-Linux». По крайней мере то, что мне было нужно, там не было.

День третий, четвёртый, пятый… Программы для Windows


Я начал искать другие программы для восстановления файловой структуры. Программы работающие как «photorec» меня не интересовали (но, я так же «потестил» foremost, extundelete, ext4Magic и ещё несколько — безрезультатно.). Но оказалось, что никаких других актуальных программ восстановления файлов и каталогов под Linux, на нашей планете, больше нет. Зато под Windows их десятки и многие из тех что «на слуху», позволяют работать с образами дисков.

План был такой:

  1. На свой USB-HDD я копирую образ своего повреждённого HDD.
  2. Ставлю VirtualBox и создаю виртуалку с Windows.
  3. «Расшариваю» этой виртуалке свой USB-HDD.
  4. Устанавливаю различные программы для восстановления файлов и разделов и смотрю что будет.

Чтобы создать образ повреждённого диска, необходимо выполнить команду:

 sudo dd if="/dev/DISKNAME" of="/PATH/TO/IMAGE.dd" conv=sync,noerror

Как я понял, лучше использовать именно «dd» (т.к. все пишут что — «лучше использовать именно „dd“»), где:

  • if — это мой жёсткий диск. Используйте sudo fdisk -l, чтобы узнать точный путь вашего диска
  • of — это путь к создаваемому образу
  • noerror — укажите обязательно, иначе создание прервётся, если будет ошибка. У меня сыпались сотни ошибок в конце операции
  • sync — как я понял, необходим, если вы работаете с «повреждённым» диском, но это не точно

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

Я не буду писать их названий, думаю это будет неправильно, поскольку они не справились. Вообще, оказалось что, большая часть «популярных» программ — это что-то типа «photorec с платным графическим интерфейсом». Лишь, паре из них удалось найти что-то, похожее на правду, но результат был гораздо хуже чем у R-Linux, другие вообще нашли только файлы от новой установленной операционной системы. Будь у меня FAT или NTFS, возможно результат был бы лучше — есть программы, которые работают только с ними.

Последняя надежда


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

Свою основную «ставку» я сделал на набор программ sleuthkit. Это набор консольных программ для анализа жёстких дисков. Ещё есть программа AutoPsy, которая «под капотом», работает именно на них. Я также попробовал AutoPsy под Windows и под Linux — тоже безрезультатно.

В общем, я снова перешел в терминал и принялся изучать sleuthkit. Я вводил разные команды, но постоянно получал ошибки раздела. Проблема была в том, что я работал с образом всего жёсткого диска. Т.е. мне обязательно нужно было прописывать «offset» — точку, начала «повреждённого» раздела жёсткого диска. И вроде, казалось, что я всё делаю правильно — но ничего не получалось (я так и не разобрался с ними до конца, поэтому не буду приводить примеры команд — мало ли). Тогда я решил, что создам образ конкретного повреждённого раздела и буду работать с ним. Я снова вспомнил про testdisk.

Пишу в терминале:

testdisk /path/to/image.dd

Далее всё как в начале статьи. [No Log] -> [Proceed] -> [Intel] -> [Analyse] -> [Quick Search]. Снова вижу свои старые разделы. Нажимаю «Enter». В прошлый раз я работал с образом. Но сейчас восстановлю разделы на реальном диске:


testdisk правильно видит мои старые разделы. Если у вас не так, то вам нужно будет нажать [Deeper Search] и выбрать их. Я уже писал об этом выше. Я же нажимаю [Write]:


Подтверждаю, что готов записать таблицу, нажимая [y]:


Нажимаю [OK]. Появляется это окно:


Нажимаю [Advanced]:


Теперь здесь видны мои «старые» правильные разделы. Выбираю первый «data», он всё так же повреждён, но мне нужно лишь создать его образ. Нажимаю [Image Creation], указываю папку для сохранения. Будьте внимательны — testdisk создаст образ под названием «image.dd». На всякий случай, убедитесь что в папке назначения нет файла с таким именем (а то мало ли). Начинается создание образа раздела.

Когда образ раздела был создан, я подумал, а что будет, если я попробую «прогнать» его через R-Linux? Я снова запустил её:


Обратите внимание на таблицу разделов «бывшего повреждённого» диска ST9750420AS. testdisk «вернул» ему его старую таблицу разделов (но раздел «data» всё так же повреждён).

В прошлый раз я выбрал образ раздела, сейчас же, выберу реальный «воссозданный» «Раздел1». Нажимаю [Показать содержимое диска] и буквально через 40 минут вижу это (правая часть картинки):


Видите небольшую разницу между разделом «Распознанный4», появившимся после сканирования в начале статьи, и восстановленным разделом «Раздел1». Когда я «прошелся» по каталогам, оказалось, что почти все они целы. Визуально, файлы и проекты на месте. Даже логи лежали там, где должны были лежать и теперь их больше 100 в каждом каталоге. Серьёзно? И это то, что нужно было сделать? Т.е. я даже пятичасового сканирования не запускал. Это было просто невероятно, особенно после недели бессонницы.

Оказалось, что почти все мои данные в порядке. Разумеется что были и повреждённые файлы. Было много мусорных файлов и каталогов. Я не закрывал R-Linux и через поиск искал недостающее. За пару дней я восстановил всё что было нужно.

Немного экспериментов


Теперь я спокоен. Я всё восстановил. Также у меня сохранён образ моего раздела. Я решил немного «поэкспериментировать» и подробнее изучить рекомендации из интернета. Но эксперименты эти оказались недолгими.

По запросу, "Cant't open filesystem. Filesystem seems damaged", в поисковике, единственное что вы найдёте — это ветки форумов с печальным концом. Я где-то нашёл рекомендацию, что для восстановления структуры данных можно попробовать команду (НЕ ВВОДИТЕ ЕЁ) "fsck -y /dev/DISKNAME" и она «автоматически всё поправит». Я попробовал её и вот результат:


Она и правда восстановила каталоги на моём разделе — только это каталоги ошибочно поставленной операционной системы. И как я понял — «откатиться» назад нельзя.

И даже testdisk теперь ничего не видит. Даже метка «data» слетела:


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

Заключение


Как вы поняли, я не эксперт в восстановлении данных. Но как показал личный опыт — многие авторы статей и рекомендаций, в интернете, тоже далеко не эксперты.

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

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

  1. Создать LiveUSB (Linux, Windows — не важно, главное, чтобы был testdisk).
  2. Через LiveUSB запустить testdisk и найти старые разделы (через [Quick Search] и [Deeper Search]). Если данные на них видны, то можно спокойно сохранить их, разумеется, на другой жёсткий диск. Если нет — то идти дальше по пунктам.
  3. Если есть возможность, лучше создать образ всего жёсткого диска и работать только с ним. Это может сделать почти любая программа для восстановления данных. В Linux можно воспользоваться командой sudo dd if="/dev/DISKNAME" of="/PATH/TO/IMAGE.dd" conv=sync,noerror (ее описание есть выше).
  4. LiveUSB — это, конечно, хорошо, но как показал опыт, не всякая программа будет работать в ней. R-Linux работать отказалась. Виртуалка, кстати, тоже зависала несколько раз. Поэтому, скорее всего, нужна будет полноценная установленная система (Linux, Windows — не важно).
  5. Далее снова открыть testdisk. Если есть образ диска, то открыть его так: testdisk /path/to/image.dd. Найти свои старые разделы, выбрать их и нажать [Write] (вверху есть подробная инструкция). Это единственная программа, которой я позволю вносить изменения на диск (т.к. в случае ошибки всегда можно повторить процедуру). Если есть возможность, нужно создать через testdisk образы восстановленных разделов.
  6. Поставить программы для восстановления данных и «скормить» им восстановленные testdisk-ом разделы, а лучше их образы. Не позволять программам вносить изменений (если нет сохранённых образов разделов) — они должны только показать данные, которые можно будет восстановить.

Не забывайте делать коммиты, чаще используйте bitbucket и github. И никогда не откладывайте резервное копирование. Удачи вам!

Комментарии (78)


  1. Shaz
    13.12.2021 12:13
    -11

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


    1. aik
      13.12.2021 12:23
      +3

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


      1. Shaz
        13.12.2021 12:26
        +5

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


        1. falcon4fun
          15.12.2021 09:22
          +2

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

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


  1. aik
    13.12.2021 12:21
    +28

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


    1. rease Автор
      13.12.2021 15:30
      +3

      Да, Вы правы)

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


      1. aik
        13.12.2021 17:07
        +4

        Бэкапы. :)


        1. aleksandy
          14.12.2021 06:57

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


          1. aik
            14.12.2021 12:37
            +1

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


  1. Sergey_datex
    13.12.2021 13:10
    +12

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

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

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

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


    1. netch80
      13.12.2021 13:30

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

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


      1. Sergey_datex
        13.12.2021 13:52
        +1

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


        1. netch80
          13.12.2021 14:17

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

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


          1. Sergey_datex
            13.12.2021 14:38
            +1

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


            1. ner0
              13.12.2021 15:57

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


              1. Sergey_datex
                13.12.2021 16:03
                +1

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


                1. mpa4b
                  13.12.2021 18:20
                  +2

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


                  1. Sergey_datex
                    14.12.2021 00:55

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

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


                    1. Zhurikello
                      14.12.2021 01:21

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


                    1. mpa4b
                      14.12.2021 16:23

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


    1. aik
      13.12.2021 13:34
      +1

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


      1. epstein_dkh
        13.12.2021 18:06
        +1

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


        1. aik
          13.12.2021 18:21
          +1

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

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


          1. rease Автор
            13.12.2021 19:09

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


            1. JerleShannara
              13.12.2021 19:27
              +3

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


              1. rease Автор
                13.12.2021 19:45

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


                1. JerleShannara
                  13.12.2021 21:14

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


                1. aapchy199
                  14.12.2021 10:52

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

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


      1. NTDLL
        13.12.2021 20:07

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

        А сейчас вспомните, как вы меня хаяли. Я кстати ту публикацию удалил, её обсуждали не очень дальновидные люди по всей видимости.
        Так всё таки, что лучше, HDD или SSD?


        1. fedorro
          13.12.2021 21:22
          +3

          SSD и бэкапы на HDD)


        1. aik
          13.12.2021 21:42

          Лучше ссд и бэкапы. В несколько мест.
          Ибо запороть удалённое можно и на жестком диске. Просто ссд это делает в силу собственной конструкции совершенно автоматически.


        1. Massacre
          15.12.2021 13:24

          А у них вообще разное предназначение. SSD — эфемерное быстрое хранилище (потому, что может умереть непредсказуемо в любой момент), HDD — более медленное классическое. Умереть тоже может, но более предсказуемо, ну и данные, как правило, можно восстановить.

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


    1. Earthsea
      13.12.2021 14:07
      +4

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

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


      1. Sergey_datex
        13.12.2021 14:20
        +10

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


  1. emashev
    13.12.2021 13:13
    +2

    Несколько лет назад мне принесли диск от хранилки Qnap после форматирования.
    Пробовал все вышестоящие утилиты, но файлы они восстанавливали без имен и структуры каталогов. А их там было тясячи. Помогла ext3grep - восстановились файлы с корректными именами и структурой каталогов.


  1. man_of_letters
    13.12.2021 13:34
    +4

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

    https://rlab.ru/tools/rsaver.html


    1. lll000lll
      14.12.2021 06:10

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


  1. shiz0id
    13.12.2021 16:00
    +18

    За старания 5

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

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

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


    1. rease Автор
      13.12.2021 16:23
      +2

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


      1. n0isy
        14.12.2021 08:36
        +2

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


        1. danfe
          14.12.2021 11:03
          +3

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


        1. Zhurikello
          14.12.2021 11:06
          +2

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


        1. dMac
          15.12.2021 02:27
          +2

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


      1. zuek
        14.12.2021 11:36
        +1

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

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

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


        1. rease Автор
          14.12.2021 14:31
          +1

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

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

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


          1. JerleShannara
            14.12.2021 14:55

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


        1. navion
          16.12.2021 12:05

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


  1. werter_l
    13.12.2021 16:44

    Спасибо, что поделились.
    Зы. Бэкаплю в нес-ко мест


  1. NTDLL
    13.12.2021 16:54

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


    1. rease Автор
      13.12.2021 18:05

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

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


      1. engine9
        14.12.2021 12:13
        +1

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


        1. rease Автор
          14.12.2021 13:07

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

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


      1. sundmoon
        14.12.2021 17:31

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

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


  1. speshuric
    13.12.2021 17:02
    +2

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

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

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

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

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


    1. 1A1A1
      13.12.2021 18:29
      +1

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


      1. speshuric
        13.12.2021 18:36
        +1

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


        1. rease Автор
          13.12.2021 20:49
          +1

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

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


          1. dMac
            15.12.2021 02:30

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


      1. engine9
        14.12.2021 12:17

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


    1. rease Автор
      13.12.2021 20:56
      +3

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

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


  1. vgogolin
    13.12.2021 20:25
    +3

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


  1. rostislav-zp
    13.12.2021 21:37

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


  1. AVX
    13.12.2021 22:29
    +1

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

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

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

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

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


    1. rease Автор
      14.12.2021 12:37

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

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

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

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


      1. AVX
        14.12.2021 14:15

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

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


  1. lll000lll
    14.12.2021 06:06
    +2

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


  1. evil_random
    14.12.2021 07:04
    +2

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


  1. YMax
    14.12.2021 07:43
    +1

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

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


  1. Black_Spirit
    14.12.2021 10:16

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


  1. engine9
    14.12.2021 12:09
    +2

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

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

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


    1. rease Автор
      14.12.2021 14:46

      Благодарю)

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


    1. Massacre
      15.12.2021 13:31

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


      1. rease Автор
        15.12.2021 14:30

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


        1. Massacre
          16.12.2021 02:07

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


  1. LM7777
    14.12.2021 20:24
    +1

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

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

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

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


  1. Lord_Prizrak
    15.12.2021 04:18
    +1

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


    1. rease Автор
      15.12.2021 10:02
      +1

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

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

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


  1. v0id
    16.12.2021 04:23

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