Зовнішнє копіювання та відновлення¶

Зовнішні копії чекають після перебудови

Коли крок 4 перебудовує записи без старих налаштувань, зовнішня реплікація цих доменів призупиняється, доки не підтверджено значення за замовчуванням розміщення. Див. Розміщення для кожного елемента.

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

Зовнішня реплікація¶

Зберігайте швидку локальну резервну копію та додайте одну чи кілька зовнішніх реплік. Задайте репозиторій для кожного домену на сторінці Налаштування, Зовнішнє. BombVault реплікує туди нові знімки командою restic copy за принципом найкращих зусиль, тож збій зовнішнього ніколи не провалює локальне резервне копіювання. У такій схемі локальний репозиторій залишається основним, а зовнішній є реплікою, але основний репозиторій домену зовсім не мусить бути локальним; про резервне копіювання просто в S3, rest-server тощо замість реплікації туди див. Віддалені основні репозиторії нижче.

Кілька зовнішніх цілей для домену. Кожен домен (контейнери, VM, flash, config, набори файлів і набори даних ZFS) може реплікуватися на кілька зовнішніх місць призначення одночасно, не лише на одне, тож ви можете тримати, наприклад, rest-server на машині друга та bucket S3 паралельно. Додайте додаткові цілі в Налаштування, Зовнішнє, кожна з власним репозиторієм, класом сховища S3, прапорцем append-only, зберіганням і бюджетом росту. Наявне єдине налаштування зовнішнього переноситься недоторканим як перша ціль, і кожна ціль домену реплікується за зовнішнім розкладом цього домену.
Зовнішній розклад для кожного домену (редагується поряд з кожним іншим розкладом у Налаштування, Розклади): залиште його порожнім, щоб реплікувати після кожного локального резервного копіювання, або задайте періодичність (наприклад weekly Sun 03:00), щоб відправляти зовнішнє рідше, ніж ви резервуєте локально. Кнопка Реплікувати зараз охоплює запуски за запитом.
Зовнішнє зберігання живе в Налаштування, Зберігання, тож ви можете зберігати зовнішні копії довше як архів. Залиште політику всю нульовою, щоб ніколи не обрізати зовнішні знімки автоматично.
Обмеження пропускної здатності (Налаштування, Зовнішнє) обмежують швидкість вивантаження/завантаження restic, тож реплікація не насичує ваш WAN.
Індикатор реплікації показує, який домен реплікується, поки вона триває (на його сторінці та Панелі). Це активний індикатор, а не смуга відсотків, бо restic copy не надає машинозчитуваного прогресу.

Відновлення з будь-якого місця

Кожен контейнер, VM, набір файлів, flash і конфігурація додатка перелічують свої резервні копії як одну часову шкалу за всіма місцями, де лежить резервна копія. Резервна копія, скопійована до B2, з'являється один раз, позначена кожним місцем, яке її тримає. Відновлення бере перше місце, до якого може дотягнутися, починаючи з репозиторію, куди записано елемент, і ти можеш вибрати інше місце для кожного рядка. Зовнішні місця читаються лише тоді, коли ти їх відкриваєш. Видалення в одному місці спершу перевіряє інші і повідомляє, чи була це остання копія.

Місця призначення¶

Налаштування, Зовнішнє починаються з блоку Місця призначення: це місця, куди потрапляють зовнішні копії, налаштовані один раз для всіх доменів. Потім місце призначення з'являється кнопкою в рядку Розміщення кожного домену й кожного елемента. Коли його вперше позначають для домену, BombVault створює репозиторій цього домену в теці під ним, наприклад rclone:onedrive:BombVault/containers. Flash, Автобекап і набори даних ZFS не мають рядка Розміщення, тому їхній зовнішній розділ натомість пропонує Додати з і назву місця призначення.

Додати місце призначення відкриває майстер із п'яти кроків:

