Перейти до змісту

Усунення несправностей

Коротка добірка поширених питань. Повну таблицю усунення несправностей на боці хоста для VM через SSH (permission-denied, перевірка ключа хоста, відсутні змінні шаблону та інше) див. у посібнику з резервного копіювання VM через SSH на GitHub.

Щось підключено неправильно

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

Я не можу дістатися до вебінтерфейсу

BombVault подає HTTPS з коробки на порту 3443 (самопідписаний сертифікат), тож відкрийте https://<your-unraid-ip>:3443. Прийміть попередження про самопідписаний сертифікат або поставте BombVault за зворотним проксі з власним сертифікатом. Якщо ви запускаєте з HTTP_ONLY=true, він натомість подає звичайний HTTP на порту 3000 (призначено для використання за проксі, що термінує TLS).

Я втратив свій APP_KEY

APP_KEY виводить пароль репозиторію restic. Без нього (і без набору для відновлення ключа шифрування) зашифровані резервні копії не можна відновити. Ось чому Панель докучає вам завантажити набір для відновлення. Див. Зовнішнє копіювання та відновлення. Згенеруйте ключ командою openssl rand -hex 32 і збережіть його поза сервером, перш ніж покладатися на будь-яку резервну копію.

Резервне копіювання VM не з'єднується

