Pritunl-säkerhetskopia: kontrolltillstånd kontra den genererade profilen

Det ena arkivet återställer en fungerande Pritunl-distribution; det andra återställer en bild av den. En klientprofil, en kopia av värdkonfigurationen och en tarball av tillståndskatalogen ser alla ut som säkerhetskopior, och ingen av dem ensam tar tillbaka de organisationer, användare och serverdefinitioner som Pritunl hanterar. Skillnaden är ägandeskap: en del tillstånd tillhör en databas, en del tillhör värden och en del är regenererad utdata. Väljer du fel lager producerar återställningen en server som startar, lyssnar och ingenting vet. Den här jämförelsen skiljer de tre lagren åt så att arkivet du behåller matchar det fel du återhämtar dig från.

Två objekt ser ut som säkerhetskopior och bara ett återställer tjänsten

En nedladdad klientprofil innehåller ett certifikat, en nyckel och en slutpunkt. Den är komplett för den enda enheten och värdelös som register över distributionen: den bär inga organisationer, inga inaktiverade användare, inga serverrutter och inga administrativa konton. Återställning från en mapp med profiler ger klienter som inte kan autentisera sig mot något.

En kopia av värdkonfigurationen är lika ofullständig. /etc/pritunl.conf innehåller inställningar på värdnivå, bland annat hur databasen nås, och den innehåller inte själva VPN-objekten.

Vad databasen äger och vad värden äger

Pritunl förvarar serverdefinitioner, användare, organisationer och nycklar i MongoDB. Databasen är det auktoritativa kontrollplanet, och varje genererad OpenVPN-fil på disken är utdata som härleds från den. En ändring som görs direkt i en genererad fil överlever till nästa regenerering och försvinner sedan, och därför är redigering av körtidsfiler ingen hållbar rättelse. Samma regel gäller för effektiva rutter och gränssnitt: de beskriver vad kontrollplanet har producerat, inte vad det borde producera.

Värden bidrar med en mindre men icke-överförbar uppsättning värden. Ett av dem är /var/lib/pritunl/pritunl.uuid, identiteten för just den noden.

Den identiteten spelar störst roll i ett kluster. En ersättningsvärd behöver sin egen registrering i stället för en klon av en aktiv nods UUID, annars slåss de två om samma identitet. Registrera mappningen mellan varje värd, dess UUID och databasen den pekar på, eftersom en enda databasdump inte beskriver vilka värdinställningar som hörde till vilken maskin. Programvaruversioner och offentliga slutpunktsnamn hör hemma i samma register.

Gör en konsekvent dump, inte en katalogkopia

Att kopiera MongoDB-datakatalogen medan tjänsten skriver producerar filer som kanske inte utgör en användbar databas. Använd i stället databasens dumpväg som stöds, körd mot den topologi du faktiskt 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 fristående värd tål den enkla formen. En replikuppsättning behöver en konsekvent tidpunkt, och en oplog-baserad dump har krav som en vanlig dump inte har. Den understödda proceduren beror på din MongoDB-version och topologi, så härled den inte från förekomsten av en datakatalog. Arkivera värdlagret bredvid dumpen, i samma körning, med samma tidsstämpel.

Öva återställningen innan du behöver den

En säkerhetskopia som ingen har återställt är en hypotes. Bygg tjänsten i ett isolerat nätverk, återställ dumpen och lägg tillbaka värdens filer:

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

Verifiera sedan objekten i stället för processen: logga in, bekräfta att organisationer och användare finns och starta en testklient mot en serverdefinition du känner igen. Hindra den återställda värden från att annonsera produktionsslutpunkten eller acceptera riktiga anslutningar tills adresser och identiteter är avsiktliga. Det är också här du upptäcker att arkivet behöver autentiseringsuppgifter som bara fanns på den havererade maskinen, så lagra återställningsuppgifterna på en oberoende plats. En återställning som beror på värden du just förlorade är ingen återställningsplan.

Kom till sist ihåg att en gammal ögonblicksbild återställer gamla beslut. Om en administratör inaktiverade en identitet efter att dumpen togs, återaktiverar återställningen den. Avstämning efter återställning hör till proceduren, inte till eftertanken.