Gotowość do odzyskiwania

Libre WebUI oferuje tylko do odczytu inwentaryzację odzyskiwania jako pierwszą bramkę bezpieczeństwa kopii zapasowych i odtwarzania. Raportuje znany stan oraz wykryte warunki blokujące migawkę. Nie uzyskuje blokady konserwacyjnej i nie kopiuje, szyfruje, przesyła, usuwa, naprawia ani odtwarza danych.

libre-webui recovery-check --json > recovery-inventory.json

W kopii źródeł uruchom raz npm run build:backend i zastąp libre-webui recovery-check poleceniem npm run recovery:check --. Instalacje npx i Homebrew domyślnie sprawdzają ~/.libre-webui; DATA_DIR i jawne opcje ścieżek nadpisują tę lokalizację.

Polecenie kończy się kodem 0, gdy nie ma blokad, 1, gdy raport jest pełny, ale istnieją blokady odzyskiwania, oraz 2 dla błędnych argumentów lub niespodziewanej awarii zbierania. Użyj --data-dir PATH lub --database PATH, aby sprawdzić inną lokalizację. Domyślna inwentaryzacja woluminu lub --data-dir przyjmuje wyłącznie kanoniczny plik DATA_DIR/data.sqlite i odrzuca twarde dowiązania, dowiązania symboliczne oraz nieregularne wpisy bazy/WAL/SHM. Jawna ścieżka --database może znajdować się poza DATA_DIR, ale baza i pliki towarzyszące nadal muszą być zwykłymi plikami i nie mogą być dowiązaniami symbolicznymi. Gdy --database jest używane bez --data-dir, katalog nadrzędny bazy staje się katalogiem danych, aby wspólnie zinwentaryzować klucz, bloby i definicje wtyczek.

Środowisko odczytuje też historyczne definicje wtyczek z deterministycznego katalogu plugins pakietu backendu oraz, przy względnym PLUGINS_DIR, z historycznej lokalizacji względem backendu. Odzyskiwanie inwentaryzuje aktywne stare ścieżki i blokuje migawkę samego woluminu, jeśli zawierają definicje niestandardowe. Wdrożenia pakietowe mogą wielokrotnie przekazać --legacy-plugins-dir PATH, gdy układ obrazu przenosi te katalogi zgodności.

Dla prywatnego wdrożenia Compose uruchom kontrolę wewnątrz wdrożonego kontenera, aby raport opisywał jego zamontowany wolumin, kod i sekrety:

docker exec libre-webui \
  libre-webui recovery-check --json --data-dir /app/backend/data

Co sprawdza inwentaryzacja

Wersjonowany raport JSON zapisuje:

• wersje aplikacji, Node.js, systemu operacyjnego i architektury;
• rozmiary SQLite i WAL/SHM, quick_check, walidację kluczy obcych, odcisk schematu, wersję użytkownika, brakujące wymagane tabele i kontrolę pliku źródłowego bez podążania za dowiązaniami przed utworzeniem prywatnej migawki inspekcyjnej;
• czytelność, zapisywalność, liczbę plików i bajtów katalogu danych;
• wybrane źródło klucza szyfrowania i nieodwracalny 16-znakowy odcisk;
• walidację trwałego .encryption_key bez podążania za dowiązaniami i z pojedynczym dowiązaniem;
• obecność, liczbę, rozmiary i umieszczenie w katalogu danych niestandardowych definicji wtyczek oraz zaszyfrowany lokalny katalog blobów, osadzone media, referencje głosowe, tekst dokumentów, stare wektory dokumentów i wektory platformy z wierszami ACL/filtrów;
• ograniczone, tylko do odczytu uwierzytelnienie każdego kanonicznego lokalnego obiektu blob i osadzonej obwiedni wektora platformy, z pełną weryfikacją fragmentów/sum kontrolnych blobów oraz dostępności kluczy;
• ograniczone, tylko do odczytu uwierzytelnienie każdej rozpoznawalnej starej obwiedni tekstowej AES-GCM w czatach, notatkach, dokumentach, preferencjach, sekretach wtyczek, stanie galerii/mediów i e-mailach kont oraz każdej związanej z AAD obwiedni nazwy głosu, nagrania i transkrypcji;
• liczbę zadań/wykonań/podglądów Work oraz oczekiwane woluminy Docker, PVC Kubernetes lub skrócone tożsamości ścieżek hosta; wolumin Docker musi mieć etykietę zarządzaną i dokładny identyfikator zadania właściciela;
• stany starych zadań generowania mediów oraz trwałe zadania według stanu, próby według wyniku, strumienie i liczbę zdarzeń oraz ostatni globalny kursor;
• ograniczone uwierzytelnienie zaszyfrowanych trwałych ładunków zadań i zdarzeń oraz ograniczoną kontrolę składni nieprzezroczystych ładunków referencji; oraz
• jawne blokady, ostrzeżenia i dane znajdujące się poza katalogiem aplikacji.

