Сам по себе подход "zfs send | zfs receive раз в час" - вполне рабочий механизм доставки снапшотов, но не полноценная стратегия бэкапа PostgreSQL. Возможно им даже можно пользоваться для 1-2 серверов, но для fleet-level управления это абсолютно неприменимо.
Полноценное СРК/бэкап-решение - это не только транспорт, а еще управление, контроль, хранение, и восстановление. Поэтому:
- мы не говорим, что "делаем бэкап лучше, чем ZFS или PostgreSQL";
- мы говорим, что превращаем такие нативные механизмы в управляемое, централизованное и контролируемое полноценное СРК-решение.
Это полезный дополнительный механизм защиты от человеческих ошибок, но не замена бэкапу. Standby продолжает меняться, зависит от primary и от доставки WAL. Например, если на primary случайно удалили таблицу и вы не успели вовремя среагировать, это удаление будет применено и на delayed standby. То есть вашей "копии вчерашнего состояния" уже не существует.
Сам по себе подход "zfs send | zfs receive раз в час" - вполне рабочий механизм доставки снапшотов, но не полноценная стратегия бэкапа PostgreSQL. Возможно им даже можно пользоваться для 1-2 серверов, но для fleet-level управления это абсолютно неприменимо.
Полноценное СРК/бэкап-решение - это не только транспорт, а еще управление, контроль, хранение, и восстановление. Поэтому:
- мы не говорим, что "делаем бэкап лучше, чем ZFS или PostgreSQL";
- мы говорим, что превращаем такие нативные механизмы в управляемое, централизованное и контролируемое полноценное СРК-решение.
Это полезный дополнительный механизм защиты от человеческих ошибок, но не замена бэкапу. Standby продолжает меняться, зависит от primary и от доставки WAL. Например, если на primary случайно удалили таблицу и вы не успели вовремя среагировать, это удаление будет применено и на delayed standby. То есть вашей "копии вчерашнего состояния" уже не существует.
Нет, это не "бэкап сутки назад". Это отложенная реплика.
Что вы получите:
- pg_basebackup -R создаст standby;
- recovery_min_apply_delay = 86400000 заставит его применять WAL с лагом 24 часа;
- в итоге это будет живой экземпляр PostgreSQL, который всегда отстает от primary на сутки.
Это не зафиксированная копия, а живой процесс.
Если угодно, можно привести такую аналогию:
бэкап - это фотография;
delayed standby - это видеотрансляция с задержкой 24 часа.