Перейти до основного вмісту

Готовність до відновлення

Libre WebUI надає інвентаризацію відновлення лише для читання як першу захисну перевірку резервного копіювання й відновлення. Вона повідомляє про відомий стан та умови, що блокують знімок. Вона не отримує блокування обслуговування й не копіює, шифрує, завантажує, видаляє, виправляє чи відновлює дані.

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

Із вихідного коду один раз виконайте npm run build:backend і замініть libre-webui recovery-check на npm run recovery:check --. Установлення npx і Homebrew типово перевіряють ~/.libre-webui; DATA_DIR та явні параметри шляхів перевизначають розташування.

Команда повертає 0 без блокувань, 1 за повного звіту з блокуваннями й 2 за неправильних аргументів або збою збирання. Використовуйте --data-dir PATH або --database PATH. Інвентаризація типового тому чи --data-dir приймає лише канонічний DATA_DIR/data.sqlite і відхиляє жорсткі/символічні посилання та нерегулярні файли бази/WAL/SHM. Явна --database може бути поза DATA_DIR, але база й супровідні файли мають бути звичайними й не символічними посиланнями. Без --data-dir батьківський каталог бази вважається коренем даних, щоб разом урахувати ключ, блоби й плагіни.

Середовище також читає історичні плагіни з детермінованого каталогу plugins пакета серверної частини та, для відносного PLUGINS_DIR, старого шляху відносно неї. Активні старі шляхи інвентаризуються й блокують знімок лише тому за наявності користувацьких визначень. Пакетне розгортання може кілька разів передати --legacy-plugins-dir PATH для переміщених каталогів сумісності.

Для приватного Compose запускайте перевірку в контейнері, щоб звіт описував його том, код і секрети:

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

Що перевіряє інвентаризація​

Версіонований JSON записує:

  • версії програми, Node.js, ОС та архітектури;
  • розміри SQLite і WAL/SHM, quick_check, зовнішні ключі, відбиток схеми, версію користувача, відсутні таблиці й перевірку вихідних файлів без переходу за посиланнями до приватного знімка перевірки;
  • можливість читання й запису, кількість файлів і байтів каталогу;
  • джерело ключа й односторонній 16-символьний відбиток;
  • перевірку постійного .encryption_key без переходу за посиланнями й з одним жорстким посиланням;
  • наявність, кількість, розмір і включення до кореня користувацьких плагінів, локальних зашифрованих блобів, медіа, голосів, тексту документів, старих і платформних векторів з ACL/фільтрами;
  • обмежену автентифікацію лише для читання кожного канонічного локального блоба й оболонки вектора, з повною перевіркою фрагментів, контрольних сум і наявності ключа;
  • обмежену автентифікацію розпізнаваних старих текстових оболонок AES-GCM у чатах, нотатках, документах, налаштуваннях, секретах, галереї та електронній пошті, а також пов’язаних з AAD назв голосів, записів і транскрипцій;
  • кількість завдань, виконань і переглядів Work та очікувані томи Docker, PVC Kubernetes або хешовані шляхи хоста; том має мати керовану мітку й точний ID власника;
  • стани старих завдань медіа й постійні завдання за станом, спроби за результатом, потоки/події та останній глобальний курсор;
  • обмежену автентифікацію зашифрованого вмісту завдань/подій і синтаксис непрозорих посилань; і
  • явні блокування, попередження й дані поза каталогом програми.

Звіт ніколи не містить ключів, секретів JWT/сеансів, облікових даних постачальників, вмісту плагінів або користувачів і буквальних шляхів робочих просторів хоста. Виводяться лише ознаки наявності секретів і незворотний відбиток ключа.

Підключення лише для читання допустиме для перевірки й дає попередження, а не блокування. Готовність програми потребує запису; не запускайте Libre WebUI на знімку лише для читання, який використовує засіб копіювання.

Блокування​