Raport nigdy nie zawiera kluczy szyfrowania, sekretów JWT/sesji, poświadczeń dostawców, treści wtyczek, treści użytkowników ani literalnych ścieżek obszarów hosta. Emituje tylko informacje o obecności sekretów i nieodwracalny odcisk klucza.

Montowanie danych tylko do odczytu jest prawidłowe dla inspekcji i powoduje ostrzeżenie, nie blokadę. Gotowość aplikacji nadal wymaga zapisywalnego magazynu; nigdy nie uruchamiaj Libre WebUI na migawce tylko do odczytu używanej przez narzędzie kopii.

Blokady

Każdą blokadę traktuj jako nieudaną bramkę. Typowe przyczyny to brakująca lub uszkodzona baza, niepełny schemat, brakujący lub sprzeczny klucz, uszkodzony albo nieuwierzytelniony stary lub platformowy szyfrogram, przekroczone limity weryfikacji, nieczytelny katalog danych, dowiązane lub nieregularne źródło SQLite, aktywne wykonania lub podglądy Work, zadania mediów lub zadania trwałe, brakujący lub błędnie oznaczony obszar Work, niezgodne głowy strumieni trwałych zdarzeń lub luki sekwencji, niestandardowe wtyczki poza katalogiem danych albo płaszczyzna sterowania, która nie może zweryfikować zewnętrznych obszarów. Wycisz aktywną pracę i usuń brakujące zależności przed migawką; nie edytuj raportu, aby ukryć blokadę.

Zaszyfrowane trwałe ładunki są uwierzytelniane względem tożsamości zadania/zdarzenia i walidowane jako kanoniczny ograniczony JSON. Nieprzezroczyste referencje są tylko ograniczane i sprawdzane składniowo: obecna warstwa nie ma autorytatywnego repozytorium referencji blobów, które pozwoliłoby dowieść istnienia lub dostępu do celu. Raport ustawia referenceTargetsVerified na false i ostrzega przy takich referencjach; nigdy nie ujawnia ich wartości ani ładunku.

Stare pola tekstowe poprzedzają obowiązkowy znacznik obwiedni, dlatego prawdziwe jawne wiersze ze starszych schematów pozostają czytelne i nie są raportowane jako uwierzytelniony szyfrogram. Kanoniczne obwiednie są zawsze uwierzytelniane; trójczęściowe wartości z IV lub tagiem szerokości obwiedni przy błędnym formacie kończą się zamknięciem. Pola zapisanych głosów mają jednoznaczną obwiednię binarną i zawsze muszą uwierzytelnić profil, właściciela i tożsamość pola. Sekcja JSON encryption.legacyCiphertext raportuje sumy rekordów i bajtów bez ujawniania tekstu jawnego.

