Maintenance

Operational upkeep of a running Vetrix instance: keeping the database recoverable, keeping the search index consistent with the relational store, and moving the deployment onto a new release. These pages describe the background schedulers that do this work unattended, the admin settings and environment variables that steer them, and the manual procedures an operator falls back to when a scheduler has stalled or a run has failed.

Pages

• Database Backup & Restore — The pg_dump scheduler and its per-config cron rows, the four destination adapters (local, S3, GCS, Azure Blob) with AES-256-GCM-sealed credentials, retention pruning by age and count, the restore runbook for both an in-place primary replace and an inspection-only staging_schema target, and the vetrix-cli backup command tree that wraps every admin endpoint.
• Search Indexing — The transactional-outbox pipeline that mirrors relational writes into OpenSearch: the admin_settings tunables and which of them need a restart, how to read queue depth and the /admin/search badges, recovery for stranded claims and rows parked past the max-attempts cap, triggering the drift-repair full sweep by hand, and the first-run backfill and rollback procedure.
• Upgrades and Migrations — How the startup migration step applies pending *.up.sql files before traffic is accepted, the upgrade sequence for Docker Compose, Kubernetes, and bare-metal binary deployments, the manual .down.sql path for rolling back, what to capture beforehand, and the additive-migration rule a multi-replica rolling update depends on.

Related

• Git Storage — the repository-data side of a backup; the database dump above covers only the relational store.