Backups¶

Database¶

PostgreSQL is the primary data store. Regular backups are critical.

pg_dump (Logical Backup)¶

pg_dump -h localhost -U vectis -d vectis -F c -f vectis_backup_$(date +%Y%m%d).dump

Restore:

pg_restore -h localhost -U vectis -d vectis -c vectis_backup_20260401.dump

Continuous Archiving (WAL)¶

For point-in-time recovery, configure PostgreSQL WAL archiving:

1. Set wal_level = replica and archive_mode = on in postgresql.conf.
2. Configure archive_command to copy WAL files to S3 or a backup volume.
3. Use pg_basebackup for the initial base backup.
4. Restore to any point in time using recovery_target_time.

This is the recommended approach for production deployments where data loss must be minimized.

Media Files (Object Storage)¶

Uploaded media (product images, documents) is stored in S3-compatible object storage — the bundled RustFS container in local dev, Amazon S3 or another S3-compatible provider (via a storage extension) in production.

Replication¶

For production, use S3 cross-region replication (or your provider's server-side replication equivalent) to maintain copies in a secondary region.

Manual Backup¶

aws s3 sync s3://vectis-media ./media-backup/ --endpoint-url $S3_ENDPOINT

Or with the mc client, which works against any S3-compatible store — including the dev RustFS container:

mc alias set rustfs http://localhost:9000 rustfsadmin rustfsadmin
mc mirror rustfs/vectis-uploads ./media-backup/

Valkey¶

Valkey (Redis-compatible) stores sessions and cache. While losing Valkey is not catastrophic (sessions expire, cache rebuilds), you may want to persist session data:

• RDB snapshots — periodic point-in-time snapshots, the default Valkey behavior (Redis RDB format).
• AOF — append-only file for crash recovery with minimal data loss.

Temporal¶

Temporal stores workflow execution history in its own database (typically a separate PostgreSQL instance). Back up the Temporal database using the same pg_dump strategy.

Temporal data is required to resume in-progress workflows after a restore. Without it, running workflows are lost and must be manually re-triggered.

Search (Meilisearch + Typesense)¶

Vectis runs two co-equal search engines: Meilisearch for admin search and Typesense for the storefront. Both are derived stores — their indexes can be rebuilt from the primary database at any time:

python -m vectis.modules.search.indexer --reindex

The reindexer targets whichever engine each surface is configured to use, so a single reindex restores both admin (Meilisearch) and storefront (Typesense) indexes.

Backing up search data is optional since it can always be regenerated. For faster recovery, Meilisearch supports snapshot exports:

curl -X POST 'http://localhost:7700/snapshots' -H 'Authorization: Bearer $MEILISEARCH_API_KEY'

Typesense supports document export/import for the same purpose:

curl -H "X-TYPESENSE-API-KEY: $TYPESENSE_API_KEY" \
  'http://localhost:8108/collections/storefront_products/documents/export' > storefront_products.jsonl

Backup Schedule Recommendations¶

Disaster Recovery¶

1. Provision infrastructure — new database, Valkey, S3.
2. Restore PostgreSQL from latest backup.
3. Restore media from S3 replica.
4. Run Alembic — alembic upgrade head (idempotent, ensures schema is current).
5. Reindex search — rebuild both Meilisearch (admin) and Typesense (storefront) indexes from DB.
6. Start services — API, workers, consumers, frontends.
7. Verify — check { health } query, test a login, browse products.

DR Runbook¶

A full DR runbook lives in the application repo at vectis/docs/DR_RUNBOOK.md with:

• A reference pg_dump script at vectis/backend/scripts/backup_postgres.sh for daily logical backups
• A weekly verify procedure (vectis/backend/scripts/verify_backup_restore.py) that restores the latest dump into an ephemeral container and asserts a known-good state — catches silent backup corruption before you need it
• Step-by-step restoration procedures for each component (Postgres, Valkey, Redpanda, Temporal, Meilisearch, Typesense, object storage)
• Cross-region replication recipes (S3 → S3, Postgres logical replication, Redpanda mirror-maker)

Schedule the weekly verify as a Temporal cron — it's part of why you have backups at all.

Webhook Secret Rotation¶

Webhook signing secrets, gateway API keys, and any other Fernet-encrypted value stored in the settings table follow the rotation pattern in Deployment → Crypto Secrets. Include the current and rotating-from keys in your backup recovery procedure — without them, encrypted rows can't be decrypted after restore.