Pritunl: řídicí stav versus generovaný profil

Jeden archiv obnoví funkční nasazení Pritunl; druhý obnoví jen jeho obrázek. Klientský profil, kopie konfigurace hostitele a tarball stavového adresáře vypadají všechny jako zálohy a žádný z nich sám o sobě nevrátí organizace, uživatele a definice serverů, které Pritunl spravuje. Rozdíl je ve vlastnictví: část stavu patří databázi, část hostiteli a část je regenerovaný výstup. Zvolte špatnou vrstvu a obnova vytvoří server, který se spustí, naslouchá a nic neví. Toto srovnání odděluje tři vrstvy, aby archiv, který si ponecháte, odpovídal poruše, ze které se zotavujete.

Dva objekty vypadají jako zálohy a službu obnoví jen jeden

Stažený klientský profil obsahuje certifikát, klíč a koncový bod. Je úplný pro to jedno zařízení a jako záznam o nasazení je bezcenný: nenese žádné organizace, žádné deaktivované uživatele, žádné trasy serverů ani žádné administrativní účty. Obnova ze složky profilů dává klienty, kteří se nemohou autentizovat vůči ničemu.

Kopie konfigurace hostitele je stejně částečná. /etc/pritunl.conf obsahuje nastavení na úrovni hostitele, včetně toho, jak se dostat k databázi, a neobsahuje samotné objekty VPN.

Co vlastní databáze a co vlastní hostitel

Pritunl uchovává definice serverů, uživatele, organizace a klíče v MongoDB. Tato databáze je autoritativní řídicí rovina a každý generovaný soubor OpenVPN na disku je z ní odvozený výstup. Změna provedená přímo v generovaném souboru přežije do další regenerace a pak zmizí, a proto úprava běhových souborů není trvalá oprava. Stejné pravidlo platí pro efektivní trasy a rozhraní: popisují, co řídicí rovina vytvořila, ne co by měla vytvořit.

Hostitel přispívá menší, ale nepřenosnou sadou hodnot. Jednou z nich je /var/lib/pritunl/pritunl.uuid, identita toho konkrétního uzlu.

Tato identita je nejdůležitější v clusteru. Náhradní hostitel potřebuje své vlastní zařazení, nikoli klon UUID aktivního uzlu, jinak se oba přou o stejnou identitu. Zaznamenejte mapování mezi každým hostitelem, jeho UUID a databází, na kterou ukazuje, protože jediný výpis databáze nepopisuje, která nastavení hostitele patřila které stroji. Verze softwaru a veřejné názvy koncových bodů patří do stejného záznamu.

Pořiďte konzistentní výpis, ne kopii adresáře

Kopírování datového adresáře MongoDB během zápisu služby vytváří soubory, které nemusí tvořit použitelnou databázi. Použijte místo toho podporovanou cestu výpisu databáze, spuštěnou proti topologii, kterou skutečně 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ý hostitel snese tuto jednoduchou formu. Sada replik potřebuje konzistentní bod v čase a výpis založený na oplogu má požadavky, které prostý výpis nemá. Podporovaný postup závisí na vaší verzi a topologii MongoDB, takže jej neodvozujte z přítomnosti datového adresáře. Archivujte vrstvu hostitele vedle výpisu, ve stejném běhu, se stejným časovým razítkem.

Nacvičte obnovu, než ji budete potřebovat

Záloha, kterou nikdo neobnovil, je hypotéza. Postavte službu v izolované síti, obnovte výpis a vraťte soubory hostitele na místo:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

Poté ověřte objekty, ne proces: přihlaste se, potvrďte, že organizace a uživatelé existují, a spusťte jednoho testovacího klienta proti definici serveru, kterou poznáte. Zabraňte obnovenému hostiteli inzerovat produkční koncový bod nebo přijímat skutečná připojení, dokud adresy a identity nebudou záměrné. Zde také zjistíte, že archiv potřebuje přihlašovací údaje, které žily jen na selhaném stroji, takže údaje pro obnovu uložte na nezávislém místě. Obnova, která závisí na hostiteli, který jste právě ztratili, není plán obnovy.

Nakonec si pamatujte, že starý snímek obnovuje stará rozhodnutí. Pokud správce po pořízení výpisu deaktivoval identitu, obnova ji znovu aktivuje. Srovnání po obnovení patří do postupu, ne do dodatečné úvahy.