Telephelyen kívüli mentés és helyreállítás

A telephelyen kívüli másolatok várnak egy újraépítés után

Amikor a 4. lépés a régi beállítások nélkül épít újra bejegyzéseket, azoknak a tartományoknak a telephelyen kívüli replikációja szünetel, amíg az elhelyezési alapértelmezést meg nem erősítik. Lásd: Elhelyezés elemenként.

A helyi mentések megvédenek egy elveszett konténertől vagy egy rossz frissítéstől. A telephelyen kívüli replikáció és egy tesztelt helyreállítási csomag megvéd a teljes gép elvesztésétől, a zsarolóvírustól vagy egy tűztől. Ez az oldal a telephelyen kívüli replikálást, a másolat manipulációbiztossá tételét, a visszaállíthatóság bizonyítását és a helyreállítást ismerteti arra az esetre, amikor maga a BombVault eltűnt.

Telephelyen kívüli replikáció

Tartsd meg a gyors helyi mentést, és adj hozzá egy vagy több telephelyen kívüli replikát. Állíts be egy tárolót tartományonként a Beállítások, Telephelyen kívüli oldalán. A BombVault az új pillanatképeket restic copy segítségével, legjobb szándék szerint replikálja oda, így egy telephelyen kívüli zökkenő soha nem hibáztatja el a helyi mentést. Ebben a felállásban a helyi tároló marad az elsődleges, a telephelyen kívüli pedig egy replika, de egy tartomány elsődleges tárolójának egyáltalán nem kell helyinek lennie; lásd lejjebb a Távoli elsődleges tárolók szakaszt arról, hogyan menthetsz közvetlenül S3-ra, rest-serverre stb., ahelyett hogy oda replikálnál.

• Több telephelyen kívüli cél tartományonként. Minden tartomány (konténerek, VM-ek, flash, config, fájlkészletek és ZFS-adatkészletek) egyszerre több telephelyen kívüli célra is replikálhat, nem csak egyre, így párhuzamosan tarthatsz például egy rest-servert egy barátod gépén és egy S3-bucketet is. Adj hozzá további célokat a Beállítások, Telephelyen kívüli alatt, mindegyiket saját tárolóval, S3-tárolási osztállyal, append-only jelzővel, megőrzéssel és növekedési kerettel. Egy meglévő egyetlen telephelyen kívüli beállítás érintetlenül, az első célként öröklődik át, és egy tartomány minden célja az adott tartomány telephelyen kívüli ütemezése szerint replikál.
• Tartományonkénti telephelyen kívüli ütemezés (minden más ütemezés mellett a Beállítások, Ütemezések alatt szerkesztve): hagyd üresen, hogy minden helyi mentés után replikáljon, vagy állíts be egy ütemet (például weekly Sun 03:00), hogy ritkábban szállítson telephelyen kívülre, mint amilyen gyakran helyben mentesz. Egy Replikálás most gomb fedi le az igény szerinti futásokat.
• A telephelyen kívüli megőrzés a Beállítások, Megőrzés alatt él, így a telephelyen kívüli másolatokat archívumként tovább megtarthatod. Hagyd a szabályt mind nullán, hogy soha ne nyesse automatikusan a telephelyen kívüli pillanatképeket.
• A sávszélesség-korlátok (Beállítások, Telephelyen kívüli) korlátozzák a restic fel- és letöltési sebességét, hogy a replikáció ne telítse a WAN-odat.
• Egy replikációs jelző mutatja, melyik tartomány replikál éppen, amíg fut (a saját oldalán és az irányítópulton). Ez egy aktív jelző, nem egy százalékos sáv, mert a restic copy nem tesz közzé géppel olvasható folyamatjelzést.

Visszaállítás bármely helyről

Minden konténer, VM, fájlkészlet, a flash és az alkalmazás-konfiguráció egyetlen idővonalként sorolja fel a mentéseit minden hely között, ahol egy mentés fekszik. Egy B2-be másolt mentés egyszer jelenik meg, minden azt tartalmazó hellyel megjelölve. A visszaállítás az első elérhető helyet veszi, a tárolóval kezdve, ahova az elem íródik, és soronként másik helyet is választhatsz. A telephelyen kívüli helyek csak akkor olvasódnak, amikor megnyitod őket. Az egy helyen történő törlés előbb a többit ellenőrzi, és megmondja, hogy az volt-e az utolsó másolat.

Célok

A Beállítások, Telephelyen kívüli oldal a Célok résszel kezdődik: ezek azok a helyek, ahová a telephelyen kívüli másolatok kerülnek, egyszer beállítva minden tartományra. Egy cél ezután gombként jelenik meg minden tartomány és elem Elhelyezés sorában. Amikor először jelölöd be egy tartományhoz, a BombVault létrehozza a tartomány tárolóját a cél alatti egy mappában, például rclone:onedrive:BombVault/containers. A Flash, az Önmentés és a ZFS-adatkészletek nem rendelkeznek Elhelyezés sorral, ezért a telephelyen kívüli szakaszuk ehelyett a Hozzáadás innen: gombot kínálja a cél nevével.

A Cél hozzáadása egy öt lépéses varázslót nyit meg:

1. Hová kerüljenek a mentések? Minden szolgáltatás a logójával együtt szerepel, négy csoportban: S3-bucketeket kínáló tárolási szolgáltatások (Backblaze B2, Wasabi, Cloudflare R2, Hetzner Object Storage, Amazon S3 és mások), a saját S3 szervered (Garage, SeaweedFS, RustFS, Silo, Ceph, JuiceFS, Versity S3 Gateway), saját szerver és megosztások (rest-server, Hetzner Storage Box, SFTP, SMB, WebDAV, csatolt útvonal) és felhőtárhely (OneDrive, Google Drive, Dropbox, pCloud, Nextcloud és a többi, amit az rclone támogat). Mindegyik megmondja, mennyire alkalmas mentésekre: a felhős meghajtók sok kérés alatt lassulnak, ezért az első mentés és a nyesés itt tovább tart.
2. Bejelentkezés. A mezők a szolgáltatástól függnek: hozzáférési kulcs S3-hoz, felhasználónév és jelszó WebDAV-hoz és SMB-hez, alkalmazásjelszó ott, ahol a kétlépcsős bejelentkezés a szokásos jelszót blokkolja, a BombVault nyilvános SSH-kulcsa SFTP-hez és a Storage Boxhoz, vagy token a böngészőn át bejelentkező szolgáltatásokhoz. Ezeknél a varázsló egy rclone authorize parancsot mutat, amelyet egy böngészős számítógépen kell lefuttatni; a kiírt tokent a mezőbe kell írni. A Kapcsolat tesztelése mentés előtt ellenőrzi a bejelentkezést.
3. Válassz mappát. A varázsló felsorolja a cél mappáit, az Új mappa gombbal újat lehet létrehozni, és ahol a szolgáltatás jelzi, a szabad hely is látszik. Egy üres mappa a legbiztonságosabb.
4. Védelem a törlés ellen. A varázsló nyíltan megmondja, mire képes a szolgáltatás. Az append-only módú rest-server elutasítja a törlést, és a manipulációs teszt ezt ellenőrzi. Egy S3-bucket a verziókezeléssel és az Object Lockkal megtarthatja a régi verziókat, ezt a BombVault még nem tudja ellenőrizni. Egy felhős meghajtó egyáltalán nem tudja elutasítani a törlést: aki bejut a szerverre, ebbe a másolatba is bejut. A Nem módosítható (append-only) kapcsolót csak ott kapcsold be, ahol a túloldal tényleg elutasítja a törlést; a BombVault ilyenkor ott soha nem nyes.
5. Vészhelyzetre. A helyreállítási csomag felsorolja az összes célt, alattuk minden tartomány tárolójával. A bejelentkezés a BombVault beállításmentésével tér vissza; ennek hiányában, friss telepítésen a célt ugyanarra a helyre újra be kell állítani.

Az S3-szolgáltatások a restic saját S3-háttérrendszerén futnak, ezért érvényesülhet a tárolási osztály és az object lock. Minden más szolgáltatás a BombVaulttal szállított rclone-on keresztül fut, és a remote ezután megjelenik az rclone konfigurációban a Beállítások, Felhőhozzáférés alatt. A beállítások exportja tartalmazza a célokat; a hitelesítő adatokkal együtt a bejelentkezésüket is.

A fogadószerver, amelyet a csoportod egy másik példánya futtat, a varázslóban az A csoportodból alatt jelenik meg; lásd: Fogadószerver.

Egy tartomány célja, amely egy célból készült, átveszi a cél nevét, helyét, hitelesítő adatait, tárolási osztályát és a nem módosítható kapcsolót. A megőrzése, tömörítése és növekedési kerete tartományonként külön marad, a helye pedig nem mozdítható, mert ott van a tartomány tárolója. A Cél hozzáadása csak ehhez a tartományhoz gomb minden tartomány alatt továbbra is kézzel beírt tárolócímet kér.

Egy kézzel beírt cél, amelynek tárolója egy cél egyik mappájában van, csatlakozhat ehhez a célhoz. A cél az ilyen célokat az Már ennek a célnak az alatt van alatt listázza, az Átvétel pedig felfűz egyet rá. A kézzel beírt cél megtartja a tárolóját, a pillanatképeit, a megőrzését és az elhelyezését, és átveszi a cél nevét, hitelesítő adatait, tárolási osztályát és a nem módosítható kapcsolót. A BombVault először ellenőrzi, hogy a cél bejelentkezése megnyitja-e a tárolót, és nem hajlandó append-only célt olyan cél alá tenni, amely nem append-only. Ha egy tartomány elsődleges célját átveszed, a tartomány off-site mezője kiürül.

Elhelyezés elemenként

Minden konténer-, VM- és fájlkészlet-kártyának van egy Elhelyezés sora gombokkal: Helyi, majd a tartomány minden telephelyen kívüli céljához egy gomb, utánuk azok a célok, amelyek alatt a tartománynak még nincs célja. A világító gombok kapják az elem mentéseit.

• Ha a Helyi világít, az elem a Tárolva itt alatt látható tárolóba íródik, és minden más világító célra másolódik. Sötétíts el egy célt, és az semmi újat nem kap ettől az elemtől. A Helyi egyedül sehova nem másol, ami olyan adathoz illik, amelynek már van egy második másolata, például egy NAS-on élő megosztáshoz.
• Ha a Helyi sötét, az elem egyenesen az első világító cél közvetlen tárolójába íródik, onnan másolódik a többi világító célra. Először egy párbeszédablak hozza létre ezt a közvetlen tárolót.
• Egy cél gombja létrehozza a tartomány célját a cél alatt, és csak ennek az elemnek világítja be. Minden más elem másolat nélkül indul ott.
• Egy gomb mindig világít, mert a mentésnek kell egy hely, ahová mehet. Ha valamit ki akarsz hagyni a mentésekből, zárd ki.

A hely az elem első biztonsági mentésétől fogva rögzített, mert a BombVault soha nem mozgat mentéseket tárolók között. A másolatok bármikor változhatnak. Az a cél, amely már nem kap egy elemet, megtartja a meglévő másolatait, és a tartomány következő telephelyen kívüli futásakor a saját megőrzésére vágja őket vissza; a kártyán a Törlés itt: B2 azonnal eltávolítja őket. Ha ezek közül a másolatok közül néhány sehol máshol nem létezik, a megerősítés dátum szerint felsorolja őket, és kéri az elem nevét. A csak hozzáfűzésre szolgáló célokból nem lehet törölni.

