Конфігурація

Ця сторінка охоплює змінні середовища контейнера, монтування, які надає шаблон, резервне копіювання VM через SSH і налаштування зовнішнього копіювання. Шляхи репозиторіїв резервних копій налаштовуються всередині додатка (Налаштування, Сховище, Шляхи резервних копій), а не через змінні середовища.

Змінні середовища

Змінна	Обов'язкова	Опис
APP_KEY	Так	32-байтовий шістнадцятковий секрет (64 шістнадцяткові символи), що використовується для виведення пароля репозиторію restic. Згенеруйте командою openssl rand -hex 32. Бережіть його: його втрата робить зашифровані резервні копії невідновлюваними.
LIBVIRT_HOST	Для VM	Хост Unraid, до якого звертаються через SSH для резервного копіювання VM (за замовчуванням host.docker.internal; шаблон попередньо заповнює заповнювач LAN-IP). Використовуйте свою LAN IP Unraid, обов'язково в кастомній мережі br0.x. Використовується й для копій наборів даних ZFS (поле шаблону Host SSH: Address); заповнювач 192.168.x.x вважається незаданим.
LIBVIRT_SSH_PORT	Ні	Порт SSH хоста для резервного копіювання VM (за замовчуванням 22). Поле шаблону Host SSH: Port, також для наборів даних ZFS.
LIBVIRT_SSH_USER	Ні	Користувач SSH на хості для резервного копіювання VM (за замовчуванням root). Поле шаблону Host SSH: User, також для наборів даних ZFS.
LIBVIRT_URI	Ні	Повний URI з'єднання libvirt, використовується дослівно замість побудови його з трьох наведених вище змінних LIBVIRT_* (які тоді ігноруються для рядка з'єднання). За замовчуванням не задано. Потрібен на TrueNAS Scale, чий libvirtd слухає на нестандартному сокеті, який побудована форма виразити не може: qemu+ssh://<user>@<truenas-host>/system?socket=/run/truenas_libvirt/libvirt-sock. Див. розділ про TrueNAS Scale в docs/vm-backup-ssh-setup.md. Якщо це URI qemu+ssh://, кожна зі змінних LIBVIRT_HOST, LIBVIRT_SSH_USER і LIBVIRT_SSH_PORT, яку не задано, береться з нього, зокрема для власних SSH-команд BombVault (передавання NVRAM, набори даних ZFS).
PORT	Ні	Порт HTTP (за замовчуванням 3000; використовується лише з HTTP_ONLY=true).
HTTPS_PORT	Ні	Порт HTTPS (за замовчуванням 3443; шаблон публікує його 1:1, тож WebUI відповідає на https://<ip>:3443).
HTTP_ONLY	Ні	Задайте true, щоб вимкнути самопідписаний слухач HTTPS і подавати лише звичайний HTTP (для використання за зворотним проксі, що термінує TLS).
BIND_HOST	Ні	Адреса, на якій слухає WebUI (за замовчуванням 0.0.0.0, усі інтерфейси). У контейнері не задавайте її: опублікованим портам потрібні всі інтерфейси; 127.0.0.1 підходить для запуску поза Docker. Healthcheck звертається до тієї самої адреси.
TRUSTED_PROXY	Ні	Розділені комами адреси або діапазони CIDR зворотного проксі перед BombVault (наприклад, 192.168.20.11 або 10.0.0.0/8). Лише з цих вузлів заголовку X-Forwarded-For вірять, і тоді обмежувач входу рахує невдачі за реальним клієнтом, а не зсипає всіх за проксі в одне відро. Не задано (типово) означає не довіряти нікому: беззастережно прийнятий заголовок дозволив би кожному обрати собі відро.
HOST_SOURCE_ROOT	Ні	Шлях хоста, змонтований як Host Data (за замовчуванням /mnt). BombVault перекладає джерела bind-монтувань, які повідомляє Docker, у шляхи під цим монтуванням. Змінюйте лише якщо ви змонтували інший корінь хоста.
DATA_ROOT_SEGMENTS	Ні	Розділені комами назви сегментів шляху, які позначають джерело bind-монтування як дані резервного копіювання (за замовчуванням appdata, відповідно до конвенції Unraid /mnt/user/appdata/<container>). Bind-монтування контейнера автоматично вибирається для резервного копіювання, якщо БУДЬ-ЯКИЙ із перелічених сегментів з'являється як повний сегмент шляху в його джерелі на хості, наприклад DATA_ROOT_SEGMENTS=appdata,config також підхоплює прив'язку .../config. Див. Виявлення джерел резервного копіювання для інших, завжди активних способів, якими знаходиться папка даних контейнера.
PLATFORM	Ні	Примусово задає платформу, на якій BombVault вважає себе запущеним, замість автовизначення: unraid, generic або truenas (за замовчуванням не задано: автоматично визначає Unraid, перевіряючи наявність його маркера dockerMan під flash-монтуванням, інакше generic; нерозпізнане значення також повертається до generic, з записом у журнал). Задавайте її явно на звичайному хості Docker або TrueNAS Scale, замість того щоб покладатися на автовизначення, яке працює лише для Unraid: саме так і робить загальний compose-файл. Змінює конвенцію запасного шляху appdata, типові значення місця призначення відновлення при міжекземплярному відновленні та чи взагалі виконуються кроки сповіщення й плагіна-компаньйона, доступні лише на Unraid (див. internal/platform).
BOMBVAULT_SELF_CONTAINER	Ні	Назва самого контейнера BombVault, тож він ніколи не робить резервну копію (і тому не зупиняє) сам себе.
BACKUP_MAX_HOURS	Ні	Максимальна кількість реальних годин, протягом яких окремий запуск резервного копіювання може утримувати блокування свого домену, перш ніж його буде примусово скасовано (запобіжник, щоб завислий запуск не міг заблокувати домен назавжди). Порожнє (за замовчуванням) використовує 48. Підніміть його для дуже великих чи повільних хмарних резервних копій (запуск, скасований на межі, завершується помилкою context deadline exceeded). Задайте 0, щоб вимкнути обмеження повністю.
BACKUP_STALL_HOURS	Ні	Години, протягом яких резервне копіювання може зовсім не просуватися, перш ніж його буде скасовано. Порожнє (за замовчуванням) означає 2; задайте 0, щоб ніколи не скасовувати через зависання. Це тонший із двох запобіжників і зазвичай саме він спрацьовує: він стежить за тим, чи ще щось відбувається, а не за тим, скільки триває запуск, тож повільне, але справне резервне копіювання на кілька терабайт лишається в спокої, а зависле на спільному ресурсі, що не відповідає, зупиняється за години, а не за дні. Попередження записується в журнал після 30 хвилин тиші, ще до будь-якого скасування. Сканування вважається просуванням: restic не пише байтів, поки обходить велике дерево, і ця фаза відстежується за його підсумками файлів і байтів, а не за записаними байтами. Дві змінні незалежні, і BACKUP_MAX_HOURS і далі обмежує фази після самого резервного копіювання (зберігання, статистика, зовнішнє копіювання), де немає лічильників для спостереження.
DB_DUMP_MAX_HOURS	Ні	Години, які один автоматичний дамп бази даних може виконуватися до зупинки. Порожнє (усталено) означає 6; дозволені значення від 1 до 48, і межа тримається на годину нижче за BACKUP_MAX_HOURS (на половині його, якщо він менший за дві години), щоб довгий дамп обривався власною межею і так і повідомлявся, а не тягнув за собою все резервне копіювання. Дамп, що перестав просуватися, зупиняється раніше, через BACKUP_STALL_HOURS. Зупинений дамп зараховується як невдалий сам по собі, а резервне копіювання контейнера триває. На Unraid змінну додають до контейнера BombVault через Add another Path, Port, Variable.
TZ	Ні	Часовий пояс для планувальника (наприклад Europe/Berlin). Якщо не задано, усі розклади виконуються за UTC: розклад на 02:30 запуститься о 02:30 UTC, а не за місцевим часом. В Unraid це ніколи не задається вручну: система передає власний часовий пояс у кожен контейнер. Журнал запуску показує, який пояс було визначено. Пояс із переходом на літній час пропускає один запуск навесні й виконує один двічі восени, а UTC не робить ні того, ні іншого, зате двічі на рік зсувається на годину відносно вашого годинника.

Монтування

Змонтуйте сокет Docker, flash (/boot) і корінь Host Data (/mnt), як показано в шаблоні CA. Як джерела, так і місця призначення резервних копій живуть під Host Data, і воно монтується slave, тож віддалений спільний ресурс, який монтується після запуску контейнера (наприклад під /mnt/remotes), стає видимим без перезапуску.

Копіям наборів даних ZFS теж потрібен цей режим: хост монтує знімок набору даних лише після запуску контейнера. Див. Набори даних ZFS.

Шляхи репозиторіїв резервних копій за замовчуванням /mnt/user/bombvault/{container,vms,flash,config,files,zfs}, створюються під час першого резервного копіювання. Змініть розташування будь-коли в Налаштування, Сховище, Шляхи резервних копій. Кожне поле шляху має також вбудований перемикач Локально / Віддалено: шлях може бути віддаленим сховищем restic (s3:..., rest:..., sftp:..., rclone:...) замість локальної теки, і резервне копіювання йде просто туди без окремої локальної копії; див. Віддалені основні репозиторії.

Перевірка інтеграції з хостом

Відкрийте /spike у вебінтерфейсі після запуску контейнера. Він тестує кожне монтування та CLI (сокет Docker, libvirt, restic, qemu-img, rclone) і повідомляє про будь-які відсутні частини.

Визначення джерел резервної копії

Для кожного контейнера BombVault сам обирає, які bind-монтування та іменовані томи потраплять до копії. Шлях береться, щойно виконується будь-який із пунктів нижче (результат завжди можна перевизначити для окремого контейнера в його розділі Папки для резервного копіювання):

• Збіг із сегментом кореня даних: джерело bind-монтування на хості містить один із сегментів DATA_ROOT_SEGMENTS як повну складову шляху (типово лише appdata).
• Іменовані томи Docker долучаються завжди, бо одноразового відповідника в них немає і фільтрувати нічого, але тільки якщо справжній шлях зберігання тому на хості сам досяжний через монтування Host Data, так само як будь-який інший шлях хоста, що його копіює BombVault. Типовий драйвер локальних томів кладе том під корінь даних самого демона, тобто /var/lib/docker/volumes/<назва>/_data, якщо це не змінено (перевірте командою docker info -f '{{.DockerRootDir}}'). Це місце НЕ покрите вузьким монтуванням Host Data з одного каталогу, яке типово використовує звичайний docker-compose.yml. Недосяжний том мовчки пропускається, це не помилка. Щоб іменовані томи на звичайному хості справді копіювалися, спрямуйте Host Data (і HOST_SOURCE_ROOT) на спільного предка, що охоплює також корінь даних Docker: компроміс описано в коментарі Host Data у файлі compose (Unraid обходить це, монтуючи з тієї самої причини весь /mnt, власну універсальну домовленість верхнього рівня).
• Каталог проєкту Docker Compose: якщо контейнер несе звичну мітку com.docker.compose.project.working_dir (її автоматично ставить docker compose up), цей каталог додається теж, незалежно від того, чи збіглося якесь bind-монтування із сегментом кореня даних.
• Перевизначення міткою bombvault.data: поставте контейнеру мітку bombvault.data=true, щоб долучити ВСІ його bind-монтування, для розкладки, якої не ловить жодна з двох домовленостей вище (наприклад одиничне монтування /srv/plex/config без проєкту Compose). Будь-яке непорожнє значення, окрім false, вважається істинним; відсутня мітка або bombvault.data=false не змінюють нічого.
• Мітка bombvault.dbdump: поставте контейнеру bombvault.dbdump=false, щоб вимкнути його автоматичний дамп бази даних (0, no і off роблять те саме), або назвіть рушій (postgres, mysql, mariadb), щоб знімати дамп із контейнера, якого BombVault сам не розпізнає. Мітка перебиває перемикач на картці контейнера, який на Unraid і є звичним шляхом.

Модель безпеки

Root-рівний контроль над хостом

Через сокет Docker BombVault може зупиняти, видаляти та відтворювати контейнери й читати/писати appdata, а для резервного копіювання VM він входить на хост через SSH (qemu+ssh://, root за замовчуванням), щоб виконати virsh. Кожен, хто має доступ до його вебінтерфейсу, фактично має root на хості.

• Необов'язковий захист паролем (Налаштування, Безпека): задайте пароль, щоб вимагати вхід, очистьте його, щоб вимкнути. Типово вимкнено для довіреної локальної мережі. Пароль зберігається з Argon2id над значенням, приперченим ключем APP_KEY, тож скопійований /config без ключа нічого не вартий, а з ключем атака повільна. Новий пароль має бути не коротшим за 12 символів; наявний коротший працює далі, поки його не змінять. Сеанси підписані (HMAC, похідний від APP_KEY), і зміна пароля робить їх недійсними; входи обмежені п'ятьма невдачами на хвилину для кожного клієнта.
• Двофакторна автентифікація (Налаштування): часовий код із застосунку-автентифікатора на додачу до пароля та вісім одноразових резервних кодів, які видаються один раз під час увімкнення. Спільний секрет зберігається зашифрованим ключем APP_KEY, а вимкнення вимагає чинного коду.
• Ключі доступу (WebAuthn) розміщені на окремій картці, щойно задано пароль, і діють разом із паролем, а не замість нього, тож видалення всіх ключів доступу нікого не замикає. Їм потрібне справжнє доменне ім'я і сертифікат, якому довіряє браузер. Типовий https://<ip>:3443, це саме те, що WebAuthn відхиляє, і картка так і каже, замість того щоб пропонувати кнопку, яка не спрацює.
• Зміни лише в JSON. Запит, який щось змінює, має надсилати Content-Type: application/json і не повинен бути позначений браузером як міжсайтовий, тож сторінка на іншому сайті не може змусити ваш браузер змінювати налаштування за адресою в локальній мережі. Скрипт, що працює з API, надсилає цей заголовок; усе інше відхиляється з 415.
• Оскільки захист за вибором, коли він не заданий, весь інтерфейс і API (включно з налаштуванням зовнішнього, маршрутами тесту на втручання та набором для відновлення) доступні кожному, хто має доступ до порту. Увімкніть захист, щойно почнете використовувати зовнішні, незмінні резервні копії чи шифрування.
• Запускайте BombVault лише в довіреній, не виставленій назовні мережі. Для віддаленого доступу поставте його за зворотним проксі, що додає автентифікацію та TLS. Відповіді несуть базові заголовки безпеки (CSP, nosniff, X-Frame-Options, Referrer-Policy).
• За зворотним проксі кожен запит несе адресу проксі, тож без TRUSTED_PROXY обмежувач рахує всіх клієнтів разом, і невдачі зловмисника блокують і тебе. Вкажи проксі в TRUSTED_PROXY, щоб повернути підрахунок за клієнтами.
• Зворотний проксі перед BombVault має передавати заголовок Authorization або X-API-Key на /mcp і не повинен буферизувати відповіді, інакше асистенти не зможуть підключитися. Див. Сервер MCP.
• Кінцева точка MCP /mcp відповідає 404, доки не створено ключ або не ввімкнено вхід через OAuth, і вимагає від кожного клієнта ключ або токен навіть за вимкненого пароля входу; жодна адреса не виняток, навіть localhost. Інструментів відновлення чи видалення в неї немає, а відновлення резервної копії конфігурації відкликає всі ключі. Див. Сервер MCP.
• З HTTP_ONLY=true cookie сесії втрачає свій прапорець Secure (мусить, щоб працювати через звичайний HTTP), тож вмикайте пароль за проксі, що термінує TLS, лише якщо конфіденційність має значення.
• З'єднання SSH для резервного копіювання VM довіряє ключу хоста під час першого з'єднання (TOFU) і закріплює його після цього. Перевірте ключ хоста поза каналом, якщо ваш шлях від контейнера до хоста не є довіреним.
• Резервні копії шифруються restic, коли шифрування ввімкнене (Налаштування; увімкнене за замовчуванням), з ключем, виведеним з APP_KEY.

Сервер MCP

Серверу MCP не потрібна змінна середовища. Ви вмикаєте його, створивши ключ у Налаштування, Інтеграції, Сервер MCP, і він відповідає за шляхом /mcp на тому самому порту, що й вебінтерфейс (наприклад, https://192.168.1.10:3443/mcp). Без активного ключа цей шлях відповідає 404. Клієнтів, сертифікати й обмеження описано на сторінці Сервер MCP.

Резервне копіювання VM через SSH

BombVault робить резервні копії віртуальних машин KVM/libvirt без монтування будь-якого шляху libvirt. Він виконує virsh на хості через SSH (qemu+ssh://), тож він ніколи не може вплинути на ваш хостовий VM Manager.

Монтувати сокет libvirt хоста в контейнер на Unraid ненадійно: цими шляхами володіє VM Manager, і перемикання "Enable VMs" може залишити libvirt нездатним запуститися. SSH-ключ дає root на хості, це той самий рівень довіри, що й у сокета Docker, який BombVault уже використовує.

Швидке налаштування:

1. Налаштування, Інтеграції, SSH хоста: скопіюйте показаний публічний ключ.
2. Додайте його до /root/.ssh/authorized_keys в Unraid (також збережений на flash, тож він переживає перезавантаження).
3. Натисніть Перевірити з'єднання.

Шаблон додає --add-host=host.docker.internal:host-gateway, тож контейнер може дістатися до хоста. Задайте LIBVIRT_HOST на свою LAN IP Unraid, якщо ця назва не розв'язується (наприклад коли контейнер працює в кастомній мережі br0.x). Якщо ви змінили порт SSH Unraid, задайте LIBVIRT_SSH_PORT відповідно. Живі знімки додатково потребують гостьового агента qemu у VM і диска на /mnt/cache (не /mnt/user).

Повний посібник з налаштування VM і мережі

Повний покроковий посібник (увімкнення SSH, стійка авторизація ключа, маршрутизація в кастомній мережі та VLAN, метод для кожної VM і усунення несправностей на боці хоста) живе за адресою docs/vm-backup-ssh-setup.md на GitHub.

Налаштування зовнішнього копіювання

Налаштуйте зовнішню репліку на сторінці Налаштування, Зовнішнє. Повний робочий процес див. у Зовнішнє копіювання та відновлення (незмінне/append-only, тестування на втручання та тренування DR). Коротко:

• Бекенди: SMB/CIFS та NFS (змонтуйте спільний ресурс і вкажіть на нього Шлях резервних копій), нативні бекенди restic без rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo) або будь-яке віддалене сховище rclone (rclone:<remote>:<bucket>/path). Backblaze B2 тут не має власного бекенда: підключайтеся до нього через його кінцеву точку S3 (s3:https://s3.<region>.backblazeb2.com/<bucket>/<path>), вказавши ідентифікатор ключа та ключ застосунку як облікові дані S3.
• Спільні хмарні облікові дані зберігаються зашифрованими в Налаштування, Хмарний доступ, Спільні хмарні облікові дані.
• Цілі SSH не потребують нічого встановленого на дальньому боці. sftp: потребує лише SSH-сервера. Додайте публічний ключ з Налаштування, Інтеграції, SSH хоста (також за адресою /config/ssh/id_ed25519.pub) до ~/.ssh/authorized_keys цільового користувача.
• Зовнішнє копіювання: BombVault реплікує нові знімки командою restic copy за принципом найкращих зусиль, поверх основного репозиторію (зазвичай локального). Кожен домен має власний зовнішній розклад, плюс кнопка Реплікувати зараз.
• Кілька зовнішніх цілей для домену: кожен домен може реплікуватися на кілька зовнішніх місць призначення одночасно. Додайте додаткові цілі в Налаштування, Зовнішнє, кожна з власним репозиторієм, класом сховища S3, прапорцем append-only, зберіганням і бюджетом росту; усі вони реплікуються за зовнішнім розкладом цього домену. Наявне єдине налаштування зовнішнього переноситься як перша ціль.
• Місця призначення: зовнішні місця призначення налаштовуються один раз у Налаштування, Зовнішнє, Місця призначення, через майстер, який перелічує всі підтримувані сервіси. Див. Місця призначення.
• Розміщення для кожного елемента: у кожного контейнера, VM і набору папок підсвічені Локально та цілі, які отримують його резервні копії. Налаштування, Сховище, Розміщення за замовчуванням задає це для кожного домену для елементів без власного вибору. Див. Розміщення для кожного елемента.
• Зберігання для кожного джерела: локальна і зовнішня політики обидві живуть у Налаштування, Зберігання (залиште зовнішню всю нульовою, щоб ніколи не обрізати зовнішні знімки автоматично). У картках Локальне зберігання і Зовнішнє зберігання є Правила зберігання за джерелом, що дають контейнерам, VM, flash, папкам, ZFS або самокопії власні правила зберігання, для їхніх локальних копій і для їхнього зовнішнього репозиторію. Джерело без власних правил дотримується спільних, а зберігання після кожної копії, зовнішнє копіювання, ручне очищення та попередній перегляд зберігання використовують правила того джерела, з яким працюють. Додаткові зовнішні цілі зберігають правила, задані для них у Налаштування, Зовнішнє.
• Обмеження пропускної здатності: обмежте швидкість вивантаження/завантаження restic у Налаштування, Зовнішнє.
• Спершу стрімінг: у Налаштування, Зовнішнє обери медіасервери (Plex, Jellyfin та Emby обрано заздалегідь за назвою образу), швидкість надсилання, з якої сервер вважається таким, що веде стрімінг, ліміт вивантаження під час стрімінгу і через скільки після потоку повертається звичайний ліміт.
• Клас холодного та архівного сховища (S3): для нативного зовнішнього репозиторію S3 виберіть рівень, придатний для читання під час відновлення (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval). Віддалені сховища rclone задають свій клас у конфігурації rclone.
• Віддалений основний репозиторій замість локального: сам Шлях резервних копій домену може бути одним із бекендів вище, без локальної копії і без кроку реплікації; вбудований перемикач Локально/Віддалено та його налаштування безпеки (пропускна здатність, append-only, бюджет росту) описано в Віддалені основні репозиторії.

Аномалії

Виявлення аномалій налаштовують на картці Аномалії у розділі Налаштування, Цілісність. Кожен елемент керування зберігається одразу після зміни, а три під перемикачем приховані, поки виявлення вимкнене.

Параметр	Типово	Що робить
Виявляти аномалії	Увімк.	Порівнює кожну копію з власною історією елемента. У вимкненому стані нічого нового не перевіряється, а пункт Аномалії зникає з бічної панелі; картка й далі веде до попередніх знахідок.
Чутливість	Збалансована	Сувора повідомляє і про менші зміни, Мʼяка лише про великі.
Надсилати сповіщення для	Лише критичні знахідки	Мінімальна важливість, за якої повідомлення надсилається каналами, налаштованими в Сповіщення. Повторні збої копій і дампів та невдалі планові перевірки відновлення вже надсилають власне повідомлення й не надсилаються двічі.
Зберігати старі копії, коли джерело різко зменшилося або було перезаписане	Увімк.	Поки елемент має відкриту знахідку про майже порожнє джерело, сильне зменшення або заново збережену більшу частину даних, зберігання й очищення не чіпають його старі копії. Підтвердьте знахідку або позначте її як очікувану, щоб їх відпустити.

Кожен елемент може мати власну чутливість і власний мінімум сповіщень. Задайте їх на сторінці Аномалії: в елемента з відкритими знахідками вони в розділі Спостереження на його картці, будь-який інший елемент відкриває їх із картки Нічого не відкрито. Їх також можна задати на панелі самого елемента: у розділі тек контейнера й у налаштуваннях ВМ (обидва в розширеному режимі), у редакторі тек набору тек і на сторінках Flash та Автобекап. Для елемента ZFS вони в його редакторі на сторінці ZFS і діють для кожного набору даних його дерева.

Портативні налаштування (експорт та імпорт)

Картка Експорт / імпорт налаштувань на сторінці Налаштування, Система записує всю вашу конфігурацію BombVault (налаштування доменів, зовнішні цілі, розклади, зберігання, сповіщення) до портативного файлу JSON, який ви можете імпортувати на іншому екземплярі, тож перехід на нову машину чи клонування налаштувань не означає повторне введення всього вручну. Імпорт показує попередній перегляд і запитує підтвердження, і він ніколи не торкається ваших даних резервних копій чи історії.

Експорт може містити облікові дані

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