Куди зберігати бекапи? Кожен сервіс показано з логотипом, у чотирьох групах: сервіси зберігання з бакетами S3 (Backblaze B2, Wasabi, Cloudflare R2, Hetzner Object Storage, Amazon S3 та інші), твій власний сервер S3 (Garage, SeaweedFS, RustFS, Silo, Ceph, JuiceFS, Versity S3 Gateway), твій власний сервер і спільні ресурси (rest-server, Hetzner Storage Box, SFTP, SMB, WebDAV, змонтований шлях) та хмарні сховища (OneDrive, Google Drive, Dropbox, pCloud, Nextcloud та решта, що підтримує rclone). Для кожного вказано, наскільки він придатний для резервних копій: хмарні диски сповільнюються за великої кількості запитів, тому перша резервна копія й очищення там тривають довше.
Увійдіть до обраного сервісу. Поля залежать від сервісу: ключ доступу для S3, користувач і пароль для WebDAV та SMB, пароль застосунку там, де двофакторний вхід блокує звичайний пароль, публічний SSH-ключ BombVault для SFTP і Storage Box або токен для сервісів, що входять через браузер. Для них майстер показує команду rclone authorize, яку треба виконати на комп'ютері з браузером; токен, який вона виведе, вставляється в поле. Перевірити з'єднання перевіряє вхід, перш ніж щось буде збережено.
Виберіть теку. Майстер показує теки на місці призначення; Нова тека створює нову, а вільне місце показано там, де сервіс його повідомляє. Порожня тека найнадійніша.
Захист від видалення. Майстер прямо каже, що вміє сервіс. Rest-server у режимі append-only відмовляє у видаленні, і тест на втручання це перевіряє. Бакет S3 може зберігати старі версії завдяки версіонуванню й блокуванню об'єктів, чого BombVault поки не може перевірити. Хмарний диск узагалі не може відмовити у видаленні: хто потрапив на сервер, той потрапив і до цієї копії. Вмикай Незмінний (append-only) лише там, де віддалений бік справді відмовляє у видаленні; BombVault тоді ніколи не очищає там нічого.
На випадок аварії. Набір для відновлення перелічує кожне місце призначення з репозиторієм кожного домену під ним. Вхід повертається разом із резервною копією налаштувань BombVault; на свіжому встановленні без неї налаштуй місце призначення знову в тому самому місці.

Сервіси S3 працюють через власний бекенд S3 у restic, і саме тому до них застосовні клас сховища та блокування об'єктів. Усі інші сервіси працюють через rclone, який постачається з BombVault, а його remote потім з'являється в конфігурації rclone в Налаштування, Хмарний доступ. Експорт налаштувань містить місця призначення; з увімкненими обліковими даними він містить і їхній вхід.

Приймальний сервер, який запускає інший екземпляр вашої групи, з'являється в майстрі в розділі З вашої групи; див. Приймальний сервер.

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

Ціль, введена вручну й така, що лежить у папці місця призначення, може приєднатися до нього. Місце призначення перелічує такі цілі в розділі Уже під цим місцем призначення, а Прийняти підвішує одну з них під нього. Ціль зберігає свій репозиторій, snapshots, зберігання та розміщення й бере назву, облікові дані, клас сховища та перемикач незмінності місця призначення. BombVault спершу перевіряє, що вхід місця призначення відкриває репозиторій, і відмовляється ставити ціль append-only під місце призначення, яке не append-only. Якщо прийняти основну ціль домену, поле off-site цього домену очищається.

Розміщення для кожного елемента¶

Кожна картка контейнера, VM і набору файлів має рядок Розміщення з кнопок: Локально і по одній кнопці на кожну зовнішню ціль домену, а далі місця призначення, під якими в домену ще немає цілі. Підсвічені кнопки отримують резервні копії елемента.

Коли Локально підсвічено, елемент записується в репозиторій, показаний під Збережено на, і копіюється до кожної іншої підсвіченої цілі. Згаси ціль, і вона більше не отримає нічого нового від цього елемента. Саме лише Локально нікуди не копіює, це підходить для даних, які вже мають другу копію, наприклад для спільного ресурсу, що лежить на NAS.
Коли Локально погашено, елемент записується прямо в прямий репозиторій першої підсвіченої цілі й звідти копіюється до решти підсвічених цілей. Уперше діалог створює цей прямий репозиторій.
Кнопка місця призначення створює ціль домену під цим місцем призначення і підсвічує її лише для цього елемента. Кожен інший елемент починає без копії там.
Одна кнопка завжди лишається підсвіченою, бо резервній копії треба кудись потрапити. Щоб виключити щось із резервного копіювання, додай це до виключень.

Розташування фіксується від першої резервної копії елемента, бо BombVault ніколи не переміщує резервні копії між репозиторіями. Копії ж можна змінювати будь-коли. Ціль, яка більше не отримує елемент, зберігає наявні копії і скорочує їх до власного зберігання під час наступного зовнішнього запуску домену; Видалити в B2 на картці прибирає їх одразу. Коли частина цих копій не існує більше ніде, підтвердження перелічує їх за датою і просить ім'я елемента. З цілей append-only нічого не можна видалити.