A sor alatt a kártya megmondja, hova kerül az elem, és mi van ott ténylegesen: hány helyszín tartja, mikor látták utoljára az egyes célokat, és teljesül-e a 3-2-1. Egy helyszín az eredeti adatokat tartalmazó szerver, minden telephelyen kívüli cél és minden Az épületen kívül jelölt tároló. A BombVault a másolatokat és a helyszíneket ellenőrzi; a 3-2-1 "két adathordozó" részét nem ellenőrzi.

Elhelyezési alapértelmezések

A Beállítások, Tárolás, Elhelyezési alapértelmezések alatt tartományonként egy sor van, ugyanazokkal a gombokkal. A másolatok azonnal érvényesek minden saját választás nélküli elemre, és a Compose-stackek projektmappáira is. A hely egy új elemre az első mentésekor válik érvényessé; a megváltoztatása egyetlen mentést sem mozgat. Mentés előtt a sor megnevez minden célt, amely elemeket nyer vagy veszít, és hogy ez hány pillanatképet jelent. Az Alkalmazás a biztonsági mentés nélküli elemekre minden még mentés nélküli elemet visszaállít az alapértelmezésre.

Egy új telephelyen kívüli cél megkap minden elemet, amely nincs Helyire állítva. Az azt hozzáadó párbeszédablak megmondja, hány elemről van szó, és ahol ismert, mennyi előzményt jelent ez, és felajánlja, hogy kihagyja azokat az elemeket, amelyeket más céloknál is kihagytak.

Közvetlen tárolók

Ha egy elemnél kikapcsolod a Helyit, így egy közvetlen tároló nélküli cél lesz az otthona, egy párbeszédablak nyílik meg egy javasolt hellyel a cél mellett, például s3:https://s3.eu-central-003.backblazeb2.com/bucket/containers-direct, és egy kapcsolatteszttel, amely semmit nem hoz létre. A Létrehozás és használat létrehozza a tárolót, és odairányítja az elemet. A közvetlen tároló átveszi a cél kulcsát, tárolási osztályát, korlátait, append-only beállítását és megőrzését, és velük együtt változik; a Tárolók kártya csak olvashatóként mutatja. Ha a cél új kulcsa nem tudja megnyitni, a közvetlen tároló megtartja azt a kulcsot, amije van, és a mentés ezt jelzi. Egy közvetlen tárolón lévő elem onnan másolódik a többi világító célra, soha nem arra a célra, amelyhez a tároló tartozik. A pillanatképei a bv:direct címkét viselik, és minden más megőrzési kör megtartja őket, így egy közvetlen tároló, amely elvesztette a kapcsolatát a céljával, soha nem öregszik a helyi szabályok szerint. A B2-t az S3-végpontján keresztül érjük el, ahol a kulcsazonosítót és az alkalmazáskulcsot kell megadni S3-hitelesítő adatként; a cél saját mappájára korlátozott kulcs nem éri el a mellette lévő mappát, ezért korlátozd inkább a kulcsot a cél feletti mappára.

Az épületen kívül

Egy nevesített tároló megjelölhető Az épületen kívül-ként a Tárolók kártyán. A távoli tárolók megjelölve indulnak; kapcsold ki egy ugyanabban az épületben lévő rest-servernél. A jelölés csak a helyszíneket és a 3-2-1-et számolja a kártyákon. Egyetlen másolatot sem változtat meg.

Újraépítés után

A másolási választások a BombVault saját beállításaiban élnek. Egy, a Biztonsági mentések felfedezése gombbal végzett újraépítés után, visszaállított /config nélkül, ezek eltűnnek, és minden másolása újra elküldené a B2-be azokat az elemeket, amelyeket kihagytál. Ezért minden újraépített tartomány telephelyen kívüli replikációja szünetel. Az irányítópult sárgán mutatja, és az Elhelyezési alapértelmezések felajánlja az Alapértelmezés megerősítése lehetőséget, egy előnézettel arról, mit másol a következő futás, és azokkal a nevekkel a mentésekben, amelyeknek nincs bejegyzésük, amelyeket ott kihagyhatsz. Csak a megerősítés zárja le a szünetet; egy beállításfájl importálása visszahozza a szabályokat és az alapértelmezéseket, de nem zárja le.

Távoli elsődleges tárolók

