Pritunl-back-up: besturingsstatus versus het gegenereerde profiel

Het ene archief herstelt een werkende Pritunl-implementatie; het andere herstelt een afbeelding ervan. Een clientprofiel, een kopie van de hostconfiguratie en een tarball van de statusmap lijken allemaal op back-ups, en geen ervan alleen brengt de organisaties, gebruikers en serverdefinities terug die Pritunl beheert. Het verschil zit in eigendom: een deel van de status is van een database, een deel van de host en een deel is opnieuw gegenereerde uitvoer. Kies de verkeerde laag en de herstelactie levert een server op die start, luistert en niets weet. Deze vergelijking scheidt de drie lagen, zodat het archief dat u bewaart past bij de storing waarvan u herstelt.

Twee objecten lijken op back-ups en slechts één herstelt de dienst

Een gedownload clientprofiel bevat een certificaat, een sleutel en een eindpunt. Het is compleet voor dat ene apparaat en waardeloos als registratie van de implementatie: het bevat geen organisaties, geen uitgeschakelde gebruikers, geen serverroutes en geen beheerdersaccounts. Herstellen vanuit een map met profielen levert clients op die zich tegen niets kunnen authenticeren.

Een kopie van de hostconfiguratie is eveneens gedeeltelijk. /etc/pritunl.conf bevat instellingen op hostniveau, waaronder hoe de database te bereiken is, en bevat niet de VPN-objecten zelf.

Wat de database bezit en wat de host bezit

Pritunl bewaart serverdefinities, gebruikers, organisaties en sleutels in MongoDB. Die database is het gezaghebbende besturingsvlak, en elk gegenereerd OpenVPN-bestand op schijf is daarvan afgeleide uitvoer. Een wijziging die rechtstreeks in een gegenereerd bestand wordt aangebracht, overleeft tot de volgende regeneratie en verdwijnt dan, daarom is het bewerken van runtime-bestanden geen duurzame oplossing. Dezelfde regel geldt voor effectieve routes en interfaces: ze beschrijven wat het besturingsvlak heeft geproduceerd, niet wat die zou moeten produceren.

De host levert een kleinere maar niet-overdraagbare set waarden. Een daarvan is /var/lib/pritunl/pritunl.uuid, de identiteit van dat specifieke knooppunt.

Die identiteit is het belangrijkst in een cluster. Een vervangende host heeft zijn eigen inschrijving nodig in plaats van een kloon van de UUID van een actief knooppunt, anders vechten de twee om dezelfde identiteit. Leg de koppeling vast tussen elke host, zijn UUID en de database waarnaar hij wijst, want één database-dump beschrijft niet welke hostinstellingen bij welke machine hoorden. Softwareversies en openbare eindpuntnamen horen in dezelfde registratie.

Maak een consistente dump, geen mapkopie

Het kopiëren van de MongoDB-datamap terwijl de dienst schrijft, levert bestanden op die mogelijk geen bruikbare database vormen. Gebruik in plaats daarvan het ondersteunde dumppad van de database, uitgevoerd tegen de topologie die u werkelijk hebt:

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

Een zelfstandige host verdraagt die eenvoudige vorm. Een replicaset heeft een consistent moment in de tijd nodig, en een op oplog gebaseerde dump heeft eisen die een gewone dump niet heeft. De ondersteunde procedure hangt af van uw MongoDB-versie en -topologie, dus leid die niet af uit de aanwezigheid van een datamap. Archiveer de hostlaag naast de dump, in dezelfde run, met dezelfde tijdstempel.

Oefen het herstel voordat u het nodig hebt

Een back-up die niemand heeft hersteld, is een hypothese. Bouw de dienst in een geïsoleerd netwerk, herstel de dump en zet de hostbestanden terug:

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

Controleer daarna de objecten in plaats van het proces: log in, bevestig dat organisaties en gebruikers aanwezig zijn en start één testclient tegen een serverdefinitie die u herkent. Houd de herstelde host ervan af het productie-eindpunt aan te kondigen of echte verbindingen te accepteren totdat adressen en identiteiten bewust zijn. Hier ontdekt u ook dat het archief inloggegevens nodig heeft die alleen op de uitgevallen machine stonden, dus bewaar herstelgegevens op een onafhankelijke plek. Een herstel dat afhangt van de host die u zojuist kwijt was, is geen herstelplan.

Bedenk ten slotte dat een oude momentopname oude beslissingen herstelt. Als een beheerder een identiteit heeft uitgeschakeld nadat de dump is gemaakt, schakelt het herstel die weer in. Afstemming na herstel hoort in de procedure, niet in de nabeschouwing.