Barman PostgreSQL backup: почему восстановление срывается
Классическая картина: проверка конфигурации возвращает ok, копии идут по расписанию, отчёты зелёные — настройка barman считается законченной. Сбой или ночная попытка развернуть базу показывают другое: цепочка журналов прервана, и восстановление останавливается на последней полной копии — вместе с потерей часов или суток транзакций.
Первый источник отказов — архивация журналов. Команда передачи сегмента возвращает ошибку, а сервер продолжает писать: с точки зрения приложения всё работает. Barman исправно получает свежие копии, но между последней из них и аварийной точкой зияет разрыв — резервное копирование postgresql формально есть, а восстановление базы после сбоя упирается в ближайшую цельную точку.
Второй источник — политика хранения. Ретеншн по числу файлов или по возрасту, без привязки к цепочке журналов, сносит сегменты, нужные для точки восстановления, и оставляет полные копии, до которых уже не добраться. Отдельно всплывают доступы: после смены служебных ключей или закрытия сетевого обмена архивация останавливается молча, а отчёт показывает вчерашнюю удачную копию.
Третий источник — восстановление ни разу не прогоняли. Пока разворот не сделан на отдельном инстансе и время до рабочего состояния не измерено, никто не знает ни фактического окна потери данных, ни длительности простоя. Проверка, которая не запускалась, проверкой не считается.
Все три сбоя лежат в одной плоскости: настроена выгрузка копий, но не настроена гарантия восстановления. Разбираем, как это закрывается.
Измеримый эффект управляемого резервного копирования
Показатели после настройки управляемого резервного копирования меняются не сами по себе — их видно только потому, что мы фиксируем базовые значения до внедрения. Снимаем исходную картину: сколько сейчас занимает восстановление, когда последний раз копия реально разворачивалась, сколько места занимает архив и кто отвечает за его очистку. Те же числа переснимаем после настройки Barman и повторяем на каждой плановой проверке.
| Показатель | До настройки | После настройки |
|---|---|---|
| Время восстановления базы | восстанавливают «по памяти», от часов, точка отката заранее неизвестна | отработанный сценарий, точка восстановления выбирается осознанно, переключение — единицы минут |
| Проверка копий | копия есть, но ни разу не разворачивалась | регулярный разворот на отдельный стенд с фиксацией результата и времени |
| Срок хранения копий | архив растёт, чистка руками, удаляют «когда место кончится» | политика хранения: свежие копии, недельные, месячный архив, старое удаляется автоматически |
| Целостность цепочки | разрыв обнаруживают при попытке восстановиться | разрыв виден сразу, копирование останавливается с ошибкой, а не молча |
| Влияние на рабочую базу | окно копирования совпадает с пиком нагрузки | копирование вынесено в согласованное окно, отклик базы не проседает |
Как убедиться, что цифры не декларация
Раз в квартал разворачиваем копию на отдельном стенде и замеряем фактическое время восстановления — без этого любые обещания по времени отката ничего не стоят. Результат фиксируем в отчёте: дата, выбранная точка восстановления, фактическое время, что помешало. Если показатель ухудшился, разбираем причину: вырос объём базы, изменилась схема хранения или сломалось расписание запуска.
Режимы работы и ограничения разных схем копирования
Barman не сводит копирование к одному сценарию: полные снимки базы, инкрементальные копии и непрерывная передача изменений решают разные задачи и по-разному ограничивают восстановление. Ошибка — выбирать режим по привычке, а не по требованиям к точке восстановления и допустимому окну обслуживания.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Полные снимки базы | Небольшие базы, редкие изменения, простое окно | Время и объём растут вместе с базой, хранение расширяется линейно |
| Непрерывная передача изменений | Нужна точка восстановления внутри дня | Требует запаса места под журнал, разрыв цепочки обнуляет глубину восстановления |
| Инкрементальные копии | Крупные базы, где полный снимок не укладывается в окно | Опирается на предыдущую копию, восстановление собирается из цепочки дольше |
| Копии с реплики | Разгрузка основной базы | Задержка реплики и согласованность снимка под нагрузкой |
Рабочая схема обычно гибридная: редкий полный снимок как опора, непрерывная передача изменений для точности внутри суток, инкрементальные уровни между ними — так окно обслуживания остаётся в допустимых границах, а глубина восстановления измеряется днями, а не часами. Перед вводом в регламент мы прогоняем пробное восстановление: цепочка проверяется на разрыв, а не на бумаге.
Порядок внедрения: от обследования до передачи в эксплуатацию
Внедрение резервного копирования начинается не с установки Barman, а с инвентаризации: какие кластеры обслуживаем, какой объём потери данных допустим, сколько времени есть на восстановление. От этих ответов зависит схема резервирования — архивация журналов предзаписи вместе с периодическими полными копиями, отдельное хранилище под копии и политика хранения по расписанию.
- Обследование кластеров: версии, объёмы, темп изменений, окна обслуживания, требования к точке и времени восстановления.
- Схема резервирования: где размещаем сервер резервного копирования, куда пишутся копии, глубина хранения, режим архивации журналов и потоковой передачи.
- Настройка: подключение серверов, расписания полных и инкрементальных копий, политика хранения, уведомления об ошибках архивации.
- Тестовое восстановление: разворачиваем копию на отдельном инстансе, замеряем время до рабочего состояния и проверяем откат на точку во времени.
- Регламент копирования: расписания, ответственные, порядок действий при сбое, проверка целостности и ротация копий.
- Мониторинг и передача в эксплуатацию: алерты на сбой архивации, панель состояния, документация, обучение команды.
Передаём систему после контрольного восстановления: пока откат не проверен на реальных данных, регламент считается черновиком.
Конфигурации, регламенты и документация на выходе
После внедрения у команды заказчика остаются не только работающие задания копирования, но и всё, что нужно для их сопровождения без автора внедрения. Инженер, не участвовавший в настройке, должен по этим материалам поднять восстановление на тестовом контуре и получить тот же результат.
- Конфигурация копирования — рабочие файлы настроек сервера и подключённых узлов с пояснениями: что задаёт расписание, глубину хранения, режим передачи журналов и почему выбраны такие значения.
- Документация по копированию — описание всей цепочки: откуда снимается копия, где хранится, сколько живёт, что происходит при недоступности источника или хранилища.
- Политики доступа — роли и права на чтение настроек, запуск копий и восстановление, разграничение по средам и порядок согласования ручных операций в продуктивной среде.
- Инструкция восстановления — пошаговый сценарий полного и точечного возврата данных, включая откат на нужный момент времени, с ожидаемым результатом на каждом шаге.
- Регламент проверок — как часто и на каком контуре прогоняется восстановление, какие признаки подтверждают пригодность копии, что делать при расхождении.
- Контроль состояния — автоматические проверки и правила оповещений: кому и в каких случаях приходит тревога о неудачной копии.
- Журнал приёмки — зафиксированные результаты тестовых восстановлений с временем и объёмом данных.
Передаём вместе с разбором: проходим по каждому артефакту, отвечаем на вопросы, фиксируем владельцев. Дальше команда ведёт систему сама.
Кейс: восстановление за минуты вместо нескольких часов
До: дамп, который никто не разворачивал
Кластер из нескольких узлов бэкапился ночным дампом и ручным копированием каталога данных. Готовность копий никто не проверял: считалось, что раз файл создан — он пригоден. Журналы предзаписи архивировались нерегулярно, поэтому восстановления на точку перед сбоем не существовало — только «последний удачный дамп», то есть потеря данных за сутки и больше.
После: потоковая копия и регулярные учения
Подняли Barman отдельным сервером: он снимает полные копии потоком, непрерывно принимает журнальные сегменты и хранит их вне основного кластера. Политика хранения держит несколько полных копий и весь журнальный ряд за нужный период — этого достаточно для восстановления на точку непосредственно перед аварией. Раз в неделю копия разворачивается на отдельном стенде: кластер стартует, сверяются контрольные суммы и счётчики строк в ключевых таблицах.
Время восстановления сократилось с примерно пяти часов до 12–18 минут вместе с переносом и запуском. Доля проверенных копий выросла с нуля до 100% — каждая полная копия проходит разворот на стенде до попадания в ротацию. Ушёл класс отказов, при котором повреждённая копия вскрывалась только в момент аварии, а также сценарий с потерей суточного объёма изменений.
Что делать, если Barman уже развёрнут, но копии не проверялись?
Развёрнутый Barman — это ещё не работающая система резервного копирования. Пока восстановление ни разу не проверялось, неизвестны ни целостность копий, ни реальное время простоя при отказе. Начинаем с аудита копирования: какие серверы действительно попадают в конфигурацию, куда уходят архивы WAL, нет ли разрывов в цепочке и что показывает лог архиватора.
Разрыв критичен: потеря одного сегмента WAL лишает возможности восстановиться на произвольную точку во времени, и обнаруживается это обычно в момент аварии, а не на плановой проверке. Проверка восстановления снимает вопрос — копия разворачивается на отдельный инстанс и сверяется с источником по контрольным суммам и числу строк в ключевых таблицах.
Затем — пересмотр схемы копирования. Ежедневный полный снимок на растущей базе перестаёт укладываться в окно и начинает влиять на нагрузку; рабочая схема сочетает базовый снимок, инкрементальные копии и политику хранения, где старые срезы чистятся, а глубина отката остаётся достаточной.
Отдельная часть — регламент: проверка восстановления по расписанию, а не по случаю. Автоматический разворот на тестовый контур, замер времени до готовности базы, алерт при сбое архивации WAL или копии, отчёт о состоянии по каждому серверу.
После этого отказ на проде — отработанный сценарий с известным временем восстановления, а не первое знакомство с бэкапом.
Технические вопросы по хранению и проверке копий
Хранение копий — это не папка на диске, а политика: где лежит копия, сколько живёт и как проверяется. До старта работ фиксируем три параметра — площадку размещения, объём хранилища и жизненный цикл копий. Ниже — ответы на сомнения, которые чаще всего всплывают при настройке Barman.
Нужна ли отдельная внешняя площадка для копий?
Она снимает главный класс отказов — потерю данных вместе с сервером. Основной поток копий идёт на локальное хранилище, откуда восстановление быстрее, а вторая копия выгружается на внешнюю площадку тем же инструментом. Если связь пропала, копирование не останавливается: копии пишутся локально и доставляются наружу, когда канал вернулся.
Сколько места займут копии?
Объём хранилища копий считается от размера базы, скорости изменений и выбранного жизненного цикла. Жизненный цикл задаёт, сколько полных копий и цепочек журнала предзаписи сохраняется: держим последние полные копии за нужный период, остальное удаляется. Тогда архив не растёт бесконечно, а откат на нужную точку остаётся возможным.
Как понять, что копия действительно восстановится?
Копия без проверки — это предположение. Настраиваем автоматическую проверку: копия разворачивается на отдельном стенде, база поднимается, проходят контрольные запросы. Если проверка не прошла, ответственный получает уведомление до аварии, а не в момент восстановления.
Обсудим вашу схему резервирования и вернёмся с планом
Опишите, как резервирование устроено сейчас, — и мы вернёмся с оценкой и планом работ, а не с общими словами. Начинаем с разбора текущей схемы: где снимаются копии, куда уходит архив журналов, проверяется ли целостность и что произойдёт при отказе основного узла. По итогам вы получаете целевую схему на Barman, этапы внедрения и границы ответственности.
- Топология и требования: сколько узлов, есть ли реплики, какие базы критичны, допустимая потеря данных и целевое время восстановления.
- Разбор текущей схемы: расписание копий, глубина хранения, занимаемый объём, куда пишется архив журналов, как устроен доступ к хранилищу.
- История проверок резервных копий: делались ли тестовые восстановления, на каком стенде, чем закончились, расходится ли копия с рабочим состоянием.
- Целевой контур: потоковая передача полных копий, непрерывное архивирование журналов, вынос хранилища на отдельный сервер или в объектное хранилище.
- Политика хранения: сколько держим полных копий и журналов, как ротация укладывается в доступный объём, какие точки отката остаются доступными.
- Регламент проверок: расписание тестовых восстановлений на отдельный стенд, автоматическая сверка и оповещение о сбое архивации.
- Оценка и план работ: этапы, сроки, зависимости от вашей инфраструктуры, точки согласования, какие доступы нужны с вашей стороны.
- Передача в эксплуатацию: документация, настройки мониторинга, инструкции для дежурной смены и порядок действий при восстановлении.
