Как только очередной вендор обещает «убить нативные тулзы PostgreSQL», где-то устало вздыхает DBA. Попытка сделать бэкап PostgreSQL «лучше самого PostgreSQL» — это изначально неверная постановка задачи. 

Универсальный файловый агент не притворяется глубоко PostgreSQL-aware решением. Его задача в другом: взять нативные механизмы СУБД и превратить их в управляемый и наблюдаемый процесс на уровне всей инфраструктуры.

Вокруг такого подхода обычно сразу возникают неприятные, но правильные вопросы. Кто отвечает за консистентность? Где на самом деле живет PITR? Что будет, если потеряется WAL-сегмент? Можно ли восстановить одну таблицу, а не весь инстанс? И зачем вообще нужен внешний слой поверх pg_probackup, если у PostgreSQL уже есть свои зрелые инструменты?

Под катом — честный разговор о границах ответственности между PostgreSQL и внешней платформой.

Привет, Хабр! Я Виктор, в Хайстекс руковожу отделом разработки. Сегодня расскажу про фичу, которая снимает ложную дилемму «API или универсальность», потому что оба сценария можно применять параллельно.

При переносе виртуальных машин между облаками и частными контурами API-интеграция обычно даёт максимум автоматизации. Но как только целевых площадок становится больше одной-двух или появляется «собранная на коленке» платформа, выясняется, что у этой автоматизации есть цена. Миграция через API превращается в отдельный проект на недели разработки и тестирования. Этот пост — для инженеров и архитекторов, которые занимаются миграциями ВМ и упираются в стоимость и сроки поддержки API-интеграций под каждую новую целевую площадку.

Под катом — как сделать целевую сторону миграции воспроизводимой без зависимости от API конкретного облака и без ожидания поддержки со стороны платформы.