Настройка резервного копирования БД: PostgreSQL, MySQL, MongoDB

Почему резервное копирование PostgreSQL ломается в проде

Копии создаются каждую ночь, задание отчитывается об успехе — а в момент аварии восстановление базы после сбоя упирается в ошибку на середине. Типовой сценарий: резервное копирование PostgreSQL настроено формально, проверено на пустой базе, и до первого реального отказа в архив никто не заглядывал.

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

Второй — съём копии поверх открытой транзакции. Когда снимок берётся без согласованной точки, в архив попадает состояние, которого база никогда не имела: часть изменений записана, часть нет. Такие битые резервные копии распаковываются без единой ошибки и расходятся с источником уже на проверке целостности.

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

Что меняется после внедрения: сроки восстановления и простои

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

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

Отдельная метрика — доля сбоев, которые переходят в аварию, а не в штатный откат. Проверка целостности после каждой копии, сверка контрольных сумм и алерт на незавершённое задание превращают тихие отказы в обычные задачи. В аварию уходит меньшая часть инцидентов с данными.

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

Сравнение подходов к резервному копированию: что выбрать

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

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

Этапы внедрения: от схемы данных до передачи регламентов

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

1. Аудит баз данных. Инвентаризация всех экземпляров PostgreSQL, MySQL и MongoDB: объёмы, скорость роста, профиль нагрузки, критичность контура. Здесь же выясняется, что резервируется по инерции, а что не резервируется вовсе.
2. Целевые показатели. По каждому контуру фиксируем допустимую потерю данных и целевое время восстановления — от них зависит частота полных и инкрементальных копий и глубина архивации журналов.
3. Схема хранения копий. Где лежат копии, срок хранения, правила ротации, шифрование и разделение доступов: учётная запись резервного копирования не должна иметь прав удалять продакшен.
4. Настройка и автоматизация. Расписания, полные и инкрементальные копии, непрерывная архивация журналов, мониторинг заданий с алертами на ошибку или пропуск запуска.
5. Тестовое восстановление. Разворачиваем копии на отдельном стенде, замеряем фактическое время восстановления и проверяем целостность данных на выбранный момент, а не наличие файла в хранилище.
6. Регламент восстановления. Пошаговый порядок действий, ответственные, точки принятия решений; учения по нему, чтобы документ проверялся практикой, а не лежал в документации.
7. Пересмотр схемы. При росте объёмов или изменении архитектуры расписания и глубина хранения пересматриваются, иначе требования по потере данных тихо перестают выполняться.

Конфигурации, схемы хранения и регламенты восстановления

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

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

Пример из практики: восстановление за минуты вместо часов

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

Перевели базы на непрерывное архивирование журналов предзаписи PostgreSQL плюс базовую копию раз в сутки и инкрементальные каждые 15 минут. Ретенция выстроена по уровням: минутные срезы держим сутки, суточные — месяц, месячные — год, и всё в объектном хранилище в другом дата-центре, а не рядом с данными. Отдельно описали, что делать, если архивный том недоступен: восстановление идёт из последней базовой копии и наката журналов.

Каждую копию автоматика разворачивает на отдельном стенде: сверяются контрольные суммы, счётчики строк по ключевым таблицам и время последней транзакции. Если копия не поднимается или расходится по данным — приходит оповещение, а архив уходит в карантин до разбора. Так битый бэкап перестаёт быть сюрпризом в момент аварии.

Метрики после: точка восстановления — 5 минут вместо суток, подъём — 12-18 минут против 4-6 часов, доля проверенных копий — 100%. Откат возможен на любой момент в пределах месяца, а не только на последнюю ночь. В регламент добавили ежемесячную учебную тревогу: восстановление на стенд без предупреждения команды.

Что делать, если база уже работает в кластере с репликацией?

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

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

Репликация и резервное копирование встраиваются в работающий кластер без его перестройки. Копии снимаются с выделенной реплики, выведенной из переключения: основной узел не получает лишнюю нагрузку, а расписание не пересекается с окнами обслуживания. Такой контур добавляется одним узлом и набором правил.

Проверяем не наличие копий, а восстановление: разворачиваем снимок на отдельном стенде, сверяем целостность и замеряем время до рабочего состояния. Хранилище копий держим в отдельном контуре с учётной записью только на запись, чтобы инцидент на площадке не унёс и резервы. Перестройка контура копирования при этом не трогает сам кластер и не требует остановки сервиса.

Технические сомнения: объёмы копий, шифрование и доступы

Объём копий растёт быстрее самих данных: полный слепок, инкременты и журнал предзаписи в сумме дают в 2–3 раза больше исходного размера базы. Ротация здесь важнее размера диска — последние N полных копий на суточном цикле, недельные и месячные срезы, сжатие. Без неё реестр копий растёт линейно и упирается в диск.

Нагрузку определяет источник копии, а не время запуска. Снятие со вторичной реплики или снимка файловой системы не отбирает ресурсы у основной базы: чтение идёт на отдельном узле. Шифрование включаем на стороне источника, ключи храним отдельно от копий — доступ к хранилищу тогда не даёт доступа к данным.

Доступы разграничиваем по ролям: один контур запускает задания и смотрит состояние, второй умеет только восстанавливать, третий видит лишь метаданные. Пригодность подтверждаем восстановлением на отдельном стенде — копия, которую ни разу не разворачивали, для нас не существует.

Копии займут весь диск?

Объём считаем от суточного прироста и глубины хранения, а не от размера базы. В PostgreSQL инкрементальная схема с ротацией обычно занимает меньше, чем десять полных суточных слепков.

Кто получит доступ к копиям?

Только роли, которым он нужен по задаче: восстановление, проверка, аудит. Ключи шифрования лежат в отдельном хранилище, поэтому выгрузка копии наружу не раскрывает данные.

Обсудим задачу: пришлите схему базы и текущий регламент

Чтобы оценка по резервному копированию опиралась на факты, а не на общие пожелания, достаточно нескольких вводных: схема размещения данных, действующий регламент и требования к восстановлению. По ним инженеры считают объём копий, длительность окна и число точек восстановления — и возвращаются с планом внедрения.

Что прислать для оценки:

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

На первой встрече разбираем аудит текущей схемы копий и точки отказа в ней, обсуждаем консультацию инженера по выбору режима копирования и хранение копий вне основной площадки. Дальше — план внедрения копирования с проверкой восстановления на тестовом контуре, а не только с фактом успешной выгрузки.

Опишите задачу — вернёмся с оценкой работ по резервному копированию и планом.