Copia de seguridad y restauración

La copia de seguridad de un control plane tiene un trabajo más difícil que la mayoría: debe volver con su ledger con alteraciones detectables demostrablemente intacto. olivares dr está construido en torno a ese requisito — cada bundle registra las puntas de cadena por tenant, la restauración falla con código distinto de cero si el ledger restaurado no es seguro para la continuidad, y dr drill comprueba la continuidad del ledger del backup a la restauración sobre un ledger sintético en un directorio temporal e imprime el RTO medido. No comprueba concesiones, la custodia de claves ni los efectos posteriores al punto de restauración, y no toca un directorio de datos de producción.

El bundle se cifra bajo una KEK que tú proporcionas — una passphrase derivada con Argon2id (--passphrase-file) o una clave en bruto de 32 bytes de tu KMS (--kek-key-file); se requiere exactamente una. Las claves de firma de auditoría y de catálogo viajan selladas dentro del bundle.

El control de restauración de DR registrado admite PostgreSQL 15, 16, 17 y 18 en 26.10 (medido en 15.19, 16.15, 17.11 y 18.6). Las demás versiones principales se rechazan con DR restore control contract: PostgreSQL major <major> is unsupported (verified contracts: 15, 16, 17, 18), donde <major> es la versión principal detectada del servidor. Un control nunca se repara: tras actualizar la instalación existente a una nueva versión principal, se rechaza un control que no coincida con el catálogo y los permisos de esa versión.

Hacer la copia de seguridad

SQLite (nodo único) — segura mientras serve está en ejecución (el snapshot usa VACUUM INTO; el WAL permite la lectura concurrente):

olivares dr backup \
  --data-dir /var/lib/olivares --engine sqlite \
  --out /backups/olivares-dr-$(date -u +%Y%m%dT%H%M%SZ).drbundle \
  --passphrase-file <your-dr-passphrase-file>

Postgres — un pg_dump --format=custom consistente impulsado por el mismo comando (--engine postgres --dsn … --admin-dsn …), o entrégale un dump prefabricado con --snapshot-file. Ejecutar el dump directamente requiere --admin-dsn: pg_dump mantiene row_security=off y aborta como rol de aplicación contra las tablas FORCE ROW LEVEL SECURITY, así que el comando rechaza de entrada en vez de no producir nada. Para un RPO casi nulo, --pitr-ref produce un bundle compañero de claves+manifiesto que se empareja con tu configuración PITR de archivado de WAL (deploy/postgres/backup/pitr-setup.md); los scripts envoltorio deploy/postgres/backup/pg-dump.sh / pg-restore.sh empaquetan el mismo flujo.

Dos interruptores de honestidad que conviene conocer:

• La copia de seguridad se niega a capturar un ledger que no verifica en el momento del backup — --allow-unverified existe, queda registrado y no se recomienda.
• Con un snapshot prefabricado (--snapshot-file/--pitr-ref) y sin --admin-dsn (un rol dedicado NOSUPERUSER BYPASSRLS), la copia advierte de que el conjunto de tenants capturado puede estar limitado por RLS e incompleto — el dump en sí es correcto; lo que necesita el rol de administrador es el inventario cross-tenant del manifiesto. (Ejecutar pg_dump directamente es un caso distinto: se rechaza de plano, ver arriba.)

Programación: el stack de Compose incluye un perfil de backup, el chart de Helm un CronJob; en bare metal, programa con cron el comando de arriba. Las cifras de la tabla son objetivos. En los niveles con cron, el RPO objetivo es el intervalo de cron. dr drill mide el RTO de SQLite sobre un ledger sintético (restauración, arranque y verificación). No mide el RPO y no mide una restauración de Postgres. Los RTO de SQLite medidos, con su número de eventos y el host, están en docs/DR-RUNBOOK.md; no son los objetivos de esta tabla.

Nivel	Mecanismo	RPO objetivo	RTO objetivo
SQLite	dr backup con cron	el intervalo de cron	< 15 min
Postgres lógico	pg-dump.sh con cron	el intervalo de cron	< 30 min
Postgres PITR	base backup + archivado de WAL	≈ segundos	< 30 min

Refleja los bundles fuera del sitio y mantén la KEK separada de los bundles (3-2-1): una copia en el mismo host no es recuperación ante desastres, y un bundle que viaja con su passphrase no está cifrado en ningún sentido que importe.

Simulacro — antes de necesitarlo

dr verify comprueba un bundle sin tocar tu directorio de datos. En SQLite lo restaura en un directorio temporal y verifica la continuidad del ledger, y sale con código distinto de cero si esa comprobación falla. En Postgres comprueba el digest del bundle y que las claves se descifran. La verificación completa de la cadena de un bundle Postgres necesita una restauración sobre un Postgres temporal. Ejecuta la comprobación con:

olivares dr verify --in /backups/olivares-dr-<ts>.drbundle \
  --passphrase-file <your-dr-passphrase-file>

dr inspect --in <bundle> imprime el manifiesto (sin necesidad de KEK, sin mostrar secretos) — qué motor, qué tenants, qué puntas de cadena. Ejecuta el simulacro con la misma cadencia que la copia de seguridad; un backup no verificado es una esperanza, no un control.

Restaurar

olivares dr restore --in /backups/olivares-dr-<ts>.drbundle \
  --data-dir /var/lib/olivares --engine sqlite \
  --passphrase-file <your-dr-passphrase-file>

La secuencia de restauración es deliberada: primero las claves de firma (fail-closed al sobrescribir — --force es la anulación explícita), luego el snapshot del store, y después arranca el store restaurado y demuestra la continuidad del ledger, saliendo con código distinto de cero si la cadena no es segura. Tras cualquier restauración, vuelve a verificar contra tu pin de checkpoint fuera de banda — un snapshot más antiguo restaurado puede pasar un recorrido ingenuo y aun así fallar la comparación fuera de banda (troubleshooting § ledger).

Las dos claves que lo deciden todo

Clave	Regla
La DR KEK (passphrase o clave en bruto)	sin ella todo bundle es ruido. Guárdala en un sistema distinto al de los bundles; perder ambas a la vez es el modo de fallo
audit-signing.key (en el directorio de datos)	haz una copia fuera de banda en el aprovisionamiento — el motor solo advierte en el primer arranque, no hay escrow obligatorio, y una clave perdida deja el ledger permanentemente inverificable. Fija también la clave pública fuera de banda (GET /v1/audit/pubkey)

Para la custodia basada en KMS de las propias claves de firma (envelopes BYOK, ceremonias de rotación, olivares keys), consulta la referencia de la CLI; para los recorridos de los modos de fallo, la página de troubleshooting.