AiHummer
Română▾
AutentificareCont personal
v1.2.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Operare/Backup-uri și recuperare în caz de dezastru

Backup-uri și recuperare în caz de dezastru

v1.2.x · actualizat 2026-06-26

Starea lui AiHummer este mică și bine definită, ceea ce face ca copiile de rezervă să fie simple — atâta timp cât îți amintești că cheia principală nu se află în baza de date și trebuie protejat pe cont propriu. Această pagină acoperă ce să salvezi, cum să faci backup și cum să recuperezi.

Ce să faci backup

Există trei lucruri independente de protejat:

Ce Unde De ce
Bază de date PostgreSQL Sursa adevărului — agenți, conversații, memorie, setări, secrete criptate
Pete AIHUMMER_BLOB_DIR Media și atașamente de fișiere la care face referire baza de date
Cheie principală AIHUMMER_MASTER_KEY Decriptează seiful; niciodată stocat în baza de date

[!DANGER] Fă o copie de rezervă AIHUMMER_MASTER_KEY separat și să o depozitezi undeva în altă parte decât exportul bazei de date. Seiful este criptat în plic cu această cheie — pierde cheia principală și secretele criptate nu pot fi recuperate, chiar și cu un perfect copie de rezervă a bazei de date.

PostgreSQL este sursa adevărului

Tratați baza de date ca fiind autorizativă. Linia de bază recomandată este o zilnic pg_dump plus Arhivarea WAL pentru recuperare la un moment dat (PITR) astfel încât să poți avansa până la orice moment între dump-uri.

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

Asociați dump-urile cu arhivarea continuă WAL (PITR) pentru recuperare detaliată între snapshot-uri.

Memoria lui Einstein trăiește și în baza de date: Markdown-ul canonic lizibil de oameni (MEMORY.md) și magazinul de vectori v2 sunt proiecții derivat din acesta, nu din depozite autoritare separate.

Salvarea bloburilor

Fișierele media și atașamentele trăiesc sub AIHUMMER_BLOB_DIR. Faceți o copie de rezervă a acestui director împreună cu baza de date, astfel încât conversațiile restaurate să poată în continuare să acceseze atașamentele lor. Dacă AIHUMMER_BLOB_DIR nu este configurat, serviciul media/fișiere nu este activ și nu există nimic suplimentar de copiat.

Comenzile de backup și restaurare aihummer

CLI grupează rutina în două comenzi:

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

Folosiți acestea pentru copiile de siguranță și restaurările operaționale obișnuite. Consultați Referință CLI pentru comenzile aferente.

[!WARNING] O restaurare a bazei de date singură nu reprezintă o recuperare completă. Restaurează și directorul blob. și asigură-te că același AIHUMMER_MASTER_KEY este prezent pe gazda țintă — altfel, seiful nu poate fi decriptat.

Recuperare în caz de dezastru

Pentru un scenariu complet de pierdere a gazdei, urmați manual de recuperare în caz de dezastru (docs/runbooks/disaster-recovery.md). Ordinul de recuperare este:

  1. Provisionați un gazdă și instalați aceeași versiune AiHummer.
  2. Restabilește cheie principală în AIHUMMER_MASTER_KEY.
  3. Restabilește bază de date (ultima copie de siguranță, apoi avansează folosind WAL/PITR dacă sunt folosite).
  4. Restabilește director blob la AIHUMMER_BLOB_DIR.
  5. Restaurare configurarea modulului și artefacte (setările trăiesc în baza de date; restaurează orice fișiere de configurare specifice modulului din backup-ul tău).
  6. Restabilește Fișierele de memorie ale lui Einstein — MEMORY.md și Markdown-ul canonic (proiecția memoriei) — în directorul lor (sau lăsați-le să fie reconstruite din bază de date).
  7. Dacă se folosește sidecar-ul embedder, restaurați magazin de vectori v2 (sau reconstruiește indexurile din baza de date restaurată/Markdown).
  8. Ridică serviciile (aihummer up) și verifică cu /readyz și deploy/host/smoke.sh.

[!TIP] De asemenea, păstrează AIHUMMER_MEDIA_TOKEN_SECRET cu cheia ta principală. Ea păstrează semnat URL-urile de descărcare media valabile după reporniri și reconstruiri.

Unde următor?