Восстановление повреждённой базы данных SQL Server
О чём эта статья
Эта инструкция объясняет, почему базы данных на SQL Server и MySQL могут повреждаться и даёт практический план действий по восстановлению. Статья покрывает как системные приёмы для MySQL (service, mysqlcheck, ALTER TABLE), так и варианты для Microsoft SQL Server (.mdf/.ldf) — включая использование Recovery Toolbox for SQL Server для извлечения данных из повреждённых MDF-файлов. В конце — чек-листы для ролей, методология восстановления, схема принятия решения и советы по безопасности и соответствию требованиям конфиденциальности.
Кому это полезно
Системным администраторам и DBA
Разработчикам, поддерживающим БД
Службам техподдержки и инженерам по восстановлению данных
Ключевые варианты запроса (SEO-интенции)
Восстановление повреждённой базы данных SQL Server
Как починить MDF файл
Восстановление MySQL таблицы
Инструменты для восстановления SQL Server
Понимание: Microsoft SQL Server и MySQL — в чём разница
Microsoft SQL Server — коммерческая СУБД от Microsoft, использует файлы данных .mdf/.ndf и журналы .ldf. Для проверки целостности используются DBCC-команды.
MySQL — популярная открытая СУБД. Внутренние механизмы хранения (MyISAM, InnoDB) определяют методы восстановления: CHECK TABLE/REPAIR TABLE для MyISAM, утилиты и InnoDB recovery-параметры для InnoDB.
Краткое определение терминов
MDF — основной файл данных Microsoft SQL Server.
LDF — файл журнала транзакций Microsoft SQL Server.
MyISAM / InnoDB — движки хранения MySQL.
Почему база данных может быть повреждена
Наиболее частые причины повреждений:
Ошибочное перезапись или удаление файлов данных.
Сбой оборудования (повреждение дисков, контроллеров, RAID-массивов).
Неправильные настройки или некорректное завершение работы СУБД.
Инфекции вредоносным ПО или последствия неудачной антивирусной чистки.
Внутренние ошибки СУБД или баги при обновлении/миграции.
Коррупция из-за сетевых сбоев при удалённом хранении файлов.
Important: перед любыми изменениями сделайте побочную копию (битовую копию) проблемных файлов и снимок системы.
Общественные принципы восстановления
Приостановите операции записи на сервер (если возможно).
Сделайте физические копии файлов данных и журналов (.mdf/.ldf или каталога MySQL).
Проводите операции только на копиях — не работайте с оригиналом.
Документируйте каждый шаг и сохраняйте логи.
Если данные персональные, учитывайте требования конфиденциальности и GDPR.
Последовательность действий: быстрый план (5 шагов)
Снимите резервную копию файлов или снимок тома.
Попробуйте мягкий перезапуск сервиса СУБД.
Запустите встроенные средства проверки целостности.
Попробуйте восстановление таблиц/файлов (CHECK/REPAIR, DBCC, экспорт через инструмент).
Если встроенные средства не помогают — используйте сторонний инструмент или восстановление из резервной копии.
Вариант A: Шаги для MySQL (практическая инструкция)
Примечание: команды предполагают работу под системой Linux и корректное имя сервиса. Перед выполнением замените и
на реальные имена.
1. Сохранение копии и перезапуск сервиса
Сделайте копию каталога данных, обычно /var/lib/mysql, на отдельный диск.
Остановите службу, проверьте статус и перезапустите:
sudo systemctl stop mysql
sudo systemctl status mysql.service
sudo systemctl restart mysql.service
Иногда простой перезапуск решает проблему (закрывает зависшие процессы, снимает блокировки). Если это не помогает — переходите к проверке таблиц.
2. Проверка и восстановление таблицы MyISAM
Войдите в MySQL или используйте утилиту mysql/mysqlcheck.
Проверка таблицы через SQL:
CHECK TABLE `name_of_the_table`;
Если обнаружены ошибки, выполните:
REPAIR TABLE `name_of_the_table`;
REPAIR TABLE эффективен для таблиц MyISAM, но может привести к потере строк в процессе восстановления. Поэтому используйте копию данных.
3. Утилита mysqlcheck
Перейдите в каталог данных при необходимости:
cd /var/lib/mysql
Тест таблицы:
mysqlcheck
Для попытки ремонта:
mysqlcheck -r
4. Изменение движка таблицы для пересборки
Иногда пересборка таблицы через ALTER приводит к восстановлению структуры:
SHOW CREATE TABLE ;
ALTER TABLE ENGINE = MyISAM;
-- или для InnoDB:
ALTER TABLE ENGINE = InnoDB;
Замените движок с осторожностью: если таблица InnoDB, смена на MyISAM потеряет транзакционность и ограничения.
Notes: Для InnoDB используйте параметры innodb_force_recovery в my.cnf только в крайнем случае и последовательно увеличивайте значение (1..6) с перезапуском сервиса. Это режим для извлечения данных, а не для нормальной работы.
Вариант B: Шаги для Microsoft SQL Server (.mdf/.ldf)
1. Проверка целостности DBCC CHECKDB
Запустите DBCC CHECKDB, чтобы получить рекомендации по восстановлению:
USE master;
ALTER DATABASE YourDatabase SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('YourDatabase') WITH NO_INFOMSGS, ALL_ERRORMSGS;
ALTER DATABASE YourDatabase SET MULTI_USER;
DBCC CHECKDB вернёт возможные сценарии (REPAIR_ALLOW_DATA_LOSS, REPAIR_REBUILD). Решение о применении REPAIR_ALLOW_DATA_LOSS — крайнее и может привести к потерям данных.
2. Восстановление из резервной копии
Всегда предпочтительнее восстановить базу из исправной резервной копии (полная/дифференциальная/журнал транзакций). Последовательность восстановления зависит от имеющихся бэкапов.
3. Детач/аттач и восстановление файлов
Если физические файлы .mdf доступны, можно попытаться:
Отключить базу (detach), переместить/копировать файлы и подключить (attach).
Использовать CREATE DATABASE … FOR ATTACH / FOR ATTACH_REBUILD_LOG.
4. Использование стороннего инструмента
Если встроенные средства не возвращают работоспособную базу, используйте надёжный инструмент для извлечения данных из .mdf (например, Recovery Toolbox for SQL Server). Процесс обычно включает выбор .mdf, анализ и экспорт как SQL-скрипт или прямой экспорт в сервер.
Recovery Toolbox for SQL Server и аналогичные решения позволяют извлечь таблицы, представления, хранимые процедуры и т.д. в виде SQL-скриптов или импортировать их напрямую на целевой сервер.
Когда встроенные инструменты не помогут (примеры ситуаций)
Файлы сильно повреждены физически (битые сектора) — может потребоваться восстановление на уровне диска.
Журнал транзакций отсутствует или повреждён так, что невозможна корректная перекомпозиция транзакций.
Перезапись файла (overwrite) уничтожила прежние данные — восстановление затруднено без внешней копии.
Контрпример: REPAIR_ALLOW_DATA_LOSS в DBCC допускает восстановление структуры, но может удалить строки; это оправдано лишь когда других резервных копий нет.
Методология: как выбирать стратегию восстановления (шаг за шагом)
Оцените, какие файлы повреждены (.mdf/.ldf или каталоги MySQL).
Если мягкие методы не помогают — попытайтесь восстановить из резервной копии.
Если резервных копий нет — используйте инструменты для извлечения данных.
После извлечения — прогоните тесты целостности и восстановите повседневную работу.
Mermaid схема выбора стратегии
flowchart TD
A[Обнаружена ошибка] --> B{Имеется свежая резервная копия?}
B -- Да --> C[Восстановить из бэкапа]
B -- Нет --> D[Сделать физическую копию файлов]
D --> E[Перезапустить сервис]
E --> F{Нормализовалось?}
F -- Да --> G[Мониторинг и аудит]
F -- Нет --> H[Запустить CHECK/DBCC]
H --> I{Ошибки исправимы?}
I -- Да --> J[Применить ремонт]
I -- Нет --> K[Использовать сторонний инструмент]
K --> L[Экспорт в новую БД]
L --> G
Чек-листы по ролям
DBA
Сделать физическую копию файлов.
Запустить DBCC CHECKDB / CHECK TABLE.
Пробный рестарт сервиса и просмотр логов.
Восстановление из бэкапа при наличии.
Если нет бэкапа — выбрать сторонний инструмент и план миграции.
Разработчик
Оценить, какие приложения зависят от таблицы.
Подготовить тестовую среду для валидации экспортированных данных.
Помочь с выполнением SQL-скриптов восстановления и тестов целостности.
Служба поддержки
Уведомить заинтересованные стороны и зафиксировать инцидент.
Подготовить журнал событий и скриншоты ошибок.
Помочь собрать логи и передать их DBA.
Критерии приёмки
База подключается и проходит минимальные запросы целостности.
Выполнено сравнение количества строк в основных таблицах с известными контрольными суммами (если имеются).
Безопасность и соответствие требованиям конфиденциальности
Если в базе находятся персональные данные, фиксируйте доступ и операции восстановления.
Минимизируйте количество копий данных и храните их в зашифрованном виде.
Убедитесь, что экспортируемые данные не попадают в общедоступные логи.
Часто встречающиеся ошибки и их интерпретация
“The FILE SIZE property is incorrect” — проблемы с размером файла в заголовке .mdf; часто исправляется через восстановление/инструмент.
“Logical consistency-based I/O error” (ошибка контрольной суммы) — указывает на повреждение данных на уровне страниц.
“File appears to have been truncated by the Operating System” — вероятно, нехватка места или некорректная настройка хранения.
1‑строчный глоссарий
DBCC CHECKDB — встроенная проверка целостности Microsoft SQL Server.
REPAIR TABLE — операция MySQL для восстановления MyISAM-таблиц.
mysqlcheck — консольная утилита для проверки и ремонта MySQL таблиц.
Тесты и критерии приёмки восстановления
Выполнить SELECT COUNT(*) для ключевых таблиц и сверить с ожидаемыми значениями.
Прогнать набор интеграционных тестов, зависящих от данных.
Проверить, что индексы не содержат ошибок и время выполнения основных запросов в пределах SLA.
Риски и смягчение
Риск потери данных при применении агрессивных команд восстановления — смягчение: работать на копиях и иметь стратегию экспорта.
Риск утечки данных при использовании сторонних инструментов — смягчение: использовать проверенные решения и зашифрованные каналы передачи.
Итоги
Всегда начинайте с резервной копии и работы с копиями файлов.
Для MySQL: сначала перезапустите сервис, затем CHECK/REPAIR или mysqlcheck; используйте ALTER TABLE для пересборки таблиц.
Для Microsoft SQL Server: используйте DBCC CHECKDB и восстановление из бэкапа; если встроенные методы не помогают — рассмотрите специализированный инструмент для .mdf-файлов.
Документируйте все шаги и проверяйте соответствие требованиям безопасности.
Если у вас есть конкретная ошибка или лог — прикрепите его в комментарии, и я помогу интерпретировать и предложу последовательность действий.
