Sauvegardes et reprise après sinistre

# 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

L'état de AiHummer est petit et bien défini, ce qui rend les sauvegardes simples — tant que vous vous souvenez que le **la clé principale n'est pas dans la base de données** et doit être protégé indépendamment. Cette page couvre quoi sauvegarder, comment, et comment récupérer. ## Que sauvegarder Il y a trois choses indépendantes à protéger : | Quoi | Où | Pourquoi | |---|---|---| | **Base de données** | PostgreSQL | La source de vérité — agents, conversations, mémoire, paramètres, secrets chiffrés | | **Gouttes** | `AIHUMMER_BLOB_DIR` | Médias et pièces jointes référencés par la base de données | | **Clé passe-partout** | `AIHUMMER_MASTER_KEY` | Déchiffre le coffre-fort ; **jamais stocké dans la base de données** | > [!DANGER] > Sauvegarder `AIHUMMER_MASTER_KEY` **séparément** et le stocker ailleurs que > la sauvegarde de la base de données. Le coffre est chiffré par enveloppe sous cette clé — **perdre le > la clé principale et les secrets chiffrés sont irrécupérables**, même avec un parfait > sauvegarde de base de données. ## PostgreSQL est la source de vérité Traitez la base de données comme faisant autorité. La référence recommandée est une **quotidien `pg_dump`** plus **Archivage WAL pour la récupération à un point dans le temps (PITR)** ainsi vous pouvez avancer jusqu'à n'importe quel moment entre les sauvegardes. ```bash # Daily logical dump pg_dump "$AIHUMMER_DATABASE_URL" --format=custom --file=aihummer-$(date +%F).dump ``` Associez les dumps à l'archivage WAL continu (PITR) pour une récupération granulaire entre les snapshots. La mémoire d'Einstein vit aussi dans la base de données : le Markdown canonique lisible par l'homme (`MEMORY.md`) et le magasin de vecteurs v2 sont **projections** dérivé de celui-ci, et non de sources autoritaires séparées. ## Sauvegarde des blobs Les médias et les pièces jointes se trouvent sous `AIHUMMER_BLOB_DIR`. Sauvegardez ce répertoire en même temps que la base de données afin que les conversations restaurées puissent toujours retrouver leurs pièces jointes. Si `AIHUMMER_BLOB_DIR` n'est pas configuré, le service média/fichier n'est pas actif et il n'y a rien de supplémentaire à copier. ## Les commandes de sauvegarde et de restauration aihummer L'interface en ligne de commande regroupe la routine en deux commandes : ```bash aihummer backup [dir] # write a backup into [dir] aihummer restore <file> # restore from a backup file ``` Utilisez-les pour des sauvegardes et des restaurations opérationnelles ordinaires. Voir le [Référence CLI](/fr/v1.0/reference/cli) pour les commandes associées. > [!WARNING] > La restauration d'une base de données seule n'est pas une récupération complète. Restaurez également le répertoire des blobs. > et assurez-vous que le **même** `AIHUMMER_MASTER_KEY` est présent sur l'hôte cible — > sinon le coffre-fort ne peut pas être décrypté. ## Récupération après sinistre Pour un scénario de perte complète d'hôte, suivez le **manuel de reprise après sinistre** (`docs/runbooks/disaster-recovery.md`). L'ordre de recouvrement est : 1. Fournir un hôte et installer la même version d'AiHummer. 2. Restaurer le **clé maîtresse** dans `AIHUMMER_MASTER_KEY`. 3. Restaurer le **base de données** (dernier vidage, puis avancer via WAL/PITR si utilisé). 4. Restaurer le **répertoire de blobs** à `AIHUMMER_BLOB_DIR`. 5. Restaurer **configuration du module et artefacts** (les paramètres résident dans la base de données; restaurer tous les fichiers de configuration spécifiques aux modules à partir de votre sauvegarde). 6. Restaurer le **Fichiers de mémoire d'Einstein** — `MEMORY.md` et le Markdown canonique (la projection de mémoire) — dans leur répertoire (ou laissez-les être reconstruits à partir de base de données). 7. Si le sidecar de l'embedder est utilisé, restaurer le **magasin de vecteurs v2** (ou reconstruire les index de la base de données restaurée/Markdown). 8. Lancer les services (`aihummer up`) et vérifier avec `/readyz` et `deploy/host/smoke.sh`. > [!TIP] > Gardez aussi `AIHUMMER_MEDIA_TOKEN_SECRET` avec votre clé principale. Il reste signé > URL de téléchargement de médias valides lors des redémarrages et des reconstructions. ## Où aller ensuite - Sondes et test de fumée utilisés pour vérifier une restauration : [systemd et contrôles de santé](/fr/v1.0/operations/systemd-health). - Gestion des versions et migrations lors d'une mise à jour : [Politique de mise à niveau](/fr/v1.0/operations/upgrade-policy).