Можливості

BombVault простий за замовчуванням і глибокий, коли вам це потрібно. Інтерфейс показує лише найнеобхідніше, поки ви не перемкнете перемикач Простий вигляд / Розширений вигляд. Ця сторінка групує повний набір можливостей.

Обсяг резервного копіювання

Контейнери, у кожного свій перемикач розкладу, порядок копіювання і власна історія.

Що	Що зберігається
Контейнери Docker	Каталог appdata плюс визначення контейнера (образ, змінні середовища, порти, мітки, томи). Типово весь каталог appdata; Вибрати папки на контейнері точно позначає, які папки охоплює копія, з живим підрахунком шляхів, списком того, що ви виключили, і перемикачем Пропускати папки кешу для кожного кореня (CACHEDIR.TAG).
Віртуальні машини KVM / libvirt	Образ(и) диска VM, XML-визначення та UEFI NVRAM (коректне вимкнення або живий знімок, через SSH). Живі знімки автоматично відкочуються до коректного резервного копіювання, якщо знімок не вдається створити, тож резервне копіювання VM ніколи просто не завершується помилкою. Коли увімкнено Лише змінені блоки, запущена ВМ з дисками qcow2 читається через контрольні точки libvirt, тож копія читає лише блоки, записані після попередньої, а кожен знімок і далі сам відновлює весь диск. Диски на томах ZFS (zvol) передаються через zfs send тим самим SSH-з'єднанням, тож VM, диски якої є zvol, зберігається як одна VM. Стан прокинутого vTPM зберігається поруч із NVRAM, якщо XML-визначення VM вказує його шлях. Емульований vTPM, який TrueNAS налаштовує для гостьових Windows 11, цього шляху не публікує, тож тримайте ключ відновлення такої гостьової системи під рукою. Див. посібник з резервного копіювання VM.
Unraid flash	Уся USB-флешка (/boot): ОС, ліцензія, конфігурація масиву, спільні ресурси, мережа та конфігурація плагінів. Відновлення, це завантаження .zip в один клік, яке ніколи не перезаписує робочу flash.
Конфігурація додатка	Власний /config BombVault (база налаштувань, зовнішні облікові дані, пара SSH-ключів libvirt), знятий за допомогою SQLite VACUUM INTO, тож база даних у режимі WAL ніколи не захоплюється посеред запису. Відновлюється через самоперезапуск, тож робоча база даних ніколи не перезаписується під відкритим дескриптором.
Файли та теки	Іменовані набори файлів: будь-яка тека на сервері (спільний ресурс, ваші документи, фотобібліотека), кожен з необов'язковими шаблонами виключення для окремого набору. Повна рівність з іншими доменами (розклади, зберігання, зовнішнє копіювання, перевірки цілісності та тренування відновлення).
Набори даних ZFS	Набір даних разом з усіма наборами під ним, прочитаний з одного знімка ZFS, тож усі вони з одного моменту, і збережений через restic як тека: з дедуплікацією, переглядом і відновленням окремих файлів. Нові дочірні набори додаються самі, будь-який можна виключити, а набір, який не вдається прочитати, пропускається й називається на ім'я. За бажанням контейнери зупиняються або виконується команда лише на мить знімка. Томи (volumes) не входять: том VM зберігається разом з її VM, том без VM поки не зберігається. Див. Набори даних ZFS.

Відновлення

Кероване відновлення проводить свіжу установку через аварію в одному місці.

