Pritunl: ohjaustila vastaan luotu profiili

Toinen arkisto palauttaa toimivan Pritunl-jakelun; toinen palauttaa vain sen kuvan. Asiakasprofiili, isännän kokoonpanon kopio ja tilakansion tarball näyttävät kaikki varmuuskopioilta, eikä mikään niistä yksinään tuo takaisin organisaatioita, käyttäjiä ja palvelinmääritelmiä, joita Pritunl hallitsee. Ero on omistuksessa: osa tilasta kuuluu tietokannalle, osa isännälle ja osa on uudelleen luotu tuloste. Valitse väärä kerros, niin palautus tuottaa palvelimen, joka käynnistyy, kuuntelee eikä tiedä mitään. Tämä vertailu erottaa kolme kerrosta, jotta säilyttämäsi arkisto vastaa vikaa, josta palaudut.

Kaksi objektia näyttää varmuuskopioilta ja vain yksi palauttaa palvelun

Ladattu asiakasprofiili sisältää varmenteen, avaimen ja päätepisteen. Se on täydellinen sille yhdelle laitteelle ja hyödytön jakelun tietueena: se ei kanna organisaatioita, poistettuja käyttäjiä, palvelinreittejä eikä ylläpitotilejä. Palauttaminen profiilien kansiosta antaa asiakkaita, jotka eivät voi todentaa itseään mihinkään.

Isännän kokoonpanon kopio on yhtä osittainen. /etc/pritunl.conf sisältää isäntätason asetukset, mukaan lukien miten tietokantaan päästään, eikä se sisällä itse VPN-objekteja.

Mitä tietokanta omistaa ja mitä isäntä omistaa

Pritunl säilyttää palvelinmääritelmät, käyttäjät, organisaatiot ja avaimet MongoDB:ssä. Se tietokanta on valtuutettu ohjaustaso, ja jokainen levylle luotu OpenVPN-tiedosto on siitä johdettu tuloste. Suoraan luotuun tiedostoon tehty muutos säilyy seuraavaan uudelleenluontiin ja katoaa sitten, minkä vuoksi ajonaikaisten tiedostojen muokkaaminen ei ole kestävä korjaus. Sama sääntö koskee tehokkaita reittejä ja liitäntöjä: ne kuvaavat, mitä ohjaustaso tuotti, eivät sitä, mitä sen pitäisi tuottaa.

Isäntä antaa pienemmän mutta siirtokelvottoman arvojoukon. Yksi niistä on /var/lib/pritunl/pritunl.uuid, kyseisen solmun identiteetti.

Tuo identiteetti on tärkein klusterissa. Korvaava isäntä tarvitsee oman rekisteröitymisensä aktiivisen solmun UUID:n kloonin sijaan, muuten kaksi taistelee samasta identiteetistä. Kirjaa kunkin isännän, sen UUID:n ja sen osoittaman tietokannan välinen kartoitus, koska yksittäinen tietokantavedos ei kuvaa, mitkä isäntäasetukset kuuluivat millekin koneelle. Ohjelmistoversiot ja julkiset päätepisten nimet kuuluvat samaan tietueeseen.

Tee johdonmukainen vedos, älä kansiokopiota

MongoDB:n datakansion kopioiminen palvelun kirjoittaessa tuottaa tiedostoja, jotka eivät välttämättä muodosta käyttökelpoista tietokantaa. Käytä sen sijaan tietokannan tuettua vedospolkua, ajettuna sitä topologiaa vasten, joka sinulla todella on:

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

Erillinen isäntä sietää tuon yksinkertaisen muodon. Replikajoukko tarvitsee johdonmukaisen ajanhetken, ja oplog-pohjaisella vedoksella on vaatimuksia, joita tavallisella vedoksella ei ole. Tuettu menettely riippuu MongoDB-versiostasi ja topologiastasi, joten älä päättele sitä datakansion olemassaolosta. Arkistoi isäntäkerros vedoksen viereen samassa ajossa samalla aikaleimalla.

Harjoittele palautus ennen kuin tarvitset sitä

Varmuuskopio, jota kukaan ei ole palauttanut, on hypoteesi. Rakenna palvelu eristettyyn verkkoon, palauta vedos ja laita isännän tiedostot takaisin:

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

Tarkista sitten objektit prosessin sijaan: kirjaudu sisään, vahvista että organisaatiot ja käyttäjät ovat läsnä ja käynnistä yksi testiasiakas tunnistamaasi palvelinmääritelmää vasten. Estä palautettua isäntää mainostamasta tuotannon päätepistettä tai hyväksymästä todellisia yhteyksiä, kunnes osoitteet ja identiteetit ovat tarkoituksellisia. Tässä myös huomaat, että arkisto tarvitsee tunnistetietoja, jotka elivät vain epäonnistuneella koneella, joten säilytä palautuksen tunnistetiedot riippumattomassa paikassa. Palautus, joka riippuu juuri menettämästäsi isännästä, ei ole palautussuunnitelma.

Muista lopuksi, että vanha tilannekuva palauttaa vanhoja päätöksiä. Jos ylläpitäjä poisti identiteetin käytöstä vedoksen ottamisen jälkeen, palautus ottaa sen uudelleen käyttöön. Palautuksen jälkeinen täsmäytys kuuluu menettelyyn, ei jälkiviisauteen.