Pritunl-backup: kontroltilstand kontra den genererede profil

Det ene arkiv gendanner en fungerende Pritunl-udrulning; det andet gendanner et billede af den. En klientprofil, en kopi af værtskonfigurationen og en tarball af tilstandsmappen ligner alle backups, og ingen af dem alene bringer de organisationer, brugere og serverdefinitioner tilbage, som Pritunl administrerer. Forskellen er ejerskab: noget tilstand tilhører en database, noget tilhører værten, og noget er regenereret output. Vælg det forkerte lag, og gendannelsen giver en server, der starter, lytter og intet ved. Denne sammenligning adskiller de tre lag, så det arkiv, du beholder, passer til den fejl, du genopretter fra.

To objekter ligner backups, og kun ét gendanner tjenesten

En downloadet klientprofil indeholder et certifikat, en nøgle og et endepunkt. Den er komplet til den ene enhed og ubrugelig som registrering af udrulningen: den bærer ingen organisationer, ingen deaktiverede brugere, ingen serverruter og ingen administrative konti. Gendannelse fra en mappe med profiler giver klienter, der ikke kan godkende sig over for noget.

En kopi af værtskonfigurationen er lige så delvis. /etc/pritunl.conf indeholder indstillinger på værtsniveau, herunder hvordan databasen nås, og den indeholder ikke selve VPN-objekterne.

Hvad databasen ejer, og hvad værten ejer

Pritunl opbevarer serverdefinitioner, brugere, organisationer og nøgler i MongoDB. Den database er det autoritative kontrolplan, og hver genereret OpenVPN-fil på disken er output, der er afledt af den. En ændring, der foretages direkte i en genereret fil, overlever indtil den næste regenerering og forsvinder derefter, og derfor er redigering af runtime-filer ikke en holdbar rettelse. Den samme regel gælder for effektive ruter og grænseflader: de beskriver, hvad kontrolplanen har produceret, ikke hvad den burde producere.

Værten bidrager med et mindre, men ikke-overdrageligt sæt værdier. En af dem er /var/lib/pritunl/pritunl.uuid, identiteten af netop den knude.

Den identitet betyder mest i en klynge. En erstatningsvært har brug for sin egen tilmelding i stedet for en klon af en aktiv knudes UUID, ellers kæmper de to om den samme identitet. Registrer tilknytningen mellem hver vært, dens UUID og den database, den peger på, fordi et enkelt databasedump ikke beskriver, hvilke værtindstillinger der hørte til hvilken maskine. Softwareversioner og offentlige endepunktnavne hører i samme registrering.

Tag et konsistent dump, ikke en mappekopi

Kopiering af MongoDB-datamappen, mens tjenesten skriver, producerer filer, der muligvis ikke udgør en brugbar database. Brug i stedet databasens understøttede dumppsti, kørt mod den topologi, 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 selvstændig vært tåler den enkle form. Et replikaset kræver et konsistent tidspunkt, og et oplog-baseret dump har krav, som et almindeligt dump ikke har. Den understøttede procedure afhænger af din MongoDB-version og -topologi, så udled den ikke af tilstedeværelsen af en datamappe. Arkivér værtslaget ved siden af dumpet, i samme kørsel, med samme tidsstempel.

Øv gendannelsen, før du får brug for den

En backup, som ingen har gendannet, er en hypotese. Byg tjenesten i et isoleret netværk, gendan dumpet, og læg værtsfilerne tilbage:

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

Verificer derefter objekterne frem for processen: log ind, bekræft at organisationer og brugere er til stede, og start én testklient mod en serverdefinition, du genkender. Forhindr den gendannede vært i at annoncere produktionens endepunkt eller acceptere rigtige forbindelser, indtil adresser og identiteter er bevidste. Det er også her, du opdager, at arkivet har brug for legitimationsoplysninger, der kun levede på den fejlede maskine, så opbevar gendannelsesoplysninger et uafhængigt sted. En gendannelse, der afhænger af den vært, du netop har mistet, er ikke en gendannelsesplan.

Husk til sidst, at et gammelt snapshot gendanner gamle beslutninger. Hvis en administrator deaktiverede en identitet, efter at dumpet blev taget, genaktiverer gendannelsen den. Afstemning efter gendannelse hører i proceduren, ikke i eftertanken.