Архивация WAL — это процесс копирования завершённых WAL-файлов (по 16 МБ) из каталога
pg_wal/в долговременное хранилище (диск, NFS, S3 и т.д.) сразу после их заполнения. Point-in-Time Recovery (PITR) — это механизм в PostgreSQL, который позволяет восстановить базу данных до любого момента времени в прошлом, начиная с момента создания полного резервного копирования.
Это дополняет физический бэкап (pg_basebackup) и позволяет восстановить базу данных на любой момент времени — от момента бэкапа до последней заархивированной записи WAL.
Как это работает (по шагам)
- WAL-файл заполняется
- PostgreSQL пишет изменения в WAL-файлы в
pg_wal/. - Каждый файл имеет размер 16 МБ (по умолчанию).
- Когда файл заполнен — он закрывается и помечается как готовый к архивации.
- Выполняется
archive_command
- копирует WAL-файл в архивное хранилище
# postgresql.conf
archive_mode = on
archive_command = 'cp %p /archive/wal/%f'
archive_command = 'cp %p /mnt/nfs/wal-archive/%f' # Локальный диск / NFS:
archive_command = 'aws s3 cp %p s3://my-bucket/wal-archive/%f' # AWS S3 (через `awscli`)
archive_command = 'gzip -c %p | ssh backup-server "cat > /archive/%f.gz"' # С сжатием и проверкой # команда должна возвращать код 0 при успехе, иначе PostgreSQL будет повторять попытку.
# - `%p` — полный путь к WAL-файлу (например, `/var/lib/postgresql/16/main/pg_wal/000000010000000000000001`)
# - `%f` — имя файла (`000000010000000000000001`)- Файл помечается как заархивированный
- После успешного выполнения
archive_commandвpg_wal/archive_status/создаётся файл.done:
000000010000000000000001.done #Это означает: «WAL-файл можно удалить, когда он больше не нужен».- При восстановлении используется
restore_command
- При PITR PostgreSQL читает архив через команду:
# postgresql.conf
restore_command = 'cp /archive/wal/%f %p'Требования
| Параметр | Значение |
|---|---|
wal_level | replica или logical (не minimal!) |
archive_mode | on |
archive_command | Действующая команда копирования |
| Хранилище | Достаточно места, надёжность (лучше — отдельный сервер/облако) |
Как использовать архив WAL для восстановления (PITR) ^psql-PITR-WALarchiveRestore
pg_basebackup -h primary -D /backup/data -P -R # Есть базовый бэкап (состояние на 10:00).
# Настроено архивирование WAL
archive_mode = on
archive_command = 'cp %p /backup/wal/%f'
# Произошла ошибка в 14:30. Нужно вернуться к состоянию на 14:25.
### Восстановление
# 1. Остановить PostgreSQL.
# 2. Удалить текущий `PGDATA` (или использовать новый каталог).
# 3. Распаковать базовый бэкап.
# 4. Создать `recovery.signal`.
# Указать в `postgresql.auto.conf`:
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2025-06-15 14:25:00'
### Что происходит дальше?
# - PostgreSQL загружает базовый бэкап (состояние на 10:00).
# - Последовательно применяет все WAL-файлы из архива.
# - Останавливается ровно в 14:25.
# - Удаляет `recovery.signal`, создаёт `recovery.done` → сервер переходит в режим primary.Цели восстановления (recovery targets)
| Параметр | Пример | Когда использовать |
|---|---|---|
recovery_target_time | '2025-06-15 14:25:00' | Самый частый случай — по времени |
recovery_target_xid | '123456789' | Если знаете XID транзакции-виновника |
recovery_target_lsn | '0/1A2B3C4D' | Для точного восстановления по позиции WAL |
recovery_target_name | 'before_deploy' | Если использовали pg_create_restore_point() |
recovery_target_inclusive | false | Исключить целевую транзакцию |
Важные нюансы
# postgresql.conf моды
archive_mode = always # архивирует WAL даже на standby. Осторожно!
# - Обычно достаточно `archive_mode = on`.
**Проверяйте работоспособность `archive_command
- Не защищает от ошибок в
archive_command— нужно мониторить!`** Если команда падает — WAL не архивируется → нет возможности PITR. Мониторьте логи на предмет:
WARNING: archiving write-ahead log file "..." failed too many timesАрхивация WAL — это “лента времени” вашей базы данных.
Вместе с pg_basebackup она даёт:
-
Полное восстановление после катастрофы,
-
Возврат к любому моменту в прошлом,
-
Гарантию минимальной потери данных.
-
PITR работает только вперёд от момента бэкапа.
-
Если пропущен хотя бы один WAL-файл — восстановление не удастся.
- Решение: мониторьте
pg_stat_archiver.
- Решение: мониторьте