Під рядком картка повідомляє, куди йде елемент і що там насправді є: скільки сайтів його тримають, коли кожну ціль бачили востаннє, і чи дотримано 3-2-1. Сайт, це сервер з оригінальними даними, кожна зовнішня ціль і кожен репозиторій, позначений Поза приміщенням. BombVault перевіряє копії й сайти; частину 3-2-1 про "два носії" він не перевіряє.

Розміщення за замовчуванням¶

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

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

Прямі репозиторії¶

Вимкнення Локально для елемента, так що його домом стає ціль без прямого репозиторію, відкриває діалог із запропонованим розташуванням поруч із ціллю, наприклад s3:https://s3.eu-central-003.backblazeb2.com/bucket/containers-direct, і перевіркою з'єднання, яка нічого не створює. Створити і використати створює репозиторій і спрямовує елемент до нього. Прямий репозиторій переймає ключ, клас сховища, ліміти, налаштування append-only та зберігання цілі й змінюється разом із ними; картка Репозиторії показує його лише для читання. Коли новий ключ цілі не може його відкрити, прямий репозиторій зберігає той ключ, який має, і збереження про це повідомляє. Елемент на прямому репозиторії копіюється звідти до решти підсвічених цілей, але ніколи до цілі, якій належить цей репозиторій. Його знімки несуть мітку bv:direct, і кожне інше очищення зберігає їх, тож прямий репозиторій, що втратив зв'язок зі своєю ціллю, ніколи не старіє за локальними правилами. До B2 звертаються через його кінцеву точку S3, вводячи ідентифікатор ключа та ключ застосунку як облікові дані S3; ключ, обмежений власною текою цілі, не може дістатися до теки поруч із нею, тож натомість обмеж ключ текою над ціллю.

Поза приміщенням¶

Іменований репозиторій можна позначити як Поза приміщенням на картці Репозиторії. Віддалені репозиторії починають позначеними; вимкни це для rest-server у тій самій будівлі. Позначка лише враховує сайти й 3-2-1 на картках. Жодної копії вона не змінює.

Після перебудови¶

Вибори копіювання живуть у власних налаштуваннях BombVault. Після перебудови через «Знайти резервні копії» без відновленого /config вони зникають, і копіювання всього відправило б назад до B2 елементи, які ти залишив осторонь. Тому зовнішня реплікація кожного перебудованого домену призупиняється. Панель показує це бурштиновим, а Розміщення за замовчуванням пропонує Підтвердити значення за замовчуванням з попереднім переглядом того, що скопіює наступний запуск, і імен у резервних копіях, яким немає відповідника, які там можна залишити осторонь. Лише підтвердження завершує паузу; імпорт файлу налаштувань повертає правила й значення за замовчуванням, але паузу не завершує.

Віддалені основні репозиторії¶

