Уявіть: сервер із 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-архівування.
