Copias de seguridad y recuperación ante desastres

# Daily logical dump
pg_dump "$AIHUMMER_DATABASE_URL" --format=custom --file=aihummer-$(date +%F).dump

aihummer backup [dir]      # write a backup into [dir]
aihummer restore <file>    # restore from a backup file

El estado de AiHummer es pequeño y bien definido, lo que hace que las copias de seguridad sean sencillas, siempre y cuando recuerdes que el **la llave maestra no está en la base de datos** y debe ser protegido por sí mismo. Esta página cubre qué respaldar, cómo, y cómo recuperar. ## Qué respaldar Hay tres cosas independientes que proteger: | Qué | Dónde | ¿Por qué? | |---|---|---| | **Base de datos** | PostgreSQL | La fuente de la verdad — agentes, conversaciones, memoria, configuraciones, secretos encriptados | | **Motas** | `AIHUMMER_BLOB_DIR` | Medios y archivos adjuntos referenciados por la base de datos | | **Llave maestra** | `AIHUMMER_MASTER_KEY` | Descifra la bóveda; **nunca almacenado en la base de datos** | > [!DANGER] > Hacer una copia de seguridad `AIHUMMER_MASTER_KEY` **por separado** y guárdalo en algún lugar diferente de > el volcado de la base de datos. La bóveda está cifrada en un sobre con esta clave — **pierde el > la llave maestra y los secretos cifrados son irrecuperables**, incluso con un perfecto > copia de seguridad de la base de datos. ## PostgreSQL es la fuente de la verdad Trata la base de datos como autoritaria. La línea base recomendada es una **diaria `pg_dump`** más **Archivado WAL para recuperación en un punto en el tiempo (PITR)** así que puedes avanzar hasta cualquier momento entre volcados. ```bash # Daily logical dump pg_dump "$AIHUMMER_DATABASE_URL" --format=custom --file=aihummer-$(date +%F).dump ``` Combina los volcados con el archivado WAL continuo (PITR) para una recuperación detallada entre instantáneas. La memoria de Einstein también vive en la base de datos: el Markdown canónico legible por humanos (`MEMORY.md`) y la tienda de vectores v2 son **proyecciones** derivado de ello, no de almacenes autoritativos separados. ## Respaldando blobs Los medios y archivos adjuntos se encuentran bajo `AIHUMMER_BLOB_DIR`. Haz una copia de seguridad de este directorio junto con la base de datos para que las conversaciones restauradas aún puedan resolver sus archivos adjuntos. Si `AIHUMMER_BLOB_DIR` no está configurado, el servicio de medios/archivos no está activo y no hay nada extra que copiar. ## Los comandos de respaldo y restauración de aihummer La CLI agrupa la rutina en dos comandos: ```bash aihummer backup [dir] # write a backup into [dir] aihummer restore <file> # restore from a backup file ``` Utilice estos para copias de seguridad y restauraciones operativas ordinarias. Vea el [Referencia de CLI](/es/v1.0/reference/cli) para comandos relacionados. > [!WARNING] > Restaurar solo una base de datos no es una recuperación completa. Restaura también el directorio de blobs. > y asegúrate de que **lo mismo** `AIHUMMER_MASTER_KEY` está presente en el host de destino — > de lo contrario, la bóveda no se puede descifrar. ## Recuperación ante desastres Para un escenario de pérdida total del anfitrión, siga el **manual de recuperación ante desastres** (`docs/runbooks/disaster-recovery.md`). La orden de recuperación es: 1. Provisione un host e instale la misma versión de AiHummer. 2. Restaurar el **llave maestra** en `AIHUMMER_MASTER_KEY`. 3. Restaurar el **base de datos** (último volcado, luego avanzar mediante WAL/PITR si se utiliza). 4. Restaurar el **directorio de blobs** en `AIHUMMER_BLOB_DIR`. 5. Restaurar **configuración de módulo y artefactos** (las configuraciones viven en la base de datos; restaurar cualquier archivo de configuración específico del módulo desde tu copia de seguridad). 6. Restaurar el **Archivos de memoria de Einstein** — `MEMORY.md` y el Markdown canónico (la proyección de la memoria) — en su directorio (o dejar que se reconstruyan a partir de la base de datos). 7. Si se utiliza el sidecar del embeber, restaure el **almacén de vectores v2** (o reconstruir los índices de la base de datos restaurada/Markdown). 8. Levantar servicios (`aihummer up`) y verificar con `/readyz` y `deploy/host/smoke.sh`. > [!TIP] > También mantener `AIHUMMER_MEDIA_TOKEN_SECRET` con tu llave maestra. Mantiene firmado > URLs de descarga de medios válidas a través de reinicios y reconstrucciones. ## ¿A dónde vamos ahora? - Sondas y la prueba de humo utilizadas para verificar una restauración: [systemd y controles de salud](/es/v1.0/operations/systemd-health). - Control de versiones y migraciones durante una actualización: [Política de actualización](/es/v1.0/operations/upgrade-policy).