Pritunl: kalagayan ng kontrol kumpara sa nabuong profile

Isang archive ang nagbabalik ng gumaganang deployment ng Pritunl; ang isa ay nagbabalik lamang ng larawan nito. Ang profile ng kliyente, kopya ng pagsasaayos ng host, at tarball ng direktoryo ng kalagayan ay mukhang backup lahat, at wala sa kanila mag-isa ang nagbabalik ng mga organisasyon, user, at depinisyon ng server na pinamamahalaan ng Pritunl. Ang pagkakaiba ay pagmamay-ari: bahagi ng kalagayan ay pag-aari ng database, bahagi ng host, at bahagi ay muling nabuong output. Pumili ng maling layer at ang pagbabalik ay gagawa ng server na nagsisimula, nakikinig at walang alam. Hinihiwalay ng paghahambing na ito ang tatlong layer upang ang archive na itinatago mo ay tumugma sa pagkabigong binabawi mo.

Dalawang bagay ang mukhang backup at isa lamang ang nagbabalik ng serbisyo

Ang na-download na profile ng kliyente ay naglalaman ng sertipiko, key at endpoint. Kumpleto ito para sa isang device na iyon at walang silbi bilang talaan ng deployment: wala itong organisasyon, walang hindi aktibong user, walang ruta ng server at walang administratibong account. Ang pagbabalik mula sa folder ng mga profile ay nagbibigay ng mga kliyenteng hindi makapagpapatunay sa anuman.

Ang kopya ng pagsasaayos ng host ay kaparehong bahagya. Ang /etc/pritunl.conf ay may mga setting sa antas ng host, kabilang ang paraan ng pag-abot sa database, at wala itong mga bagay na VPN mismo.

Ano ang pag-aari ng database at ano ang pag-aari ng host

Itinatago ng Pritunl ang mga depinisyon ng server, user, organisasyon at key sa MongoDB. Ang database na iyon ang awtoritatibong control plane, at bawat nabuong file na OpenVPN sa disk ay output na nagmula rito. Ang pagbabagong ginawa nang direkta sa nabuong file ay tumatagal hanggang sa susunod na muling pagbuo at pagkatapos ay nawawala, kaya ang pag-edit ng mga runtime file ay hindi pangmatagalang pag-aayos. Ganoon din ang tuntunin sa mga epektibong ruta at interface: inilalarawan nila ang ginawa ng control plane, hindi ang dapat nitong gawin.

Nag-aambag ang host ng mas maliit ngunit hindi maililipat na set ng mga halaga. Isa rito ang /var/lib/pritunl/pritunl.uuid, ang pagkakakilanlan ng partikular na node na iyon.

Ang pagkakakilanlang iyon ang pinakamahalaga sa cluster. Ang kapalit na host ay nangangailangan ng sariling pagpapatala kaysa kopya ng UUID ng aktibong node, kung hindi ay nag-aagawan ang dalawa sa parehong pagkakakilanlan. Itala ang pagmamapa sa pagitan ng bawat host, UUID nito at database na tinutukoy nito, dahil ang isang dump ng database ay hindi naglalarawan kung aling mga setting ng host ang pag-aari ng aling makina. Ang mga bersyon ng software at pampublikong pangalan ng endpoint ay kabilang sa parehong talaan.

Gumawa ng pare-parehong dump, hindi kopya ng direktoryo

Ang pagkopya ng direktoryo ng data ng MongoDB habang nagsusulat ang serbisyo ay gumagawa ng mga file na maaaring hindi bumuo ng magagamit na database. Gamitin sa halip ang sinusuportahang landas ng dump ng database, na pinatakbo laban sa topolohiyang mayroon ka talaga:

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

Ang nakatayo nang host ay pinapayagan ang simpleng anyo na iyon. Ang set ng replica ay nangangailangan ng pare-parehong punto sa oras, at ang dump na nakabatay sa oplog ay may mga kinakailangang wala sa simpleng dump. Ang sinusuportahang pamamaraan ay nakasalalay sa iyong bersyon at topolohiya ng MongoDB, kaya huwag itong hinuha mula sa pagkakaroon ng direktoryo ng data. I-archive ang layer ng host sa tabi ng dump, sa parehong pagtakbo, na may parehong timestamp.

Sanayin ang pagbabalik bago mo ito kailanganin

Ang backup na wala pang nagbabalik ay isang hypothesis. Buuin ang serbisyo sa isang hiwalay na network, ibalik ang dump at ilagay muli ang mga file ng host:

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

Pagkatapos ay i-verify ang mga bagay kaysa sa proseso: mag-log in, kumpirmahin na naroon ang mga organisasyon at user, at maglunsad ng isang test client laban sa depinisyon ng server na kinikilala mo. Pigilan ang naibalik na host na mag-anunsyo ng production endpoint o tumanggap ng tunay na koneksyon hanggang sa ang mga address at pagkakakilanlan ay sinadya. Dito rin mo matutuklasan na ang archive ay nangangailangan ng mga kredensyal na nabuhay lamang sa nabigong makina, kaya itago ang mga kredensyal sa pagbawi sa isang malayang lugar. Ang pagbabalik na umaasa sa host na katatapos mo lang mawala ay hindi plano sa pagbawi.

Sa wakas, tandaan na ang lumang snapshot ay nagbabalik ng lumang desisyon. Kung ang isang administrator ay nag-disable ng pagkakakilanlan pagkatapos kunin ang dump, ibinabalik ito ng pagbawi. Ang pagkakasundo pagkatapos ng pagbawi ay bahagi ng pamamaraan, hindi ng huling pag-iisip.