Egy tartomány mentési útvonala (Beállítások, Tárolás) nem korlátozódik helyi mappára: irányítsd egyenesen egy restic távoli tárolóra (s3:..., rest:http://host:8000/repo, sftp:felhasznalo@host:/repo, rclone:remote:bucket/utvonal), és a BombVault közvetlenül oda ment, külön helyi másolat és replikációs lépés nélkül. Ez valóban más alak, mint a fenti külső telephelyi replikáció: ott a helyi tároló az elsődleges, a külső pedig annak legjobb tudás szerinti archívuma; itt a távoli tároló maga az elsődleges, és ez az egyetlen példány, amíg az adott tartományhoz nem állítasz be külső telephelyi replikációt is (vagy egy második távoli tárolót).

A hat útvonalmező (Konténerek, VM-ek, Flash, Önmentés, Mappák, ZFS-adatkészletek) mindegyike mellett közvetlenül ott áll egy Helyi / Távoli kapcsoló:

• Helyi a megszokott mappaböngészőt mutatja.
• Távoli ezt egy egyszerű URL-mezőre cseréli, plusz egy gombra, amely ugyanazt a kapcsolatteszt és hitelesítőadat párbeszédet nyitja meg, amit a külső telephelyi célok használnak, csak épp ehhez az elsődleges tárolóhoz beállítva. Onnan a következőket kapod:
  • Kapcsolattesztet a valódi útvonal ellen, mielőtt rábíznád magad.
  • Sávszélesség-korlátokat (fel- és letöltés), hogy egy ütemezett mentés a távoli elsődleges tárolóba ne telítse a WAN-vonaladat: ugyanazok a restic kapcsolók, --limit-upload és --limit-download, amiket a külső telephelyi replikáció használ, most magára a mentésre alkalmazva.
  • Append-only védelmet (változtathatatlanság), ugyanazzal az aktív manipulációs teszttel ellenőrizve (valódi DELETE próba a túloldal ellen), amit a külső telephelyi célok kapnak. Bekapcsolva a BombVault megtagadja a tároló saját nyesését: mivel mögötte nincs külön helyi másolat, az ezen a gépen lévő hitelesítő adatok nem lehetnek képesek törölni a mentés egyetlen példányát.
  • Növekedési keret riasztást, ugyanabból a tárolóméret-trendből számolva, amit a Tárolás kártya amúgy is követ.

Ezek közül semmi sem kötelező: egy kézzel beírt távoli útvonal mentett biztonsági beállítások nélkül pontosan úgy ment, ahogy eddig (korlátlan sávszélesség, nyesehető, nincs keretriasztás). A biztonsági párbeszéd arra az esetre van, amikor ugyanazt a védelmet szeretnéd, amit egy külső telephelyi másolat kap, anélkül hogy pusztán ezért külön külső célt kellene létrehoznod.

A felhő- és REST-hitelesítő adatok közösek

Egy távoli elsődleges tároló ugyanazokkal az S3/REST hitelesítő adatokkal azonosít, amelyek a Beállítások, Felhőhozzáférés, Megosztott felhőbeli hitelesítő adatok alatt vannak beállítva. Az elsődleges tárolóknak nincs külön hitelesítőadat-tárolójuk.

SMB és WebDAV hoszt-csatolás nélkül

A Beállítások, Felhőhozzáférés, rclone alatt van egy űrlap Windows- vagy Samba-megosztáshoz és WebDAV-szerverhez (Nextcloud, ownCloud, SharePoint vagy bármely más). Add meg a rövid nevet, a hosztot és a megosztást (SMB) vagy az URL-t és a szervertípust (WebDAV), a felhasználót és a jelszót, és a BombVault megírja helyetted az rclone szakaszt. A jelszót tárolás előtt maga az rclone homályosítja el; ha már létező névvel adsz hozzá célt, az lecseréli azt a szakaszt, ahelyett hogy egy másodikat adna hozzá.

Az űrlap a kész hellyel válaszol, például rclone:nas:backups. Írd ezt egy Mentési útvonalba vagy egy telephelyen kívüli célba, és ha szeretnél, adj hozzá egy almappát (rclone:nas:backups/bombvault). A megosztás az útvonal első szakasza, nem a név része.

Ez jobb út, mint a megosztást az Unraidben csatolni: a restic nem javasolja, hogy egy tároló csatolt CIFS-megosztáson legyen, itt pedig semmi sincs csatolva. Az NFS azért nincs az űrlapon, mert sem a resticnek, sem az rclone-nak nincs NFS-backendje; NFS-hez csatold az exportot a hoszton, és irányíts rá egy Mentési útvonalat.

Módosíthatatlan (append-only) telephelyen kívüli

Jelölj egy telephelyen kívüli tárolót append-only-ként, hogy a zsarolóvírus vagy egy feltört hoszt ne tudja törölni vagy átírni a mentéseidet. A túloldal (egy restic/rest-server --append-only módban futva) érvényesíti. A BombVault csak ellenőrzi, és soha nem mutat zöldet pusztán egy konfigurációs állítás alapján.

A vezetett telephelyen kívüli beállítás varázsló végigvezet a backend választásától (rest-server / rclone / S3) egészen egy beilleszthető rest-server telepítési kódrészletig, egy kapcsolattesztig, a módosíthatatlan kapcsolóig (amely azonnal lefuttatja a manipulációs tesztet) és egy megőrzési stratégiáig, így az append-only telephelyen kívüli mentés elérhető a konfigok kézi szerkesztése nélkül.

A /locks/ alatti sikeres törlés várt viselkedés

Az append-only nem azt jelenti, hogy semmit sem lehet többé törölni. A resticnek fel kell vennie és el kell engednie a saját zárait, ezért a /locks/ szándékosan írható és törölhető marad. A pillanatfelvételek és a mögöttük lévő adatok, vagyis pontosan az, amit egy zsarolóvírus célba venne, nem távolíthatók el. Ha magad próbálod ki a túloldalt, a /locks/ alatt sikeres törlés helyes viselkedés, nem rés a védelemben.

A módosíthatatlan tárolók soha nem nyesődnek erről a gépről

Egy módosíthatatlan telephelyen kívüli tároló szándékosan soha nem nyesi a régi pillanatképeket. Állíts be egy növekedési keret riasztást hozzá, hogy értesülj, mielőtt a tárolóméret elszabadulna.

Manipulációs teszt

A BombVault időnként bizonyítja az append-only garanciát azzal, hogy ténylegesen megkísérel egy törlést a telephelyen kívüli tároló ellen, egy nem létező objektumra célozva:

• Az elutasítás azt jelenti, hogy védett.
• Az elfogadás azt jelenti, hogy nem védett.
• Egy nem meggyőző eredmény (a szerver elérhetetlen, hitelesítési hiba) soha nem billenti át a tárolt ítéletet.

Egy valódi védett-védtelen átbillenés egyetlen riasztást indít.

DR-próbák

A BombVault kétféle szintű bizonyítékot kínál arra, hogy a mentéseid ténylegesen visszaállíthatók, nem csak jelen vannak.

• Visszaállítás-ellenőrző próbák (helyi). A BombVault időnként lefuttatja a restic check --read-data-subset parancsot (korlátozva, soha nem egy lemezt megtöltő teljes visszaállítás), és tartományonként Visszaállíthatóság igazolva jelvényt mutat. Az ütem a Beállítások, Ütemezések alatt él; a jelvény a Beállítások, Integritás alatt.
• DR-próbák (telephelyen kívüli). A BombVault visszaállít egy valódi célt a telephelyen kívüli tárolóból egy eldobható homokozóba, ellenőrzi fájlról fájlra és bájtról bájtra, majd feltakarít. Ez bizonyítja, hogy telephelyen kívülről helyre tudsz állni, nem csak azt, hogy a tároló válaszol.

A zsarolóvírus-védelmi eredménytábla az irányítópulton mindezt tartományonkénti zöld / sárga / piros helyzetté gyűjti össze, egy korral bélyegzett ellenőrzőlistával (telephelyen kívüli beállítva, append-only igazolva, replikáció naprakész, visszaállítási próba sikeres, titkosítás be, nyesési stratégia beállítva). Minden piros sor mélyhivatkozással a javításra mutat, és a kártya csak igazolt tényeken vált valaha is zöldre.

Példányok párosítása

A Fogadók, a lehívási források, a Példányok oldal és a Mesh telephelyen kívüli mind egy másik BombVaulttal beszélnek. Ezt egyetlen párosítási csoport tagjaiként teszik, és egy példány tizenkét szóval csatlakozik a csoporthoz.

Az első példányon nyisd meg a Beállítások → Párosítás fület, és a párosítókártyákon kattints a Jelmondat létrehozása gombra. Megjelenik tizenkét szó egy ablakban, amelyben egy Másolás gomb is van. Minden további példányon nyisd meg ugyanazt a helyet, kattints a Jelmondat megadása gombra, és illeszd be vagy gépeld be őket, vagy kattints az ablakban a Beillesztés gombra. Egy szót, amely nincs a listán, az oldal már gépelés közben megnevez a helyével együtt, az utolsó szó pedig egy ellenőrző összeget hordoz, így egy elgépelt vagy felcserélt szó kiderül, mielőtt bármi párosodna. A jelmondatot csak egyetlen példányon hozd létre: két példány, amely mindkettő jelmondatot hoz létre, két külön csoportot alkot. Ha egy percig senki nem jelentkezik, a fül két kiutat kínál: jelenítsd meg újra a szavakat, hogy ott add meg őket, vagy add meg a másik példány szavait, és csatlakozz a csoportjához egy lépésben. A párosítás bejelentkezési jelszó nélkül is működik, de állíts be egyet: enélkül bárki, aki meg tudja nyitni ezt a webes felületet, elolvashatja a szavakat, és a csoporton keresztül megszerezheti a benne lévő minden példány restic jelszavát. A párosítókártya erre figyelmeztet, amíg nincs beállítva jelszó. Jelszóval a jelmondat újbóli megjelenítése kéri azt. A Csoport elhagyása ismét kivesz egy példányt.

Bárki, aki ismeri a szavakat, csatlakozhat a csoporthoz, ezért kezeld őket jelszóként.

Hogyan érik el egymást a tagok. Minden példány a böngésződből ismeri meg a saját hálózati címét, amint bejelentkezel, ez a relay-kártyán Ez a példány a hálózatodon néven jelenik meg; javítsd ott, ha reverse proxy vagy szokatlan port áll előtte. Ugyanazon a hálózaton a tagok multicasttal hirdetik meg ezt a címet, és közvetlenül beszélnek egymással, és ahol a multicast nem tud átjutni egy konténerhálózaton, mint amilyen a Docker alapértelmezett bridge hálózata, egy példány ehelyett a saját alhálózatában keresi meg a többieket egy aláírt hívással, amelyre csak egy csoporttag tud válaszolni, így a párosítás relay nélkül is másodpercek alatt befejeződik. Ha semmi nem jön elő, a párosítókártya alatti Nem találod? egyetlen címet fogad el kézzel megadva, egy másik alhálózathoz vagy nem szabványos porthoz. A különböző hálózatokon lévő példányok egy relayen mennek keresztül, amelyet ugyanazon a fülön választasz ki:

• Projekt-relay (alapértelmezett): parleyport.halleluja.design, ugyanaz a relay, amelyet a KnightLoader is használ. Nincs mit beállítani.
• Saját relay: a ParleyPort konténer az Unraid Community Apps-ból, vagy az egyik példányod, amely már elérhető kívülről, és be van kapcsolva a Szolgáljon relayként. Az a példány ezután a saját címén, a /relay/connect alatt válaszol, a már meglévő reverse proxyja és tanúsítványa mögött, és csak a te csoportodat engedi be. Add meg a relay címét minden példányon, amelynek használnia kell azt.
• Nincs relay: a tagok automatikusan csak ugyanazon a hálózaton találják meg egymást, sehol máshol.

Mit lát a relay. Minden hívás a tagok között AES-256-GCM-mel van lezárva, a tizenkét szóból származtatott kulccsal, és ez a kulcs sosem hagyja el a példányaidat. A relay megismer egy hash-t, amely csoportosítja a kapcsolatokat, hogy melyik példánynak szól egy üzenet, mekkora, és mikor halad át. Egy közvetlen hívás a helyi hálózaton ugyanígy van lezárva, és alá is van írva, így semmi sem függ az önaláírt tanúsítványtól, amelyet egy példány kiszolgál.

Mi utazik a csoporton át. A Példányok oldal eredményjelzői, egy kérés egy tartomány azonnali ellenőrzésére, a Mesh telephelyen kívüli ajánlatai, és amire egy fogadónak vagy lehívási forrásnak szüksége van: a másik példány tárolóhelyei és a restic jelszava. Mentési adat soha: az mindig egyenesen a restic háttérrendszerekhez megy. Az APP_KEY sem: a restic jelszó azon példány tárolóit nyitja meg, és semmi mást, sem a tárolt titkait, sem a munkameneteit, sem a helyreállítási kódjait.

A párosítás előtti bejegyzések. A flottatokennel hozzáadott példányok, valamint a másik példány APP_KEY-ével beállított Fogadók és lehívási források a frissítés után is megmaradnak, és Újra párosítás jelöléssel jelennek meg. A Fogadók és lehívási források továbbra is működnek: első indulásakor a BombVault minden tárolt APP_KEY-t lecserél az abból származtatott restic jelszóra. Párosítsd a két példányt, majd szerkeszd a bejegyzést, és válaszd ki a példányát. Egy ilyen példány átveszi a régi kártyáját, amint egy azonos nevű példány megjelenik a csoportban.

Az egyetlen hely, amely még mindig kézzel kér APP_KEY-t, a Visszaállítás egy másik BombVault tárolóból, arra az esetre, ha a másik példány eltűnt, és nem tud válaszolni egy csoportban.

Fogadó irányítópult (a fogadó oldal)

A fogadó oldal, csak olvasható módon figyelve, integritás-ellenőrzéssel ezen a gépen.

Minden fenti a küldő oldal. Azon a gépen, amely módosíthatatlan telephelyen kívüli másolatokat fogad egy másik BombVaulttól, a Fogadó irányítópult független, csak olvasható monitorozást ad azokról a tárolókról a fogadó hardveren, így egy csendes hiba a túlsó végen nem marad észrevétlen.

Kapcsold be a Fogadó kapcsolót a Beállításokban egy Fogadó fül felfedéséhez. Alapból ki van kapcsolva; csak olyan gépen engedélyezd, amely ténylegesen fogad módosíthatatlan telephelyen kívüli mentéseket. Ezután regisztrálj egy fogadott tárolót (csak olvasható, a küldő példány restic jelszavával megnyitva, amelyet a párosítási csoporton keresztül kap meg), hogy megkapd:

• Egy forrás szerint csoportosított pillanatkép-leltárt, így pontosan látod, mely konténerek, VM-ek és fájlkészletek landoltak.
• Utoljára fogadva forrásonként, így tudod, mindegyik mennyire friss.
• Egy független restic check-et, amely a fogadó hardveren fut, így az integritás ott ellenőrződik, ahol az adat ténylegesen ül, nem csak a küldőn.
• Egy holtemberkapcsolót: riasztás, amikor egy forrás abbahagyja a küldést egy általad beállított időablakon belül.
• Integritási riasztásokat: riasztás, amikor egy ellenőrzés a fogadó oldalon meghiúsul.

A Fogadó szigorúan csak olvasható. Soha nem ír a fogadott tárolóba, így soha nem tudja megtörni az append-only garanciát, amelyre a küldő támaszkodik.

Fogadószerver

A fogadó gép azt a rest-servert is futtathatja, amelyre a többiek másolnak. A Fogadó fül tetején a Fogadószerver beállítása egy megosztáson lévő mappát kér, az Új mappa gombbal újat is létre lehet hozni, valamint egy portot (8000, kivéve ha egy másik konténer már használja). A BombVault ezután:

1. visszautasítja a műveletet, ha már van rest-server nevű konténer, vagy egy másik konténer foglalja a portot;
2. letölti a restic/rest-server képet, és a Docker-socketen át append-only módban indítja, privát tárolókkal és a mappában lévő bejelentkezési fájllal;
3. kiírja az Unraid-sablonját a flash meghajtóra, így a konténer szerkeszthető marad a Docker fülön, vagy letölthető sablonként kínálja fel, ha a flash meghajtó nem érhető el;
4. lefuttatja rajta a manipulációs tesztet, és megmutatja, hogy elutasítja-e a törlést.

A csoportod példányai ezután a célvarázslóban az A csoportodból alatt találják meg a szervert, a fogadó gép nevén. Minden példány az első választáskor saját bejelentkezést kap, és ott csak a saját mappájába ír. A kártya felsorolja ezeket a bejelentkezéseket, a Bejelentkezés visszavonása pedig elvesz egyet; amit az a példány már átmásolt, a mappában marad. A beállítás egy bejelentkezést a csoporton kívüli valakinek is létrehoz, amelynek jelszavát a kártya egyszer mutatja meg.

Az a példány, amely a fogadó gépet csak a relayen át éri el, nem használhatja a szervert, mert a relay nem visz mentéseket. Előbb add meg a fogadó gép címét a Beállítások, Párosítás alatt. Ha a BombVault saját IP-címen fut (például br0-n), töltsd ki a Cím a partnereknek mezőt, mert a szerver a hoszt címén figyel.

Végigvezetett példa: két Unraid gép, elejétől a végéig

Fent az alkatrészek szerepelnek. Itt egy teljes összeállítás valódi értékekkel, mert az alkatrészeket könnyebb összerakni, ha az ember egyszer már látta őket összerakva.

Két gép: a TOWER futtatja a konténereket és küldi a mentéseket, a VAULT fogadja őket és kikényszeríti a változtathatatlanságot. Cseréld a saját neveidre, címeidre és megosztási útvonalaidra.

1. A VAULT gépen állítsd fel az append-only kiszolgálót. A TOWER BombVaultjában menj a Beállítások → Telephelyen kívüli → Beállítás pontra, válaszd a rest-server lehetőséget, és készítsd el a receptet. Másold ki az Unraid sablon (XML) fület, mentsd a VAULT gépen /boot/config/plugins/dockerMan/templates-user/my-rest-server.xml néven, majd Docker → Add Container, és válaszd a rest-server elemet a sablonlistából. Indítás előtt írd be a megjelenített htpasswd sort a VAULT gépen a /mnt/user/appdata/rest-server/.htpasswd fájlba. Az egyszer használatos jelszó egyszer jelenik meg és sosem kerül tárolásra, másold ki most. Az a sor ugyanazt a jelszót hordozza, már bcrypttel kivonatolva: a nyílt szöveg a TOWER REST-hitelesítő adataiba kerül, a kivonatolt sor a VAULT .htpasswd fájljába. Neked semmit sem kell kivonatolnod.

Hagyd bent a `--append-only` kapcsolót az OPTIONS mezőben. Ez az egésznek a lényege: nélküle a VAULT megint csak egy hétköznapi megosztás.

2. A TOWER gépen irányítsd oda a külső tárolót. A tároló címe azt a mintát követi, amit a recept kiír:

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

Az útvonal első szakasza a htpasswd felhasználó, a második a tároló. Add meg a generált felhasználót és jelszót a cél REST hitelesítő adataiként, majd futtasd a kapcsolatellenőrzést.

3. A TOWER gépen kapcsold be a „Változtathatatlan” beállítást. A manipulációs teszt azonnal lefut, és védett eredményt kell adnia. Mit jelentenek a válaszok:

Eredmény	Mi történt
védett	A VAULT elutasította a törlést. Ez az egyetlen megfelelő állapot.
NEM védett	A VAULT elfogadott egy törlést. Hiányzik a --append-only, vagy eltávolították.
nem egyértelmű	Egyik sem. Általában a cím nem az, amit maga a restic használ, vagy megváltoztak a hitelesítő adatok. Semmi nem kerül rögzítésre, és nem indul riasztás.

4. A VAULT gépen nézd meg, mi érkezik. Párosítsd a két gépet (Példányok párosítása), kapcsold be a Beállítások → Általános → Fogadó pontot, nyisd meg a Fogadó fület, és regisztráld a tárolót csak olvasható módon, a TOWER-t megadva küldő példányként.

A hely a konténeren belüli útvonal, a gazdagép csatolási pontjához képest megadva

Ezt add meg: user/appdata/rest-server/bombvault-containers/containers, és ne ezt: /mnt/user/appdata/…. A BombVault konténerben fut, ahol a gazdagép /mnt könyvtára máshová van csatolva; abszolút gazdagép-útvonal ott nem létezik. Ha mégis beilleszted, a BombVault mostantól megmondja a helyette használandó relatív útvonalat.

A VAULT a mentéskor megkapja a TOWER restic jelszavát a csoporton keresztül; senkinek sem kell kulcsot beírnia.

5. Ha akarod, tedd kölcsönössé. Ismételd meg ugyanazt az öt lépést a másik irányban: egy rest-server a TOWER gépen, amely a VAULT másolatát fogadja. Ekkor mindkét gép kikényszeríti a másik változtathatatlanságát, és egyik sem tudja törölni a másik mentéseit.

Vezetett helyreállítás

Egy dedikált Helyreállítás fül egy helyen végigvezet egy friss vagy újraépített telepítést a katasztrófaeseten:

1. Először visszaállítja a BombVault saját beállításait, így a mentési útvonalak, telephelyen kívüli célok és hitelesítő adatok, amelyekre a folyamat többi része szüksége van, előre kitöltve jelennek meg (a Docker socketen keresztüli önújraindítással alkalmazva, így az élő beállítás-adatbázis soha nem íródik felül nyitott handle alatt).
2. Ellenőrzi, hogy a BombVault olvasni tudja-e a mentéseidet (a titkosításikulcs-buktató előre).
3. Lehetővé teszi, hogy rámutass a meglévő tárolódra (helyi vagy telephelyen kívüli).
4. Felfedezi a benne tárolt konténereket, VM-eket, fájlkészleteket és ZFS-adatkészleteket.
5. A konténereket és a VM-eket egyszerre visszaállítja (leállítva hagyva, így te indítod el őket szándékosan), a fájlkészleteket és a ZFS-elemeket pedig felsorolja, hogy egyenként állítsd vissza őket; a ZFS-elemek kikapcsolva térnek vissza. A helyreállítási csomagod egy kattintásnyira van.

Tervezett migráció versus katasztrófa

A vezetett helyreállítás egy mentésből állítja vissza a BombVault saját beállításait. Egy tervezett átköltözéshez egy új gépre ehelyett közvetlenül átviheted a konfigurációdat az Beállítások exportálása / importálása kártyával (egy hordozható JSON-fájl). Lásd: Konfiguráció.

Visszaállítás egy másik BombVault tárolóból

Egy külön kártya a Helyreállítás fülön megnyit egy másik BombVault-példány tárolóját (egy a /mnt alá csatolt megosztás vagy egy távoli URL) annak a példánynak az APP_KEY-ével, egy egyszeri, csak olvasható munkamenetben. Böngészd az ott tárolt konténereket, VM-eket és fájlkészleteket, válassz egy pillanatképet és állítsd vissza, és a visszaállított objektum normál helyi konténerré, VM-mé vagy fájlkészletté válik. Semmi sem íródik soha a másik tárolóba, és a saját mentési beállításaid érintetlenek maradnak (a munkamenet a memóriában él és magától lejár). Egy konténer áthelyezése az A szerverről a B szerverre nem jelenti a tárolóbeállításaid átirányítását és utólagos visszaállítását. Ez a kártya egyszeri: megnyit egy munkamenetet, visszaállítja, amit kiválasztasz, és elfelejti a másik példányt. Ha ehelyett állandó elrendezést szeretnél, amelyben ez a gép ütemezetten lehívja egy másik példány pillanatképeit a saját tárolójába, arra a Példányok oldal Lehívás füle való.

Az a konténer, amelynek a hálózata ezen a szerveren nem létezik, például egy Unraid br0 hálózat egy sima Docker-gazdán, a sora alatt hálózatválasztót mutat. A BombVault a választott hálózaton hozza létre, a többi hálózatával együtt. A fix IP-cím és a MAC-cím a régi hálózathoz tartozott, ezért elmarad, és ezeket az új hálózat adja.

Titkosításikulcs-helyreállító csomag

Ez az a darab, amely a vészhelyreállítást akkor is lehetővé teszi, amikor nincs futó BombVault.

Egy kattintás letölti a mesterkulcsot, a származtatott restic jelszót, valamint a pontos tárolóhelyeket és parancsokat, így közvetlenül a restic CLI-vel állíthatsz vissza bármely gépen. Egy irányítópult-emlékeztető nyaggat, amíg el nem tárolod.

Tárold a helyreállítási csomagot a szerveren kívül

A csomag azt a titkot tartalmazza, amely visszafejti a mentéseidet. Tartsd biztonságos, a szervertől elkülönített helyen (egy jelszókezelő, egy nyomtatott példány egy széfben). Ha elveszíted a BombVaultot és az APP_KEY-t is, helyreállítási csomag nélkül, a titkosított mentéseid nem állíthatók helyre.

Nem mindig a legújabb pillanatképet kell visszaállítani

A restic 0.17 óta a restic snapshots minden pillanatkép méretét mutatja. Adatvesztés után a legújabb pillanatkép lehet a kiürített, ezért ne állíts vissza olyan pillanatképet, amely sokkal kisebb az előzőeknél. Zsarolóvírus után lehet a titkosított, szokásos méretben. Ha a BombVault még fut, előbb nézd meg az Anomáliák oldalát: megnevezi az utolsó jó mentést. A visszaállításhoz nincs szükség a BombVault anomáliaadataira, és a megőrzés szüneteltetése mindig csak több pillanatképet tart meg.

A csomag lezárása

Ha bekapcsoltad az age-titkosítást az egyszerű exportokhoz (Beállítások), a csomag is le lesz vele zárva, és bombvault-recovery-kit.md.age néven töltődik le. Bináris helyett ASCII-armored formátumú, így továbbra is sima szöveg: jelszókezelőbe illesztése vagy kinyomtatása pontosan úgy működik, mint eddig, csak a tartalma olvashatatlan a kulcsod nélkül.

Ne tárold az age-kulcsot a csomagban

Egy lezárt csomag megnyitásához szükséged van az age privát kulcsodra. Olyan helyen tartsd, amely nem magától a csomagtól függ, különben egy helyett két dolgot kell majd helyreállítanod. A lezárás akkor éri meg, ha a csomag olyan helyen van, amely felett nincs teljes ellenőrzésed (megosztott jelszókezelő, felhős jegyzetek, egy kinyomtatott példány egy irodában); a saját széfedben lévő csomagot már a széf védi.

Bekapcsolt titkosítás és beállított, használható címzett nélkül a letöltést a BombVault eleve elutasítja. Soha nem tér át arra, hogy a mesterkulcsot nyílt szövegként adja ki.

Ha a csomag épp nincs kéznél

A jelszó sehol nincs tárolva, az APP_KEY értékéből számolódik. A kulccsal és egy shellel tehát magad is előállíthatod:

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

Ez HMAC-SHA256 a rögzített bombvault:restic-repo karakterlánc fölött, kulcsként a hexadecimális APP_KEY nyers bájtjaival, kimenetként 64 kisbetűs hexadecimális karakter. Ugyanez az érték szerepel a csomagban származtatott restic jelszóként; ez a szakasz arra a napra való, amikor a csomag máshol van, mint te.

Fogadott tárolónál a KÜLDŐ példány kulcsát használd

Az a tároló, amely külső telephelyi replikációval érkezett ide, a küldő gépen jött létre, annak saját APP_KEY kulcsával. A fogadó gép kulcsából származtatva olyan jelszót kapsz, amelyet a restic elutasít, és ez pontosan úgy néz ki, mint egy sérült tároló, holott nem az. Ez a szokásos oka annak, hogy a restic check egy fogadott tárolón újra és újra jelszót kér.

Mivel a helyreállítási definíciók minden tárolón belül élnek (<repo>/def, <repo>/vm-def), egy másolt tárolómappa teljesen önálló, így a csomag plusz a tároló minden, amire egy bare-metal visszaállításnak szüksége van.

Adatbázis-dump visszaszerzése

Egy adatbázis-dump önálló visszaállítási pont a konténerek tárolójában, dbdump:<container> címkével és egyetlen fájllal, /dbdump/<container>.sql. A BombVault a Mentések alatt listázza, letölti és importálja őket; alább ugyanezek a lépések pusztán a restickel, arra a napra, amikor a BombVault nincs kéznél.

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

Az egyes dumpokon a dbversion: és dbname: címke megmondja, melyik kiszolgálóverzióból való és mely adatbázisokat tartalmazza. A teljes fájl vége -- PostgreSQL database cluster dump complete vagy -- Dump completed.

Importáld egy azonos vagy újabb verziójú (PostgreSQL), illetve azonos főverziójú (MySQL és MariaDB) konténerbe, amelyet egyszer üres adatmappával indítottál, hogy feltöltse magát. A gazdagépnek nem kell adatbázis-kliens, a konténerben van:

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

Ha egy teljes dumpból csak egy adatbázis kell, a MySQL és a MariaDB elfogadja a --one-database <name> kapcsolót a kliens parancsán. A PostgreSQL-dumpban adatbázisonként egy szakasz van, mindegyik egy \connect <name> sorral kezdődik: másold a szakaszt külön fájlba, és az adatbázis létrehozása után -d <name> kapcsolóval importáld.

A rootként készült dump magával viszi a kiszolgáló felhasználóit

A rootként készült teljes MySQL- vagy MariaDB-dump tartalmazza a mysql rendszeradatbázist, így az importálás az új kiszolgáló fiókjait, a root jelszavát is beleértve, a dumpban lévőkre cseréli. PostgreSQL-en a konténer által létrehozott felhasználóra kapott role ... already exists üzenet várható és ártalmatlan.