Gdy istnieje kolumna users.email_lookup schematu v4, odzyskiwanie uwierzytelnia każdy niepusty e-mail i ponownie oblicza jego odseparowany domenowo token wyszukiwania. Brak lub rozbieżność tokenu albo token przy pustym e-mailu blokuje migawkę. Bazy sprzed v4 pozostają zgodne, ponieważ nie mają tej kolumny pochodnej.

Bieżąca granica kopii zapasowej

Narzędzie prywatnego wdrożenia zatrzymuje działającą aplikację i używa niezmiennego obrazu kontenera, zamontowanego woluminu oraz środowiska do utworzenia zintegrowanego archiwum solo. Manifest jest podpisany Ed25519, a cały ładunek zaszyfrowany kluczem kopii AES-256-GCM przechowywanym przez operatora. Zawiera SQLite, lokalne bloby i osadzone wektory, selektory środowiska oraz chronioną konfigurację potrzebną do odszyfrowania stanu. Narzędzie sprawdza podpis, sumę szyfrogramu i odszyfrowany ładunek przed publikacją archiwum i raportu. libre-webui-restore przyjmuje tylko nowy wolumin Docker, sprawdza odszyfrowaną inwentaryzację przed kopiowaniem danych i publikuje odzyskaną konfigurację jako prywatne pliki w nowym katalogu docelowym.

Chroniona konfiguracja obejmuje pulę PostgreSQL oraz limity połączenia, bezczynności, instrukcji i blokady migracji; limit połączenia Redis; oba ustawienia kwot blobów; selektory platformy; prefiks S3 i tryb adresowania. Wartości znajdują się w podpisanym i zaszyfrowanym ładunku, nie w jawnym manifeście, i przy odtworzeniu są publikowane jako konfiguracja z trybem 0600.

Archiwum solo nie obejmuje woluminów Work Docker, PVC Kubernetes, katalogów obszarów związanych z hostem, modeli Ollama ani stanu zewnętrznych dostawców. Zachowaj wyłączenia w podpisanym manifeście i osobno wykonuj migawki zewnętrznego Work. Profil team używa oddzielnego przepływu offline: eksport PostgreSQL, dokładne wersjonowane obiekty szyfrogramu S3, inwentaryzacja PGVector, konfiguracja i tożsamość klucza są zamykane w tym samym podpisanym/zaszyfrowanym formacie i sprawdzane na czystym celu PostgreSQL/S3. Pamięć Redis, obecność, budzenia i dzierżawy są odbudowywane z kanonicznego SQL.

Kopia team uwierzytelnia też każdy ograniczony zaszyfrowany ładunek zadania i zdarzenia w dokładnym eksporcie PostgreSQL. Chroniona podpisana inwentaryzacja zapisuje sumy zadań, zdarzeń, strumieni, kursorów, obwiedni, referencji i uwierzytelnionego tekstu jawnego. Każdy strumień musi zawierać dokładnie ciągłą sekwencję 1..last_sequence, a globalna sekwencja kursora PostgreSQL nie może pozostawać za największym zapisanym kursorem. Odtwarzanie powtarza kontrole na czystym celu i wymaga pełnej zgodności z podpisanym źródłem. Luki między różnymi globalnymi kursorami są dozwolone, ponieważ alokacja tożsamości PostgreSQL nie jest transakcyjna; ciągłość obowiązuje w strumieniu.

Gdy PLUGINS_DIR wskazuje poza DATA_DIR, odzyskiwanie inwentaryzuje dokładny katalog i oznacza go jako wyłączony z archiwum woluminu aplikacji. Definicje tam blokują migawkę samego woluminu, dopóki operator nie zorganizuje odpowiedniej kopii katalogu. To samo dotyczy aktywnych starych katalogów. Dowiązania symboliczne, pliki nieregularne lub nieczytelne definicje JSON zawsze blokują i nigdy nie są śledzone ani pomijane.

