Pritunl-backup: kontrolltilstand kontra den genererte profilen

Det ene arkivet gjenoppretter en fungerende Pritunl-distribusjon; det andre gjenoppretter et bilde av den. En klientprofil, en kopi av vertskonfigurasjonen og en tarball av tilstandsmappen ser alle ut som sikkerhetskopier, og ingen av dem alene bringer tilbake organisasjonene, brukerne og serverdefinisjonene som Pritunl administrerer. Forskjellen er eierskap: noe tilstand tilhører en database, noe tilhører verten, og noe er regenerert utdata. Velger du feil lag, gir gjenopprettingen en server som starter, lytter og ikke vet noe. Denne sammenligningen skiller de tre lagene slik at arkivet du beholder samsvarer med feilen du gjenoppretter fra.

To objekter ser ut som sikkerhetskopier, og bare ett gjenoppretter tjenesten

En nedlastet klientprofil inneholder et sertifikat, en nøkkel og et endepunkt. Den er komplett for den ene enheten og ubrukelig som register over distribusjonen: den bærer ingen organisasjoner, ingen deaktiverte brukere, ingen serverruter og ingen administrative kontoer. Gjenoppretting fra en mappe med profiler gir klienter som ikke kan autentisere seg mot noe.

En kopi av vertskonfigurasjonen er like delvis. /etc/pritunl.conf inneholder innstillinger på vertsnivå, blant annet hvordan databasen nås, og den inneholder ikke selve VPN-objektene.

Hva databasen eier, og hva verten eier

Pritunl oppbevarer serverdefinisjoner, brukere, organisasjoner og nøkler i MongoDB. Den databasen er det autoritative kontrollplanet, og hver generert OpenVPN-fil på disken er utdata avledet fra den. En endring som gjøres direkte i en generert fil, overlever til neste regenerering og forsvinner deretter, og derfor er redigering av kjøretidsfiler ingen varig løsning. Den samme regelen gjelder for effektive ruter og grensesnitt: de beskriver hva kontrollplanet har produsert, ikke hva det burde produsere.

Verten bidrar med et mindre, men ikke-overførbart sett med verdier. En av dem er /var/lib/pritunl/pritunl.uuid, identiteten til nettopp den noden.

Den identiteten betyr mest i en klynge. En erstatningsvert trenger sin egen registrering i stedet for en klone av UUID-en til en aktiv node, ellers kjemper de to om samme identitet. Registrer tilordningen mellom hver vert, UUID-en dens og databasen den peker på, fordi en enkelt databasedump ikke beskriver hvilke vertsinnstillinger som hørte til hvilken maskin. Programvareversjoner og offentlige endepunktnavn hører hjemme i samme register.

Ta en konsistent dump, ikke en mappekopi

Kopiering av MongoDB-datamappen mens tjenesten skriver, produserer filer som kanskje ikke utgjør en brukbar database. Bruk i stedet den støttede dumppathen til databasen, kjørt mot topologien du faktisk har:

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

En frittstående vert tåler den enkle formen. Et replikasett trenger et konsistent tidspunkt, og en oplog-basert dump har krav som en vanlig dump ikke har. Den støttede prosedyren avhenger av MongoDB-versjonen og -topologien din, så ikke utled den fra tilstedeværelsen av en datamappe. Arkiver vertslaget ved siden av dumpen, i samme kjøring, med samme tidsstempel.

Øv på gjenopprettingen før du trenger den

En sikkerhetskopi som ingen har gjenopprettet, er en hypotese. Bygg tjenesten i et isolert nettverk, gjenopprett dumpen og legg vertsfiler tilbake:

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

Verifiser deretter objektene i stedet for prosessen: logg inn, bekreft at organisasjoner og brukere er til stede, og start én testklient mot en serverdefinisjon du kjenner igjen. Hindre den gjenopprettede verten i å annonsere produksjonsendepunktet eller godta ekte tilkoblinger før adresser og identiteter er bevisste. Det er også her du oppdager at arkivet trenger påloggingsinformasjon som bare levde på maskinen som feilet, så oppbevar gjenopprettingsopplysninger på et uavhengig sted. En gjenoppretting som avhenger av verten du nettopp mistet, er ingen gjenopprettingsplan.

Til slutt, husk at et gammelt øyeblikksbilde gjenoppretter gamle beslutninger. Hvis en administrator deaktiverte en identitet etter at dumpen ble tatt, aktiverer gjenopprettingen den igjen. Avstemming etter gjenoppretting hører i prosedyren, ikke i ettertanken.