Архивация WAL — это процесс копирования завершённых WAL-файлов (по 16 МБ) из каталога pg_wal/ в долговременное хранилище (диск, NFS, S3 и т.д.) сразу после их заполнения. Point-in-Time Recovery (PITR) — это механизм в PostgreSQL, который позволяет восстановить базу данных до любого момента времени в прошлом, начиная с момента создания полного резервного копирования.

Это дополняет физический бэкап (pg_basebackup) и позволяет восстановить базу данных на любой момент времени — от момента бэкапа до последней заархивированной записи WAL.

Как это работает (по шагам)

  1. WAL-файл заполняется
  • PostgreSQL пишет изменения в WAL-файлы в pg_wal/.
  • Каждый файл имеет размер 16 МБ (по умолчанию).
  • Когда файл заполнен — он закрывается и помечается как готовый к архивации.
  1. Выполняется 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`)
  1. Файл помечается как заархивированный
  • После успешного выполнения archive_command в pg_wal/archive_status/ создаётся файл .done:
000000010000000000000001.done #Это означает: «WAL-файл можно удалить, когда он больше не нужен».
  1. При восстановлении используется restore_command
  • При PITR PostgreSQL читает архив через команду:
# postgresql.conf
restore_command = 'cp /archive/wal/%f %p'

Требования

ПараметрЗначение
wal_levelreplica или logical (не minimal!)
archive_modeon
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_inclusivefalseИсключить целевую транзакцию

Важные нюансы

# 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.