Trwałe zadania i uporządkowane zdarzenia są aktywne w obu profilach. Odzyskiwanie blokuje się podczas aktywnej próby zadania lub wykonania Work, waliduje ładunki i ciągłość głów strumieni oraz zachowuje kanoniczny stan SQL. Solo uruchamia ograniczonego workera wbudowanego; team uruchamia te same procedury w workerze zewnętrznym i używa Redis wyłącznie do budzenia i rozsyłania.

W produkcji przechowuj klucze szyfrowania i sekrety JWT w chronionym menedżerze, archiwa poza hostem i zaszyfrowane oraz testuj odtwarzanie w czystym zgodnym środowisku. Inwentaryzacja to migawka znanego stanu przed operacją, a nie blokada konserwacyjna ani niezależny dowód odtwarzalności każdego zasobu zewnętrznego.

Polecenia podpisanej i zaszyfrowanej kopii

Poniższe przykłady używają zainstalowanego libre-webui z globalnego npm lub Homebrew. Bez instalacji globalnej zastąp je npx --yes libre-webui@latest. W kopii źródeł zbuduj backend raz i zastąp libre-webui backup przez npm run recovery:backup --. Produkcyjny obraz Docker udostępnia to samo polecenie w /usr/local/bin/libre-webui. Kopia i odtwarzanie team wymagają także pg_dump i pg_restore PostgreSQL 16; są w obrazie produkcyjnym i ścieżce formuły Homebrew. Przed użyciem z npm/npx zainstaluj zgodnego klienta PostgreSQL.

Wygeneruj klucz archiwum AES-256-GCM i parę podpisującą Ed25519 w prywatnym katalogu, a następnie przenieś klucze prywatne do chronionego magazynu poza hostem:

install -d -m 0700 /absolute/private/libre-backup-keys
libre-webui backup keygen \
  --directory /absolute/private/libre-backup-keys

Dla wyciszonego katalogu solo utwórz i niezależnie sprawdź archiwum:

libre-webui backup create \
  --offline \
  --data-dir /absolute/path/to/libre-data \
  --output /absolute/backups/libre-solo.lwbackup \
  --encryption-key /absolute/private/libre-backup-keys/backup-encryption.key \
  --signing-private-key /absolute/private/libre-backup-keys/backup-signing-private.pem

libre-webui backup verify \
  --archive /absolute/backups/libre-solo.lwbackup \
  --encryption-key /absolute/private/libre-backup-keys/backup-encryption.key \
  --signing-public-key /absolute/private/libre-backup-keys/backup-signing-public.pem

Najpierw przeprowadź kontrolę odtwarzania, a zastosuj je wyłącznie do nowego, pustego katalogu:

libre-webui backup restore-preflight \
  --archive /absolute/backups/libre-solo.lwbackup \
  --target /absolute/restore/libre-data \
  --encryption-key /absolute/private/libre-backup-keys/backup-encryption.key \
  --signing-public-key /absolute/private/libre-backup-keys/backup-signing-public.pem

libre-webui backup restore-apply \
  --archive /absolute/backups/libre-solo.lwbackup \
  --target /absolute/restore/libre-data \
  --encryption-key /absolute/private/libre-backup-keys/backup-encryption.key \
  --signing-public-key /absolute/private/libre-backup-keys/backup-signing-public.pem

libre-webui backup restore-verify \
  --target /absolute/restore/libre-data

Dla team zatrzymaj wszystkie repliki i workery, pozostaw załadowane środowisko PostgreSQL/S3/keyring źródła i utwórz skoordynowane archiwum:

libre-webui backup create-team \
  --offline \
  --output /absolute/backups/libre-team.lwbackup \
  --encryption-key /absolute/private/libre-backup-keys/backup-encryption.key \
  --signing-private-key /absolute/private/libre-backup-keys/backup-signing-private.pem

