A replica is not a backup: it can faithfully copy accidental deletion or corruption. Protect PostgreSQL and pgvector with base backups plus WAL for point-in-time recovery, independent retention, restore drills, and documented recovery time and recovery point objectives. Replication and automated failover improve availability, but require lag, split-brain, extension, and client-reconnection planning.
Derived vectors may be rebuildable, but a full rebuild can violate RTO or provider budget. Source truth, model availability, pipeline version, and rebuild duration determine the policy.
Database data, roles/privileges as required, extension compatibility, schema migrations, configuration, and WAL needed for the recovery window. Store backup encryption keys and credentials separately. A logical dump is useful for portability but is not a complete substitute for physical PITR at large scale.
Read replicas can serve retrieval if acceptable lag is enforced. A newly ingested or revoked source may not yet appear, so read-after-write and access-revocation semantics need a primary route, lag gate, or visible-generation check. ANN indexes replicate through PostgreSQL's physical mechanisms, but provider behavior must be verified.
Run scheduled restore drills into an isolated environment. Choose a target time before a test deletion, recover, validate schema/roles/extensions, compare row and checksum counts, run vector plans, evaluate sample recall, and measure RPO/RTO. Rehearse primary failure and client reconnection separately.
Create a recovery plan for this PostgreSQL/pgvector system [inventory and objectives]. Separate backup, PITR, replicas, failover, and derived-state rebuild. Include encryption, extension versions, model dependencies, lag gates, restore validation, drill schedule, and RPO/RTO evidence.
Verification contract: A timed restore drill must recover a chosen point and pass authorization, row/checksum, query-plan, and retrieval-quality checks.