• Повне відновлення в один клік. Виберіть знімок, натисніть Відновити. Готово.
• Одна часова шкала для кожного елемента. Контейнери, VM, набори файлів, flash і конфігурація додатка перелічують свої резервні копії як одну часову шкалу за кожним місцем, де вони лежать, репозиторієм, куди їх записано, і кожною зовнішньою ціллю. Резервна копія, скопійована назовні, з'являється один раз, позначена кожним місцем. Зовнішні місця читаються, коли ти їх відкриваєш, а видалення в одному місці повідомляє, чи була це остання копія.
• Контейнери перевстановлюються автоматично. Визначення контейнера відтворюється через Docker API, тож контейнер знову з'являється на вкладці Docker в Unraid точно таким, як був.
• GPU, ліміти та посилання повертаються. Відновлений контейнер отримує назад свої ліміти ресурсів, драйвер журналів, налаштування DNS, застарілі посилання та свій GPU або середовище виконання (--gpus, --runtime=nvidia). На хості без цього драйвера GPU чи середовища виконання відновлення про це повідомляє й пропонує Відновити без GPU та середовища виконання, зокрема після відновлення кількох контейнерів або стека. Посилання на контейнер, якого немає або який зупинений під час запуску відновленого, пропускається, і історія запусків про це повідомляє.
• Віртуальні машини відтворюються автоматично. XML повторно імпортується через SSH, тож VM знову з'являється у VM Manager з повторно приєднаними диском та UEFI NVRAM, навіть після того, як VM була видалена. Знайти резервні копії відбудовує запис, який зник повністю (наприклад після свіжого встановлення).
• Індивідуальне відновлення. Відновіть один контейнер, одну VM чи один набір файлів, не торкаючись інших.
• Відновлення flash, це завантаження .zip. Воно потоково передається у ваш браузер як flash-<id>.zip, готове для передачі у створювач USB Unraid. Робоча /boot ніколи не зачіпається.
• Плагіни по одному. Сторінка Flash показує плагіни з кожної копії флешки з версією та розміром і повертає один плагін на робочу флешку: його файл .plg, його теку в config/plugins і файли пакетів, які є в копії. Більше на флешці нічого не змінюється. Unraid встановить плагін під час наступного завантаження або одразу через Plugins, Install Plugin.
• Запланований експорт flash у zip. Після кожного резервного копіювання flash за бажанням записуйте знімок як звичайний .zip до вибраної теки (єдиний перезаписуваний flash-latest.zip або накопичувальна історія). Спрямуйте його на теку Syncthing чи rclone, щоб резервна копія завантажувальної USB автоматично залишала сервер.
• Передпольотна перевірка конфліктів. Перш ніж щось буде зупинено чи видалено, відновлення перевіряє, що статична IP контейнера та опубліковані порти хоста вільні, і перериває роботу з чітким повідомленням замість того, щоб залишити напівзавершене відновлення.
• Перевірки перед відновленням. Кожне вікно відновлення спершу перевіряє, що репозиторій відповідає, що збережений ключ його відкриває, що точка відновлення є і що в місці призначення вистачить місця для того, що запише відновлення. Кнопка запуску заблокована, доки хоч одна перевірка не пройдена, а (i) на кнопці каже, яка.
• План відновлення. Перед підтвердженням вікно показує, що зробить відновлення порівняно з поточним станом: нові, замінені й незмінні файли, список на запит, і файли в місці призначення, яких немає в копії і які лишаються на місці. Для контейнерів і ВМ воно також порівнює налаштування, які створить відновлення, з робочими: образ і тег, порти, назви змінних і томи або пам'ять, vCPU, диски й мережу. restic обчислює це пробним запуском за розміром і часом зміни, не читаючи файли; дуже велике дерево зупиняється через 30 секунд і повідомляє про це. Відновлення стека перевіряє і планує кожного учасника та називає того, хто його блокує.
• Спільні теки. Відновлення на місце називає кожен інший контейнер, запущений чи ні, чиє підключення сягає теки, у яку воно пише, наприклад «цей шлях також використовує nextcloud-db». Це попередження, воно нічого не блокує.
• Відновлення на рівні файлів. Розгорніть Файли знімка контейнера, відфільтруйте, позначте будь-яку кількість файлів і тек, потім відновіть вибране на місці або до вибраної теки.
• Відновлення набору файлів. Відновіть знімок набору файлів на місці (після явного підтвердження) або до вибраної теки, ніколи мовчки. Вибіркове відновлення працює й тут.
• Відновлення набору даних ZFS. Відновіть один набір даних елемента на місце (після страхувального знімка ZFS, який лишається, доки ви його не видалите), у теку або лише вибрані файли, чи всі набори резервної копії в теку. Набір даних ніколи не відкочується і не замінюється.
• Відновлення зберігає стан запуску. Контейнер чи VM, який працював під час резервного копіювання, повертається запущеним; той, що був зупинений, залишається зупиненим. Позначте Залишити зупиненим після відновлення, щоб відтворити без запуску.
• Відновлення цілого стеку. Контейнери з одного проєкту Docker Compose групуються в панель Стеки. Відновити стек… відбудовує кожного учасника з його останньої резервної копії залишеним зупиненим, потім за бажанням запускає їх у порядку depends_on.
• Живий прогрес, скасування та зворотний зв'язок про зайнятість. Довге відновлення показує живу смугу відсотків і може бути скасоване з підтвердженням, що враховує тип. Скасоване відновлення записується як скасоване, а не як помилка.
• Кероване відновлення. Спеціальна вкладка Відновлення проводить свіже встановлення через сценарій катастрофи. Див. Зовнішнє копіювання та відновлення.
• Відновлення з іншого репозиторію BombVault. Одноразова сесія лише для читання відкриває репозиторій іншого екземпляра BombVault з APP_KEY того екземпляра, тож ви можете витягнути контейнер із сервера A на сервер B, не торкаючись власних налаштувань. Див. Зовнішнє копіювання та відновлення.
• Властивості ZFS повертаються. Кожна копія ZFS зберігає локально задані властивості кожного набору даних, наприклад стиснення, розмір запису, квоту та чутливість до регістру. Відновлення в новий набір даних створює його з ними, а відновлення в наявний показує їх і задає лише на ваше бажання. Див. Набори даних ZFS.
• Імпорт із плагіна Appdata.Backup. На сторінці Відновлення вкажіть BombVault теку резервних копій плагіна. Кожен архів контейнера стає точкою відновлення свого контейнера з датою, коли плагін його створив. Уже імпортовані архіви пропускаються, а самі архіви лише читаються. Контейнеру спершу потрібна одна резервна копія в BombVault, щоб відновлення мало його опис. Зберігання не видаляє імпортовані точки відновлення, тож непотрібну видаліть самі.

Зберігання та планування

