Pritunl: vadības stāvoklis pret ģenerēto profilu

Viens arhīvs atjauno strādājošu Pritunl izvietojumu; otrs atjauno tikai tā attēlu. Klienta profils, resursdatora konfigurācijas kopija un stāvokļa direktorija tarballs visi izskatās kā rezerves kopijas, un neviens no tiem vienatnē neatgriež organizācijas, lietotājus un serveru definīcijas, ko pārvalda Pritunl. Atšķirība ir īpašumā: daļa stāvokļa pieder datubāzei, daļa resursdatoram, un daļa ir no jauna ģenerēta izvade. Izvēlieties nepareizo slāni, un atjaunošana radīs serveri, kas startē, klausās un neko nezina. Šis salīdzinājums atdala trīs slāņus, lai arhīvs, ko paturat, atbilstu kļūmei, no kuras atjaunojaties.

Divi objekti izskatās kā rezerves kopijas, un tikai viens atjauno pakalpojumu

Lejupielādēts klienta profils satur sertifikātu, atslēgu un galapunktu. Tas ir pilnīgs šai vienai ierīcei un bezjēdzīgs kā izvietojuma reģistrs: tas nenes organizācijas, atspējotus lietotājus, serveru maršrutus vai administratīvos kontus. Atjaunošana no profilu mapes dod klientus, kuri nevar autentificēties pret neko.

Resursdatora konfigurācijas kopija ir tikpat daļēja. /etc/pritunl.conf satur resursdatora līmeņa iestatījumus, tostarp veidu, kā sasniegt datubāzi, un tajā nav pašu VPN objektu.

Kas pieder datubāzei un kas pieder resursdatoram

Pritunl glabā serveru definīcijas, lietotājus, organizācijas un atslēgas MongoDB. Šī datubāze ir autoritatīvā vadības plakne, un katrs diskā ģenerētais OpenVPN fails ir no tās atvasināta izvade. Izmaiņas, kas veiktas tieši ģenerētajā failā, saglabājas līdz nākamajai atkārtotajai ģenerēšanai un pēc tam pazūd, tāpēc izpildlaika failu rediģēšana nav ilgtspējīgs labojums. Tas pats noteikums attiecas uz faktiskajiem maršrutiem un saskarnēm: tie apraksta, ko vadības plakne ir radījusi, nevis to, ko tai vajadzētu radīt.

Resursdators sniedz mazāku, bet nepārnesamu vērtību kopu. Viena no tām ir /var/lib/pritunl/pritunl.uuid, konkrētā mezgla identitāte.

Šī identitāte ir vissvarīgākā klasterī. Aizvietotājresursdatoram ir vajadzīga sava reģistrācija, nevis aktīva mezgla UUID klons, citādi abi cīnās par vienu un to pašu identitāti. Reģistrējiet kartējumu starp katru resursdatoru, tā UUID un datubāzi, uz kuru tas norāda, jo viens datubāzes izgājums neapraksta, kuri resursdatora iestatījumi piederēja kurai mašīnai. Programmatūras versijas un publiskie galapunktu nosaukumi pieder tajā pašā ierakstā.

Veiciet konsekventu izgājumu, nevis direktorija kopiju

MongoDB datu direktorija kopēšana, kamēr pakalpojums raksta, rada failus, kas var neveidot lietojamu datubāzi. Tā vietā izmantojiet datubāzes atbalstīto izgājuma ceļu, kas palaists pret topoloģiju, kāda jums faktiski ir:

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

Atsevišķs resursdators pieļauj šo vienkāršo formu. Replikācijas kopai ir vajadzīgs konsekvents laika punkts, un uz oplogu balstītam izgājumam ir prasības, kādu vienkāršam izgājumam nav. Atbalstītā procedūra ir atkarīga no jūsu MongoDB versijas un topoloģijas, tāpēc neizseciniet to no datu direktorija klātbūtnes. Arhivējiet resursdatora slāni līdzās izgājumam, tajā pašā izpildē, ar to pašu laikspiedolu.

Trenējiet atjaunošanu, pirms tā jums nepieciešama

Rezerves kopija, kuru neviens nav atjaunojis, ir hipotēze. Izveidojiet pakalpojumu izolētā tīklā, atjaunojiet izgājumu un ievietojiet resursdatora failus atpakaļ:

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

Pēc tam pārbaudiet objektus, nevis procesu: piesakieties, apstipriniet, ka organizācijas un lietotāji ir klātesoši, un palaidiet vienu testa klientu pret servera definīciju, kuru atpazīstat. Neļaujiet atjaunotajam resursdatoram reklamēt ražošanas galapunktu vai pieņemt reālus savienojumus, kamēr adreses un identitātes nav apzinātas. Šeit arī atklājat, ka arhīvam ir vajadzīgas akreditācijas datu kopas, kas pastāvēja tikai sabojātajā mašīnā, tāpēc glabājiet atjaunošanas akreditācijas datus neatkarīgā vietā. Atjaunošana, kas ir atkarīga no resursdatora, kuru tikko zaudējāt, nav atjaunošanas plāns.

Visbeidzot, atcerieties, ka vecs momentuzņēmums atjauno vecus lēmumus. Ja administrators atspējoja identitāti pēc izgājuma veikšanas, atjaunošana to atkal iespējo. Saskaņošana pēc atjaunošanas pieder procedūrai, nevis vēlākām pārdomām.