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

В идеальном мире миграция работает как часы: контроллер подключается к платформе по API, автоматически создает сети, разворачивает машины и переносит данные. В суровой реальности крупного энтерпрайза эта схема часто рушится: целевое облако может быть «самописным» и не иметь нужных методов, либо безопасники отказываются пускать стороннее ПО в закрытый контур. Для работы в условиях таких ограничений мы используем режим Direct2Target (D2T). Это подход, при котором данные передаются напрямую на диски заранее подготовленной ВМ, полностью минуя интеграцию с управляющим слоем облака.

В теории концепция звучит изящно, но у инженеров логично возникает скепсис по поводу физики процесса. Я расшифровал техническую сессию с нашего недавнего вебинара. Вопросов под катом, конечно, не сто, но я оставил самую суть — те, что нам чаще всего задают архитекторы: как не утилизировать сеть на 100%, как «наживую» перенести PostgreSQL без потери консистентности, как пробиться через глухой NAT и что делать, если целевая ВМ не завелась.

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

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

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

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

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

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

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