Przed odtworzeniem załaduj zmienne dla oddzielnej pustej bazy PostgreSQL i pustego wersjonowanego zasobnika S3. Kontrola sprawdza podpis, zaszyfrowane archiwum i chronioną inwentaryzację oraz dowodzi pustki bazy i prefiksu bez publikowania danych. Zastosowanie odtwarza czyste cele, sprawdza schemat PostgreSQL, dokładne obiekty S3 i rekordy PGVector oraz zapisuje chronioną konfigurację do nowego prywatnego katalogu:

libre-webui backup restore-team-preflight \
  --archive /absolute/backups/libre-team.lwbackup \
  --encryption-key /absolute/private/libre-backup-keys/backup-encryption.key \
  --signing-public-key /absolute/private/libre-backup-keys/backup-signing-public.pem

libre-webui backup restore-team-apply \
  --archive /absolute/backups/libre-team.lwbackup \
  --configuration-output /absolute/restore/libre-team-config \
  --encryption-key /absolute/private/libre-backup-keys/backup-encryption.key \
  --signing-public-key /absolute/private/libre-backup-keys/backup-signing-public.pem

Nigdy nie kieruj odtwarzania na bazę lub zasobnik źródłowy, istniejący katalog danych ani katalog konfiguracji zawierający pliki. Przechowuj klucz publiczny podpisu z procedurą odtwarzania; samo archiwum i klucz publiczny nie pozwalają odszyfrować ładunku.

Jeśli odtwarzanie team zgłasza niepełne wycofanie, traktuj oba cele jako zanieczyszczone i nie ponawiaj od razu. Sprawdź i wyczyść bazę PostgreSQL, a następnie wypisz i usuń każdą wersję obiektu oraz znacznik usunięcia pod dokładnym prefiksem S3. Ponownie uruchom restore-team-preflight; zastosowanie jest bezpieczne dopiero po udanej kontroli czystego celu.

Zaplanowane, zweryfikowane ćwiczenia odzyskiwania

Kopie, których nigdy nie odtworzono, są nadzieją, a nie odzyskiwaniem. Ćwiczenie dowodzi odtwarzalności instancji, wykonując całą powyższą ścieżkę od początku do końca bez przestoju i bez operatora:

1. Przygotowuje wyciszoną migawkę katalogu danych — SQLite przez API kopii online, bloby i pliki przez fizyczne kopiowanie. Czeka na spokojny moment i odmawia, gdy trwa zadanie, zgodnie z recovery-check.
2. Kopia staje się podpisanym, zaszyfrowanym AES-256-GCM archiwum z tymczasowymi kluczami ćwiczenia i pełną inwentaryzacją.
3. Archiwum jest sprawdzane, odtwarzane do izolowanego celu i ponownie weryfikowane.
4. Ćwiczenie zapisuje czas odtwarzania jako wykazane RTO, a odstęp między sukcesami ogranicza osiągalne RPO harmonogramu, po czym usuwa wszystkie artefakty. Ćwiczenia są weryfikacją, nie kopią: archiwum ani klucz nie są zachowywane.

Włącz harmonogram przez RECOVERY_DRILL_INTERVAL_HOURS (np. 24); ćwiczenia działają na wspólnym harmonogramie pod dzierżawą koordynatora, więc repliki i nakładające się kroki nie uruchomią ich podwójnie. Strona System pokazuje historię i przycisk "Run drill now" dla administratorów, oparty na GET /api/recovery/drills i POST /api/recovery/drills/run. Nieudane ćwiczenie automatyczne ostrzega każdego administratora przez skrzynkę powiadomień i subskrybowane webhooki; ręczne uruchomienie zgłasza odmowę bezpośrednio. RECOVERY_DRILL_HISTORY ogranicza historię (domyślnie 60 wpisów).

Ćwiczenia obejmują profil solo (SQLite), gdzie archiwum systemu plików jest autorytatywną ścieżką kopii. Profil team zachowuje skoordynowany przepływ backup create-team; próba odtworzenia pozostaje obecnie krokiem procedury operatora.