Для небольшой базы, миграции или восстановления отдельной таблицы pg_dump подходит хоро... — 1 сентября 2026 г. в 10:24:05.184
Для небольшой базы, миграции или восстановления отдельной таблицы pg_dump подходит хорошо. Он создает логический дамп и позволяет переносить данные между мажорными версиями PostgreSQL. Но у этой простоты есть цена: каждый дамп — полная копия, а восстановиться можно только на момент его создания. Если между ночным бэкапом и аварией прошло несколько часов, этих изменений в копии уже нет. Для продакшена с более жестким RPO используют WAL-G. Он делает физический бэкап кластера и непрерывно сохраняет WAL-сегменты. Благодаря этому PostgreSQL можно восстановить до конкретного момента времени через PITR. Дальше возникает вопрос хранения. Бэкапы и WAL можно отправлять в VK Object Storage: так они не занимают локальный диск базы, а ротацию можно автоматизировать через Lifecycle Policies. Например, удалять старые WAL и переводить неактуальные базовые копии из Hotbox в Icebox. Получается два разных сценария: 1️⃣pg_dump — небольшие базы, миграции, отдельные таблицы и схемы 2️⃣WAL-G + S3 — production, непрерывная архивация WAL и восстановление на нужную точку времени. И в обоих случаях остается главное: бэкап нужно не только создать, но и регулярно проверять восстановлением. Иначе время реального restore может сильно отличаться от расчетного. 🚩 Обе схемы, настройку WAL-G с VK Object Storage, PITR, lifecycle, Object Lock можно найти здесь