Pritunl: gjendja e kontrollit kundrejt profilit të gjeneruar

Një arkiv rikthen një vendosje Pritunl funksionale; tjetri rikthen vetëm një imazh të saj. Një profil klienti, një kopje e konfigurimit të hostit dhe një tarball i drejtorisë së gjendjes duken të gjitha si kopje rezervë dhe asnjë prej tyre vetëm nuk i kthen organizatat, përdoruesit dhe përkufizimet e serverit që menaxhon Pritunl. Dallimi është pronësia: një pjesë e gjendjes i përket një baze të dhënash, një pjesë hostit dhe një pjesë është dalje e rigjeneruar. Zgjidhni shtresën e gabuar dhe rikthimi prodhon një server që niset, dëgjon dhe nuk di asgjë. Ky krahasim i ndan tre shtresat, që arkivi që mbani të përputhet me dështimin nga i cili po rikuperoheni.

Dy objekte duken si kopje rezervë dhe vetëm një rikthen shërbimin

Një profil klienti i shkarkuar përmban një certifikatë, një çelës dhe një pikë fundore. Është i plotë për atë pajisje të vetme dhe i padobishëm si regjistrim i vendosjes: nuk mbart organizata, përdorues të çaktivizuar, rrugë serveri apo llogari administrative. Rikthimi nga një dosje me profile jep klientë që nuk mund të vërtetojnë identitetin ndaj asgjëje.

Një kopje e konfigurimit të hostit është njëlloj e pjesshme. /etc/pritunl.conf mban cilësime në nivel hosti, duke përfshirë si të arrihet baza e të dhënave, dhe nuk përmban vetë objektet VPN.

Çfarë zotëron baza e të dhënave dhe çfarë zotëron hosti

Pritunl i mban përkufizimet e serverit, përdoruesit, organizatat dhe çelësat në MongoDB. Ajo bazë të dhënash është rrafshi autoritar i kontrollit dhe çdo skedar OpenVPN i gjeneruar në disk është dalje e nxjerrë prej saj. Një ndryshim i bërë drejtpërdrejt në një skedar të gjeneruar mbijeton deri në rigjenerimin e ardhshëm dhe pastaj zhduket, prandaj redaktimi i skedarëve të kohës së ekzekutimit nuk është një rregullim i qëndrueshëm. I njëjti rregull vlen për rrugët dhe ndërfaqet efektive: ato përshkruajnë atë që prodhoi rrafshi i kontrollit, jo atë që duhet të prodhojë.

Hosti kontribuon me një grup më të vogël, por të patransferueshëm vlerash. Njëri prej tyre është /var/lib/pritunl/pritunl.uuid, identiteti i atij nyjeje të caktuar.

Ai identitet ka më shumë rëndësi në një grup. Një host zëvendësues ka nevojë për regjistrimin e vet në vend të një kloni të UUID-së së një nyjeje aktive, përndryshe të dy përleshen për të njëjtin identitet. Regjistroni hartën midis çdo hosti, UUID-së së tij dhe bazës së të dhënave drejt së cilës tregon, sepse një eksport i vetëm i bazës së të dhënave nuk përshkruan cilat cilësime hosti i përkisnin cilës makinë. Versionet e softuerit dhe emrat publikë të pikave fundore i përkasin të njëjtit regjistrim.

Bëni një eksport konsistent, jo një kopje drejtorie

Kopjimi i drejtorisë së të dhënave të MongoDB ndërsa shërbimi shkruan prodhon skedarë që mund të mos formojnë një bazë të dhënash të përdorshme. Përdorni në vend të kësaj rrugën e eksportit të mbështetur nga baza e të dhënave, të ekzekutuar ndaj topologjisë që keni në të vërtetë:

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

Një host i pavarur e toleron atë formë të thjeshtë. Një grup replikash ka nevojë për një pikë konsistente në kohë dhe një eksport i bazuar në oplog ka kërkesa që një eksport i thjeshtë nuk i ka. Procedura e mbështetur varet nga versioni dhe topologjia juaj e MongoDB, prandaj mos e nxirrni nga prania e një drejtorie të dhënash. Arkivoni shtresën e hostit pranë eksportit, në të njëjtin ekzekutim, me të njëjtin vulë kohore.

Provoni rikthimin para se t’ju duhet

Një kopje rezervë që askush nuk e ka rikthyer është një hipotezë. Ndërtoni shërbimin në një rrjet të izoluar, rikthejeni eksportin dhe vendosni skedarët e hostit përsëri:

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

Pastaj verifikoni objektet dhe jo procesin: identifikohuni, konfirmoni se organizatat dhe përdoruesit janë të pranishëm dhe nisni një klient testues ndaj një përkufizimi serveri që e njihni. Pengoni hostin e rikthyer të reklamojë pikën fundore të prodhimit ose të pranojë lidhje reale derisa adresat dhe identitetet të jenë të qëllimshme. Këtu gjithashtu zbuloni se arkivi ka nevojë për kredenciale që jetonin vetëm në makinën e dështuar, prandaj ruani kredencialet e rikthimit në një vend të pavarur. Një rikthim që varet nga hosti që sapo humbët nuk është plan rikthimi.

Së fundi, mbani mend se një pamje e vjetër rikthen vendime të vjetra. Nëse një administrator çaktivizoi një identitet pasi u mor eksporti, rikthimi e riaktivizon atë. Pajtimi pas rikuperimit i përket procedurës, jo mendimit të mëvonshëm.