Шлях резервної копії домену (Налаштування, Сховище) не обмежений локальною текою: спрямуйте його прямо на віддалений репозиторій restic (s3:..., rest:http://host:8000/repo, sftp:користувач@host:/repo, rclone:remote:bucket/шлях), і BombVault копіюватиме просто туди, без окремої локальної копії та без кроку реплікації. Це справді інша форма, ніж зовнішня реплікація вище: там основним є локальний репозиторій, а зовнішній править за його архів у міру можливого; тут віддалений репозиторій і є основним, і він єдина копія, доки ви не налаштуєте для цього домену ще й зовнішню реплікацію (або другий віддалений репозиторій).

Кожне з шести полів шляху (Контейнери, Віртуальні машини, Flash, Автобекап, Папки, Набори даних ZFS) має прямо поруч перемикач Локально / Віддалено:

Локально показує звичний огляд тек.
Віддалено змінює його на просте поле URL і кнопку, що відкриває те саме вікно перевірки з'єднання та облікових даних, яким користуються зовнішні призначення, але налаштоване для цього основного репозиторію. Звідти ви отримуєте:
- Перевірку з'єднання зі справжнім шляхом, перш ніж на нього покладатися.
- Обмеження смуги (віддача та приймання), щоб планова копія до віддаленого основного репозиторію не забивала ваш канал WAN: ті самі ключі restic --limit-upload і --limit-download, які використовує зовнішня реплікація, застосовані до самої копії.
- Захист append-only (незмінність), перевірений тим самим активним тестом втручання (справжня проба DELETE на дальньому боці), який отримують зовнішні призначення. Коли він увімкнений, BombVault відмовляється сам чистити репозиторій: за ним немає окремої локальної копії, тож облікові дані на цій машині не мають бути здатні видалити єдину копію резервних даних.
- Сигнал бюджету зростання, взятий із того самого тренду розміру репозиторію, який картка Сховище й так відстежує.

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

Облікові дані хмари та REST спільні

Віддалений основний репозиторій проходить перевірку тими самими обліковими даними S3/REST, що задані в розділі Налаштування, Хмарний доступ, Спільні хмарні облікові дані. Окремого сховища облікових даних для основних репозиторіїв немає.

SMB і WebDAV без монтування на хості¶

У Налаштування, Хмарний доступ, rclone є форма для спільного ресурсу Windows або Samba і для сервера WebDAV (Nextcloud, ownCloud, SharePoint чи будь-якого іншого). Заповніть коротке ім'я, хост і спільний ресурс (SMB) або URL і тип сервера (WebDAV), користувача й пароль, і BombVault сам запише розділ rclone. rclone сам обфускує пароль перед збереженням; якщо додати місце призначення з уже наявним ім'ям, цей розділ замінюється, а не з'являється другий.

Форма відповідає готовим розташуванням, наприклад rclone:nas:backups. Впишіть його у Шлях резервних копій або в зовнішнє місце призначення і за бажання додайте підтеку (rclone:nas:backups/bombvault). Спільний ресурс є першим сегментом шляху, а не частиною імені.

Цей шлях кращий, ніж монтувати спільний ресурс на Unraid: restic не радить тримати репозиторій на змонтованому ресурсі CIFS, а тут нічого не монтується. NFS у формі немає, бо ні restic, ні rclone не мають бекенда NFS; для NFS змонтуйте експорт на хості й укажіть на нього Шлях резервних копій.

Незмінне (append-only) зовнішнє¶

Позначте зовнішній репозиторій як append-only, щоб програма-вимагач чи скомпрометований хост не могли видалити чи переписати ваші резервні копії. Дальній бік (restic/rest-server, що працює в режимі --append-only) забезпечує це. BombVault лише завжди перевіряє це й ніколи не показує зелений на основі самого лише твердження конфігурації.

Майстер керованого налаштування зовнішнього проводить вас від вибору бекенда (rest-server / rclone / S3) через готовий до вставлення фрагмент розгортання rest-server, тест з'єднання, перемикач незмінності (який негайно запускає тест на втручання) та стратегію зберігання, тож зовнішнє append-only досяжне без ручного редагування конфігурацій.

Успішне видалення в /locks/ очікуване

Append-only не означає, що більше нічого не можна видалити. restic має створювати та знімати власні блокування, тому /locks/ навмисно лишається доступним для запису й видалення. Знімки та дані за ними, тобто саме те, на що націлений шифрувальник, видалити неможливо. Якщо ви самі перевірите віддалену сторону, успішне видалення в /locks/ є правильною поведінкою, а не дірою в захисті.

Незмінні репозиторії ніколи не очищаються з цієї машини

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

Тест на втручання¶

BombVault періодично доводить гарантію append-only, фактично намагаючись виконати видалення проти зовнішнього репозиторію, націлене на неіснуючий об'єкт:

Відмовлено означає захищено.
Прийнято означає не захищено.
Непереконливий результат (сервер недоступний, помилка автентифікації) ніколи не перевертає збережений вердикт.

Справжнє перекидання із захищеного на незахищене спричиняє єдине сповіщення.

Тренування DR¶

BombVault пропонує два рівні доказу того, що ваші резервні копії справді можна відновити, а не лише наявні.

Тренування перевірки відновлення (локальні). BombVault періодично запускає restic check --read-data-subset (обмежене, ніколи не повне відновлення, що заповнює диск) і показує значок Відновлюваність підтверджено для кожного домену. Періодичність живе в Налаштування, Розклади; значок у Налаштування, Цілісність.
Тренування DR (зовнішні). BombVault відновлює реальну ціль із зовнішнього репозиторію в одноразову пісочницю, перевіряє її файл за файлом і байт за байтом, потім прибирає. Це доводить, що ви можете відновитися із зовнішнього, а не лише що репозиторій відповідає.

Оціночна картка захисту від програм-вимагачів на Панелі згортає це в зелену / жовту / червону позицію для кожного домену, з контрольним списком з мітками віку (зовнішнє налаштовано, append-only перевірено, реплікація актуальна, тренування відновлення пройдено, шифрування ввімкнено, стратегія очищення задана). Кожен червоний рядок веде глибоким посиланням до виправлення, а картка стає зеленою лише на перевірених фактах.

Спарювання екземплярів¶

Приймачі, джерела Стягування, сторінка Екземпляри та Mesh-зовнішнє — усі вони розмовляють з іншим BombVault. Вони роблять це як учасники однієї групи спарювання, і екземпляр приєднується до групи дванадцятьма словами.

На першому екземплярі відкрийте Налаштування → Спарювання і на картках спарювання натисніть Згенерувати фразу. З'являться дванадцять слів у вікні з кнопкою Копіювати. На кожному іншому екземплярі відкрийте те саме місце, натисніть Ввести фразу і вставте слова або введіть їх, або натисніть Вставити в цьому вікні. Слово, якого немає в списку, сторінка називає разом із його позицією вже під час набору, а останнє слово несе контрольну суму, тож помилково набране чи переставлене слово виявляється ще до того, як щось спарюється. Генеруйте фразу лише на одному екземплярі: два екземпляри, на кожному з яких створено свою фразу, утворюють дві окремі групи. Якщо протягом хвилини ніхто не відгукнеться, вкладка пропонує два виходи: показати слова знову, щоб ввести їх там, або ввести слова іншого екземпляра і приєднатися до його групи за один крок. Спарювання працює і без пароля входу, але встановіть його: без нього будь-хто, хто може відкрити цей вебінтерфейс, може прочитати слова і отримати через групу пароль restic кожного екземпляра в ній. Картка спарювання повідомляє про це, поки пароль не встановлено. З паролем повторний показ фрази запитає його. Покинути групу знову виводить екземпляр із неї.

Будь-хто, хто знає ці слова, може приєднатися до групи, тож ставтеся до них як до пароля.

Як учасники досягають один одного. Кожен екземпляр дізнається власну адресу в мережі з вашого браузера в момент входу, вона показана на картці реле як Цей екземпляр у вашій мережі; виправте її там, якщо попереду стоїть зворотний проксі або нестандартний порт. В одній мережі учасники оголошують цю адресу мультикастом і говорять напряму, а там, де мультикаст не може пройти крізь мережу контейнера, як-от типову мережу bridge у Docker, екземпляр натомість шукає інших у власній підмережі підписаним викликом, відповісти на який може лише учасник групи, тож спарювання все одно завершується за секунди без реле. Якщо нічого не знайшлося, Не можете його знайти? під карткою спарювання приймає одну адресу вручну, для іншої підмережі або нестандартного порту. Екземпляри в різних мережах ідуть через реле, обране на тій самій вкладці:

Реле проєкту (типове): parleyport.halleluja.design, те саме реле, яким користується KnightLoader. Нічого налаштовувати не треба.
Власне реле: контейнер ParleyPort з Unraid Community Apps, або один з ваших екземплярів, що вже доступний зовні, з увімкненим Працювати як реле. Такий екземпляр тоді відповідає на /relay/connect на своїй власній адресі, за тим самим зворотним проксі й сертифікатом, які він уже має, і впускає лише вашу групу. Введіть адресу реле на кожному екземплярі, який має його використовувати.
Без реле: учасники знаходять одне одного автоматично лише в одній мережі, і більше ніде.

Що бачить реле. Кожен виклик між учасниками запечатаний AES-256-GCM під ключем, виведеним із дванадцяти слів, і цей ключ ніколи не залишає ваші екземпляри. Реле дізнається лише хеш, що групує з'єднання, для якого екземпляра призначене повідомлення, який у нього розмір і коли він проходить. Прямий виклик у локальній мережі запечатаний так само і теж підписаний, тож ніщо не залежить від самопідписаного сертифіката, який видає екземпляр.

Що подорожує через групу. Оціночні картки сторінки Екземпляри, запит перевірити один домен зараз, пропозиції виносного сховища Mesh і те, що потрібно приймачу чи джерелу Стягування: розташування репозиторіїв іншого екземпляра та його пароль restic. Дані резервного копіювання не подорожують ніколи; вони й далі йдуть прямо до бекендів restic. Так само й APP_KEY: пароль restic відкриває лише репозиторії цього екземпляра й нічого більше, ні його збережені секрети, ні сесії, ні коди відновлення.

Записи від часу до спарювання. Екземпляри, додані токеном fleet, а також приймачі й джерела Стягування, налаштовані APP_KEY іншого екземпляра, залишаються після оновлення й позначені як Спарувати знову. Приймачі й джерела Стягування продовжують працювати: під час першого запуску BombVault замінює кожен збережений APP_KEY на виведений із нього пароль restic. Спаруйте обидва екземпляри, потім відредагуйте запис і оберіть його екземпляр. Такий екземпляр переймає свою стару картку, щойно в групі з'являється екземпляр з тим самим ім'ям.

Єдине місце, яке досі приймає APP_KEY вручну, це Відновлення з іншого репозиторію BombVault, для випадку, коли іншого екземпляра вже немає і він не може відповісти в групі.

Панель отримувача (приймальний бік)¶

Приймальна сторона, спостережувана лише на читання, з перевіркою цілісності на цій машині.

Приймальна сторона, спостережувана лише на читання, з перевіркою цілісності на цій машині.

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

Увімкніть перемикач Приймач у Налаштуваннях, щоб відкрити вкладку Приймач. Вона вимкнена за замовчуванням; вмикайте її лише на машині, яка справді отримує незмінні зовнішні резервні копії. Потім зареєструйте отриманий репозиторій (лише для читання, відкритий паролем restic екземпляра-відправника, який надходить через групу спарювання), щоб отримати:

Інвентар знімків, згрупований за джерелом, тож ви можете точно бачити, які контейнери, VM і набори файлів надійшли.
Востаннє отримано для кожного джерела, тож ви знаєте, наскільки свіже кожне з них.
Незалежний restic check, що запускається на приймальному обладнанні, тож цілісність перевіряється там, де дані фактично лежать, а не лише на відправнику.
Запобіжник: сповіщення, коли джерело перестає надсилати протягом заданого вами вікна.
Сповіщення про цілісність: сповіщення, коли перевірка на приймальному боці не проходить.

Отримувач строго лише для читання. Він ніколи не пише в отриманий репозиторій, тож він ніколи не може зламати гарантію append-only, на яку покладається відправник.

Приймальний сервер¶

Приймальна машина може також запускати rest-server, на який копіюють інші. Налаштувати приймальний сервер угорі вкладки Приймач запитує теку на спільному ресурсі, а Нова тека створює її, і порт (8000, якщо його не займає інший контейнер). Після цього BombVault:

відмовляється, якщо контейнер з іменем rest-server уже існує або порт зайнятий іншим контейнером;
завантажує restic/rest-server і запускає його через сокет Docker у режимі append-only з приватними репозиторіями та файлом логінів у теці;
записує його шаблон Unraid на flash-накопичувач, тож контейнер залишається придатним до редагування на вкладці Docker, або пропонує шаблон на завантаження, коли flash-накопичувач недоступний;
запускає проти нього тест на втручання і показує, чи відмовляє він у видаленні.

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

Екземпляр, який досягає приймальної машини лише через реле, не може користуватися сервером, бо реле не передає резервні копії. Спершу додайте адресу приймальної машини в Налаштування, Спарювання. Якщо BombVault працює на власній IP-адресі (наприклад, на br0), заповніть Адреса для партнерів, бо сервер слухає на адресі хоста.

Повний приклад: дві машини Unraid, від початку до кінця¶

Вище описано окремі частини. Ось одне завершене налаштування зі справжніми значеннями, бо частини легше скласти, побачивши їх складеними бодай раз.

Дві машини: TOWER тримає контейнери й надсилає копії, VAULT приймає їх і забезпечує незмінність. Підставте власні імена, адреси та шляхи спільних ресурсів.

1. На VAULT підніміть сервер у режимі append-only. У BombVault на TOWER відкрийте Налаштування → Зовнішнє → Налаштувати, виберіть rest-server і створіть рецепт. Скопіюйте вкладку Шаблон Unraid (XML), збережіть її на VAULT як /boot/config/plugins/dockerMan/templates-user/my-rest-server.xml, потім Docker → Add Container і виберіть rest-server зі списку шаблонів. Перед запуском впишіть показаний рядок htpasswd на VAULT у /mnt/user/appdata/rest-server/.htpasswd. Одноразовий пароль показується один раз і ніде не зберігається: скопіюйте його зараз. Цей рядок несе той самий пароль, уже хешований bcrypt: відкритий текст іде в облікові дані REST на TOWER, хешований рядок — у .htpasswd на VAULT. Хешувати вам нічого не треба.

Залиште `--append-only` у полі OPTIONS. У цьому вся суть: без нього VAULT знову звичайний спільний ресурс.

2. На TOWER спрямуйте туди зовнішній репозиторій. Адреса репозиторію має вигляд, який друкує рецепт:

rest:http://VAULT:8000/bombvault-containers/containers

Перший сегмент шляху — користувач htpasswd, другий — репозиторій. Введіть створені логін і пароль як облікові дані REST для призначення та запустіть перевірку з'єднання.

3. На TOWER увімкніть «Незмінне». Перевірка на підміну запускається одразу й має повідомити захищено. Що означають відповіді:

Результат	Що сталося
захищено	VAULT відмовив у видаленні. Це єдиний успішний стан.
НЕ захищено	VAULT прийняв видалення. `--append-only` відсутній або його прибрали.
невизначено	Ні те, ні інше. Зазвичай адреса не та, яку використовує сам restic, або змінилися облікові дані. Нічого не записується і жоден сигнал не подається.

4. На VAULT дивіться, що надходить. Спаруйте обидві машини (Спарювання екземплярів), увімкніть Налаштування → Загальні → Приймач, відкрийте вкладку Приймач і зареєструйте репозиторій лише для читання з TOWER як екземпляром-відправником.

Розташування — це шлях усередині контейнера, записаний відносно точки монтування хоста

Введіть user/appdata/rest-server/bombvault-containers/containers, а не /mnt/user/appdata/…. BombVault працює в контейнері, де /mnt хоста змонтовано в іншому місці; абсолютного шляху хоста там немає. Якщо ви його вставите, BombVault тепер підкаже потрібний відносний шлях.

VAULT отримує пароль restic від TOWER через групу, коли ви зберігаєте; вводити ключ вручну нікому не треба.

5. За бажання зробіть це взаємно. Повторіть ті самі п'ять кроків у зворотному напрямку: rest-server на TOWER, що приймає копію з VAULT. Тоді кожна машина забезпечує незмінність для іншої, і жодна не може видалити копії іншої.

Кероване відновлення¶

Спеціальна вкладка Відновлення проводить свіже чи перебудоване встановлення через сценарій катастрофи, в одному місці:

Спершу відновлює власні налаштування BombVault, тож шляхи резервних копій, зовнішні цілі та облікові дані, які потребує решта процесу, приходять попередньо заповненими (застосовуються через самоперезапуск через сокет Docker, тож робоча база налаштувань ніколи не перезаписується під відкритим дескриптором).
Перевіряє, що BombVault може прочитати ваші резервні копії (пастка з ключем шифрування наперед).
Дає вам змогу вказати на ваш наявний репозиторій (локальний чи зовнішній).
Знаходить контейнери, VM, набори файлів і набори даних ZFS, збережені в ньому.
Відновлює контейнери та VM за один раз (залишеними зупиненими, тож ви запускаєте їх свідомо) і показує набори файлів та елементи ZFS, які відновлюються по одному; елементи ZFS повертаються вимкненими. Набір для відновлення в одному кліку.

Планова міграція проти катастрофи

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

Відновлення з іншого репозиторію BombVault¶

Окрема картка на вкладці Відновлення відкриває репозиторій іншого екземпляра BombVault (спільний ресурс, змонтований під /mnt, або віддалений URL) з APP_KEY того екземпляра, в одноразовій сесії лише для читання. Перегляньте контейнери, VM і набори файлів, збережені там, виберіть знімок і відновіть його, і відновлений об'єкт стає звичайним локальним контейнером, VM чи набором файлів. Нічого ніколи не пишеться в інший репозиторій, а ваші власні налаштування резервного копіювання залишаються недоторканими (сесія живе в пам'яті й закінчується сама). Переміщення контейнера із сервера A на сервер B не означає перенаправлення налаштувань репозиторію та їх повернення після цього. Ця картка одноразова: вона відкриває сесію, відновлює вибране й забуває інший екземпляр. Якщо ж вам потрібна постійна схема, за якої ця машина за розкладом забирає знімки іншого екземпляра у власний репозиторій, це вкладка Стягування на сторінці Екземпляри.

