Выбор проверяют по времени и стоимости восстановления: полный бэкап проще как исходная точка, инкрементный сокращает копируемый объём, но добавляет зависимости. Для PITR нужен непрерывный WAL от соответствующего бэкапа. Частота полных копий не уменьшает сама по себе генерацию WAL. Разделяйте объём создаваемого журнала, его удержание на сервере и архивное хранение.
Что выбрать для большой PostgreSQL: частые полные или инкрементные бэкапы? Как уменьшить объём WAL?
Как связаны стоимость копирования, цепочка восстановления, RPO/RTO и хранение WAL — и почему нельзя вручную чистить pg_wal.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Большой размер БД сам по себе не определяет стратегию. Нужны допустимая потеря данных, время восстановления, скорость изменения данных, пропускная способность и место под копии.
Полная физическая копия дороже по чтению и передаче, зато даёт самостоятельную базовую точку. Инкрементная хранит изменения относительно предыдущей копии и может сократить работу, но восстановление зависит от целой цепочки. Встроенные инкрементные копии поддерживаются начиная с PostgreSQL17; конкретный backup-инструмент может использовать собственную механику. Для встроенного варианта применяется pg_combinebackup. Проверяйте совместимость версий и не смешивайте форматы.
Для восстановления на момент времени физический бэкап дополняют непрерывным архивом WAL — документация PITR. Логический pg_dump не служит базой для проигрывания WAL. Более свежая базовая копия может сократить объём проигрывания при восстановлении, но не останавливает создание журнала.
Под «уменьшить WAL» могут подразумеваться разные задачи:
- Генерация: искать лишние массовые изменения и неоправданные индексы; оценивать
wal_compression, который сжимает full-page images с затратами CPU. Слишком частые checkpoints могут увеличивать их число. - Удержание в pg_wal: проверять сбои архивации, отстающие реплики и replication slots. Не удалять файлы вручную: они могут требоваться для восстановления или репликации.
- Архив: применять сжатие и согласованную политику хранения backup-инструмента, сохраняя всю цепочку для требуемого окна восстановления.
Параметры описаны в разделе WAL. Нельзя отключать гарантии сохранности данных ради красивой цифры объёма журнала.
Окончательную схему выбирают после пробного восстановления на отдельном окружении. Измеряют полный путь до работоспособного приложения, а не только скорость создания копии.