Репликация не заменяет резервное копирование.
Распространенное заблуждение: «У нас есть реплика БД → бэкап не нужен»
Реальность: Бухгалтер удалил проводки → репликация применила удаление на реплике → данные потеряны везде. Резервное копирование защищает от того, от чего не защищает репликация.
Зачем нужно резервное копирование БД
Репликация не решает три критичные задачи.
Задача 1: Защита от логических ошибок
Сценарий: Администратор случайно удалил табличное пространство. Операция легитимна для СУБД. Репликация воспроизвела удаление на всех репликах. Результат без бэкапа: потеря данных без возможности восстановления.
Задача 2: Инициализация реплики
Создание реплики требует начальной копии данных. Источник: резервная копия или снимок мастера. Без резервной копии невозможно запустить новую реплику.
Задача 3: Клонирование базы
Тестовые и dev-среды требуют копии продакшн-данных. Процесс клонирования: Резервная копия продакшн-БД ↓ Восстановление в тестовую среду ↓ Изоляция от продакшна. Репликация не подходит — тестовая среда не должна быть синхронизирована с продакшном.
Главная ошибка резервного копирования БД
Типичный подход: «Делаем полную выгрузку раз в день — этого достаточно.» Проблема: выгрузка не подходит для высоконагруженных БД.
Почему выгрузка не работает
| Проблема | Последствие |
|---|---|
| Высокая нагрузка на СУБД | деградация производительности продакшн |
| Длительное время выгрузки | копия устаревает к моменту завершения |
| Невозможность согласованной выгрузки | данные на разных этапах транзакций |
| Необходимость хранения снимка | потребление ресурсов СУБД |
Для OLTP-БД с высокой нагрузкой выгрузка не применима. Правильный подход: физическое копирование файлов + журналы транзакций.
Два метода резервного копирования БД
Метод 1: Логическое копирование (выгрузка данных)
Данные читаются из БД и сохраняются в текстовом формате. Механизм логической выгрузки: Запрос к таблицам ↓ Чтение строк ↓ Преобразование в текст (SQL, CSV, XML) ↓ Сохранение в файл. Примеры утилит: PostgreSQL: pg_dump; MySQL: mysqldump; Oracle: expdp/impdp.
Метод 2: Физическое копирование (файлы БД)
Копируются файлы данных и журналы транзакций. Механизм физического копирования: Снимок файлов БД (согласованное состояние) ↓ Копирование файлов данных ↓ Копирование журналов транзакций ↓ Возможность восстановления на любую точку времени. Примеры утилит: PostgreSQL: pg_basebackup; Oracle: RMAN; MS SQL: нативное резервное копирование.
Сравнение методов
| Параметр | Логическое | Физическое |
|---|---|---|
| Скорость копирования | медленно | быстро |
| Нагрузка на СУБД | высокая | низкая |
| Размер копии | меньше (только данные) | больше (файлы + журналы) |
| Восстановление | медленное | быстрое |
| PITR (восстановление на момент) | нет | да |
| Переносимость между версиями | да | ограничена |
Для продакшн OLTP-БД — только физическое копирование.
Физическое резервное копирование
Основа надежного backup высоконагруженных БД.
Полное физическое копирование
Копируются все файлы БД и журналы на момент создания копии. Процесс полного бэкапа: Остановка записи в файлы (или согласованный снимок) ↓ Копирование файлов данных ↓ Копирование контрольных файлов ↓ Архивация журналов транзакций ↓ Возобновление записи. Полный бэкап — база для инкрементального копирования.
Инкрементальное копирование
Копируются только измененные блоки данных с момента последнего бэкапа. Схема инкрементального backup: Воскресенье: Full (все файлы); Понедельник: Incr1 (изменения с воскресенья); Вторник: Incr2 (изменения с понедельника); Среда: Incr3 (изменения со вторника). Восстановление: Full + Incr1 + Incr2 + Incr3. Преимущество: минимальное время создания копии, низкая нагрузка.
Журналы транзакций (Redo Logs, WAL)
Журналы фиксируют все изменения данных. Применение журналов: Восстановление на любую точку времени (PITR); Минимизация потери данных (RPO близок к 0); Накат изменений после восстановления файлов. Без архивации журналов восстановление возможно только на момент создания полного бэкапа.
Point-in-Time Recovery (PITR)
Восстановление БД на произвольный момент времени. Процесс PITR: Восстановление последнего полного бэкапа ↓ Применение инкрементальных копий ↓ Применение журналов транзакций до целевого момента ↓ БД в состоянии на выбранную дату/время. Пример: Ошибочное удаление данных в 14:30. Восстановление на 14:29 — данные вернутся. PITR критичен для минимизации потери данных.
Логическое резервное копирование
Применяется для специфичных задач, не для продакшн-бэкапов.
Когда логическое копирование оправдано:
- Клонирование отдельных таблиц — не нужна вся БД;
- Миграция между версиями СУБД — физические копии несовместимы;
- Выгрузка для аналитики — данные нужны в текстовом формате;
- Архивирование исторических данных — долгосрочное хранение.
Ограничения логической выгрузки: невозможность PITR; длительное время выгрузки и восстановления; высокая нагрузка на СУБД; проблемы согласованности при высокой нагрузке. Выгрузка — вспомогательный инструмент, не основной метод backup.
Выбор стратегии резервного копирования
Профиль БД определяет стратегию.
| Тип БД | Нагрузка | Метод | Периодичность |
|---|---|---|---|
| OLTP продакшн | высокая | физический + PITR | Full еженедельно, Incr ежедневно |
| OLAP/DWH | средняя | физический | Full еженедельно |
| Dev/Test | низкая | логический | по требованию |
| Архив | нет | логический | разовая выгрузка |
Критичные OLTP-БД требуют физического копирования с архивацией журналов.
Родные утилиты СУБД
Лучший выбор — штатные средства резервного копирования СУБД.
| СУБД | Утилита физического backup | Особенности |
|---|---|---|
| PostgreSQL | pg_basebackup, pg_probackup | WAL архивация, PITR |
| Oracle | RMAN | инкрементальное копирование, блочное восстановление |
| MS SQL Server | нативное резервное копирование | Full, Differential, Log backup |
| MySQL | MySQL Enterprise Backup | горячее копирование InnoDB |
Родные утилиты оптимизированы под конкретную СУБД и дают максимальную производительность.
Системы резервного копирования (агенты)
Специализированные системы управляют расписанием и хранением. Роль систем резервного копирования: Централизованное управление расписанием; Управление ротацией копий; Интеграция с системами хранения; Мониторинг и оповещения. Важно: системы backup используют родные утилиты СУБД для создания согласованных копий. Агенты не заменяют штатные средства СУБД — они интегрируются с ними.
Проверка восстановления БД
Главная ошибка: не проверять восстановление. Статистика: 30% резервных копий БД невозможно восстановить из-за ошибок конфигурации. Сценарий без проверки: Настроили backup ↓ Копии создаются годами ↓ Авария БД ↓ Попытка восстановления ↓ Копии повреждены / неполные журналы / несовместимая версия ↓ Потеря данных. Правильный подход: ежемесячная проверка восстановления в тестовой среде.
Резервное копирование БД и репликация решают разные задачи. Ключевые принципы: репликация не защищает от логических ошибок; физическое копирование для продакшн OLTP-БД; логическое — для клонирования и миграций; PITR критичен для минимизации потери данных; родные утилиты СУБД — оптимальный выбор. Обязательные элементы стратегии: полный бэкап + инкрементальный; архивация журналов транзакций; регулярная проверка восстановления. Правильно: физический backup + PITR для продакшн, логический для клонирования.
Частые вопросы
Почему репликация не заменяет резервное копирование?
Репликация воспроизводит все операции, включая ошибочные. Если администратор удалил таблицу, репликация применит удаление на всех репликах. Резервная копия позволяет откатиться до момента до ошибки. Также репликация не решает задачу клонирования БД для тестовых сред.
Физическое или логическое копирование для продакшн-БД?
Для OLTP продакшн — только физическое. Логическое создаёт высокую нагрузку, занимает много времени, не поддерживает PITR. Физическое копирование быстрее, не нагружает СУБД, поддерживает восстановление на любую точку времени через журналы транзакций.
Как часто проверять восстановление БД?
Минимум раз в месяц в изолированной тестовой среде. Проверка должна включать полное восстановление БД и проверку целостности данных. 30% копий оказываются неработоспособными при первой попытке восстановления — без регулярных проверок это выяснится только при реальной аварии.