Під рядком контейнера, чиєї мережі немає на цьому сервері, наприклад мережі br0 з Unraid на звичайному Docker-хості, з'являється вибір мережі. BombVault створює його у вибраній мережі разом з іншими мережами. Фіксована IP-адреса та MAC-адреса належали старій мережі й відкидаються, тому їх видає нова мережа.

Набір для відновлення ключа шифрування¶

Це та частина, яка робить аварійне відновлення можливим навіть коли немає запущеного BombVault.

Один клік завантажує головний ключ, похідний пароль restic та точні розташування репозиторіїв і команди, тож ви можете відновити прямо за допомогою restic CLI на будь-якій машині. Нагадування на Панелі докучає, поки ви його не збережете.

Зберігайте набір для відновлення поза сервером

Набір містить секрет, який розшифровує ваші резервні копії. Тримайте його в безпечному місці окремо від сервера (менеджер паролів, роздрукована копія в сейфі). Якщо ви втратите і BombVault, і APP_KEY без набору для відновлення, ваші зашифровані резервні копії не можна буде відновити.

Найновіший знімок не завжди той, який слід відновлювати

Починаючи з restic 0.17, restic snapshots показує розмір кожного знімка. Після втрати даних найновішим може виявитися спорожнілий знімок, тож не відновлюйте знімок, що набагато менший за попередні. Після програми-вимагача це може бути зашифрований знімок звичного розміру. Якщо BombVault ще працює, спершу загляньте на його сторінку Аномалії: там зазначено останню добру копію. Для відновлення не потрібні дані BombVault про аномалії, а пауза зберігання лише лишає більше знімків.

