Připravenost k obnově

Libre WebUI poskytuje inventář obnovy pouze pro čtení jako první bezpečnostní bránu zálohování a obnovy. Kontrola recovery-check hlásí známý stav a podmínky blokující snapshot, ale nezískává maintenance lock, nekopíruje, nešifruje, nenahrává, nemaže, neopravuje ani neobnovuje data.

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

Ze zdrojů jednou spusťte npm run build:backend a libre-webui recovery-check nahraďte npm run recovery:check --. Instalace npx a Homebrew ve výchozím stavu kontrolují ~/.libre-webui; DATA_DIR a explicitní cesty ji přepíší.

Stav 0 znamená žádné blokátory, 1 úplný report s blokátory a 2 neplatné argumenty nebo neočekávané selhání sběru. Jinou cestu zkontrolujete pomocí --data-dir PATH či --database PATH; explicitní volba --database smí ukazovat mimo datový kořen. Výchozí inventář přijímá pouze kanonický DATA_DIR/data.sqlite a odmítá hardlinky, symlinky a neregulární databázové/WAL/SHM soubory. Explicitní databáze může být mimo DATA_DIR, ale musí být regulárním souborem bez symlinků; bez --data-dir se její nadřazená složka stane datovým kořenem.

Runtime čte také historické definice pluginů z deterministické složky plugins backendového balíčku a starší backendové cesty relativního PLUGINS_DIR. Vlastní definice v aktivních legacy cestách blokují snapshot samotného volume. Zabalená instalace může vícekrát uvést --legacy-plugins-dir PATH.

Pro soukromé Compose spusťte kontrolu uvnitř nasazeného kontejneru:

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

Co inventář kontroluje

Verzovaný JSON report zaznamenává:

• verzi aplikace, Node.js, operačního systému a architektury;
• velikost SQLite a WAL/SHM, quick_check, cizí klíče, otisk schématu, user version, chybějící tabulky a no-follow kontrolu zdrojů;
• čitelnost/zapisovatelnost datové složky, počet souborů a bajtů;
• zdroj šifrovacího klíče, nevratný 16znakový otisk a bezpečnost .encryption_key;
• vlastní pluginy, šifrované místní blob objekty, vložená média, hlasové reference, text dokumentů a legacy/platformní vektory s ACL;
• omezené úplné ověření kanonických blobů, vektorových obálek, chunků/checksumů a dostupných klíčů;
• ověření rozpoznatelných legacy obálek AES-GCM v chatech, poznámkách, dokumentech, preferencích, tajemstvích pluginů, médiích, e-mailu a hlasových polích vázaných AAD;
• úlohy/běhy/náhledy Work a očekávané Docker volumes, Kubernetes PVC či hashované hostitelské cesty se správným vlastníkem;
• stavy mediálních a trvalých úloh, pokusy, event streamy a globální cursor;
• ověření šifrovaných payloadů úloh/událostí a syntaktickou kontrolu omezených opaque referencí; a
• explicitní blokátory, varování a data mimo datovou složku aplikace.

Report nikdy neobsahuje klíče, JWT/session tajemství, přihlašovací údaje poskytovatele, obsah pluginů či uživatelů ani doslovné cesty hostitele. Read-only mount je pro kontrolu platný a způsobí varování, nikoli blokátor; proti této kopii aplikaci nespouštějte.

Blokátory

Každý blokátor znamená neúspěšnou bránu. Typické příčiny jsou chybějící nebo poškozená databáze, neúplné schéma, chybějící či konfliktní klíč, poškozený/neověřený ciphertext, překročení limitů, nečitelná složka, linkovaný zdroj SQLite, aktivní Work/media/trvalé úlohy, chybějící nebo špatně označený pracovní prostor, neshodný event head či mezera sekvence, externí vlastní pluginy nebo control plane, která neumí ověřit externí prostory. Aktivní práci zastavte a závislosti opravte; report neupravujte, abyste blokátor skryli.

Šifrované payloady se ověřují vůči identitě úlohy/události a jako kanonický omezený JSON. Opaque reference lze kontrolovat pouze velikostně a syntakticky, protože neexistuje autoritativní repository referencí blobů. referenceTargetsVerified se nastaví na false a zobrazí varování bez hodnot payloadu.

Legacy texty vznikly před povinným markerem obálky, takže skutečný plaintext starých schémat zůstává čitelný a nepočítá se jako ověřený ciphertext. Kanonické obálky se ověřují vždy; poškozené tříčástové hodnoty se bezpečně odmítnou. Hlasová pole mají jednoznačnou binární obálku vázanou na profil, vlastníka a pole. encryption.legacyCiphertext uvádí počty a bajty bez plaintextu.

Se schématem v4 a users.email_lookup se ověřuje každý e-mail a znovu počítá doménově oddělený klíčovaný token. Chybějící, neshodný nebo token na null e-mailu blokuje; starší databáze bez sloupce zůstávají kompatibilní.

Současná hranice zálohy

