Бэкапы

Вариант 1: Простой бэкап (встроенный)

Никакой настройки, кроме S3-доступов. trip2g делает периодические полные снапшоты базы, гзипает и заливает в S3-совместимое хранилище (AWS S3, MinIO, Backblaze, …).

trip2g --simple-backup ...

• Снапшоты по расписанию (раз в час) с ретеншеном (старые удаляются).
• Восстановление на старте: если сервер стартует без локальной базы, он сначала тянет последний снапшот из S3. Если база уже есть — не делает ничего; ваши данные восстановлением не затираются.
• Бэкап при выключении: по умолчанию trip2g делает последний снапшот при graceful shutdown, чтобы плановая остановка зафиксировала финальное состояние. Управляется --simple-backup-on-shutdown (по умолчанию true).

Для rolling-деплоя без простоя ставьте --simple-backup-on-shutdown=false на уходящем инстансе: сменщик уже встаёт, часовые снапшоты идут, а дамп на выключении только гонялся бы с новым писателем и замедлял дренаж.

Компромисс: между снапшотами можно потерять до часа записей.

Вариант 2: Litestream (непрерывный)

Litestream стримит каждую запись в S3 по мере поступления, так что падение теряет секунды, а не час — и это вход к read-репликам. Запускается sidecar'ом; настройка — в гайде litestream.

С Litestream выключите собственный maintenance trip2g, чтобы они не дрались за WAL:

trip2g --simple-backup=false --vacuum-cron=false ...

(--vacuum-cron и так выключен по умолчанию. Никогда не включайте его под Litestream — VACUUM и wal_checkpoint(TRUNCATE) ломают реплику Litestream.)

Какой выбрать?

Не запускайте оба на одной базе — когда Litestream включён, он и есть ваш бэкап. Начните с простого бэкапа; переходите на Litestream, когда нужно меньшее окно восстановления или read-реплики.