Запечатування набору¶

Якщо ви ввімкнули шифрування age для звичайних експортів (Налаштування), набір теж запечатується ним і завантажується як bombvault-recovery-kit.md.age. Він у текстовій формі ASCII-armor, а не двійковий, тож лишається звичайним текстом: вставити його в менеджер паролів або надрукувати можна так само, як раніше, просто без вашого ключа вміст не прочитати.

Не зберігайте ключ age всередині набору

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

З увімкненим шифруванням і без налаштованого придатного отримувача завантаження просто відхиляється. BombVault ніколи не відкочується до видачі головного ключа у відкритому вигляді.

Якщо набору немає під рукою¶

Пароль ніде не зберігається, він обчислюється з APP_KEY. Маючи ключ і оболонку, ви можете відтворити його самі:

printf 'bombvault:restic-repo' \
  | openssl dgst -sha256 -mac HMAC -macopt hexkey:$APP_KEY -r \
  | cut -d' ' -f1

Це HMAC-SHA256 над сталим рядком bombvault:restic-repo, ключем є сирі байти шістнадцяткового APP_KEY, результат друкується як 64 малі шістнадцяткові символи. Те саме значення є в наборі як виведений пароль restic; це на той день, коли набір лежатиме не там, де ви.

Для отриманого репозиторію беріть ключ ВІДПРАВНОГО примірника

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

