Pritunl: riadiaci stav verzus generovaný profil
Klientsky profil a kópia konfigurácie vyzerajú obe ako zálohy. Porovnajte, čo vlastní MongoDB, čo vlastní hostiteľ a ako obnoviť funkčný Pritunl.
Jeden archív obnoví funkčné nasadenie Pritunl; druhý obnoví len jeho obraz. Klientsky profil, kópia konfigurácie hostiteľa a tarball stavového adresára vyzerajú všetky ako zálohy a žiadny z nich sám o sebe nevráti organizácie, používateľov a definície serverov, ktoré Pritunl spravuje. Rozdiel je vo vlastníctve: časť stavu patrí databáze, časť hostiteľovi a časť je regenerovaný výstup. Zvoľte nesprávnu vrstvu a obnova vytvorí server, ktorý sa spustí, načúva a nič nevie. Toto porovnanie oddeľuje tri vrstvy, aby archív, ktorý si ponecháte, zodpovedal poruche, z ktorej sa zotavujete.
Dva objekty vyzerajú ako zálohy a službu obnoví len jeden
Stiahnutý klientsky profil obsahuje certifikát, kľúč a koncový bod. Je úplný pre to jedno zariadenie a ako záznam o nasadení je bezcenný: nenesie žiadne organizácie, žiadnych deaktivovaných používateľov, žiadne trasy serverov ani žiadne administratívne účty. Obnova zo priečinka profilov dáva klientov, ktorí sa nevedia autentizovať voči ničomu.
Kópia konfigurácie hostiteľa je rovnako čiastočná. /etc/pritunl.conf obsahuje nastavenia na úrovni hostiteľa, vrátane toho, ako sa dostať k databáze, a neobsahuje samotné objekty VPN.
Čo vlastní databáza a čo vlastní hostiteľ
Pritunl uchováva definície serverov, používateľov, organizácie a kľúče v MongoDB. Táto databáza je autoritatívna riadiaca rovina a každý generovaný súbor OpenVPN na disku je z nej odvodený výstup. Zmena vykonaná priamo v generovanom súbore prežije do ďalšej regenerácie a potom zmizne, a preto úprava runtime súborov nie je trvalá oprava. Rovnaké pravidlo platí pre efektívne trasy a rozhrania: opisujú, čo riadiaca rovina vytvorila, nie čo by mala vytvoriť.
Hostiteľ prispieva menšou, ale neprenosnou sadou hodnôt. Jednou z nich je /var/lib/pritunl/pritunl.uuid, identita toho konkrétneho uzla.
Táto identita je najdôležitejšia v clustri. Náhradný hostiteľ potrebuje svoje vlastné zaradenie, nie klon UUID aktívneho uzla, inak sa obaja bijú o rovnakú identitu. Zaznamenajte mapovanie medzi každým hostiteľom, jeho UUID a databázou, na ktorú ukazuje, pretože jediný výpis databázy neopisuje, ktoré nastavenia hostiteľa patrili ktorému stroju. Verzie softvéru a verejné názvy koncových bodov patria do rovnakého záznamu.
Urobte konzistentný výpis, nie kópiu adresára
Kopírovanie dátového adresára MongoDB počas zápisu služby vytvára súbory, ktoré nemusia tvoriť použiteľnú databázu. Použite namiesto toho podporovanú cestu výpisu databázy, spustenú proti topológii, ktorú skutočne máte:
mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid
Samostatný hostiteľ znesie túto jednoduchú formu. Sada replík potrebuje konzistentný bod v čase a výpis založený na oplogu má požiadavky, ktoré obyčajný výpis nemá. Podporovaný postup závisí od vašej verzie a topológie MongoDB, takže ho neodvodzujte z prítomnosti dátového adresára. Archivujte vrstvu hostiteľa vedľa výpisu, v tom istom behu, s rovnakou časovou pečiatkou.
Nacvičte obnovu, kým ju budete potrebovať
Záloha, ktorú nikto neobnovil, je hypotéza. Postavte službu v izolovanej sieti, obnovte výpis a vráťte súbory hostiteľa na miesto:
mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /
Potom overte objekty, nie proces: prihláste sa, potvrďte, že organizácie a používatelia existujú, a spustite jedného testovacieho klienta proti definícii servera, ktorú poznáte. Zabráňte obnovenému hostiteľovi inzerovať produkčný koncový bod alebo prijímať skutočné pripojenia, kým adresy a identity nebudú zámerné. Tu tiež zistíte, že archív potrebuje prihlasovacie údaje, ktoré žili len na zlyhanom stroji, takže údaje na obnovu uložte na nezávislom mieste. Obnova, ktorá závisí od hostiteľa, ktorého ste práve stratili, nie je plán obnovy.
Nakoniec si pamätajte, že starý snímok obnovuje staré rozhodnutia. Ak správca po vyhotovení výpisu deaktivoval identitu, obnova ju znova aktivuje. Zosúlaďovanie po obnovení patrí do postupu, nie do dodatočnej úvahy.