Нет лучшего средства восстановления потерянных данных, чем бэкап. Касается это и данных, удалённых случайно, просто не всегда этот источник актуален: файл мог быть слишком молод для резервной копии. Если в бэкап он не попал, а дело происходит в Linux, остаётся поторопиться: чем скорее начнём, тем выше вероятность успеха. Как раз про профилактику у нас есть отдельный разбор - приложения для резервного копирования в Linux.
Дальше по шагам: что сделать в первую минуту, как понять, какой из двух подходов вам подойдёт, и какими утилитами это делается.
Удаление файла в Linux почти никогда не стирает сами данные. Файловая система убирает запись из каталога и помечает блоки свободными, а содержимое остаётся на месте до тех пор, пока поверх него что-нибудь не запишут. Отсюда единственное правило, которое действительно определяет исход: чем меньше на раздел пишут после удаления, тем больше шансов.
Отмонтируйте раздел, если это возможно. Если отмонтировать нельзя - перемонтируйте его в режим только для чтения, здесь указывается точка монтирования, а не устройство:
sudo umount /dev/sda1
sudo mount -o remount,ro /mnt/data
Если удалённое лежало на корневом разделе, ни то ни другое не пройдёт: система пишет логи, обновляет журналы, крутит своп. Здесь правильный путь один - выключить машину и загрузиться с live-образа. Заодно решится вопрос с утилитами: на live-сборках вроде SystemRescue нужный набор уже собран, и не придётся выяснять, есть ли пакет в репозитории вашего дистрибутива.
Восстановленные файлы всегда пишем на другой носитель. Не на тот раздел, с которого их вытаскиваем. Иначе вы затираете ровно те блоки, которые пытаетесь прочитать, и с каждым спасённым файлом теряете несколько других. Это самая частая и самая дорогая ошибка в восстановлении данных.
Правильная последовательность - не ковырять диск напрямую, а один раз прочитать его в файл-образ и дальше работать с образом. Диск после этого не трогается вообще, а неудачную попытку можно повторить сколько угодно раз.
Для здорового носителя достаточно dd. Если диск сыплется и читается с ошибками, берите ddrescue: он пропускает битые участки, ведёт карту прочитанного и умеет дочитывать пропущенное за несколько проходов.
sudo dd if=/dev/sda1 of=/mnt/backup/sda1.img bs=4M status=progress
sudo ddrescue -d -r3 /dev/sda1 /mnt/backup/sda1.img /mnt/backup/sda1.map
И здесь ловушка с именем пакета, на которой спотыкаются регулярно. В Debian и Ubuntu GNU ddrescue ставится пакетом gddrescue, а команда потом называется ddrescue:
sudo apt install gddrescue
Пакет с очевидным именем ddrescue в этих дистрибутивах - совсем другая программа, dd_rescue Курта Гарлоффа. Она делает похожую работу, но не ведёт карту и не умеет дочитывать за несколько проходов. Команда установится, что-то запустится, а обещанного поведения не будет. В RHEL-семействе такой путаницы нет: там пакет называется ddrescue и содержит именно GNU-версию.
Дальше все утилиты можно натравливать на файл образа ровно так же, как на устройство - вместо /dev/sda1 подставляете /mnt/backup/sda1.img.
Инструменты восстановления делятся на два семейства, и путать их - значит получить не тот результат.
| Признак | По метаданным | Сигнатурный карвинг |
|---|---|---|
| Что читает | Журнал и служебные структуры файловой системы | Сырые байты раздела |
| Имена файлов | Сохраняются | Теряются, на выходе f0012345.jpg |
| Структура каталогов | Сохраняется | Теряется, всё в общей куче |
| Когда работает | Сразу после удаления, пока журнал не перезаписан | Даже после форматирования |
| Файловые системы | ext3/ext4 и другие, для каждой свой инструмент | Любые, файловая система игнорируется |
| Инструменты | extundelete, debugfs | PhotoRec, scalpel, foremost |
Логика простая. Сначала пробуем по метаданным - если получится, вы получите файлы с их настоящими именами и в своих папках. Не вышло - переходим к карвингу, который вытащит содержимое, но опознавать его придётся руками.
Про устройство самих файловых систем, если хочется понимать, что именно тут происходит, - в отдельном материале про файловые системы.
Для ext3 и ext4 первое, что стоит попробовать, - extundelete. Он читает журнал файловой системы и восстанавливает файлы вместе с именами. Раздел при этом должен быть отмонтирован: на смонтированной файловой системе утилита работать откажется.
sudo apt install extundelete
sudo extundelete /dev/sda1 --restore-all
sudo extundelete /dev/sda1 --restore-file home/user/documents/otchet.odt
sudo extundelete /dev/sda1 --restore-directory home/user/documents
Путь указывается относительно корня раздела, без ведущего слэша, - это первое, обо что спотыкаются.
Результат утилита складывает в каталог RECOVERED_FILES внутри текущего рабочего каталога. Поэтому перед запуском перейдите в папку на другом носителе:
cd /mnt/backup
Проект старый и новых релизов давно не выпускал, но для ext4 по журналу он до сих пор остаётся первым разумным вариантом. А вот ext4magic использовать не стоит: проект заброшен в январе 2025 года, ext4 нынешних версий он разбирает неверно, и сам сопровождающий советует его не применять.
Если журнал уже затёрт и extundelete ничего не нашёл - это не приговор, просто переходим к сигнатурам.
PhotoRec игнорирует файловую систему целиком и ищет по разделу сигнатуры известных форматов - начало и конец файла. Ему всё равно, ext4 у вас, XFS или отформатированная флешка. Ставится он вместе с TestDisk, одним пакетом. Запуск интерактивный: утилита сама проведёт по шагам - выбрать носитель, тип таблицы разделов, раздел, форматы файлов и каталог для результата.
sudo apt install testdisk
sudo photorec /dev/sda1
sudo photorec /mnt/backup/sda1.img
Каталог для результата PhotoRec спрашивает отдельным шагом - укажите путь на другом носителе. Имена файлов не восстанавливаются: на выходе вы получите recup_dir.1/f0012345.jpg и дальше разбираете глазами.
Важная оговорка про TestDisk. Его часто советуют как средство «отменить удаление», и для ext4 это неверно: по документации самого проекта при удалении в ext3/ext4 не сохраняются сведения о размещении данных, которые нужны обычному undelete. TestDisk силён в другом - восстановить потерянную таблицу разделов, вернуть к жизни раздел, который перестал определяться, аккуратно скопировать файлы с повреждённой файловой системы. Для отдельных удалённых файлов в ext4 используйте PhotoRec, а не TestDisk.
Scalpel работает по той же сигнатурной логике, что и PhotoRec, но список форматов задаётся вручную в конфигурационном файле - /etc/scalpel/scalpel.conf (в старых сборках /etc/scalpel.conf). Заголовки распространённых типов там уже прописаны, но все строки закомментированы: нужные надо раскомментировать, иначе утилита запустится и честно ничего не найдёт.
sudo apt install scalpel
Формат строки конфига такой: расширение, чувствительность к регистру, максимальный размер файла, заголовок, футер. Колонка с регистром обязательна, без неё строка разбирается неправильно. Для картинок GIF и JPEG рабочие строки выглядят так:
gif y 5000000 \x47\x49\x46\x38\x37\x61 \x00\x3b
gif y 5000000 \x47\x49\x46\x38\x39\x61 \x00\x3b
jpg y 200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9
Две строки для GIF - не опечатка: это два разных заголовка, GIF87a и GIF89a, и нужны обе.
sudo scalpel /dev/sda1 -c /etc/scalpel/scalpel.conf -o /mnt/backup/scalpel-out
Каталог, указанный в -o, не должен существовать - scalpel откажется стартовать, если он уже создан. При повторном запуске либо удаляйте прежний, либо задавайте новое имя. И, как договорились выше, каталог этот живёт на другом носителе.
Scalpel - это форк foremost, и главное отличие у него в скорости. Если нужна не скорость, а качество разбора, особенно по изображениям, - берите foremost.
sudo apt install foremost
sudo foremost -t jpg,gif,png,bmp -i /dev/sda1 -o /mnt/backup/foremost-out
Ключ -t принимает список типов через запятую, all берёт все известные утилите форматы, но и работать будет заметно дольше. Подробности по параметрам - в справке: man foremost.
Про установку в RHEL-семействе стоит сказать отдельно. Часть этих утилит приезжает из EPEL, часть в репозиториях отсутствует вовсе, и выяснять это в момент аварии - плохая идея. Проверяйте dnf search заранее, а для разовой операции всё же проще загрузиться с live-образа, где набор уже собран.
Каждая попытка восстановления - это чтение диска, а на сыплющемся носителе ещё и нагрузка, которая приближает окончательный отказ. Поэтому останавливаться тоже надо уметь.
Прекращайте самостоятельные попытки, если данные критичны для бизнеса, а первые два подхода результата не дали. Прекращайте немедленно, если диск щёлкает, не определяется или отваливается посреди чтения: здесь речь уже не о программном восстановлении, а о механике, и каждый новый запуск снижает шансы лаборатории. Если вы ещё не снимали образ, а диск ведёт себя странно - образ через ddrescue это ровно то, что стоит сделать до всех остальных решений.
Отдельно стоит понять, что вы вообще чините. Если файлы пропадают сами по себе, каталоги читаются через раз, а в логах сыплются ошибки ввода-вывода, то удаление тут ни при чём - разбираться надо с носителем. Про это у нас есть диагностика проблем с диском на работающем сервере и разбор показателей SMART.
И возвращаясь к тому, с чего начали: любой из описанных сценариев дороже и дольше, чем настроенное резервное копирование. Восстановление удавшимся не гарантировано никогда - бэкап гарантирован.
По теме: о безвозвратном удалении данных, права доступа к файлам в Linux.
Проще не терять, чем восстанавливать.
Инженеры ITTELO подберут сервер под резервное копирование - с нужным объёмом дисков, контроллером и запасом на рост, соберут и протестируют его перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
Серверы резервного копирования · +7 (800) 551-80-12 · info@ittelo.ru