Худший бэкап — не тот, что не восстановился. А тот, что положил прод. Что, если post-script не отработал? Моргнула сеть или случился таймаут. Внешний оркестратор просто пишет в лог «Failed» и снимает задачу. А вот PostgreSQL об этом не знает. База остается в режиме бэкапа и начинает непрерывно копить WAL-файлы, ожидая команды на завершение. Получается, что инструмент для защиты бизнеса от даунтайма, своими руками этот даунтайм и устроил. Уметь дернуть pg_backup_start()— мало. Если СРК не имеет встроенного watchdog-механизма для сброса зависших сессий, резервное копирование превращается в угрозу доступности. Разделение ответственности — правильный архитектурный подход, но он означает, что защита базы от переполнения диска полностью ложится на ваши плечи. О зависшем backup mode, разрывах PITR и других неудобных вопросах эксплуатации PostgreSQL совместно с Акурой поговорим на вебинаре 26 марта. 👉🏼 Регистрируйтесь по ссылке