• Случайное выполнение деструктивного запроса (DROP TABLE или ошибочный UPDATE без WHERE) в продакшн-базе.
• Необходимость откатить состояние СУБД на секунду до момента совершения логической ошибки.
• Ошибки согласованности при запуске инстанса в режиме восстановления архивов.

1. Поиск точного LSN или временной метки ошибки через pg_waldump

# Поиск деструктивной транзакции DROP TABLE в архивах WAL
pg_waldump /var/lib/postgresql/wal_archive/00000001000000A1000000B2 | grep -E "DROP|COMMIT"

2. Остановка текущего экземпляра и разворачивание базового бэкапа

systemctl stop postgresql

# Очистка текущего каталога данных (или перенос в backup_old)
rm -rf /var/lib/postgresql/16/main/*

# Разворачивание физического базового бэкапа (basebackup)
tar -xvf /mnt/backups/base_backup_2024_01_01.tar -C /var/lib/postgresql/16/main/

3. Конфигурация параметров восстановления в postgresql.conf

Создайте маркерный файл recovery.signal в каталоге данных:

touch /var/lib/postgresql/16/main/recovery.signal
chown postgres:postgres /var/lib/postgresql/16/main/recovery.signal

В конец файла /var/lib/postgresql/16/main/postgresql.conf добавьте параметры таргетинга:

# Команда для извлечения недостающих WAL-файлов из архива
restore_command = 'cp /var/lib/postgresql/wal_archive/%f %p'

# Целевая точка восстановления по времени (UTC или локальное время)
recovery_target_time = '2024-03-30 14:25:30'

# Действие по достижении точки: pause (для проверки) или promote
recovery_target_action = 'pause'
recovery_target_inclusive = false

4. Запуск инстанса, проверка данных и финализация

systemctl start postgresql

-- Проверка состояния: находится ли сервер в режиме восстановления
SELECT pg_is_in_recovery();

-- Если данные корректны, завершить восстановление и открыть базу на запись
SELECT pg_wal_replay_resume();