Непрерывный бэкап и read-реплики через Litestream

Litestream реплицирует вашу SQLite-базу в S3 непрерывно — каждая запись стримится в объектное хранилище — вместо периодических полных снапшотов, которые делает встроенный простой бэкап trip2g. Упал сервер — теряете секунды, а не час. Запускается маленьким sidecar рядом с trip2g; внутрь ничего не вкомпилировано.

Запуск рядом с trip2g

Litestream следит за WAL вашего SQLite-файла и отгружает его в S3. Два флага trip2g делают их совместимыми:

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

--vacuum-cron=false — самый важный (и это значение по умолчанию). Опциональная maintenance-задача trip2g делает wal_checkpoint(TRUNCATE) + VACUUM. Litestream должен быть единственным, кто трогает WAL: TRUNCATE-чекпойнт может срезать WAL-фреймы, которые Litestream ещё не реплицировал, а VACUUM перезаписывает всю базу в новую генерацию Litestream. Поэтому с Litestream никогда не включайте --vacuum-cron. (Litestream сам чекпойнтит; vacuum он не делает, и он вам не нужен.)
--simple-backup=false — не запускайте ещё и S3-снапшот-бэкап trip2g. Litestream и есть ваш бэкап; держать оба избыточно.

Минимальный конфиг (litestream.yml):

dbs:
  - path: /data/data.sqlite3
    replicas:
      - type: s3
        endpoint: https://your-s3-or-minio
        bucket: trip2g-backups
        path: data.sqlite3

Запустите litestream replicate -config litestream.yml рядом с trip2g. Восстановление на свежем сервере: litestream restore -config litestream.yml /data/data.sqlite3 до старта trip2g.

Шифрование

Litestream 0.3.13+ поддерживает нативное клиентское age-шифрование (E2E) — простейший способ закрыть требование «бэкапы зашифрованы at-rest и in-transit» для комплаенса. Добавьте age-ключ в конфиг реплики; бакет видит только шифртекст.

Дальше бэкапа: read-реплики

В Litestream есть VFS — расширение SQLite (litestream.so), которое приложение загружает через load_extension(), чтобы читать S3-бэкап-поток напрямую из кода. Это не CLI-инструмент и не готовый сервер read-реплики. Использование требует интеграции на уровне приложения: просто указать S3-бакет из командной строки не получится. Кроме того, per-page S3-запросы дают задержку — для горячего чтения не подходит.

Для проверенной в продакшене живой read-реплики trip2g — чтение локально с задержкой репликации в доли секунды, записи форвардятся на первичный, ноль ошибок чтения при перезапуске первичного — смотрите read-replica. Там в качестве транспорта репликации используется LiteFS (документация) — FUSE-ФС, которая стримит изменения SQLite между машинами. Хорошо ложится на single-writer модель trip2g и на деплой без простоя.

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

Полное сравнение — в backup. Коротко: простой бэкап (встроенные S3-снапшоты) — дефолт без настройки; Litestream — апгрейд, когда нужна непрерывная репликация и минимальная потеря данных.

Если вы также разворачиваете живую read-реплику через LiteFS, учтите: Litestream и LiteFS оба работают с WAL SQLite. Запускайте Litestream-бэкап на отдельном первичном сервере без LiteFS-монтирования — не на FUSE-монтировании /litefs.