Практика резервного копирования в Postgres Pro

pg_probackup — это утилита для управления резервным копированием и восстановлением кластеров баз данных Postgres Pro. Она предназначена для регулярного создания резервных копий экземпляра Postgres Pro, позволяющих восстанавливать сервер в случае необходимости.

Основные возможности pg_probackup

Полные и инкрементальные резервные копии: поддерживаются режимы FULL, DELTA, PAGE и PTRACK, что позволяет оптимизировать использование дискового пространства и ускорить процесс резервного копирования.
Поддержка S3-хранилищ: в версии Postgres Pro Enterprise реализована возможность хранения резервных копий в облачных хранилищах, таких как MinIO, Amazon S3 и VK Cloud.
Параллельное выполнение операций: возможность выполнения резервного копирования, восстановления и других операций в несколько потоков для повышения производительности.
Валидация и проверка целостности: автоматическая проверка целостности данных и резервных копий без необходимости восстановления данных кластера.
Удалённый режим работы: возможность выполнения резервного копирования и восстановления на удалённых серверах через SSH.

Установка и настройка

Инициализация каталога резервных копий:

pg_probackup init -B /path/to/backup/catalog

Добавление экземпляра базы данных:

pg_probackup add-instance -B /path/to/backup/catalog -D /path/to/data/directory --instance instance_name

Настройка конфигурации экземпляра:

pg_probackup set-config -B /path/to/backup/catalog --instance instance_name --pguser=backup_user --pgdatabase=backup_db

Создание резервных копий

Полное резервное копирование:

  pg_probackup backup -B /path/to/backup/catalog --instance instance_name --backup-mode=FULL --stream

Инкрементальное резервное копирование (DELTA):

  pg_probackup backup -B /path/to/backup/catalog --instance instance_name --backup-mode=DELTA --stream

Инкрементальное резервное копирование (PAGE):

  pg_probackup backup -B /path/to/backup/catalog --instance instance_name --backup-mode=PAGE --stream

Инкрементальное резервное копирование (PTRACK):

  pg_probackup backup -B /path/to/backup/catalog --instance instance_name --backup-mode=PTRACK --stream

Восстановление из резервной копии

Остановка сервера Postgres Pro:

sudo systemctl stop postgrespro-std-13

Очистка каталога данных:

