Pritunl: starea de control versus profilul generat

O arhivă restaurează o implementare Pritunl funcțională; cealaltă restaurează doar o imagine a ei. Un profil de client, o copie a configurației gazdei și un tarball al directorului de stare arată toate ca niște copii de rezervă și niciunul singur nu readuce organizațiile, utilizatorii și definițiile de server pe care le administrează Pritunl. Diferența este proprietatea: o parte a stării aparține unei baze de date, o parte gazdei, iar o parte este rezultat regenerat. Alegeți stratul greșit și restaurarea produce un server care pornește, ascultă și nu știe nimic. Această comparație separă cele trei straturi, astfel încât arhiva pe care o păstrați să corespundă defecțiunii din care vă recuperați.

Două obiecte arată ca niște copii de rezervă și doar unul restaurează serviciul

Un profil de client descărcat conține un certificat, o cheie și un punct final. Este complet pentru acel singur dispozitiv și inutil ca evidență a implementării: nu transportă organizații, utilizatori dezactivați, rute de server sau conturi administrative. Restaurarea dintr-un dosar de profiluri oferă clienți care nu se pot autentifica față de nimic.

O copie a configurației gazdei este la fel de parțială. /etc/pritunl.conf conține setări la nivel de gazdă, inclusiv cum se ajunge la baza de date, și nu conține obiectele VPN în sine.

Ce deține baza de date și ce deține gazda

Pritunl păstrează definițiile de server, utilizatorii, organizațiile și cheile în MongoDB. Acea bază de date este planul de control autoritar, iar fiecare fișier OpenVPN generat pe disc este un rezultat derivat din ea. O modificare făcută direct într-un fișier generat supraviețuiește până la următoarea regenerare și apoi dispare, de aceea editarea fișierelor de execuție nu este o corecție durabilă. Aceeași regulă se aplică rutelor și interfețelor efective: descriu ce a produs planul de control, nu ce ar trebui să producă.

Gazda contribuie cu un set mai mic, dar netransferabil, de valori. Una dintre ele este /var/lib/pritunl/pritunl.uuid, identitatea acelui nod anume.

Acea identitate contează cel mai mult într-un cluster. O gazdă de înlocuire are nevoie de propria înregistrare, nu de o clonă a UUID-ului unui nod activ, altfel cele două se luptă pentru aceeași identitate. Înregistrați maparea dintre fiecare gazdă, UUID-ul ei și baza de date către care indică, deoarece un singur dump al bazei de date nu descrie ce setări ale gazdei aparțineau cărei mașini. Versiunile de software și numele publice ale punctelor finale aparțin aceleiași evidențe.

Faceți un dump consistent, nu o copie de director

Copierea directorului de date MongoDB în timp ce serviciul scrie produce fișiere care s-ar putea să nu formeze o bază de date utilizabilă. Folosiți în schimb calea de dump acceptată a bazei de date, rulată pe topologia pe care o aveți de fapt:

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

O gazdă de sine stătătoare tolerează acea formă simplă. Un set de replici are nevoie de un punct consistent în timp, iar un dump bazat pe oplog are cerințe pe care un dump simplu nu le are. Procedura acceptată depinde de versiunea și topologia dumneavoastră MongoDB, așa că nu o deduceți din prezența unui director de date. Arhivați stratul gazdei lângă dump, în aceeași rulare, cu aceeași marcă de timp.

Exersați restaurarea înainte de a avea nevoie de ea

O copie de rezervă pe care nimeni nu a restaurat-o este o ipoteză. Construiți serviciul într-o rețea izolată, restaurați dumpul și puneți la loc fișierele gazdei:

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

Apoi verificați obiectele, nu procesul: autentificați-vă, confirmați că organizațiile și utilizatorii sunt prezenți și porniți un client de test împotriva unei definiții de server pe care o recunoașteți. Împiedicați gazda restaurată să anunțe punctul final de producție sau să accepte conexiuni reale până când adresele și identitățile nu sunt deliberate. Tot aici descoperiți că arhiva are nevoie de acreditări care existau doar pe mașina defectată, așa că păstrați acreditările de recuperare într-un loc independent. O restaurare care depinde de gazda pe care tocmai ați pierdut-o nu este un plan de restaurare.

În sfârșit, amintiți-vă că un instantaneu vechi restaurează decizii vechi. Dacă un administrator a dezactivat o identitate după ce a fost făcut dumpul, restaurarea o reactivează. Reconcilierea după recuperare face parte din procedură, nu din gândul de după.