Раздел восстановления linux

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

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

В этой статье мы рассмотрим утилиту fsck и её использование, чтобы помочь вам исправить ошибки диска.

Когда использовать fsck в Linux

Есть разные сценарии, когда вы захотите запустить fsck. Вот несколько примеров:

Опции программы fsck

Команду fsck необходимо запускать с привилегиями суперпользователя или root. Вы можете использовать её с разными аргументами. Их использование зависит от вашего конкретного случая. Ниже вы увидите некоторые из наиболее важных опций:

Как запустить fsck для исправления ошибок файловой системы Linux

Чтобы запустить fsck, вам нужно убедиться, что раздел, который вы собираетесь проверить, не смонтирован. Для целей этой статьи я буду использовать свой второй диск /dev/sda, смонтированный в /mnt/disk_d.

Вот что произойдёт, если я попытаюсь запустить fsck, когда раздел смонтирован.

sudo fsck /dev/sda

fsck из util-linux 2.36.1
e2fsck 1.45.6 (20-Mar-2020)
/dev/sda is in mounted.
e2fsck: Cannot continue, aborting.

Если диск не только смонтирован, но и используется (например, диск, смонтированный в корневую файловую систему), то ошибка будет «/dev/nvme0n1 is in use».

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

sudo umount /dev/sda

Тогда можно будет безопасно запускать fsck.

Понимание кодов выхода fsck

После запуска fsck он вернёт код выхода. Эти коды можно увидеть в руководстве по fsck, запустив:

Описание кодов выхода fsck:

0 Ошибок нет
1 Исправлены ошибки файловой системы
2 Система должна быть перезагружена
4 Ошибки файловой системы остались неисправленными
8 Операционная ошибка
16 Ошибка использования или синтаксиса
32 Проверка отменена по запросу пользователя
128 Ошибка общей библиотеки

Как исправить ошибки файловой системы Linux

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

sudo fsck -y /dev/sdb

Флаг -y означает автоматически отвечать «да» на любые запросы от fsck для исправления ошибки.

Точно так же вы можете запустить то же самое во всех файловых системах (с пропуском корневой файловой системы):

sudo fsck -AR -y

Как запустить fsck на корневом разделе Linux

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

Мы рассмотрим обе ситуации.

Как принудительно проверить диск с помощью fsck при загрузке системы

Это относительно легко выполнить, единственное, что вам нужно сделать, это создать файл с именем forcefsck в корневом разделе вашей системы. Используйте следующую команду:

sudo touch /forcefsck

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

После загрузки системы проверьте, существует ли ещё файл:

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

Как запустить fsck в режиме восстановления

Для запуска fsck в режиме восстановления требуется ещё несколько шагов. Сначала подготовьте вашу систему к перезагрузке. Остановите все критически важные службы, такие как MySQL/MariaDB и т. д., а затем введите.

Во время загрузки удерживайте нажатой клавишу Shift, чтобы отобразилось меню grub. Выберите Advanced options («Дополнительные параметры»).

Затем выберите Recovery mode («Режим восстановления»).

В следующем меню выберите «fsck».

Вас спросят, хотите ли вы перемонтировать / файловую систему. Выберите Yes («да»).

Вы должны увидеть нечто подобное.

Затем вы можете вернуться к нормальной загрузке, выбрав Resume («Возобновить»).

Заключение

В этом руководстве вы узнали, как использовать fsck и выполнять проверки согласованности в разных файловых системах Linux. Если у вас есть какие-либо вопросы о fsck, не стесняйтесь задавать их в разделе комментариев ниже.

Прикладная некромантия в линукс или возвращаем из небытия удаленные файлы

Время на прочтение

photorec – утилита восстановления данных таких, как файлы видео, документы, архивы с жестких дисков и cdrom дисков, а также фото (поэтому название программы Photo Recovery) со встроенной памяти камер. Список типов файлов для восстановления весьма внушителен и с ним можно ознакомиться тут.

Обе утилиты open source, распространяются под лицензией GNU General Public License (GPL). Имеются в наличие версии для linux, unix, а также для windows платформ.

В большинстве линукс дистрибутивов уже включены в состав стандартного репозитория. Для debian-based дистрибутивов установка командой:

sudo aptitude install testdisk

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

В моем случае это будет /dev/sdb.
Далее выбираем тип таблицы разделов на диске, для большинства пользователей это будет Intel/PC.

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

А затем на другом диске выбираем директорию, куда утилита сохранит восстановленные файлы.

Далее нажимаем Y и программа начинает свою работу. Для 32Мб карточки ей потребовалось меньше минуты.
Теперь о результатах работы:
Честно говоря, по началу я весьма сомневался в способностях программы. Но открыв директорию с результатами работы утилиты, я с удивлением обнаружил, что были восстановлены не только нужные недавно сделанные 10 фотографий, но и еще 110 других, самая ранняя из которых была сделана 3 года назад и не была перезаписана при дальнейшем использовании карточки, хотя форматировалась карта неоднократно.
В итоге имеем очередную победу добра над злом, счастливую улыбку обладателя фотоаппарата, еще один факт доказательства того, что существует море полезных и качественных opensource утилит.

Состояние перевода: На этой странице представлен перевод статьи fsck. Дата последней синхронизации: 10 июля 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

fsck (file system check) — утилита для проверки и восстановления файловых систем Linux. Проверка файловых систем разных физических дисков выполняется параллельно, что позволяет значительно её ускорить (см. ).

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

Проверка при загрузке

Существует два возможных варианта:

Рекомендуется по умолчанию использовать первый вариант. Если вы устанавливали систему в соответствии с руководством, то использоваться будет именно он. Если вы хотите вместо этого использовать вариант 2, то удалите хук fsck из mkinitcpio.conf и задайте параметр ядра ro. Кроме того, параметром ядра fsck.mode=skip можно полностью отключить fsck для обоих вариантов.

Если вы используете base-хук mkinitcpio, то можно принудительно выполнять fsck во время загрузки, задав параметр ядра fsck.mode=force. Проверена будет каждая файловая система на машине.

Примечание: Если вы используете другие дистрибутивы GNU/Linux, то учтите, что старые методы проверки вроде файлов forcefsck для каждой файловой системы или команды shutdown с флагом -F будут работать только с SysVinit и ранними версиями Upstart; работать с systemd они не будут. Решение, предложенное выше, является единственным рабочим для Arch Linux.

Советы и рекомандации

Следующая команда позволяет восстановить повреждённые участки файловых систем ext2/ext3/ext4 и FAT:

Важно: Разрешение на восстановление запрошено не будет. Подразумевается, что вы уже ответили «Да», запустив команду на выполнение.

# fsck -a

Интерактивное восстановление повреждённых блоков

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

# fsck -r диск

Изменение частоты проверки

Примечание: Команды tune2fs и dumpe2fs работают только с файловыми системами ext2/ext3/ext4.

По умолчанию fsck проверяет файловую систему каждые 30 загрузок (вычисляется отдельно для каждого раздела). Чтобы изменить частотку проверок, выполните:

# tune2fs -c 20 /dev/sda1

Здесь 20 — число загрузок между проверками. Если задать значение 1, то проверка будет выполняться при каждой загрузке, а значение 0 отключит сканирование.

Текущую частоту проверок и опции монтирования конкретного раздела можно узнать командой:

fstab — файл системных настроек, который используется для передачи ядру Linux информации о том, какие разделы (файловые системы) монтировать и в какие точки дерева файловой системы.

Записи в /etc/fstab выглядят примерно следующим образом.

/dev/sda1 / ext4 defaults 0 1
/dev/sda2 /other ext4 defaults 0 2
/dev/sda3 /win ntfs-3g defaults 0 0

Шестое поле каждой строки (выделено) — опция fsck:

Не запускается fsck для отдельного раздела /usr

Иногда (например, из-за внезапного отключения питания) файловые системы ext(3/4) могут повредиться так сильно, что восстановить их обычным способом не удастся. Как правило, при этом fsck выводит сообщение о том, что не удалось найти журнал (no external journal). В этом случае выполните команды ниже.

Отмонтируйте раздел от соответствующего каталога:

# umount каталог

Запишите на раздел новый журнал:

