Kopie zapasowe i odzyskiwanie po awarii

v1.1.x · zaktualizowany 2026-06-26

Stan AiHummera jest mały i dobrze zdefiniowany, co sprawia, że tworzenie kopii zapasowych jest proste — o ile pamiętasz, że klucz główny nie znajduje się w bazie danych i musi być chronione osobno. Ta strona omawia, co należy kopiować, jak to robić i jak odzyskać dane.

Co wykonać kopię zapasową

Są trzy niezależne rzeczy do ochrony:

Co	Gdzie	Dlaczego
Baza danych	PostgreSQL	Źródło prawdy — agenci, rozmowy, pamięć, ustawienia, zaszyfrowane tajemnice
Kształty	`AIHUMMER_BLOB_DIR`	Multimedia i załączniki plików odwołujące się do bazy danych
Klucz główny	`AIHUMMER_MASTER_KEY`	Odszyfrowuje skarbiec; nigdy nie przechowywane w bazie danych

[!DANGER] Utwórz kopię zapasową AIHUMMER_MASTER_KEY osobno i przechowywać to gdzie indziej niż zrzut bazy danych. Skarbiec jest zaszyfrowany w kopercie tym kluczem — stracić klucz główny i zaszyfrowane sekrety są nie do odzyskania, nawet z doskonałym kopia zapasowa bazy danych.

PostgreSQL jest źródłem prawdy

Traktuj bazę danych jako autorytatywną. Zalecana baza odniesienia to codzienny pg_dump plus Archiwizacja WAL w celu odzyskiwania do określonego punktu w czasie (PITR) więc możesz przewinąć do przodu do dowolnego momentu między zrzutami.

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

Sparuj zrzuty z ciągłym archiwizowaniem WAL (PITR) w celu precyzyjnego przywracania między migawkami.

Pamięć Einsteina żyje również w bazie danych: czytelny dla człowieka kanoniczny Markdown (MEMORY.md) i magazyn wektorów v2 są projekcje pochodzące z niego, a nie z odrębnych autorytatywnych źródeł.

Tworzenie kopii zapasowych blobów

Media i załączniki plików znajdują się pod AIHUMMER_BLOB_DIR. Utwórz kopię zapasową tego katalogu wraz z bazą danych, aby przywrócone rozmowy mogły nadal odnajdywać swoje załączniki. Jeśli AIHUMMER_BLOB_DIR nie jest skonfigurowany, usługa mediów/pliku nie jest aktywna i nie ma nic dodatkowego do skopiowania.

Polecenia aihummer do tworzenia kopii zapasowej i przywracania

CLI grupuje rutynę w dwóch poleceniach:

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

Używaj ich do zwykłych kopii zapasowych i przywracania operacyjnego. Zobacz Odwołanie CLI dla powiązanych poleceń.

[!WARNING] Samo przywrócenie bazy danych nie stanowi pełnego odzyskiwania. Przywróć również katalog blobów. i upewnij się, że to samo AIHUMMER_MASTER_KEY jest obecny na docelowym hoście — w przeciwnym razie skarbiec nie może zostać odszyfrowany.

Odzyskiwanie po katastrofie

W przypadku pełnego scenariusza utraty hosta, postępuj zgodnie z podręcznik odzyskiwania po awarii (docs/runbooks/disaster-recovery.md). Nakaz odzyskania jest:

Przydziel hosta i zainstaluj tę samą wersję AiHummer.
Przywróć klucz główny do AIHUMMER_MASTER_KEY.
Przywróć baza danych (najświeższy zrzut, następnie odtwórz za pomocą WAL/PITR, jeśli używane).
Przywróć katalog blobów w AIHUMMER_BLOB_DIR.
Przywróć konfiguracja modułu i artefakty (ustawienia znajdują się w bazie danych; przywróć wszystkie pliki konfiguracyjne specyficzne dla modułu z kopii zapasowej).
Przywróć Pliki pamięci Einsteina — MEMORY.md i kanoniczny Markdown (projekcja pamięci) — do ich katalogu (lub pozwól im być odbudowane z baza danych).
Jeśli używany jest sidecar osadnika, przywróć sklep wektorowy v2 (lub przebudować indeksy z przywróconej bazy danych/Markdown).
Uruchom usługi (aihummer up) i zweryfikować z /readyz i deploy/host/smoke.sh.

[!TIP] Również zachowaj AIHUMMER_MEDIA_TOKEN_SECRET za pomocą Twojego klucza głównego. Zachowuje podpisane adresy URL pobierania mediów ważne po ponownych uruchomieniach i przebudowach.

Dokąd dalej

Sondujące urządzenia i test dymny używane do weryfikacji przywracania: systemd i kontrole stanu.
Wersjonowanie i migracje podczas aktualizacji: Polityka aktualizacji.