Восстановление после сбоя диска

MAATRIX

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

Первое правило: остановить запись

Пока вы не понимаете, что случилось, любая запись на подозрительный диск опасна. Если файловая система уже перешла в режим только для чтения — не спешите её «размонтировать и починить». Сначала оцените, идёт ли речь о логической ошибке файловой системы или о физической деградации носителя. Это разные ситуации с разным планом действий.

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

# смотрим список дисков и разделов
lsblk -f
# монтируем только для чтения
mount -o ro /dev/vda1 /mnt/rescue
ls /mnt/rescue

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

Диагностика: файловая система или железо

Определить природу сбоя помогает несколько инструментов. Для физического состояния диска — SMART-атрибуты. На VPS доступ к SMART бывает ограничен, но на выделенном сервере он показывает переназначенные секторы, ошибки чтения и общий вердикт:

smartctl -a /dev/sda | grep -Ei 'reallocated|pending|health'
# ошибки ядра ввода-вывода
dmesg | grep -Ei 'i/o error|ata|nvme|read error'

Строки про reallocated sector с растущим числом или pending sectors говорят о деградации носителя — диск физически умирает, и его данные надо спасать немедленно. Если же SMART чист, а проблема в структуре файловой системы (неожиданная перезагрузка, сбой питания), то это логическое повреждение, которое чинится проверкой ФС. По записям dmesg видно, идут ли ошибки на уровне устройства или выше.

Спасаем данные до ремонта

Если диск физически деградирует, обычное копирование может застопориться на первом же сбойном секторе. Здесь выручает ddrescue — он копирует образ, пропуская нечитаемые участки и возвращаясь к ним позже, вытягивая максимум доступного:

# копируем образ проблемного диска на здоровый носитель
ddrescue -f -n /dev/sda /mnt/backup/rescue.img /mnt/backup/rescue.log
# повторный проход по пропущенным секторам
ddrescue -d -r3 /dev/sda /mnt/backup/rescue.img /mnt/backup/rescue.log

Работать дальше нужно уже с этим образом, а не с умирающим диском — так вы не добьёте оригинал и получите несколько попыток восстановления. Если же данные читаются нормально и речь о логической ошибке, достаточно скопировать нужные каталоги на другой сервер обычным rsync. Главное — вынести ценное в безопасность прежде, чем запускать любые инструменты починки.

Чиним файловую систему

Когда данные в безопасности, можно чинить файловую систему. Для семейства ext (ext4) это fsck, для XFS — xfs_repair. Запускать только на размонтированном разделе, иначе можно усугубить повреждение:

# раздел должен быть размонтирован
umount /dev/vda1
# проверка и починка ext4
fsck -y /dev/vda1
# для XFS
xfs_repair /dev/vda1

Флаг -y отвечает «да» на все вопросы восстановления — удобно, но именно поэтому важно, чтобы копия данных уже была снята. fsck может перемещать повреждённые фрагменты в lost+found, и что-то восстановится в виде безымянных файлов. После успешной проверки смонтируйте раздел в обычном режиме и убедитесь, что система загружается. Если файловая система повреждена слишком сильно и fsck не справляется, ставка делается на бэкап.

Восстановление из бэкапа

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

# восстановление файлов из бэкапа
rsync -avz backup-server:/backups/example.com/ /var/www/example.com/
# восстановление базы из дампа
mysql -u root -p mydb < /backups/mydb-latest.sql

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

Почему диски выходят из строя

Причины делятся на физические и логические. Физически диски изнашиваются: у SSD ограничен ресурс перезаписи, у HDD со временем растёт число сбойных секторов, случаются отказы контроллера. На виртуальных серверах вы не видите само железо, но storage под вами тоже может деградировать — поэтому бэкапы обязательны и там. Логические сбои возникают от внезапного отключения питания посреди записи, переполнения диска под завязку, ошибок при изменении разметки.

Отдельная частая причина порчи данных — работа с диском, заполненным на 100%. Когда места не остаётся, приложения падают на середине записи, а журнал файловой системы не может корректно завершиться. Поэтому следить за свободным местом — это в том числе профилактика повреждений, а не только удобство.

Профилактика: чтобы сбой не стал катастрофой

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

Хорошая инфраструктура снижает саму вероятность катастрофы. У MAATRIX доступны VPS и выделенные серверы с быстрыми NVMe-накопителями и опцией резервного копирования в RU, US и UK, с оплатой из России картой или криптой. Когда бэкапы делаются автоматически и лежат отдельно от боевого диска, любой сбой превращается из катастрофы в получасовое восстановление на свежей машине.

Частые вопросы