Строка в выводе lsblk, где ещё вчера значился раздел с терабайтами архивов, исчезла. На её месте теперь неразмеченное пространство, а вместе с разделом пропали точки монтирования, базы и вечерние дампы. Первый порыв у большинства инженеров одинаков: пересоздать раздел с теми же параметрами, смонтировать и жить дальше. Именно этот порыв чаще всего и портит файлы, которые до него были почти целы. Утилита testdisk восстанавливает не файлы, а саму запись о разделе в таблице, и при аккуратной работе не пишет ни байта в области данных соседних томов. Ниже реальная процедура: от резервной копии разметки до проверки списка файлов перед записью таблицы, с разбором типичных ошибок.
Раздел исчезает из таблицы но файлы остаются на месте
Таблица разделов живёт в первых секторах диска и по размеру скромна до смешного. В классической разметке MBR на каждую запись отводится 16 байт, четыре первичных записи умещаются в 64 байта, а в конце сектора стоит сигнатура 55AA. В GPT запись занимает 128 байт, по умолчанию их 128, и лежат они в секторах со второго по тридцать третий, а резервная копия таблицы хранится в конце диска. Удаление раздела в fdisk, gdisk или графическом gparted меняет только эти байты. Сами файлы, каталоги и метаданные остаются на своих местах, пока их место не займёт новая запись.
Отсюда главное правило: после обнаружения пропажи на диск нельзя писать. Каждая новая порция данных повышает шанс, что освободившееся место будет перекрыто. Задачи с записью останавливаются, соседние разделы отмонтируются, и по возможности вся работа ведётся из живого дистрибутива, загруженного с флешки. Система, которая стоит на пострадавшем диске, тоже запишет что-нибудь в свои журналы, поэтому живой носитель это не перестраховка, а способ заморозить картину.
Причины пропажи обычно банальны. Неточная команда fdisk не на том устройстве, прерванное изменение размеров в gparted, восстановление копии таблицы не туда, невнимательность в установщике операционной системы, редкий сбой при записи в область таблицы. Железо в большинстве случаев ни при чём, и это лучшая новость в плохой день.
Отдельно стоит помнить про диски с GPT: у них в нулевом секторе лежит защитный MBR, и часть старых утилит видит устройство целиком как один раздел неизвестного типа. Отсюда классическая ошибка диагностики: программа показывает неразмеченный диск, хотя полноценная таблица жива в секторах дальше. Прежде чем что-либо восстанавливать, стоит посмотреть на диск двумя инструментами, lsblk и parted, и сравнить картину. Если parted видит таблицу, а lsblk нет, проблема глубже случайного удаления, и речь уже о повреждении самих секторов с таблицей.
Подготовка диска и резервная копия текущей разметки
Даже повреждённая таблица заслуживает копии. Бывает, что раздел на самом деле жив, а испорчена одна запись, и тогда возврат сохранённой разметки решает всё за минуту. Порядок подготовки перед любым восстановлением выглядит так:
- прекратить любые записи на диск и отмонтировать разделы которые ещё видны;
- зафиксировать текущее состояние командами
lsblk -fиblkidв текстовый файл; - снять копию таблицы утилитой
sfdisk --dumpв файл на другом носителе; - для диска с MBR сохранить первые 512 байт командой dd в отдельный образ;
- при ошибках ввода-вывода в dmesg сначала снять полную копию диска ddrescue;
- запускать testdisk из живого дистрибутива а не из системы на этом же диске.
Команды резервного копирования выполняются за секунды:
sudo sfdisk --dump /dev/sda > /root/sda-table-backup.txt
sudo dd if=/dev/sda of=/root/mbr-copy.bin bs=512 count=1Для GPT удобна утилита sgdisk из пакета gdisk:
sudo sgdisk -b /root/sda-gpt-backup.bak /dev/sdaКопии хранятся на другом носителе или на машине администратора. Если dmesg показывает ошибки ввода-вывода, план меняется: сначала побитовая копия утилитой ddrescue на исправный диск, и уже с копии ведётся поиск. testdisk умеет работать с файлом-образом как с диском, так что сама процедура восстановления от этого не меняется. Разница в том, что при ошибках на живом носителе каждая попытка чтения способна ухудшить состояние поверхности.
Если копия sfdisk снималась до пропажи и свежая, план А выглядит иначе: разметка возвращается из файла одной командой, и testdisk не нужен вовсе:
sudo sfdisk /dev/sda < /root/sda-table-backup.txtУтилита перезапишет таблицу из текстового описания, ядро перечитает её после partprobe или перезагрузки, и разделы встанут на свои секторные границы. Копия, снятая год назад и не знающая про сегодняшние изменения, уже опасна: возврат сдвинет разделы относительно реального содержимого. По этой причине фиксация состояния идёт первым шагом, а не последним.
Пошаговая процедура в testdisk от выбора диска до анализа Quick Search
Утилита распространяется свободно, работает в Linux, Windows и macOS, интерфейс у неё консольный, из меню по стрелкам, и это единственный экран, который придётся освоить. Запуск требует прав суперпользователя, иначе списка устройств не будет:
sudo testdiskПервый экран предлагает создать журнал сессии testdisk.log в рабочем каталоге, и с этим стоит согласиться: журнал пригодится, если что-то пойдёт не по плану. Дальше выбирается устройство, и внимание на размер в списке: он должен совпадать с ожидаемым, особенно когда в сервере стоит несколько накопителей одной модели. Ошибиться здесь означает искать разделы на соседнем диске.
Третий экран спрашивает тип разметки. Программа обычно сама подставляет верное значение в квадратных скобках, [Intel] для классической MBR или [EFI GPT] для современной разметки, и автодетект оставляют как есть. Подтверждать смену геометрии, если утилита предлагает параметры цилиндров и головок, не нужно: значения по умолчанию в почти всех случаях корректны.
Основной маршрут выглядит как Analyse и затем Quick Search. Поиск опирается на сигнатуры файловых систем и заголовки логических разделов, занимает от пары секунд на SSD до десятков минут на больших HDD, и прерывать его не стоит. По завершении на экране появляется список найденных разделов с колонкой признаков: P для первичного, L для логического, звёздочка для загрузочного. Рядом с живыми записями размещаются кандидаты на возврат, и дальше начинается проверка, ради которой всё затевалось.
Проверка найденного перед записью новой таблицы разделов
Самый ответственный момент наступает до записи, а не после. Список из Quick Search сверяется с зафиксированным ранее выводом lsblk: каждый существующий раздел обязан сохранить ту же стартовую позицию и размер в секторах. Расхождение хотя бы по одному живому разделу означает, что найденная структура не соответствует текущей, и писать её нельзя ни при каком давлении сроков.
Содержимое кандидата проверяется прямо из testdisk: курсор на найденный раздел, клавиша P открывает список файлов и каталогов. Просмотр ничего не изменяет на диске, это чистое чтение. Если в списке знакомая структура и файлы с прежними именами, перед вами настоящий раздел, а не след прошлой разметки. Выход из списка по клавише q возвращает к таблице.
Когда поиск находит несколько версий одного раздела, обычно после прошлых переразметок, выбор делается по содержимому: правильная версия покажет актуальные файлы, старые следы покажут давно удалённые каталоги. Ориентироваться на размеры вслепую не стоит.
Проверка проще всего запоминается на числах. Пусть на диске было три раздела, и второй пропал после неудачного редактирования. До инцидента вывод lsblk запечатлел начало и конец каждого раздела в секторах. После Quick Search кандидат обязан показать те же стартовые позиции, что в зафиксированном файле. Совпали числа, а одно отличается на десяток секторов? Это не совпадение, это чужая запись, и писать её нельзя. Таблица не терпит приблизительности: раздел либо стоит на своих секторах, либо это уже другой раздел.
Клавиши со стрелками меняют статус записи: раздел помечается как первичный, логический или исключается из таблицы. Когда раскладка сошлась с реальностью, выбирается Write. Механизм у кнопки честный: перезаписываются только секторы с таблицей, области данных соседних томов не затрагиваются. После записи программа предлагает перезагрузку, и ядро при старте прочитает новую разметку. Без перезагрузки иногда спасает partprobe, но при живой системе надёжнее перезапустить машину. Для GPT после загрузки стоит открыть диск в gdisk: утилита сама предупредит, если основная и резервная копии таблицы разошлись, и предложит исправить.
Глубокий поиск Deeper Search для сложных случаев со старыми следами
Когда Quick Search не находит раздел или находит заведомо не тот, в дело идёт Deeper Search. Утилита сканирует всю поверхность в поисках сигнатур файловых систем и поднимает разделы, у которых уцелели только метаданные внутри области данных. На многотерабайтных накопителях это часы работы, зато выкапываются разделы после многократных переразметок, неудачных изменений размеров и частичной перезаписи начала диска. Старые разделы времён MBR, начинавшиеся с 63 сектора, и современные, выровненные по сектору 2048, находятся одинаково.
У глубокого поиска есть обратная сторона: он находит всё подряд, включая давно неактуальные структуры. Перед записью каждый кандидат проверяется клавишей P по файлам, иначе легко вернуть прошлогоднюю разметку поверх действующей.
Утилита понимает распространённые файловые системы: NTFS, FAT и exFAT, ext2, ext3 и ext4, btrfs с ограничениями, HFS+, XFS. Если цель лишь вытащить файлы без возврата раздела, соседняя PhotoRec из того же комплекта собирает файлы по сигнатурам, но это уже крайний случай с потерей структуры каталогов.
На практике после записи таблицы требуется ещё раз собрать стек над разделом. Для LVM это vgscan и затем vgchange -ay, для массивов mdadm это mdadm --assemble --scan, для шифрованного тома luksOpen из cryptsetup. Запись о разделе для них просто вход, дальше каждый слой поднимается своими инструментами.
Бывает, что раздел вернулся, а файловая система на нём выглядит повреждённой, если эксперименты затронули начало области данных. У ext2, ext3 и ext4 резервные копии суперблока хранятся в известных местах, и e2fsck умеет работать с ними. Список позиций выводится командой mke2fs с флагом -n, которая ничего не пишет на диск, а затем проверка запускается с указанием нужной копии:
sudo mke2fs -n /dev/sda3
sudo e2fsck -b 32768 /dev/sda3Число 32768 это стандартная позиция первой резервной копии на томе с обычной геометрией, точное значение подскажет вывод первой команды.
Типичные ошибки при восстановлении и правила безопасности
Список классических ошибок за годы не меняется. Сначала поверх старого создают новый раздел и форматируют его, отрезая утилите путь к данным. Потом запускают поиск прямо из системы, которая продолжает писать на этот же диск. Ещё вариант: записывают таблицу со списком, где живой раздел оказался помечен как удалённый или сдвинут по стартовой позиции. Каждый пункт лечится дисциплиной: сначала копия таблицы, потом проверка файлов, только потом Write.
После успешной записи раздел монтируется только для чтения:
sudo mount -o ro /dev/sda3 /mnt/check
sudo fsck -n /dev/sda3Проверка fsck с флагом -n ничего не меняет на диске и честно докладывает о найденных несоответствиях. Критичные файлы копируются на другой носитель немедленно, и лишь затем раздел возвращается в штатную работу с записью.
Нюанс для SSD: команда TRIM сообщает накопителю, что блоки удалённого раздела можно чистить в фоновом режиме, и возврат отдельных файлов на твердотельных дисках даёт худшие результаты, чем на старых HDD. Таблица разделов при этом не страдает: testdisk правит метаданные, а не содержимое разделов, и восстановление записи на SSD проходит так же надёжно. Ограничение TRIM накрывает только сценарий, когда раздел удалён давно, а вытащить хочется файлы внутри него. Чем меньше времени прошло с пропажи, тем выше шансы, и первая реакция на инцидент это остановка записи, а не запуск утилит.
Убедиться, что ядро приняло новую разметку, помогает dmesg: строки вида "sda: sda1 sda2 sda3" подтверждают, что таблица прочитана. Файл testdisk.log и сделанная в начале копия sfdisk остаются в архиве: при любом странном поведении накопителя они позволяют восстановить ход мысли и сравнить разметку до и после. Восстановление таблицы это операция на метаданных, и при аккуратном подходе соседние тома даже не заметят, что рядом с ними что-то происходило.