Будь-яке блокування означає невдалу перевірку. Типові причини: відсутня чи пошкоджена база, неповна схема, відсутній або суперечливий ключ, пошкоджений чи неавтентифікований шифротекст, перевищені ліміти, нечитабельний каталог, пов’язаний або нерегулярний SQLite, активні виконання/перегляди Work, завдання медіа чи постійні завдання, відсутній або неправильно позначений простір Work, невідповідності голів чи розриви послідовностей подій, плагіни поза каталогом або площина керування, яка не може перевірити зовнішні простори. Зупиніть активну роботу й виправте залежності; не редагуйте звіт, щоб приховати блокування.

Зашифрований вміст автентифікується за ідентичністю завдання/події та перевіряється як канонічний обмежений JSON. Непрозорі посилання лише обмежуються й перевіряються синтаксично: немає авторитетного сховища посилань на блоби, щоб довести існування чи доступність цілі. Звіт установлює referenceTargetsVerified у false і попереджає, не розкриваючи значень.

Старі текстові поля з’явилися до обов’язкової позначки оболонки, тому справжній відкритий текст старих схем залишається читабельним і не вважається автентифікованим шифротекстом. Канонічні оболонки завжди перевіряються; трискладові значення з IV або міткою розміру оболонки в разі пошкодження безпечно відхиляються. Голосові поля однозначно двійкові й зобов’язані автентифікувати профіль, власника й поле. encryption.legacyCiphertext повідомляє підсумки записів/байтів без відкритого тексту.

За наявності users.email_lookup схеми v4 кожна непорожня електронна адреса автентифікується, а її доменно відокремлений ключовий маркер перераховується. Відсутність, невідповідність або маркер за null блокує знімок. Бази до v4 сумісні без цієї колонки.

Поточна межа резервної копії​

Засіб приватного розгортання зупиняє програму й використовує незмінний образ контейнера, том і середовище для архіву solo. Маніфест підписано Ed25519, а дані зашифровано операторським ключем AES-256-GCM. Архів містить SQLite, локальні блоби й вектори, селектори середовища та захищену конфігурацію для розшифрування. До публікації перевіряються підпис, контрольна сума шифротексту й розшифрований вміст. libre-webui-restore приймає лише новий том Docker, перевіряє інвентаризацію до копіювання й публікує конфігурацію приватними файлами в новому каталозі.

Захищена конфігурація містить пул PostgreSQL і час очікування під’єднання, бездіяльності, інструкцій і блокування міграції; час під’єднання Redis; обидві квоти блобів; селектори платформи; префікс S3 і режим адресування. Вони містяться в підписаних зашифрованих даних, а не відкритому маніфесті, і публікуються як файли 0600.

Архів solo не містить томів Docker Work, PVC Kubernetes, каталогів, пов’язаних із хостом, моделей Ollama або зовнішнього стану. Зберігайте винятки видимими й копіюйте Work окремо. Team використовує автономний процес: експорт PostgreSQL, точні версіоновані об’єкти S3, інвентаризація PGVector, конфігурація й ключ запечатуються тим самим форматом і перевіряються на чистому PostgreSQL/S3. Кеш Redis, присутність, сигнали пробудження й оренди відновлюються з SQL.

Копія team автентифікує кожен обмежений зашифрований вміст завдання/події в точному експорті. Захищена інвентаризація рахує завдання, події, потоки, курсори, оболонки, посилання й відкритий текст. Кожен потік містить безперервне 1..last_sequence, а глобальний курсор PostgreSQL не відстає від найбільшого. Відновлення повторює перевірки й потребує збігу з джерелом. Пропуски між глобальними курсорами допустимі через нетранзакційне виділення ідентифікаторів; безперервність обов’язкова всередині потоку.

Якщо PLUGINS_DIR поза DATA_DIR, каталог інвентаризується й вилучається з тому. Будь-які визначення блокують знімок до окремої копії. Те саме стосується старих каталогів. Символічні посилання, нерегулярні чи нечитабельні JSON завжди блокують і не обходяться.