Pomocník soukromého nasazení podle potřeby zastaví aplikaci a vytvoří integrovaný solo archiv z přesného image, volume a prostředí. Manifest se podepíše Ed25519 a celý payload zašifruje operátorským AES-256-GCM klíčem. Zahrnuje SQLite, místní bloby, vložené vektory, runtime selektory a chráněnou konfiguraci. Podpis, checksum ciphertextu i dešifrovaný payload se ověří před publikací. libre-webui-restore přijímá pouze nový Docker volume a zapisuje konfiguraci jako soukromé soubory do nové složky.

Chráněná konfigurace zahrnuje pool a timeouty PostgreSQL, timeout Redis, obě blob kvóty, platformní selektory a prefix/režim adresování S3. Leží v podepsaném šifrovaném payloadu a při obnově se publikuje v režimu 0600.

Solo archiv nezahrnuje volumes Work, Kubernetes PVC, hostitelské složky, modely Ollama ani externí stav poskytovatelů. Zálohujte je zvlášť. Týmový tok zapečetí export PostgreSQL, přesné verzované objekty S3, inventář PGVector, runtime konfiguraci a identitu klíče a ověří čisté cíle. Cache, presence, wake-up a leases Redis se obnoví z SQL.

Týmová záloha ověřuje všechny omezené šifrované payloady úloh/událostí v exportu. Každý stream musí mít souvislou sekvenci 1..last_sequence a globální cursor nesmí zaostávat za největším uloženým. Obnova porovnává celý výsledek s podepsaným inventářem. Mezery mezi globálními cursory jsou povoleny, protože PostgreSQL identity není transakční; souvislost per stream je smlouva.

Pokud PLUGINS_DIR leží mimo DATA_DIR, označí se jako vyloučený a definice blokují volume backup, dokud nevznikne odpovídající snapshot. Symlinkované, neregulární či nečitelné JSON jsou vždy blokátory. Trvalé úlohy/události jsou aktivní v obou profilech; kontrola blokuje aktivní pokusy a Work, ověřuje payloady a sekvence a zachovává SQL. Solo používá vložený worker, team externí worker a Redis pouze pro wake-up/fan-out.

V produkci ukládejte šifrovací a JWT tajemství do chráněného secret manageru, šifrované archivy mimo hostitele a obnovu testujte v čistém kompatibilním prostředí. Inventář je preflight snapshot, nikoli zámek či úplný důkaz externích prostředků.

Příkazy podepsané a šifrované zálohy

Použijte nainstalované libre-webui; bez globální instalace nahraďte libre-webui backup za npx --yes libre-webui@latest, ze zdrojů po buildu použijte npm run recovery:backup --. Produkční image obsahuje /usr/local/bin/libre-webui. Team navíc vyžaduje PostgreSQL 16 pg_dump a pg_restore.

Vytvořte klíče v soukromé složce a privátní klíče přesuňte do chráněného externího úložiště:

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

Vytvoření a ověření klidového solo archivu:

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

Nejprve preflight, poté aplikace pouze do nové prázdné složky:

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

Pro tým zastavte všechny repliky a workery a vytvořte koordinovaný archiv:

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

Před obnovou načtěte prostředí pro samostatnou prázdnou databázi PostgreSQL a prázdný verzovaný bucket S3. Preflight prokáže prázdné cíle bez publikace; apply obnoví a ověří schéma, přesné objekty S3 a PGVector a zapíše chráněnou konfiguraci:

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

Nikdy neobnovujte do zdrojové databáze/bucketu ani existující datové či konfigurační složky. Veřejný podpisový klíč nestačí k dešifrování. Pokud rollback týmu nebyl úplný, považujte oba cíle za znečištěné: vyčistěte PostgreSQL a všechny verze/delete markers v přesném prefixu S3 a před opakováním znovu spusťte restore-team-preflight.

Naplánovaná ověřená cvičení obnovy

Záloha, která nebyla nikdy obnovena, je naděje, nikoli obnova. Cvičení:

1. Připraví klidový snapshot SQLite pomocí online backup API a fyzicky zkopíruje bloby/soubory; odmítne běžet během aktivní trvalé úlohy.
2. Vytvoří podepsaný archiv AES-256-GCM s dočasnými klíči a úplným inventářem.
3. Archiv ověří, obnoví do izolovaného cíle a ověří znovu.
4. Zapíše dobu obnovy jako prokázané RTO a rozestup úspěšných cvičení jako dosažitelné RPO a poté všechny artifacts i klíče smaže.

Zapněte plán pomocí RECOVERY_DRILL_INTERVAL_HOURS (například 24). Coordinator lease brání dvojímu běhu. System zobrazuje historii a „Run drill now“ přes GET /api/recovery/drills a POST /api/recovery/drills/run. Nehlídaná chyba upozorní všechny administrátory; RECOVERY_DRILL_HISTORY omezuje historii (výchozí 60).

Cvičení pokrývají solo/SQLite. Team nadále používá backup create-team a nácvik obnovy podle postupu operátora.