Pritunl: vezérlési állapot kontra a generált profil

Az egyik archívum egy működő Pritunl-telepítést állít vissza; a másik csak annak képét. Egy ügyfélprofil, a gazdagép konfigurációjának másolata és az állapotkönyvtár tarballja mind backupnak tűnik, és egyik sem hozza vissza önmagában a Pritunl által kezelt szervezeteket, felhasználókat és kiszolgálódefiníciókat. A különbség a tulajdonjog: az állapot egy része adatbázishoz tartozik, egy része a gazdagéphez, egy része pedig újragenerált kimenet. Válassza a rossz réteget, és a visszaállítás olyan kiszolgálót hoz létre, amely elindul, figyel és semmit sem tud. Ez az összehasonlítás szétválasztja a három réteget, hogy a megtartott archívum ahhoz a hibához illeszkedjen, amelyből helyreáll.

Két objektum tűnik backupnak, és csak az egyik állítja vissza a szolgáltatást

A letöltött ügyfélprofil tanúsítványt, kulcsot és végpontot tartalmaz. Az adott eszközhöz teljes, a telepítés nyilvántartásaként viszont hasznavehetetlen: nem hordoz szervezeteket, letiltott felhasználókat, kiszolgálóútvonalakat és adminisztratív fiókokat. A profilok mappájából történő visszaállítás olyan klienseket ad, amelyek semmihez sem tudnak hitelesíteni.

A gazdagép konfigurációjának másolata ugyanilyen részleges. A /etc/pritunl.conf gazdagépszintű beállításokat tartalmaz, többek között azt, hogyan érhető el az adatbázis, de magukat a VPN-objektumokat nem.

Mi van az adatbázis birtokában, és mi a gazdagépé

A Pritunl kiszolgálódefiníciókat, felhasználókat, szervezeteket és kulcsokat tárol a MongoDB-ben. Ez az adatbázis a mérvadó vezérlési sík, és minden lemezen generált OpenVPN-fájl az abból származtatott kimenet. A generált fájlban közvetlenül végrehajtott módosítás a következő újragenerálásig él, majd eltűnik, ezért a futásidejű fájlok szerkesztése nem tartós javítás. Ugyanez a szabály vonatkozik az effektív útvonalakra és interfészekre: azt írják le, amit a vezérlési sík létrehozott, nem azt, amit létre kellene hoznia.

A gazdagép kisebb, de nem átvihető értékkészlettel járul hozzá. Ezek egyike a /var/lib/pritunl/pritunl.uuid, az adott csomópont identitása.

Ez az identitás klaszterben a legfontosabb. A csere-gazdagépnek saját regisztrációra van szüksége, nem egy aktív csomópont UUID-jének klónjára, különben a kettő ugyanazért az identitásért küzd. Rögzítse az egyes gazdagépek, UUID-jük és a hivatkozott adatbázis közötti leképezést, mert egyetlen adatbázis-dump nem írja le, mely gazdagép-beállítások melyik géphez tartoztak. A szoftververziók és a nyilvános végpontnevek ugyanabba a nyilvántartásba tartoznak.

Készítsen konzisztens dumpot, ne könyvtármásolatot

A MongoDB adatkönyvtárának másolása a szolgáltatás írása közben olyan fájlokat eredményez, amelyek esetleg nem alkotnak használható adatbázist. Használja helyette az adatbázis által támogatott dump-útvonalat, a ténylegesen meglévő topológián futtatva:

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

Az önálló gazdagép elviseli ezt az egyszerű formát. A replikakészletnek konzisztens időpontra van szüksége, és az oplog-alapú dumpnak olyan követelményei vannak, amelyekkel egy egyszerű dump nem rendelkezik. A támogatott eljárás a MongoDB-verziójától és -topológiájától függ, ezért ne következtessen rá az adatkönyvtár jelenlétéből. Archiválja a gazdagép rétegét a dump mellett, ugyanabban a futásban, ugyanazzal az időbélyeggel.

Gyakorolja a visszaállítást, mielőtt szükség lenne rá

Az a backup, amelyet senki nem állított vissza, hipotézis. Építse fel a szolgáltatást izolált hálózaton, állítsa vissza a dumpot, és tegye vissza a gazdagép fájljait:

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

Ezután az objektumokat ellenőrizze, ne a folyamatot: jelentkezzen be, erősítse meg, hogy a szervezetek és felhasználók jelen vannak, és indítson egy tesztklienst egy általa ismert kiszolgálódefiníció ellen. Akadályozza meg, hogy a visszaállított gazdagép hirdesse a termelési végpontot vagy valódi kapcsolatokat fogadjon el, amíg a címek és identitások szándékosak nem lesznek. Itt fedezheti fel azt is, hogy az archívumnak olyan hitelesítő adatokra van szüksége, amelyek csak a meghibásodott gépen éltek, ezért tárolja a helyreállítási adatokat független helyen. Az a visszaállítás, amely a most elveszített gazdagéptől függ, nem visszaállítási terv.

Végül ne feledje, hogy a régi pillanatkép régi döntéseket állít vissza. Ha egy adminisztrátor a dump elkészítése után letiltott egy identitást, a visszaállítás újra engedélyezi. A helyreállítás utáni összeegyeztetés az eljáráshoz tartozik, nem az utólagos gondolkodáshoz.