Pritunl-Backup: Steuerungszustand gegenüber dem erzeugten Profil

Das eine Archiv stellt eine funktionierende Pritunl-Bereitstellung wieder her; das andere stellt nur ein Abbild davon wieder her. Ein Clientprofil, eine Kopie der Host-Konfiguration und ein Tarball des Statusverzeichnisses sehen alle wie Backups aus, und keines davon allein bringt die Organisationen, Benutzer und Serverdefinitionen zurück, die Pritunl verwaltet. Der Unterschied liegt in der Zuständigkeit: Ein Teil des Zustands gehört zu einer Datenbank, ein Teil zum Host, und ein Teil ist neu erzeugte Ausgabe. Wählen Sie die falsche Ebene, und die Wiederherstellung erzeugt einen Server, der startet, lauscht und nichts weiß. Dieser Vergleich trennt die drei Ebenen, damit das Archiv, das Sie aufbewahren, zu dem Fehlerfall passt, von dem Sie sich erholen.

Zwei Objekte sehen wie Backups aus, und nur eines stellt den Dienst wieder her

Ein heruntergeladenes Clientprofil enthält ein Zertifikat, einen Schlüssel und einen Endpunkt. Es ist für dieses eine Gerät vollständig und als Aufzeichnung der Bereitstellung wertlos: Es enthält keine Organisationen, keine deaktivierten Benutzer, keine Serverrouten und keine Administratorkonten. Eine Wiederherstellung aus einem Ordner voller Profile liefert Clients, die sich gegen nichts authentifizieren können.

Eine Kopie der Host-Konfiguration ist ebenso unvollständig. /etc/pritunl.conf enthält Einstellungen auf Host-Ebene, darunter den Weg zur Datenbank, und enthält nicht die VPN-Objekte selbst.

Was die Datenbank besitzt und was der Host besitzt

Pritunl hält Serverdefinitionen, Benutzer, Organisationen und Schlüssel in MongoDB. Diese Datenbank ist die maßgebliche Steuerungsebene, und jede erzeugte OpenVPN-Datei auf der Festplatte ist eine daraus abgeleitete Ausgabe. Eine Änderung, die direkt an einer erzeugten Datei vorgenommen wird, überlebt bis zur nächsten Neuerzeugung und verschwindet dann, weshalb das Bearbeiten von Laufzeitdateien keine dauerhafte Lösung ist. Dieselbe Regel gilt für effektive Routen und Schnittstellen: Sie beschreiben, was die Steuerungsebene erzeugt hat, nicht was sie erzeugen sollte.

Der Host steuert einen kleineren, aber nicht übertragbaren Satz von Werten bei. Einer davon ist /var/lib/pritunl/pritunl.uuid, die Identität dieses bestimmten Knotens.

Diese Identität ist in einem Cluster am wichtigsten. Ein Ersatzhost braucht seine eigene Registrierung statt eines Klons der UUID eines aktiven Knotens, sonst kämpfen die beiden um dieselbe Identität. Halten Sie die Zuordnung zwischen jedem Host, seiner UUID und der Datenbank fest, auf die er zeigt, denn ein einzelner Datenbank-Dump beschreibt nicht, welche Host-Einstellungen zu welcher Maschine gehörten. Softwareversionen und öffentliche Endpunktnamen gehören in dieselbe Aufzeichnung.

Machen Sie einen konsistenten Dump, keine Verzeichniskopie

Das Kopieren des MongoDB-Datenverzeichnisses, während der Dienst schreibt, erzeugt Dateien, die möglicherweise keine verwendbare Datenbank bilden. Verwenden Sie stattdessen den unterstützten Dump-Pfad der Datenbank und arbeiten Sie gegen die Topologie, die Sie tatsächlich haben:

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

Ein eigenständiger Host verträgt diese einfache Form. Ein Replica-Set benötigt einen konsistenten Zeitpunkt, und ein oplog-basierter Dump hat Anforderungen, die ein einfacher Dump nicht hat. Das unterstützte Verfahren hängt von Ihrer MongoDB-Version und -Topologie ab, also schließen Sie es nicht aus dem Vorhandensein eines Datenverzeichnisses. Archivieren Sie die Host-Ebene neben dem Dump, im selben Lauf, mit demselben Zeitstempel.

Üben Sie die Wiederherstellung, bevor Sie sie brauchen

Ein Backup, das niemand wiederhergestellt hat, ist eine Hypothese. Bauen Sie den Dienst in einem isolierten Netzwerk auf, stellen Sie den Dump wieder her und legen Sie die Host-Dateien zurück:

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

Überprüfen Sie dann die Objekte statt des Prozesses: Melden Sie sich an, bestätigen Sie, dass Organisationen und Benutzer vorhanden sind, und starten Sie einen Testclient gegen eine Serverdefinition, die Sie erkennen. Halten Sie den wiederhergestellten Host davon ab, den Produktionsendpunkt anzukündigen oder echte Verbindungen anzunehmen, bis Adressen und Identitäten bewusst festgelegt sind. Hier entdecken Sie auch, dass das Archiv Anmeldedaten benötigt, die nur auf der ausgefallenen Maschine existierten, also lagern Sie Wiederherstellungs-Anmeldedaten an einem unabhängigen Ort. Eine Wiederherstellung, die von dem Host abhängt, den Sie gerade verloren haben, ist kein Wiederherstellungsplan.

Denken Sie schließlich daran, dass ein alter Snapshot alte Entscheidungen wiederherstellt. Wenn ein Administrator eine Identität nach der Erstellung des Dumps deaktiviert hat, aktiviert die Wiederherstellung sie wieder. Der Abgleich nach der Wiederherstellung gehört in das Verfahren, nicht in die Nachbetrachtung.