Оскільки визначення для відновлення живуть усередині кожного репозиторію (<repo>/def, <repo>/vm-def), скопійована тека репозиторію повністю самодостатня, тож набір плюс репозиторій, це все, що потрібно для відновлення на голому залізі.

Як дістати дамп бази даних назад¶

Дамп бази даних це окрема точка відновлення в репозиторії контейнерів, із міткою dbdump:<container> і єдиним файлом /dbdump/<container>.sql. BombVault показує, завантажує та імпортує їх у розділі Резервні копії; нижче ті самі кроки з одним лише restic, на день, коли BombVault немає під рукою.

restic -r <repo> snapshots --tag dbdump:<container>
restic -r <repo> dump --tag dbdump:<container> latest /dbdump/<container>.sql > <container>.sql

Мітки dbversion: і dbname: на кожному дампі кажуть, з якої версії сервера його взято і які бази він містить. Повний файл закінчується рядком -- PostgreSQL database cluster dump complete або -- Dump completed.

Імпортуйте його в контейнер тієї самої чи новішої версії (PostgreSQL) або тієї самої основної версії (MySQL і MariaDB), один раз запущений із порожньою текою даних, щоб він розгорнувся. Клієнт бази даних на хості не потрібен, він є в контейнері:

docker exec -i <container> sh -c 'exec psql -X -U "${POSTGRES_USER:-postgres}" -d postgres' < <container>.sql
docker exec -i <container> sh -c 'exec mariadb -uroot -p"$MARIADB_ROOT_PASSWORD"' < <container>.sql
docker exec -i <container> sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD"' < <container>.sql

Для однієї бази з повного дампа MySQL і MariaDB приймають --one-database <name> у команді клієнта. У дампі PostgreSQL на кожну базу припадає свій розділ, що починається рядком \connect <name>: скопіюйте потрібний розділ в окремий файл і імпортуйте його з -d <name> після створення бази.

Дамп, знятий під root, несе із собою користувачів сервера

Повний дамп MySQL або MariaDB, знятий під root, містить системну базу mysql, тож його імпорт замінює облікові записи нового сервера, разом із паролем root, на записи з дампа. У PostgreSQL повідомлення role ... already exists про користувача, якого створив сам контейнер, очікуване і безпечне.