Представьте: сервер с PostgreSQL 15 выходит из строя из-за отказа дискового массива. Без настроенного WAL-архивирования восстановление до последней секунды невозможно — вы теряете часы транзакций. Мы настраиваем WAL-архивирование так, чтобы RPO не превышал минуту, а RTO — 30 минут даже на терабайтных базах.
Мы — команда DevOps-инженеров с 5-летним опытом, реализовали 50+ проектов по резервному копированию PostgreSQL для компаний из финтеха и ретейла. В этой статье разберём, как настроить WAL-архивирование правильно и избежать потерь.
Почему WAL-архивирование критично?
WAL (Write-Ahead Log) — это журнал предзаписи. Без его архива точка восстановления (RPO) равна интервалу полных бэкапов — часы или сутки. Для критичных систем это неприемлемо. Архив WAL позволяет выполнять Point-in-Time Recovery (PITR) на любой момент времени, что критично при ошибочных DROP-операциях или сбоях.
Какие проблемы решаем?
Отсутствие отказоустойчивости. Без архива WAL точка восстановления (RPO) может составлять часы или даже дни, если полный бэкап делается раз в сутки. При сбое теряются все изменения после последнего бэкапа. Например, при падении диска с PGDATA вы не сможете восстановиться до секунды перед сбоем — только до момента последнего полного бэкапа.
Невозможность PITR. Даже если есть полный бэкап, без архива WAL вы не можете восстановить базу на произвольный момент времени (Point-in-Time Recovery). Это критично для отката ошибочных операций (DROP TABLE, DELETE без WHERE) или для аналитики состояния базы в прошлом.
Сложности с мониторингом состояния архива. Многие забывают проверять, успешно ли копируются WAL-сегменты. В результате архив может быть пуст или повреждён, а узнают об этом только при аварии. Нужен мониторинг: pg_stat_archiver показывает количество неудачных попыток архивирования. Если failed_count растёт — пора бить тревогу.
Как настроить WAL-архивирование?
Согласно официальной документации PostgreSQL, archive_mode должен быть включён, а wal_level установлен в replica или higher.
Выбор инструмента: WAL-G или pgBackRest?
| Параметр | WAL-G | pgBackRest |
|---|---|---|
| Установка | Один бинарный файл | Пакетная установка, конфигурация в файле |
| Сжатие | brotli, gzip, lz4 | gzip, lz4, zst (с параллельным сжатием) |
| Типы бэкапов | Полный, дельта (incremental) | Полный, дифференциальный, инкрементный |
| Параллелизм | Нет параллельного сжатия/восстановления | Поддержка параллельных операций |
| Репликация бэкапов | Нет | Встроенная репликация между хранилищами |
| Восстановление | Медленнее при больших объёмах | Быстрее в 2-3 раза |
pgBackRest быстрее при восстановлении на больших базах, но WAL-G проще в настройке. Для критичных систем с терабайтами данных выбираем pgBackRest, для небольших проектов — WAL-G.
Конфигурация основных параметров
В postgresql.conf:
wal_level = replica # минимум для архивирования
archive_mode = on
archive_command = 'wal-g wal-push %p'
archive_timeout = 300 # принудительно архивировать каждые 5 минут (для PITR с малым RPO)%p — полный путь к WAL-файлу, %f — только имя файла. archive_command должен возвращать 0 при успехе. Убедитесь, что путь к wal-g доступен для пользователя postgres.
Настройка архивирования в S3 через WAL-G
# Установка
wget https://github.com/wal-g/wal-g/releases/latest/download/wal-g-pg-ubuntu-20.04-amd64.tar.gz
tar -xzf wal-g-pg-ubuntu-20.04-amd64.tar.gz
mv wal-g /usr/local/bin/
# Переменные окружения (в /etc/postgresql/16/main/environment или systemd unit)
WALG_S3_PREFIX=s3://my-pg-backups/wal
AWS_REGION=eu-central-1
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
WALG_COMPRESSION_METHOD=brotli
WALG_DELTA_MAX_STEPS=6 # delta backup до 6 шагов# postgresql.conf archive_command = 'wal-g wal-push %p' restore_command = 'wal-g wal-fetch %f %p' Проверка:
# Список загруженных WAL сегментов
sudo -u postgres wal-g wal-verify integrity
# Ручная загрузка базового бэкапа
sudo -u postgres wal-g backup-push $PGDATA
Как определить RPO и RTO для вашей базы?
Определение RPO и RTO — частый запрос от клиентов. RPO (Recovery Point Objective) — это максимально допустимая потеря данных. Для критичных систем RPO должен быть ≤ 1 минута. Достигается это настройкой archive_timeout = 60 и мониторингом очереди WAL. RTO (Recovery Time Objective) — время, за которое база должна быть восстановлена. Для базы 1 ТБ с pgBackRest RTO составляет около 30 минут при параллельном восстановлении. С WAL-G — до 2 часов.
| archive_timeout | RPO (max data loss) | WAL volume per day (1GB/hr) |
|---|---|---|
| 60 sec | ≤ 1 min | ~ 24 GB |
| 300 sec | ≤ 5 min | ~ 24 GB |
| 1800 sec | ≤ 30 min | ~ 24 GB |
Что делать, если archive_command завершается ошибкой?
Ошибки архивирования — частая проблема. Причины: сетевые сбои, проблемы с IAM-ключами, переполнение бакета. Алгоритм действий:
- Проверить
pg_stat_archiverиpostgresql.logна предмет ошибок. - Убедиться, что
archive_commandкорректен, выполнив его от пользователя postgres:sudo -u postgres wal-g wal-push /path/to/wal. - Настроить оповещение при неудачных попытках (например, через pg_stat_archiver.failed_count > 0 в Prometheus).
- Резервный вариант: временно отключить архивирование (
archive_mode = off) и накопить WAL-файлы локально, затем ручная загрузка.
Тестирование восстановления (PITR)
Обязательно выполняйте тестовое восстановление на отдельном сервере. PITR-восстановление:
# 1. Восстановить полный бэкап
sudo -u postgres wal-g backup-fetch /tmp/restore LATEST
# 2. Создать recovery.conf (PG <12) или recovery.signal (PG >=12) с restore_command
restore_command = 'wal-g wal-fetch %f %p'
# 3. Запустить PostgreSQL и проверить данныеТестируйте восстановление не реже раза в месяц. Это выявит проблемы с архивом до аварии.
Что входит в работу
- Анализ текущей инфраструктуры: версия PostgreSQL, нагрузка, доступное хранилище
- Выбор инструмента (WAL-G / pgBackRest) с обоснованием
- Настройка архивного сервера и S3-бакета
- Конфигурация postgresql.conf и скриптов архивирования
- Настройка мониторинга состояния архива (Prometheus + Grafana)
- Тестирование PITR-восстановления с замером RTO
- Документация: runbook по восстановлению, контакты ответственных
- Обучение вашей команды: как выполнять восстановление вручную
Процесс работы над проектом
- Анализ текущей инфраструктуры: версия PostgreSQL, нагрузка, доступное хранилище.
- Проектирование схемы архивирования: выбор инструмента, S3-бакет, политика хранения.
- Реализация: настройка сервера, установка и конфигурация WAL-G или pgBackRest.
- Тестирование: PITR-восстановление, проверка целостности архива.
- Деплой в production и документация: runbook по восстановлению, скрипты мониторинга.
Сроки и стоимость
Ориентировочные сроки: от 1 до 3 рабочих дней в зависимости от сложности инфраструктуры. Стоимость рассчитывается индивидуально после анализа.
Закажите аудит текущей схемы резервного копирования — выявим узкие места и предложим оптимизацию. Получите консультацию инженера по настройке WAL-архивирования.
