Спасательная операция: Полное руководство по восстановлению базы данных из дампа

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

Что такое дамп и зачем он нужен?

Дамп базы данных (backup dump) — это файл, содержащий полную структуру (таблицы, индексы, процедуры) и все данные в виде набора SQL-команд или специального бинарного формата. Это не просто копия файлов базы, а её логическое представление, которое можно восстановить на другой системе, даже с другой версией СУБД (в разумных пределах). Основные причины для восстановления: аварийное восстановление после сбоя, миграция на новый сервер, клонирование среды для тестирования или развёртывание проекта с нуля.

Важно: Регулярное создание и тестирование восстановления из дампов — это не опция, а обязательная практика. Дамп, из которого ни разу не пробовали восстановить данные, нельзя считать надёжной резервной копией.

Подготовка к восстановлению: что нужно сделать до запуска команды

Без подготовки восстановление может превратиться в хаос. Следуйте этому чек-листу:

Проверьте целостность дампа. Убедитесь, что файл не повреждён и был скачан/передан полностью. Можно проверить контрольную сумму (checksum), если она предоставлена.
Оцените размер и требования. Большой дамп может потребовать значительного свободного места на диске (иногда в 2-3 раза больше итогового размера БД) и времени на обработку.
Создайте чистую базу данных. На целевом сервере создайте пустую базу с нужной кодировкой (например, UTF8). Убедитесь, что у пользователя, от имени которого будет идти восстановление, есть все необходимые права (обычно SUPERUSER или полные права на эту БД).
Остановите связанные службы. По возможности остановите приложения, которые активно работают с восстанавливаемой базой, чтобы избежать конфликтов блокировок.
Сделайте резервную копию существующих данных, если они есть. Если вы восстанавливаете поверх существующей базы, сначала сделайте её полный дамп. «Семь раз отмерь» — золотое правило.

Практикум: команды восстановления для популярных СУБД

Процесс отличается в зависимости от системы управления базами данных.

MySQL / MariaDB

Самый частый случай. Для дампа, созданного утилитой mysqldump (текстовый SQL-файл):

Через командную строку: mysql -u username -p database_name < dump_file.sql
С явным указанием хоста и порта: mysql -h hostname -P port -u username -p database_name < dump_file.sql

Для ускорения процесса можно отключить проверку внешних ключей и индексов на время импорта:

mysql -u username -p --init-command="SET SESSION FOREIGN_KEY_CHECKS=0;" database_name < dump.sql

PostgreSQL

Здесь основная утилита — pg_restore для кастомного формата или psql для plain SQL.

Восстановление в новую базу с помощью psql: psql -U username -d new_database -f dump_file.sql
Использование pg_restore для более гибкого контроля (формат -Fc): pg_restore -U username -d new_database -v dump_file.dump

MongoDB

Для NoSQL-баз используется утилита mongorestore для бинарного дампа, созданного mongodump.

Базовое восстановление: mongorestore --uri="mongodb://username:password@localhost:27017" --db database_name /path/to/dump/
С опцией drop (удалить существующую коллекцию перед восстановлением): mongorestore --drop ...

Производительность: Для восстановления огромных дампов в MySQL/PostgreSQL используйте ключи для отключения авто-коммита, индексов и внешних ключей на время импорта, создавая их в конце. Это может ускорить процесс в разы.

Типичные ошибки и их решение

"Access denied" / "Permission denied": Проблема с правами пользователя. Проверьте привилегии и пароль. Для PostgreSQL убедитесь, что в файле pg_hba.conf разрешён доступ с нужного хоста.
"Unknown database": Целевая база данных не создана. Создайте её командой CREATE DATABASE dbname;.
Ошибки кодировки (кракозябры): Дамп создан в одной кодировке (например, WIN1251), а база восстановлена в другой (UTF8). Указывайте кодировку явно при создании БД и восстановлении (например, mysql --default-character-set=utf8mb4 ...).
Нехватка места на диске: Самая коварная ошибка. Следите за свободным местом в процессе, особенно на разделе с временными файлами.
Ошибка версии СУБД: Дамп от новой версии может не восстановиться на старой. Старайтесь использовать одинаковые или совместимые версии.

Автоматизация и лучшие практики

Ручное восстановление — это для экстренных случаев. В идеальном мире процесс должен быть автоматизирован:

Используйте планировщик задач (cron, systemd timers) для регулярного создания дампов.
Храните дампы не только на том же сервере, но и на внешнем хранилище или в облаке (S3, FTP).
Ведите журнал (лог) операций резервного копирования и восстановления.
Периодически (раз в квартал) проводите учебные тревоги — восстанавливайте базу на тестовый стенд и проверяйте целостность данных.
Для критичных баз рассмотрите репликацию в реальном времени как дополнение к дампам, но не как их замену.

FAQ: Часто задаваемые вопросы

Чем восстановление из дампа отличается от копирования файлов БД?

Копирование файлов данных (например, .ibd файлы для MySQL) часто невозможно при смене версии или архитектуры сервера, требует полной остановки СУБД и переноса огромных объёмов. Дамп — логический, более переносимый и обычно позволяет восстанавливать данные выборочно.

Можно ли восстановить только одну таблицу из полного дампа?

Да, это возможно. В MySQL можно вручную найти в SQL-дампе участки с CREATE TABLE и INSERT для нужной таблицы и выполнить их. Или использовать утилиту sed или специализированные скрипты для извлечения. В PostgreSQL с pg_restore есть ключ -t tablename.

Что делать, если процесс восстановления завис на несколько часов?

Сначала проверьте нагрузку на диск и CPU. Если они близки к 100% — процесс, скорее всего, идёт. Можно осторожно проверить размер восстанавливаемой базы или заглянуть в лог ошибок СУБД. Прерывать процесс на середине не рекомендуется — это приведёт к неконсистентному состоянию базы. Лучше дождаться или, в крайнем случае, убить процесс и начать заново с оптимизированными параметрами.

Как проверить, что восстановление прошло успешно?

После завершения: 1) Проверьте отсутствие ошибок в выводе утилиты восстановления. 2) Подключитесь к базе и выполните несколько тестовых SELECT-запросов к ключевым таблицам. 3) Проверьте количество записей в основных таблицах (например, SELECT COUNT(*) FROM important_table;). 4) Запустите основные функции вашего приложения в тестовом режиме.