# tune2fs -j /dev/раздел

Запустите fsck, чтобы восстановить раздел:

# fsck -p /dev/раздел

Intro.

Далее, с целью отката изменений, были объединены диски (10, 2 и 8) обратно в один 20Гб и отформатирован в NTFS. В нагрузку к этому, были проведены операции с MBR, результатом которой явилась ее смерть.

Итоги

1. При загрузке системы выводится сообщение MBR helper not found;
2. fdisk показывает один большой 160Гб диск.

Дураку понятно, что это начало веселой ночи.
Далее, под катом, решения вопроса.

Восстановление таблицы разделов

Данный LiveCDUSB дистрибутив, размером в 100Мб несет в себе огромную кучу софта, для работы с дисками. От разбивки, до восстановления.
Из них всех, нам нужны будут gpart, testdisk, fdisk и ms-sys.

Gpart

gpart — это утилита, сканирующая по-секторно диск на наличие разделов, которые присутствуют на носителе, но отсутствуют в таблице. В своей работе, она игнорирует уже существующую таблицу (если присутствует). Программа разаботана немецким программистом Michail Brzitwa и больше им не поддерживается. Вялотекущая разработка ведется командами Fedora и Debian. Текущая версия — 0.1h.

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

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

gpart -if /dev/sda

-i — интерактивный режим. На каждую найденную партицию будет задан вопрос, сохранять ее, либо пропустить.
-f — полный скан диска.

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

Если все ОК, то соглашаемся на запись в таблицу разделов, скрещиваем пальцы и перезагружаемся.
В моем случае, программа определила разделы, которые были до разбивки (40 и 120), что не подходило и заставило искать альтернативные способы восстановления.

Testdisk

Note: подробнее эта утилита описана в этом посте, здесь не буду повторяться.

Эта утилита аналогична предыдущей, но имеет ряд плюсов:
1. более свежая и активно поддерживается;
2. субъективно, работает намного быстрее;
3. функциональнее;
4. есть простой консольный интерфейс на базе ncurses.

В моем случае, результат был аналогичен результату gpart, что есть некорректен.
Запустив Deep search, выждав около 40 минут я получил ответ, от которого на душе так нехило отлегло.
Было найдено несколько партиций, которые накладывались одна на другую (это были изначальная (до манипуляций) 120Гб и новая, на 100Гб). Отметив ненужную, как удаленную, я записал таблицу на диск и перезагрузился. К счастью, все обошлось и компьютер вернулся к состоянию, который был изначально, а я мог с чистой совестью лечь спать.

Восстановление MBR

Для этой задачи, у нас в арсенале есть тулза ms-sys.
Сперва узнаем, что с нашей MBR.

ms-sys /dev/sda
/dev/sda has an x86 boot sector
it is unknown boot sector

Теперь видно, что на данном диске нет загрузочного сектора.
Утилита может работать с MBR различных операционных систем. Список можно получить, запустив программу без агрументов. В моем случае, необходим был от Windows 7.
Записываем MBR на диск:

ms-sys -7 /dev/sda
Windows 7 master boot record successfully written to /dev/sda

Проверяем:

ms-sys /dev/sda
it is Microsof 7 master boot record, like the one this
program creates with the switch -7 on a hard disk device.

Вот и все, нужная MBR установлена и можно перезагружаться.

Outro

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

Как я восстановил данные после форматирования, создания разделов и установки системы на «не том» жестком диске

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

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

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

комп. После этого я,

ничего не перепроверив

, запустил VirtualBox. Установщик показал мне диск в 240GB. Я благополучно создал разделы (150 GB — fileSystem, 10GB — swap, 80GB — data) и продолжил установку. Установщик успешно создал разделы, отформатировал их и установил систему в раздел fileSystem. Но оказалось что «образ-ссылка» вела на мой старый рабочий HDD.

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

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

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

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

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

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

sudo -i
fdisk -l

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы уже уничтожили вашу систему, самое худшее что вы можете сделать — это попытаться исправить ситуацию, не понимая, что именно вы делаете. Единственное, что вам нужно сделать — это оставить всё как есть и доверить восстановление данных специализированному ПО. Только так, но никак иначе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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