• Інкрементні, дедупліковані резервні копії через restic, тож навіть великі диски VM не роздувають репозиторій.
• Місця призначення: локальний шлях або зовнішнє. Спільні ресурси SMB і сервери WebDAV (Nextcloud, ownCloud, SharePoint) просто з форми в Налаштування, Хмарний доступ, rclone, без монтування на хості; NFS (змонтуйте експорт на Unraid і вкажіть на нього Шлях резервних копій); нативні бекенди restic без rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo) або будь-яке віддалене сховище rclone через rclone:<remote>:<bucket>/path. Усі облікові дані зберігаються зашифрованими.
• Цілі SSH не потребують нічого встановленого на дальньому боці. sftp: вимагає лише SSH-сервера, тож голий Raspberry Pi (без Docker, без restic) працює як зовнішнє місце призначення. Ключі хоста автоматично закріплюються під час першого контакту.
• Зовнішнє копіювання (локальне + віддалене). Зберігайте швидку локальну резервну копію та додайте одну чи кілька зовнішніх реплік, що реплікуються командою restic copy за принципом найкращих зусиль (збій зовнішнього ніколи не провалює локальне резервне копіювання). Кожен домен має власний зовнішній розклад, плюс кнопка Реплікувати зараз.
• Кілька зовнішніх цілей для домену. Кожен домен (контейнери, VM, flash, config, набори файлів і набори даних ZFS) може реплікуватися на кілька зовнішніх місць призначення одночасно, не лише на одне. Додайте додаткові цілі на сторінці Зовнішнє, кожна з власним репозиторієм, класом сховища S3, прапорцем append-only, зберіганням і бюджетом росту. Ваша наявна зовнішня копія переноситься як перша ціль, тож нічого не змінюється, поки ви не додасте другу, і кожна ціль домену реплікується за зовнішнім розкладом цього домену.
• Іменовані репозиторії. Запишіть місця зберігання резервних копій один раз у Налаштування, Сховище, Репозиторії (локальний шлях або будь-яке віддалене сховище restic із власним набором облікових даних), а потім виберіть один із них як розташування елемента на його картці. Рядок показує, скільки елементів на нього посилається, а репозиторій, який використовує елемент або розміщення за замовчуванням, не можна перемістити чи видалити, бо BombVault ніколи не переміщує вже записану резервну копію.
• Кілька наборів хмарних облікових даних. Спільні хмарні облікові дані типово діють усюди, але будь-яке призначення може натомість вибрати іменований набір облікових даних (Налаштування, Хмарний доступ, Додаткові набори облікових даних), тож бакет Hetzner S3 і локальний сервер Garage працюють пліч-о-пліч, кожен із власним ключем. Це стосується і зовнішніх цілей, і шляху резервних копій, який сам є віддаленим репозиторієм.
• Місця призначення. Зовнішнє місце призначення налаштовується один раз через майстер, який перелічує сервіси зберігання S3, твій власний сервер S3, твій власний сервер і спільні ресурси та всі хмарні сховища, які підтримує rclone, із входом, перевіркою з'єднання, вибором теки та чесним словом про захист від видалення. Потім воно з'являється кнопкою в кожному домені й елементі. Див. Місця призначення.
• Розміщення для кожного елемента. Кожна картка контейнера, VM і набору файлів має ряд кнопок, Локально і по одній на кожну зовнішню ціль, а підсвічені отримують її резервні копії. Спільному ресурсу, що вже лежить на NAS, більше не треба ще й на B2. Розташування фіксується від першої резервної копії, копії можна змінювати будь-коли, а картка повідомляє, скільки сайтів тримають елемент і чи дотримано 3-2-1. Див. Розміщення для кожного елемента.
• Розміщення за замовчуванням. Один рядок на домен визначає, куди записуються нові елементи і на які цілі копіюються елементи без власного вибору. Його зміна не переміщує жодної резервної копії і заздалегідь повідомляє, які цілі отримають чи втратять елементи.
• Ручний порядок резервного копіювання. Задайте точний порядок, у якому резервуються ваші контейнери, з панелі порядку резервного копіювання на сторінці Контейнери. Заплановані запуски та запуски з множинним вибором його дотримуються; будь-який контейнер, який ви залишите невпорядкованим, зберігає попередню поведінку спочатку найбільш прострочене, а окреме резервне копіювання контейнера незмінне.
• Налаштовуване зберігання: keep-last / щоденні / щотижневі / щомісячні / щорічні, очищаються автоматично після кожного резервного копіювання, задаються для кожного джерела (і локальне, і зовнішнє на Налаштування, Зберігання, тож ви можете зберігати зовнішні копії довше як архів). Кожне джерело також може мати власні правила, локально і для зовнішньої копії (Правила зберігання за джерелом), наприклад 7 щоденних копій для контейнерів, що змінюються щодня, і менше для VM, що змінюються рідко.
• Стиснення для кожного репозиторію: Вимкнено, Автоматично (типове значення restic) або Максимально, задається на Налаштування, Сховище для кожного шляху резервних копій і кожного іменованого репозиторію та на Налаштування, Зовнішнє для кожного зовнішнього призначення. Резервне копіювання, зовнішні копії й очищення пишуть із ним, а набір відновлення його називає, щоб звичайний restic міг і далі писати так само.
• Планування для кожного домену (щоденне / щотижневе, включно з наборами на кілька днів / кожні N днів / сирий cron), усе редагується в одному місці в Налаштування, Розклади. Окремий контейнер, VM, набір папок або елемент ZFS може мати власну періодичність, а Кожні N днів працює також для тренування відновлення, тесту на втручання та щотижневого підсумку.
• Чекати, доки застосунок простоює. Контейнер може змусити свою заплановану копію чекати, поки застосунок зайнятий, не довше за задану кількість годин, і запускати її, щойно застосунок простоює. Медіасервер простоює, коли не веде стрімінг, будь-який інший контейнер, коли його CPU і трафік кілька хвилин лишаються нижче меж із Налаштування, Розклади (у мережі хоста враховується лише CPU). Копія, що чекає, видна в журналі активності та на контейнері з причиною і терміном. Вона не тримає блокування, тож інші контейнери йдуть далі. Ручні копії ніколи не чекають. Учасники compose-стека, чия черга в тому самому запуску, чекають разом, а очікування після перезапуску триває зі своїм терміном. Якщо вимкнути контейнери, усі копії в очікуванні скасовуються, а якщо вимкнути їхній розклад, скасовуються ті, що затримали його запуски. Менша кількість годин скорочує й очікування, яке вже почалося.
• Обмеження пропускної здатності зовнішнього. Обмежте швидкість вивантаження/завантаження restic, щоб реплікація не насичувала ваш WAN.
• Спершу стрімінг. Поки медіасервер на кшталт Plex, Jellyfin чи Emby веде стрімінг, зовнішні копії вивантажуються зі зниженим лімітом і повертаються до звичайного за кілька хвилин після кінця потоку. BombVault читає вихідний трафік медіасерверів із Docker. REST, S3, B2, Azure, Google Cloud, Swift і rclone через HTTP сповільнюються просто під час копіювання; SFTP та локальні чи змонтовані теки отримують знижений ліміт на наступному кроці копіювання. Медіасервер у мережі хоста виміряти не можна. У Налаштування, Зовнішнє.
• Клас холодного та архівного сховища (S3). Для нативного зовнішнього репозиторію S3 ви можете вибрати клас сховища, обмежений рівнями, придатними для читання під час відновлення (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval), тож архівна тарифікація ніколи мовчки не зламає відновлення. Рівні глибокого архіву, які спершу потребують асинхронного розморожування (Glacier Flexible, Deep Archive), навмисно не включені. Лише нативні бекенди S3; віддалені сховища rclone задають свій клас у конфігурації rclone.
• Теки резервних копій залишаються придатними для копіювання поза машиною. Після кожного резервного копіювання BombVault послаблює локальне дерево репозиторію до каталогів 0755 / файлів 0644 (репозиторії зашифровані, тож нічого не виставляється), тож не-root користувач синхронізації через SMB не залишається заблокованим. Визначення для відновлення живуть усередині кожного репозиторію, тож скопійована тека репозиторію повністю самодостатня.

Аналітика, перевірка та моніторинг

