Настройка continuous бекапов PostgreSQL

По поводу archive_command не соглашусь. Во-первых, для скрипта это достаточно короткий и тривиальный функционал. Если что-то (а в данном случае это «что-то» — это, в основном, только потеря связи с сервером бекапов, так как падение sync — исчезающе редко, как мне кажется) отломается, то получим запись в логах postgres об ошибке архивирования. Во-вторых, действительно, один из подходов — это 1) archive_command только складывает wal-ы локально, а 2) какой-то процесс их подбирает и отправляет в безопасное место. Мы этот подход осознанно не используем, считая его гораздо менее надежным с точки зрения сохранения консистентности бекапа. Думаю очевидно, что описанный в статье подход «железобетонен» и это гарантируется средствами postgres — wal не ушли, значит, не будут удалены, wal ушли, значит они точно в безопасном месте лежат на диске. В предлагаемом же вами подходе — во второй стадии — достаточно широкое поле для ошибок, связанное с устройством и качеством этого самого процесса слежения за локальной папкой (если это свои скрипты — то нет ли в них ошибок и т.п.). Ну просто логически даже давайте посмотрим — если это скрипты — то они будут примерно такие же, как в archive_command — тогда зачем выделять вторую стадию. Если это какая-то программа типа rsync, то нужно быть уверенным, что она не отвалилась, что она работает именно как ожидаемо — то есть, удаляет здесь файл, когда убедится, что там он «synced to disk», что она синхронизирует файлы в правильном порядке — если имеется A1, А2, A3 — то желательно, чтобы файлы уходили в верном порядке, иначе при сбое может оказаться, что на сервере бекапов у вас уже есть A2 и A3, но нет A1, потому что какой-нибудь аналог rsync решил, что будет синкать, к примеру, по размеру, а не по времени сохранения. Готов согласиться, что все это можно реализовать, но это не бесплатно и уж точно не по той причине, какую вы указали — «прозрачность». Скорее это может быть связано с: А) Возможность нагрузкой на worker'ы postgres'а и, как следствие, impact на производительность самой базы (но мы после достаточно долгого использования этого подхода этого не наблюдаем) Б) Работой с альтернативными storages бекапов — например, по API и т.п., где уже действительно в одной строке archive_command команду сохранения будет выразить сложно или вовсе невозможно. Единственное, чего тут нет, но, возможно, было бы полезно добавить — это, действительно, мониторинг того, архивируются ли файлы в нужные промежутки — автоматически анализируя логи postgres или факт исчезновения wal-файлов.