rm -rf /path/to/data/directory/*

Восстановление данных:

pg_probackup restore -B /path/to/backup/catalog --instance instance_name

Запуск сервера Postgres Pro:

sudo systemctl start postgrespro-std-13

Управление резервными копиями

Просмотр списка резервных копий:

  pg_probackup show -B /path/to/backup/catalog --instance instance_name

Удаление устаревших резервных копий:

  pg_probackup delete -B /path/to/backup/catalog --instance instance_name --delete-expired

Проверка целостности резервных копий:

  pg_probackup validate -B /path/to/backup/catalog --instance instance_name

Дополнительные возможности

Архивирование внешних каталогов: возможность резервного копирования файлов и каталогов, расположенных вне каталога данных Postgres Pro, таких как скрипты, файлы конфигурации и журналы.
Частичное восстановление: восстановление только выбранных баз данных из резервной копии.
Синхронизация: клонирование экземпляра Postgres Pro для синхронизации отставшего ведомого сервера с ведущим.

Ресурсы для изучения

Официальная документация pg_probackup: Postgres Professional
Видеоурок по резервному копированию PostgreSQL с помощью pg_probackup: YouTube

Практика резервного копирования в Postgres Pro: кейсы, проблемы и решения

Кейс 1: Регулярные бэкапы в высоконагруженной OLTP-системе

Ситуация:
Банк использует Postgres Pro в качестве основной транзакционной системы. Необходимо делать инкрементальные копии каждый час и полные копии один раз в сутки, не останавливая сервис.

Решение:

Используется pg_probackup с backup-mode=PTRACK (позволяет копировать только измененные страницы).
Установлен PTRACK=on в postgresql.conf.
Применяется --stream для захвата WAL в реальном времени.

Команда:

pg_probackup backup -B /backup --instance bankdb --backup-mode=PTRACK --stream --compress --threads=4

Проблема:

Через несколько дней PTRACK-снимки повреждаются, резервная копия завершается с ошибкой PTRACK SLRU is corrupted.

Решение:

Перезапустить PTRACK: pg_probackup reset-ptrack
Следить за стабильностью на уровне ОС (ошибки I/O, сбои RAID, переполнение SLRU)
Планово делать FULL-резервную копию раз в 3–4 дня

Кейс 2: Катастрофическое восстановление из резервной копии

Ситуация:
В производственном DWH был утерян диск с данными. Последняя полная копия сделана 2 дня назад, а дельты — каждый час.

Решение:

Используется pg_probackup restore с --recovery-target-time для point-in-time recovery.
Хранятся WAL и бэкапы на внешнем S3-хранилище.
Перед восстановлением удаляется старый кластер и инициализируется пустая директория.

pg_probackup restore -B /backup --instance dwh --recovery-target-time="2024-05-19 03:00:00"

Проблема:

Ошибка WAL segment not found, невозможность применить WAL.

Решение:

Проверить наличие archive_command и его выполнение во время создания копий.
Проверить наличие всех WAL-файлов в wal-архиве.
Использовать pg_probackup show и validate для диагностики.

Кейс 3: Резервное копирование с ведомой реплики

Ситуация:
В аналитическом кластере три ноды: один мастер, две реплики. Бэкап запускается с реплики, чтобы не мешать мастеру.

Решение:

Используется --remote-proto=ssh + --remote-host=replica1 + --remote-user=postgres
Установлен pg_probackup на обоих серверах
В pg_hba.conf на мастере разрешен replication-пользователь

Команда:

pg_probackup backup -B /backup --instance analitica --remote-proto=ssh --remote-host=replica1 --remote-user=postgres --backup-mode=DELTA

Проблема:

ERROR: Cannot stream WAL because replication slot is already in use

Решение:

Назначить отдельный replication slot для pg_probackup
Использовать --slot pgbackup_slot
Добавить в план обслуживания pg_replication_slots и мониторинг отставания

Кейс 4: Хранение резервных копий в S3 (MinIO, VK Cloud, AWS)

Ситуация:
Компания хранит бэкапы в MinIO, чтобы снизить нагрузку на файловое хранилище.

Решение:

Используются параметры:

--external-dirs=s3://minio-host/pg-backups/
--s3-key-id=***
--s3-secret-key=***

Проблема:

Ошибки S3: Signature mismatch или 403 Forbidden

Решение:

Проверить настройки часов сервера (ошибки подписи при разнице более 15 сек)
Убедиться, что bucket создан, права доступа настроены, ключ активен

Кейс 5: Автоматизация и cron

Ситуация:
На сервере настроено расписание через cron:

0 0 * * * /usr/local/bin/pg_probackup backup -B /backup --instance prod --backup-mode=DELTA --stream >> /var/log/pgbackup.log 2>&1

Проблема:

Бэкапы создаются, но не удаляются старые, диск заполняется

Решение:

Добавить cron-задачу по удалению устаревших копий:

pg_probackup delete --instance prod -B /backup --delete-expired --retention-redundancy=3

Заключение

pg_probackup — мощный и гибкий инструмент, но для стабильной работы требует:

настройки прав доступа и репликации;
хранения всех WAL;
контроля PTRACK;
мониторинга метаданных резервных копий.

Best Practices резервного копирования в Postgres Pro

1. Выбор стратегии резервного копирования

Полное (FULL) резервное копирование

Делается не реже, чем раз в 3–7 дней.
Полная копия позволяет восстановить базу без зависимости от других копий.
Минусы: требует времени и места на диске.

Инкрементальные копии

Используются между полными копиями: DELTA, PAGE, PTRACK.
Рекомендуемая схема: FULL → PTRACK → PTRACK → PTRACK → FULL.
PTRACK позволяет копировать только измененные страницы (fast, lightweight).

2. Расписание и автоматизация

Пример стратегии

День недели	Тип копии	Комментарий
Пн	FULL	Базовая точка восстановления
Вт-Сб	PTRACK	Быстро, эффективно
Вс	DELTA	Проверочный инкремент с WAL

Реализация:

Планирование через cron, systemd timers или Airflow.
Использование --threads=N для многопоточного копирования.
Журналирование в отдельный лог-файл с ротацией.

3. Организация хранилища резервных копий

Retention policy

Пример настройки:

pg_probackup delete --instance prod -B /backup --delete-expired --retention-redundancy=3 --retention-window=14

Это сохранит последние 3 успешных цепочки и все, что моложе 14 дней.

4. Использование PTRACK

Что это:

Механизм отслеживания измененных страниц в Postgres Pro;
Требует включения в postgresql.conf:

ptrack_enable = on

Как использовать:

pg_probackup backup -B /backup --instance prod --backup-mode=PTRACK --stream

Best practices:

Обязательно выполняйте pg_probackup reset-ptrack после сбоя.
PTRACK не заменяет FULL. Используйте чередование.

5. Мониторинг и проверка бэкапов

Проверка после каждого бэкапа

pg_probackup validate -B /backup --instance prod

Дополнительные проверки

Автоматизированная проверка WAL-архива (на наличие пропущенных сегментов).
Логи успешности каждой операции (pg_probackup show + статус).

Уведомления

Используйте mail, slack, telegram или webhook при ошибке.
Логируйте в системный rsyslog или journald.

6. Восстановление: готовность и документация

Проверяйте восстановление не реже 1 раза в месяц:

В отдельном окружении (dev/test);
По сценарию: pg_probackup restore --recovery-target-time;
Автоматизируйте через CI (test container, Docker snapshot).

Подготовьте документацию:

Где хранятся бэкапы?
Кто ответственный за их проверку?
Какой Recovery Point Objective (RPO)?
Где хранятся ключи доступа к S3, ssh, пароли?

7. Безопасность и доступ

8. Работа с WAL

WAL архив:

Используйте archive_command:

archive_command = 'pg_probackup archive-push -B /backup --instance prod --wal-file-path=%p --wal-file-name=%f'

Обязательно включите archive_mode = on, wal_level = replica, max_wal_senders.

9. Лучшие инструменты автоматизации

Инструмент	Назначение
`cron` + bash	простая автоматизация
`Ansible`	настройка окружения и задач
`pgwatch2`, `Zabbix`, `Grafana`	мониторинг процессов
`Airflow`, `NiFi`	сложные ETL и recovery pipelines

10. Частые ошибки и советы

Проблема	Причина и решение
Ошибка WAL segment not found	WAL-файлы удалены до завершения бэкапа. Настроить правильный архив.
PTRACK corrupted	Сбой диска, перегрузка системы. `reset-ptrack`, проверка ptrack map.
WAL archive overflow	Слишком большой retention. Добавить `pg_probackup delete`.
Invalid backup state	Неправильное завершение бэкапа. Удалить вручную через `pg_probackup delete`.
Нет места для FULL	Слишком большой кластер. Используйте `--compress`, `--remote-host`.

Чек-лист хорошей практики

Установлены pg_probackup и настроен backup-режим
PTRACK включен (если используется)
Расписание FULL + PTRACK + DELETE в cron
Резервное копирование настроено с WAL-архивом
Проверка копий автоматизирована (validate)
Есть инструкция по восстановлению
Бэкапы зашифрованы или недоступны из внешней сети
Протестировано восстановление в отдельной среде
Используется retention-политика и алерты на сбои

Postgres Professional — это российская промышленная СУБД, созданная на базе открытого PostgreSQL, но значительно расширенная для корпоративного применения. В отличие от классического PostgreSQL, решения от Postgres Professional включают в себя поддержку российских ГОСТов и сертификацию ФСТЭК, повышенную надёжность, оптимизации под высоконагруженные системы (в том числе 1С и DWH), инструменты резервного копирования, мониторинга и отказоустойчивости. За платформой стоит команда ядра PostgreSQL в России, что гарантирует актуальность, стабильность и экспертную техническую поддержку 24/7.

Для компаний, которым важно не просто использовать PostgreSQL, а внедрить его на уровне корпоративных стандартов — с гарантией, сопровождением, документированными улучшениями и адаптацией под российское законодательство — Postgres Pro Enterprise становится логичным выбором. Это не просто бесплатная база данных, а полноценный продуктовый стек, совместимый с BI, аналитикой, ERP, 1С и другими системами, в том числе импортозамещёнными.

← Предыдущая статья

Обзор редакций Postgres Pro, где купить Postgres Pro, стоимость Postgres Pro

Следующая статья →

Проект миграции с MS SQL Server на Postgres Pro