Copii de rezervă și recuperare în caz de dezastru

# 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

Starea AiHummer este mică și bine definită, ceea ce face copiile de rezervă simple — atâta timp cât îți amintești că **cheia principală nu se află în baza de date** și trebuie protejată separat. Această pagină acoperă ce să copiezi, cum și cum să recuperezi. ## Ce să copiezi Există trei lucruri independente de protejat: | Ce | Unde | De ce | |---|---|---| | **Baza de date** | PostgreSQL | Sursa adevărului — agenți, conversații, memorie, setări, secrete criptate | | **Blob-uri** | `AIHUMMER_BLOB_DIR` | Media și atașamentele de fișiere referite de baza de date | | **Cheia principală** | `AIHUMMER_MASTER_KEY` | Decriptează seiful; **niciodată stocată în baza de date** | > [!DANGER] > Fă o copie de rezervă pentru `AIHUMMER_MASTER_KEY` **separat** și stoch-o în alt > loc decât dump-ul bazei de date. Seiful este criptat prin plic sub această cheie > — **pierde cheia principală și secretele criptate devin nerecuperabile**, chiar > și cu o copie de rezervă perfectă a bazei de date. ## PostgreSQL este sursa adevărului Tratează baza de date ca fiind autoritativă. Baza recomandată este un **`pg_dump` zilnic** plus **arhivare WAL pentru recuperare la un moment în timp (PITR)**, astfel încât să poți rula înainte până la orice moment dintre dump-uri. ```bash # Daily logical dump pg_dump "$AIHUMMER_DATABASE_URL" --format=custom --file=aihummer-$(date +%F).dump ``` Asociază dump-urile cu arhivarea WAL continuă (PITR) pentru o recuperare granulară între instantanee. ## Copia de rezervă a blob-urilor Media și atașamentele de fișiere se află sub `AIHUMMER_BLOB_DIR`. Fă o copie de rezervă pentru acest director împreună cu baza de date, astfel încât conversațiile restaurate să își poată rezolva în continuare atașamentele. Dacă `AIHUMMER_BLOB_DIR` nu este configurat, serviciul media/fișiere nu este activ și nu există nimic suplimentar de copiat. ## Comenzile aihummer backup și restore Interfața de linie de comandă grupează rutina în două comenzi: ```bash aihummer backup [dir] # write a backup into [dir] aihummer restore <file> # restore from a backup file ``` Folosește-le pentru copiile de rezervă și restaurările operaționale obișnuite. Consultă [referința CLI](/ro/v1.0/reference/cli) pentru comenzi conexe. > [!WARNING] > O restaurare doar a bazei de date nu este o recuperare completă. Restaurează și > directorul de blob-uri și asigură-te că **aceeași** `AIHUMMER_MASTER_KEY` este > prezentă pe gazda țintă — altfel seiful nu poate fi decriptat. ## Recuperare în caz de dezastru Pentru un scenariu de pierdere completă a gazdei, urmează **runbook-ul de recuperare în caz de dezastru** (`docs/runbooks/disaster-recovery.md`). Ordinea de recuperare este: 1. Aprovizionează o gazdă și instalează aceeași versiune AiHummer. 2. Restaurează **cheia principală** în `AIHUMMER_MASTER_KEY`. 3. Restaurează **baza de date** (cel mai recent dump, apoi rulează înainte prin WAL/PITR dacă este folosit). 4. Restaurează **directorul de blob-uri** la `AIHUMMER_BLOB_DIR`. 5. Pornește serviciile (`aihummer up`) și verifică cu `/readyz` și `deploy/host/smoke.sh`. > [!TIP] > Păstrează și `AIHUMMER_MEDIA_TOKEN_SECRET` împreună cu cheia principală. > Menține valide URL-urile semnate de descărcare media între reporniri și > reconstruiri. ## Unde mergi mai departe - Sondele și testul de fum folosite pentru a verifica o restaurare: [systemd și verificări de sănătate](/ro/v1.0/operations/systemd-health). - Versionarea și migrările în timpul unei actualizări: [Politica de actualizare](/ro/v1.0/operations/upgrade-policy).