• Пауза просто з картки. На кожній картці контейнера, VM і набору тек є Призупинити розклад, що прибирає елемент із розкладу та з Backup Everything, і Відновити розклад, щоб повернути його. Вони перемикають той самий вимикач, що й Включити до розкладу, тому завжди узгоджені. Елемент на паузі має сірий значок Розклад призупинено, а Створити резервну копію працює й надалі.
• Статус захисту (RPO). Панель показує зелений / жовтий / червоний індикатор для кожного домену, порівнюючи останню успішну резервну копію з її розкладом, тож прострочене резервне копіювання стає червоним замість того, щоб ховатися в журналі.
• Теплокарта стану резервних копій. Календар результатів резервного копіювання за день для кожного домену у стилі внесків GitHub, з перемикачем Контейнери / Віртуальні машини / Flash / Автобекап / Папки.
• Хронометраж запусків усюди. Кожен запис в історії запусків читається як початок, кінець (тривалість), а кожен контейнер і VM несе власний список Останні запуски на своїй сторінці.
• Панель, яку можна переставляти. Увімкніть режим налаштування, щоб перетягнути картки у свій порядок і приховати ті, що вам не потрібні. Розкладка зберігається для кожного браузера.
• Розмір репозиторію та тренд дедуплікації. Поточний розмір репозиторію, коефіцієнт дедуплікації та кількість знімків для кожного домену, зі спарклайном росту сховища.
• Тренування перевірки відновлення. BombVault періодично доводить, що ваші резервні копії можна відновити (restic check --read-data-subset, обмежено) і показує значок Відновлюваність підтверджено для кожного домену.
• Перевірка відновлення після першої копії. Коли перша резервна копія елемента готова, BombVault відновлює з неї вибірку (до 100 файлів і 256 МіБ) у тимчасову теку всередині теки відновлення, змушує restic перечитати кожен файл за його хешами й порівнює розміри з копією. Для файлу, завеликого для вибірки, наприклад диска ВМ, натомість перечитуються перші 64 МіБ. Картка елемента показує результат, збій надходить сповіщенням, а Перевірити відновлення запускає ту саму перевірку найновішої копії будь-коли. Наступні копії її не повторюють.
• Тест запуску. Перевірка байтів не показує, що застосунок знову запрацює. Тест запуску на картці контейнера відновлює найновішу копію в ізольовану копію й запускає її: ім'я починається з bombvault-test-, власна внутрішня мережа Docker без опублікованих портів і без виходу в LAN, 1 CPU і 2 ГіБ пам'яті, дані в тимчасовій теці всередині теки відновлення. Тест пройдено, коли перевірка здоров'я контейнера повідомляє про справність, без неї коли перший відкритий порт відповідає зсередини цієї мережі, а без обох коли контейнер продовжує працювати. Вихідний контейнер ніколи не зупиняється й не змінюється, а копія, її мережа й дані видаляються після тесту, навіть якщо BombVault перезапуститься посеред нього. Контейнери в мережі хоста, привілейовані, з пристроями та ті, що залежать від іншого контейнера, позначаються як неперевірювані. Увімкніть Тест запуску в запланованих перевірках відновлення, щоб за кожен запуск перевірявся один контейнер, починаючи з того, що перевірявся найдавніше. Результат видно на картці та на панелі. Копія не має жодної мітки оригіналу й працює без capabilities, параметрів безпеки, sysctl і cgroup parent, які додає оригінал. Контейнер, якому вони потрібні, не проходить тест, і в результаті зазначено, без чого працювала копія.
• Самовідновлювані операції. Доказово осиротіле блокування restic (залишене перезапуском посеред операції) примусово очищується та повторюється один раз, автоматично. Зберігання стабільне за ідентичністю (очищається для кожного елемента, стійке до змін шляху чи хоста), а збій зберігання надсилає сповіщення.
• Попередження, яких не бачить сканування тек. Помічник виключень відповідає на питання про розмір. Деякі з найдорожчих помилок резервного копіювання з розміром не пов'язані, тож він також містить попередження про те, як конкретний застосунок зберігає свої дані. Те, заради якого він існує: Immich зберігає альбоми, обличчя й дати кожної фотографії в базі даних PostgreSQL, що працює в окремому контейнері, тож файлова резервна копія контейнера Immich відновлює фотографії без усього цього, і відновлення виглядає вдалим. Попередження показується незалежно від того, чи пропонується якесь виключення, зокрема на контейнері, у якого нічого не вибрано для сканування, бо воно правдиве в будь-якому разі.
• Без резервної копії (покриття). Картка на Панелі, що називає все на сервері, чого не покриває жодна автоматична резервна копія, з причиною для кожного: взагалі не додано до BombVault, є, але не включено до розкладу, власний розклад вимкнено або розклад ніде не ввімкнено. Індикатор захисту над нею відповідає на інше питання, а саме, чи виконалися вчасно ті резервні копії, які заплановано, і він не бачить контейнер, який ніхто ніколи не налаштовував: його немає в жодному списку й жодній помилці, тож через нього нічого не стає жовтим. Контейнери зчитуються з живого списку Docker, а не з власних записів BombVault, бо елемент без запису і є тим, який треба назвати. Тип резервних копій, який ви вимкнули, повністю виключається з підрахунку, адже це був ваш вибір.
• Попередній перегляд зберігання. Панель поруч із налаштуваннями зберігання показує, що наступний запуск збирається видалити, ще до того, як це станеться: за репозиторіями й за елементами, з названими точками відновлення. Вона не бере блокування репозиторію і нічого не змінює, тож відповідає навіть під час резервного копіювання. Якщо зберігання вимкнено, вона так і каже, а не показує порожній список, репозиторій append-only позначено як такий (зберігання там не виконується взагалі), а недосяжний репозиторій називається, а не зникає мовчки. У Налаштування, Зберігання і для локальної, і для зовнішньої політики, кожна зі своїм попереднім переглядом.
• Аномалії. Кожна резервна копія контейнера, ВМ, набору тек, дампу бази даних, флешки та самокопії порівнюється з власною історією цього елемента. Перевірки дивляться на нові дані запуску порівняно з найбільшими звичними обсягами останніх копій і зі звичною швидкістю за годину; на копію, яка заново зберегла більшу частину даних, зокрема перейменовані й переписані файли; на розмір джерела та кількість файлів, які restic повідомляє для кожного елемента й кожного дампу; на власний час копіювання restic; на серії збоїв і періодичні збої; на перевірки відновлення, які перестали проходити; і на вільне місце локальних репозиторіїв, репозиторіїв SFTP і репозиторіїв rclone, спрогнозоване за зростанням репозиторію. Елемент навчається на своїх перших 10 копіях, а майже порожнє джерело, перезапис більшої частини даних і збої перевіряються від самого початку. Під час оновлення історію один раз зчитують зі зведень знімків, які зберігає restic 0.17, тож наявна інсталяція не починає з нуля. Чутливість (Сувора, Збалансована, Мʼяка) і мінімальну важливість, за якої надсилається сповіщення, задають глобально в Налаштування, Цілісність і змінюють для окремого елемента. Попередження закриваються самі, коли причина зникла; критичні знахідки про втрачені дані й диск, що заповнюється, лишаються, доки ви їх не підтвердите, а підтверджена знахідка не повідомляється знову, доки її причина хоч раз не зникне. Позначити як очікуване робить новий рівень нормою після 10 копій, але ніколи не вимикає перевірку майже порожнього джерела, а після зміни вибору історія елемента сама починається заново. Поки джерело майже порожнє, сильно зменшилося або копія заново зберегла більшу частину даних, зберігання лишає старі копії цього елемента, доки ви не підтвердите знахідку або не позначите її як очікувану, а знахідка посилається на останню добру копію. Сповіщення надходить один раз за епізод, а збої й перевірки відновлення, які вже сповіщають самі, не повідомляються двічі. Чого функція не робить: репозиторії S3, B2 і REST не мають даних про вільне місце, на користувацькій спільній теці Unraid вільне місце стосується всього масиву, а копії, зроблені до restic 0.17, не мають історії розмірів. Елементи ZFS теж перевіряються, набір даних за набором: кожен набір даних дерева має власну історію, набір, який спорожнів або більше не читається, вважається втратою даних, і зберігаються лише старі копії цього набору. Як елемент ZFS перевіряється за кожним набором даних, описано в розділі Набори даних ZFS, а асистент може прочитати відкриті аномалії через сервер MCP. Знахідка про розмір або кількість файлів джерела датується першою копією, у якій вона з'явилася, а Порівняти з попередньою копією показує теки, де файли зникли, з'явилися або змінилися, з приміткою, коли майже все лежить у пошуковому індексі, кеші або мініатюрах, які застосунок сам створює заново.
• Рекомендовані винятки для застосунків. Для відомих образів (Plex, Jellyfin, Emby, Sonarr, Radarr, Lidarr, Readarr, Prowlarr, Immich, Nextcloud, PhotoPrism і Tautulli від linuxserver, hotio, binhex або офіційного видавця) Помічник виключень пропонує теки, які застосунок сам знову заповнює: кеші, журнали, зображення попереднього перегляду й постери. Кожен пункт каже, що в ньому, будь-який можна вимкнути, і нічого не виключається, доки ви не натиснете Виключити вибране.
• Пакет для підтримки. ZIP без секретів в один клік для звіту про помилку: перевірка інтеграції з хостом, ваша конфігурація без жодного секрету, останні запуски, що заплановано далі, і свіжий журнал. Він також містить, як минув останній дамп кожної бази даних, елементи ZFS із точками монтування, які бачить контейнер, відкриті аномалії та скільки існує ключів MCP (але ніколи їхні імена). Паролі, токени, конфігурація rclone, облікові дані сповіщень і будь-який пароль, вбудований у розташування репозиторію, видаляються, і пакет сам повідомляє про це у своєму маніфесті, бо файл для підтримки ніколи не можна сплутати з резервною копією конфігурації. З тієї ж причини, що й набір для відновлення, він вимагає пароль входу. Журнал у ньому охоплює вивід цього контейнера від його останнього запуску; при збої, який перезапустив контейнер, дивитися треба в docker logs.
• Набір для відновлення ключа шифрування. Завантаження в один клік головного ключа, похідного пароля restic та точних розташувань репозиторіїв і команд, тож ви можете відновити без запущеного BombVault. Див. Зовнішнє копіювання та відновлення.
• Експорт та імпорт ваших налаштувань. Картка Експорт / імпорт налаштувань на сторінці Налаштування, Система записує всю вашу конфігурацію (налаштування доменів, зовнішні цілі, розклади, зберігання, сповіщення) до портативного файлу JSON, тож перехід на нову машину чи клонування налаштувань не означає повторне введення всього вручну. Ви вибираєте, чи включати зовнішні облікові дані та облікові дані сповіщень; з ними файл настільки ж чутливий, як ваш набір для відновлення. Імпорт показує попередній перегляд і запитує підтвердження, і він ніколи не торкається ваших даних резервних копій чи історії.
• Сповіщення. Webhook (Discord / Slack / Gotify / ntfy), Matrix, Healthchecks.io, електронна пошта (SMTP), самостійно розміщений сервер Apprise API та власна система сповіщень Unraid. Політика для кожної резервної копії: ніколи / у разі збою / завжди. Запланований запуск багатьох елементів може надіслати один підсумок N з M успішно. Healthchecks отримує повний життєвий цикл (/start, потім успіх або /fail), щойно задано URL.
• Щотижневий підсумок. Одне повідомлення на тиждень тими самими каналами: кількість запусків, скільки нових даних резервних копій надійшло, чи актуальна зовнішня копія, і основні збої. Типово вимкнений, власна періодичність задається в Налаштування, Сповіщення, тож про спокійний тиждень теж приходить повідомлення.
• Prometheus /metrics. За вибором (за замовчуванням вимкнено, необов'язковий bearer-токен) для Grafana чи Uptime Kuma. Надає статус резервних копій, розміри та мітки часу, без секретів чи шляхів у мітках.
• HTTP API, Home Assistant і mDNS. Скрипти й дашборди отримують API за адресою /api/v1 з іменованими токенами, лише для читання або з правом запускати резервне копіювання. Home Assistant знаходить BombVault через MQTT discovery як пристрій із датчиками та, якщо ви це дозволите, кнопкою резервного копіювання для кожного домену. А в мережі BombVault оголошує себе як bombvault.local. Див. API та інтеграції.
• Вільне місце і тижні до заповнення. Локальні репозиторії, репозиторії SFTP і призначення SMB або WebDAV, які повідомляють вільне місце, показують його і скільки тижнів залишилося за поточного росту. Репозиторії S3, B2 і REST пишуть "Вільне місце невідоме", бо ці бекенди його не повідомляють.
• Розмір за теками. У розділі «Резервні копії» контейнера, ВМ або набору тек пункт Розмір за теками показує, які теки й файли займають місце в найновішій копії та скільки з цього остання копія принесла нового чи зміненого, по одному рівню за раз. BombVault читає це з індексу репозиторію, не читаючи самих файлів, і після першого відкриття оновлює після кожної копії.
• Чому копія йшла повільно. Під час копіювання BombVault стежить, наскільки завантажені процесор, диски й мережа. Якщо копія триває значно довше, ніж зазвичай, і одна річ явно впиралася в межу, запуск про це повідомляє, наприклад «Цільовий диск disk1 був завантажений на 98%» або «BombVault використав 100% ліміту процесора свого контейнера». Інакше він нічого не повідомляє.
• Змінено після останньої копії. Контейнер, який після останньої копії створили заново з іншим образом, портами, змінними чи томами, отримує позначку біля назви. Його (i) перелічує зміни, змінні лише за назвою. Це лише примітка, вона зникає після наступної копії.

Захист від програм-вимагачів

• Незмінне (append-only) зовнішнє. Позначте зовнішній репозиторій як append-only, щоб програма-вимагач чи скомпрометований хост не могли видалити чи переписати ваші резервні копії. Дальній бік (restic/rest-server у режимі --append-only) забезпечує це; BombVault лише завжди перевіряє це й ніколи не показує зелений на основі самого лише твердження конфігурації.
• Тест на втручання. BombVault періодично доводить гарантію append-only, фактично намагаючись виконати видалення проти зовнішнього репозиторію (націлене на неіснуючий об'єкт): відмовлено означає захищено, прийнято означає не захищено. Непереконливий результат ніколи не перевертає збережений вердикт.
• Кероване налаштування зовнішнього. Майстер проводить вас від вибору бекенда через готовий до вставлення фрагмент розгортання rest-server, тест з'єднання, перемикач незмінності та стратегію зберігання.
• Тренування DR (зовнішні). Відновіть реальну ціль із зовнішнього репозиторію в одноразову пісочницю, перевірте її файл за файлом і байт за байтом, потім приберіть. Див. Зовнішнє копіювання та відновлення.
• Оціночна картка захисту від програм-вимагачів. Картка на Панелі з зеленою / жовтою / червоною позицією для кожного домену та контрольним списком з мітками віку; кожен червоний рядок веде глибоким посиланням до виправлення. Вона стає зеленою лише на перевірених фактах.
• Сигнал бюджету росту. Для незмінного зовнішнього (де старі знімки навмисно ніколи не очищаються) задайте бюджет розміру й отримуйте сповіщення, перш ніж він вийде з-під контролю.
• Спарювання за фразою. Екземпляри приєднуються до однієї групи дванадцятьма словами: створіть фразу на одному, введіть її на наступному. Учасники в одній мережі розмовляють напряму, інші через ретранслятор (проєктний, власний або жоден), і кожен виклик між ними наскрізно зашифрований. Група несе оціночні картки сторінки Екземпляри, пропозиції виносного сховища Mesh і те, що потрібно приймачу чи джерелу Стягування, ніколи дані резервного копіювання і ніколи APP_KEY. Див. Зовнішнє копіювання та відновлення.
• Сторінка Екземпляри. Увімкніть Екземпляри в Налаштуваннях, і з'явиться сторінка з карткою для кожного екземпляра вашої групи, включно з цим: його адреса, чи є з ним зв'язок, і стан захисту кожного домену з останньою резервною копією, тим самим червоним, жовтим і зеленим, що показує локальна Панель. Перевірити зараз просить учасника перевірити репозиторій одного домену. Ніщо на цій сторінці не може запустити резервне копіювання, відновлення чи видалення на іншій машині.
• Зовнішнє копіювання через Mesh. Учасник може через групу запропонувати своє зовнішнє сховище іншому учаснику. Адміністратор іншого боку бачить пропозицію на сторінці Екземпляри і приймає або відхиляє її; прийняття створює звичайний набір облікових даних і зовнішню ціль. Цим шляхом передаються лише дані для підключення, ніколи дані резервних копій.
• Панель отримувача (бік прийому). На машині, яка отримує незмінні зовнішні копії від іншого BombVault, увімкніть перемикач Приймач (Налаштування), щоб відкрити вкладку Приймач. Зареєструйте отриманий репозиторій лише для читання (відкритий паролем restic екземпляра-відправника, який надходить через групу спарювання), щоб побачити його інвентар знімків, згрупований за джерелом, коли кожне джерело востаннє надходило, і запустити незалежний restic check на приймальному обладнанні. Вона сповіщає вас, коли джерело перестає надсилати протягом заданого вами вікна (запобіжник) або коли перевірка цілісності не проходить. Строго лише для читання, тож вона ніколи не пише в отриманий репозиторій, і вимкнена за замовчуванням. Див. Зовнішнє копіювання та відновлення.
• Стягування з іншого екземпляра (бік, що забирає). Дзеркальне відображення зовнішньої реплікації: замість того щоб ця машина надсилала свої знімки назовні, вона забирає до себе чужі. Увімкніть перемикач Стягування (Налаштування), щоб відкрити вкладку Стягування на сторінці Екземпляри, виберіть інший екземпляр зі своєї групи спарювання та розташування його репозиторію, потім укажіть, який вид резервних копій він містить і як часто забирати. Його пароль restic надходить через групу, але ніколи його APP_KEY. Дальньому боку більше нічого налаштовувати не треба, і він не мусить бути запущеним. Вихідний репозиторій лише читається: його відкривають для перевірки пароля, перелічують і вказують як джерело копії, але ніколи не ініціалізують, не розблоковують, не очищують і не записують. Кожен бік зберігає власні облікові дані, а джерело rclone: відхиляється, бо rclone звертався б до нього через віддалені сховища цього екземпляра. Див. Зовнішнє копіювання та відновлення.

Звичайні експорти

• Звичайний експорт контейнера. Кнопка Експорт (звичайний tar) для кожного контейнера записує придатну для перегляду копію без інструментів поруч із репозиторієм: <name>.tar.gz тек резервної копії плюс шаблон Unraid <name>.xml. Restic залишається механізмом; це додаткова зручна копія.
• Звичайний експорт VM. VM мають той самий Експорт (звичайний tar): <name>.tar.gz образу(ів) диска плюс <name>.xml, відновлюваний за допомогою virsh define плюс диск, без потреби в BombVault чи restic.
• Шифрування звичайних експортів (age). Експорти лежать поза restic, тож вони за замовчуванням у відкритому тексті. Увімкніть шифрування age в Налаштуваннях і додайте одного чи кількох отримувачів (публічний ключ age або публічний ключ SSH). Кожен експорт (.tar.gz контейнера та VM, їхні супутні файли .xml і flash ZIP) потім запечатується для цих отримувачів, і ви розшифровуєте його пізніше поза машиною відповідним приватним ключем. Як правило безпеки, з увімкненим шифруванням і без заданого дійсного отримувача експорт завершується помилкою з чітким повідомленням замість того, щоб коли-небудь записати відкритий текст.
• Набір для відновлення теж запечатується. З тим самим увімкненим налаштуванням набір завантажується як bombvault-recovery-kit.md.age. Він у текстовій формі ASCII-armor, а не двійковий, тож лишається звичайним читабельним текстом: його й далі можна вставити в менеджер паролів або надрукувати, для чого набір і існує. Діє те саме правило безпеки: з увімкненим шифруванням і без придатного отримувача завантаження відхиляється, а не відкочується до видачі головного ключа у відкритому вигляді. Одне треба зробити правильно, коли ви це вмикаєте: щоб відкрити набір, потрібен ваш приватний ключ age, тож зберігайте цей ключ там, де він не залежить від самого набору.

ШІ-асистенти (MCP)

У BombVault вбудовано сервер MCP, через який асистент на кшталт Claude Code або Claude Desktop може читати стан резервних копій, покриття, історію запусків, точки відновлення й поточну активність. З ключем, який це дозволяє, асистент може також запустити копіювання одного елемента, одного домену або всього одразу й скасувати копіювання, які запустив сам. Відновлення, видалення, prune і налаштування залишаються у вебінтерфейсі. Кожен клієнт отримує власний ключ у Налаштування, Інтеграції, Сервер MCP; ключ показується один раз, зберігається лише як відбиток, і його можна будь-коли перейменувати, замінити або відкликати. Запуски обмежено на годину й на елемент, а захист зберігання не дає копіям асистента витіснити ваші власні точки відновлення з політики "зберігати останні N". Кожен запуск, зроблений асистентом, позначається "через MCP" з назвою ключа. Див. Сервер MCP. Дампи баз даних і набори даних ZFS входять до елементів і точок відновлення, які він читає, і він може вивести аномалії, помічені BombVault.

Застосунки та компаньйони

• Застосунок для Android. Усі сервери вашої групи на телефоні, з журналом активності їх усіх на одному екрані. Він спарюється з вашою групою за QR-кодом і відкриває кожен сервер уже з виконаним входом. Див. Застосунок для Android.
• Приймальний сервер. Машина, що приймає зовнішні копії, може одним клацанням запустити rest-server в режимі append-only і запропонувати його іншим екземплярам вашої групи, кожному зі своїм логіном. Див. Приймальний сервер.
• Налаштування, Застосунки. Сторінка, що починається із застосунку для Android, його APK для випуску, на якому працює сервер, і QR-коду до нього, а далі йдуть картки для кожного компаньйона. Картка ParleyPort пропонує його шаблон Unraid, копіює команду Docker, яка його запускає, і веде до його репозиторію та до налаштувань ретранслятора в розділі Спарювання. Картка BombVault Widget пропонує його шаблон і репозиторій, а також встановлює або видаляє плагін через SSH-з'єднання з хостом.
• BombVault Widget. Плитка на панелі Dashboard в Unraid із журналом активності BombVault і наступним запланованим запуском. Без SSH-з'єднання з хостом картка дає адресу .plg для встановлення в Plugins, Install Plugin, і видалити плагін там можна, як будь-який інший.
• Вбудовуваний журнал активності. Створіть токен лише для читання в Налаштування, Інтеграції, і ви отримаєте адресу для будь-якого дашборду, що показує iframe, наприклад Homepage, Organizr чи Heimdall: маленьку сторінку лише з живим журналом активності. Токен дає доступ до цього журналу й більше ні до чого, а Вимкнути одразу його відкликає. Вбудована сторінка доступна лише англійською.

Інше

• Зупинка резервного копіювання, що триває. Кожна картка, яка може запустити резервне копіювання, поки запуск активний, має поруч зі смугою прогресу кнопку Скасувати резервне копіювання. Запуск записується як скасований, а не як невдалий. Зупинка безпечна, бо restic записує знімок останнім, і перерваний запуск залишає лише дані без посилань і жодного знімка.
• Резервне копіювання багатьох одночасно. Виберіть кілька контейнерів і натисніть Створити копію вибраних. Пакет виконується на стороні сервера, тож він продовжується, навіть якщо ви закриєте вкладку чи втратите з'єднання. BombVault ніколи не робить резервну копію (і тому ніколи не зупиняє) власний контейнер.
• Браузер знімків зі списком точок відновлення, видаленням для кожного знімка та згортуваним деревом тек для відновлення на рівні файлів.
• Обслуговування репозиторію для кожного домену: Перевірити (restic check), Розблокувати (очистити застаріле блокування) та Очистити (застосовує політику зберігання за запитом, коли вона задана, інакше просте звільнення місця).
• Поступ перевірки, перевірок відновлення й очищення. Поки виконується одна з них, журнал активності та картка цілісності показують, докуди дорахував restic, наприклад 12 з 47 пакетів, а щойно даних досить для оцінки, і час, що лишився на цьому етапі. Тут restic рахує пакети, знімки й файли індексу, а не байти, тож смуга показує саме їх; до першого підрахунку вона рухається без числа.
• Автоматичні дампи баз даних. Розпізнані контейнери PostgreSQL, MySQL і MariaDB (офіційні образи, PostGIS, TimescaleDB, pgvector, pgautoupgrade, образи баз даних Immich, linuxserver, yobasystems і jc21 MariaDB, а також mysql-server від Oracle) вивантажуються перед кожним резервним копіюванням із запущеного сервера. Контейнери, які лише схожі на базу даних, отримують ту саму опцію на своїй картці, вимкнену, доки ви її не оберете. Дамп тече просто в репозиторій і стає там окремою точкою відновлення поруч із копією файлів; на диск він не пишеться ніколи. Облікові дані беруться зі змінних самого контейнера, включно із секретами *_FILE, і його не залишають. Кожна картка показує, чи зберігається тека даних бази при зупиненому контейнері, чи копіюється вона на ходу, чи не зберігається зовсім. Невдалий дамп не валить резервне копіювання: він з'являється як невдалий запуск із причиною і підказкою, як це виправити, і надсилає сповіщення. Дампи ніколи не завантажуються назад самі. Завантажте дамп (як є або стиснутим), збережіть його в теку, імпортуйте одним кліком у щойно запущену базу або заберіть його через CLI restic. Вимкнути його можна для окремого контейнера, міткою bombvault.dbdump=false, або для всіх контейнерів у Налаштуваннях. Виявлення аномалій стежить і за розміром кожного дампа, а асистент може вивести список дампів контейнера через сервер MCP.
• Хуки до/після резервного копіювання для кожного контейнера. Команди оболонки виконуються всередині контейнера (наприклад скидання кешу на диск); невдалий pre-хук перериває резервне копіювання. Розпізнані бази даних вивантажуються автоматично і хука для цього не потребують.
• Зупинка інших контейнерів під час резервного копіювання, з перезапуском, обмеженим станом справності. Назвіть залежні контейнери (наприклад базу даних), які потрібно зупинити, поки цей резервується. Потім BombVault повертає їх у порядку depends_on з Compose і, за замовчуванням, чекає, поки кожен повідомить про справність (або запуск, якщо він не має healthcheck), перш ніж запускати контейнери, що від нього залежать, тож залежність на кшталт Pi-hole, бази даних чи VPN-шлюзу дійсно піднята, перш ніж служби, які її потребують, замість того, щоб вони поверталися до connection refused. Очікування обмежене таймаутом для кожного контейнера (120 секунд за замовчуванням), тож повільний чи ніколи не справний контейнер ніколи не зможе підвісити запуск; і очікування, і таймаут живуть у Налаштування, Контейнери (вимкніть очікування для попереднього перезапуску всіх одразу). Той самий упорядкований перезапуск, обмежений станом справності, також обгортає оновлення образу після резервного копіювання, тож у день, коли приходить оновлення, залежні утримуються вимкненими протягом відтворення й повертаються, з обмеженням за станом справності, лише коли воно завершено.
• Шаблони виключення для кожного контейнера. Перелічіть підкаталоги, які потрібно пропустити всередині резервованого тому, по одному на рядок. Введіть шляхи так, як ви бачите їх усередині контейнера; живий попередній перегляд показує, до чого розв'язується кожен рядок, і попереджає, коли рядок нічого не виключить.
• Оновлення після успішного резервного копіювання (розширене, за замовчуванням вимкнене). Увімкніть це на контейнері, і BombVault завантажує найновіший образ і відтворює його, але лише коли справді є новіший образ, тож свіжа точка відновлення завжди існує першою. Необов'язкові додатки: сповіщення для кожного оновленого контейнера та очищення образів (базовий образ, спільний з іншими контейнерами, ніколи не видаляється). Після оновлення BombVault також просить Unraid повторно перевірити статус оновлення того одного контейнера, тож застарілий банер update available на вкладці Docker очищається сам замість того, щоб затримуватися (оновлення Unraid проходять прямо через Docker API, тож його кешований статус, а на деяких версіях і кешований дайджест, інакше продовжував би показувати банер). Це за принципом найкращих зусиль, ніколи не впливає на резервне копіювання, увімкнене за замовчуванням і має перемикач у Налаштуваннях.
• Відновлення до альтернативної теки для клонування чи перевірки.
• Порівняння знімків і теги. Порівняйте два знімки, щоб побачити, що змінилося, і призначте теги знімкам, щоб фільтрувати їх.
• Що нового після оновлення. Примітки до випуску спливають один раз для кожної нової версії, подаються з приміток, вбудованих у бінарний файл, тож діалог працює офлайн.
• HTTPS з коробки (самопідписаний або підключіть власний сертифікат за зворотним проксі).
• Healthcheck Docker. Контейнер повідомляє про справність/несправність з власного /api/health, тож інструмент автовідновлення може перезапустити його, якщо механізм коли-небудь зависне.
• Темний/світлий інтерфейс 42 мовами з вибором прапора.
• Налаштування зберігаються самі. Перемкніть перемикач або вийдіть із поля, і зміна одразу записується: елемент керування коротко спалахує, а якщо сервер відмовляє, здригається. Кнопка збереження залишилася в трьох місцях, бо зберігати їх наполовину заповненими було б небезпечно: поле конфігурації rclone, редактор набору облікових даних і пароль входу.
• Тихі спливні повідомлення. У Налаштування, Загальні можна приглушити рутинні підтвердження, і переривати вас будуть лише збої. Це задається для кожного браузера й не зачіпає сповіщень.
• Вигляд на ваш смак. Налаштування, Вигляд задає кольори (один акцентний або Режим веселки з палітрою з восьми), кути (круглі, м'які або прямі) і анімацію (вимкнено, м'яко, шалено або буремно), і все це запам'ятовується для кожного браузера. Якщо система просить менше руху, це завжди важливіше.