Резервне копіювання VM спілкується з libvirt через SSH, ніколи через монтування.

  • Переконайтеся, що SSH увімкнено на хості й публічний ключ BombVault авторизований у /root/.ssh/authorized_keys (Налаштування, Інтеграції, SSH хоста показує ключ і кнопку Перевірити з'єднання).
  • У кастомній мережі br0.x задайте LIBVIRT_HOST на свою LAN IP Unraid (контейнер не може дістатися до хоста через host.docker.internal там). Увімкніть Settings, Docker, Host access to custom networks.
  • Якщо ви змінили порт SSH Unraid, задайте LIBVIRT_SSH_PORT відповідно.
  • Повна покрокова діагностика (тест досяжності, маршрутизація VLAN, Permission denied (publickey), Host key verification failed) є в посібнику з резервного копіювання VM через SSH.

Живий знімок VM не запустився

Живі знімки потребують гостьового агента qemu, встановленого у VM, і диска на /mnt/cache (або /mnt/diskX), не /mnt/user. На вимкненій VM живий автоматично відкочується до коректного. Коректне резервне копіювання вимикає VM, резервує диски, потім перезапускає її, тож воно завжди узгоджене.

Резервне копіювання завершилося помилкою "repository is already locked"

Це зазвичай осиротіле блокування restic, залишене, коли контейнер було оновлено чи перезапущено посеред операції. BombVault виявляє доказово осиротіле блокування, примусово очищує його та повторює один раз, автоматично. Якщо воно зберігається, скористайтеся Налаштування, Цілісність, Розблокувати для ураженого домену, щоб очистити застаріле блокування вручну. Справжня проблема все ж виринає, а не ховається. Після перезапуску BombVault чекає, доки таке блокування десять хвилин не оновлювалося. Restic, який ще працює, наприклад у другому BombVault на тому самому репозиторії, оновлює своє блокування кожні п'ять хвилин.

Моя зовнішня копія не сталася після резервного копіювання

Зовнішня реплікація за принципом найкращих зусиль за задумом, тож збій зовнішнього ніколи не провалює локальне резервне копіювання. Перевірте зовнішній розклад для цього домену (Налаштування, Розклади): порожній розклад реплікує після кожного локального резервного копіювання, а періодичність відправляє рідше. Скористайтеся Реплікувати зараз на сторінці Зовнішнє для запуску за запитом і спостерігайте за індикатором реплікації на Панелі.

Відновлення перервалося, перш ніж почалося

Перш ніж щось буде зупинено чи видалено, відновлення запускає передпольотну перевірку конфліктів: воно перевіряє, що статична IP контейнера та опубліковані порти хоста вільні. Якщо інший контейнер уже тримає один із них, воно перериває роботу з чітким, дієвим повідомленням замість того, щоб залишити напівзавершене відновлення. Звільніть конфліктний порт чи IP, потім повторіть.

Звичайний експорт завершився помилкою замість запису файлу

Якщо шифрування age ввімкнене (Налаштування), але не задано дійсного отримувача, експорт завершується помилкою з чітким повідомленням замість запису відкритого тексту. Додайте дійсного отримувача (публічний ключ age або публічний ключ SSH) або вимкніть шифрування, якщо ви маєте намір, щоб експорт був у відкритому тексті. Див. Можливості.

Дамп бази даних не вдався

Невдалий дамп ніколи не валить резервне копіювання довкола себе; він записується як окремий невдалий запуск, а причина називає, що виправити.

  • Відмова у вході. Дамп входить зі змінними пароля самого контейнера (POSTGRES_PASSWORD, MARIADB_ROOT_PASSWORD, MYSQL_ROOT_PASSWORD або їхніми версіями _FILE). Перевірте їх на контейнері бази даних. Змінна _FILE, що вказує на секрет, якого користувач контейнера не може прочитати, дає таку саму відмову.
  • Бракує прав. Із випадковим паролем root дамп може увійти лише як користувач застосунку, тож містить одну цю базу, а MySQL 8.4 і новіші можуть відмовити зовсім. Дайте контейнеру справжній пароль root або вимкніть для нього дамп.
  • Системні таблиці потребують оновлення. MariaDB відмовляється віддавати дамп, коли її системні таблиці походять зі старішої версії (помилка 1558). Додайте змінну MARIADB_AUTO_UPGRADE=1 і перезапустіть контейнер або виконайте всередині нього mariadb-upgrade один раз.
  • Немає інструмента для дампа. Полегшений чи саморобний образ без pg_dump, mysqldump або mariadb-dump зняти не вдасться. Візьміть офіційний образ або вимкніть дамп.
  • Обмеження часу. Дампу відведено DB_DUMP_MAX_HOURS (усталено 6), резервному копіюванню довкола нього BACKUP_MAX_HOURS, а дамп, що перестав просуватися, обривається через BACKUP_STALL_HOURS. За останнім зазвичай стоїть блокування, яке тримає застосунок. Підніміть ту межу, що спрацювала, або знімайте дамп, коли застосунок спокійний.
  • Контейнер призупинено або він перезапускається. Дамп розмовляє з працюючим сервером. Якщо контейнер перезапускається знову і знову, його власний журнал скаже чому.
  • Пошкоджений дамп не вдалося прибрати. Дамп, який BombVault не зміг довести до кінця, видаляється. Коли це видалення не проходить, дамп лишається у списку з позначкою про пошкодження, і ви можете видалити його там.

Імпорт не вдався

Імпорт зупиняє контейнер, відсуває його теку даних убік і дає образу створити на її місці порожню. Якщо відмовляє крок перед самим імпортом, стара тека повертається на місце сама. Якщо відмовляє імпорт, контейнер лишається зі свіжою текою, а стара лежить поруч як <тека даних>.bombvault-before-import-<позначка часу>; повідомлення про помилку запуску називає точний шлях.

Повернути вручну: зупиніть контейнер, перейменуйте поточну теку даних, щоб прибрати її з дороги, поверніть збереженій теці початкову назву і запустіть контейнер. На Unraid це робить файловий менеджер на вкладці Shares.

Копія набору даних ZFS завершилася помилкою або пропустила набір

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

  • snapshot-loop: знімок не дійшов до BombVault, бо Host Data не передає нові монтування. Змініть контейнер, встановіть Access Mode для Host Data у Read/Write - Slave і перезапустіть BombVault.
  • key-not-loaded: зашифрований набір, ключ якого не завантажено, пропускається. Завантажте ключ командою zfs load-key і змонтуйте набір; наступна копія його включить.
  • ssh-auth: сервер відхилив ключ BombVault. Картка з'єднання на сторінці ZFS показує команду, що його дозволяє; виконайте її один раз на сервері.

Елемент застряг на "Вчиться N/10"

Більшість перевірок аномалій починається після 10 успішних копій елемента, а лік починається заново після Позначити як очікуване і після зміни вибору елемента. Елемент без розкладу не навчається, а контейнерові без appdata немає на чому вчитися, про що каже і його значок.

Зберігання перестало видаляти старі копії одного елемента

Їх утримує відкрита критична аномалія: джерело елемента майже порожнє, сильно зменшилося, або копія заново зберегла більшу частину даних. Відкрийте аномалію через значок біля елемента. Якщо даних бракує або їх зашифровано, спершу відновіть їх із вказаної останньої доброї копії. Потім підтвердьте аномалію або позначте її як очікувану, якщо зміна ваша, і наступний запуск почистить як завжди. Попередній перегляд зберігання позначає такий елемент як збережений. В елемента ZFS старі копії зберігає лише набір даних, названий в аномалії; інші набори даних дерева очищаються як зазвичай.

Ручне очищення повідомляє, що деякі елементи збережено

Та сама причина: очищення не чіпає старі копії елемента з такою аномалією й називає його у своєму повідомленні. Усе інше очищується як завжди.

Імпорт історії повідомляє, що репозиторій не вдалося прочитати

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

Попередження про місце на диску не збігається з панеллю Unraid

На користувацькій спільній теці Unraid (/mnt/user) вільне місце стосується всього масиву, а не одного диска. Віддалені репозиторії вимірюються лише через віддалені сховища rclone, які повідомляють вільне місце; репозиторії S3, B2, REST і SFTP не мають даних і на картці Аномалії зазначені як невиміряні.

ШІ-асистент не може підключитися

На сторінці Сервер MCP описано, що означає кожен код стану й кожна відмова точки підключення MCP і що з цим робити.

Контейнер постійно перезапускається чи виглядає несправним

BombVault повідомляє про справність/несправність з власного /api/health. Інструмент автовідновлення (наприклад Autoheal) може перезапустити його автоматично, якщо механізм коли-небудь зависне. Перевірте журнал контейнера та звіт /spike на предмет основної причини.

Досі застрягли?