Постійні завдання й упорядковані події активні в обох профілях. Перевірка блокує активну спробу чи Work, перевіряє вміст і голови потоків і зберігає канонічний SQL. Solo запускає обмежений вбудований обробник; team — ті самі обробники в зовнішньому, використовуючи Redis лише для пробудження й розсилання.

У виробничому середовищі тримайте ключі й JWT у менеджері секретів, архіви поза хостом і зашифрованими, перевіряйте відновлення в чистому сумісному середовищі. Інвентаризація — попередній знімок, а не блокування й не доказ відновлення всіх зовнішніх ресурсів.

Команди підписаних і зашифрованих копій​

Приклади використовують установлений libre-webui з npm або Homebrew. Без глобального встановлення замініть на npx --yes libre-webui@latest. Із вихідного коду зберіть серверну частину й замініть libre-webui backup на npm run recovery:backup --. Виробничий образ надає /usr/local/bin/libre-webui. Team потребує PostgreSQL 16 pg_dump і pg_restore, які входять до образу й Homebrew; для npm/npx установіть сумісний клієнт.

Створіть ключ архіву AES-256-GCM і пару Ed25519 у приватному каталозі, а потім перенесіть приватні ключі за межі хоста:

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

Для зупиненого solo створіть і незалежно перевірте архів:

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

Спочатку виконайте попередню перевірку, а потім застосовуйте лише до нового порожнього каталогу:

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

Для team зупиніть усі репліки й обробники, залиште середовище PostgreSQL/S3/сховища ключів джерела й створіть архів:

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

До відновлення завантажте змінні для окремої порожньої PostgreSQL і порожнього версіонованого S3. Попередня перевірка перевіряє підпис, архів, інвентаризацію та порожнечу цілей без публікації. Застосування відновлює, перевіряє схему, точні об’єкти S3 і PGVector та записує конфігурацію до нового приватного каталогу:

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

Ніколи не спрямовуйте відновлення до вихідної бази, сховища, наявного каталогу даних або непорожньої конфігурації. Зберігайте публічний ключ із процедурою; архів і публічний ключ не розшифровують вміст.

Якщо відкат team неповний, вважайте обидві цілі забрудненими й не повторюйте одразу. Очистьте PostgreSQL, перелічіть і видаліть усі версії об’єктів і позначки видалення під точним префіксом S3. Повторіть restore-team-preflight; застосування безпечне лише після чистої перевірки.

Заплановані перевірені навчання відновлення​

Копія, яку не відновлювали, — надія, а не відновлення. Навчання без простою й оператора виконує весь процес:

  1. Створює знімок каталогу в спокої — SQLite через API онлайн-копіювання, блоби й файли фізично. Чекає відсутності постійних завдань за правилом recovery-check.
  2. Перетворює копію на підписаний архів AES-256-GCM із тимчасовими ключами й повною інвентаризацією.
  3. Перевіряє архів, відновлює до ізольованої цілі й знову перевіряє.
  4. Записує тривалість як доведений RTO, інтервал успіхів як межу RPO й видаляє артефакти. Це перевірка, не копія: архів і ключ не зберігаються.

Увімкніть RECOVERY_DRILL_INTERVAL_HOURS (наприклад 24); спільна оренда запобігає подвійному запуску реплік. Сторінка System показує історію й кнопку "Run drill now", використовуючи GET /api/recovery/drills і POST /api/recovery/drills/run. Автоматичний збій один раз сповіщає всіх адміністраторів і вебперехоплювачі; ручний повідомляє відмову безпосередньо. RECOVERY_DRILL_HISTORY обмежує історію (типово 60).

Навчання охоплюють solo (SQLite), де файловий архів авторитетний. Team зберігає backup create-team; репетиція відновлення поки залишається кроком оператора.