Pritunl: състояние на управление срещу генерирания профил

Един архив възстановява работещо внедряване на Pritunl; другият възстановява само негов образ. Клиентският профил, копие от конфигурацията на хоста и tarball на директорията на състоянието изглеждат като резервни копия и никое от тях само по себе си не връща организациите, потребителите и дефинициите на сървъри, които Pritunl управлява. Разликата е в собствеността: част от състоянието принадлежи на база данни, част на хоста, а част е регенериран изход. Изберете грешния слой и възстановяването създава сървър, който стартира, слуша и не знае нищо. Това сравнение разделя трите слоя, за да съответства архивът, който пазите, на повредата, от която се възстановявате.

Два обекта изглеждат като резервни копия и само един възстановява услугата

Изтегленият клиентски профил съдържа сертификат, ключ и крайна точка. Той е пълен за това едно устройство и безполезен като запис за внедряването: не носи организации, деактивирани потребители, маршрути на сървъри и административни акаунти. Възстановяването от папка с профили дава клиенти, които не могат да удостоверят самоличността си пред нищо.

Копие от конфигурацията на хоста е също толкова частично. /etc/pritunl.conf съдържа настройки на ниво хост, включително как да се достигне базата данни, и не съдържа самите VPN обекти.

Какво притежава базата данни и какво притежава хостът

Pritunl съхранява дефиниции на сървъри, потребители, организации и ключове в MongoDB. Тази база данни е авторитетната контролна равнина и всеки генериран OpenVPN файл на диска е изход, производен от нея. Промяна, направена директно в генериран файл, оцелява до следващото регенериране и след това изчезва, затова редактирането на файлове по време на изпълнение не е трайно поправяне. Същото правило важи за ефективните маршрути и интерфейси: те описват какво е създала контролната равнина, а не какво трябва да създаде.

Хостът допринася с по-малък, но непрехвърляем набор от стойности. Една от тях е /var/lib/pritunl/pritunl.uuid, идентичността на този конкретен възел.

Тази идентичност е най-важна в клъстер. Заместващият хост се нуждае от собствена регистрация вместо клонинг на UUID на активен възел, иначе двете се борят за една и съща идентичност. Записвайте съответствието между всеки хост, неговия UUID и базата данни, към която сочи, защото един дъмп на базата данни не описва кои настройки на хоста са принадлежали на коя машина. Версиите на софтуера и публичните имена на крайни точки принадлежат към същия запис.

Направете последователен дъмп, а не копие на директория

Копирането на директорията с данни на MongoDB, докато услугата пише, създава файлове, които може да не образуват използваема база данни. Вместо това използвайте поддържания път за дъмп на базата данни, изпълнен срещу топологията, която действително имате:

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

Самостоятелен хост понася тази проста форма. Набор от реплики се нуждае от последователен момент във времето, а дъмп, базиран на oplog, има изисквания, каквито обикновеният дъмп няма. Поддържаната процедура зависи от вашата версия и топология на MongoDB, затова не я извеждайте от наличието на директория с данни. Архивирайте слоя на хоста до дъмпа, в същото изпълнение, със същия времеви печат.

Упражнявайте възстановяването, преди да ви потрябва

Резервно копие, което никой не е възстановил, е хипотеза. Изградете услугата в изолирана мрежа, възстановете дъмпа и върнете файловете на хоста обратно:

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

След това проверете обектите, а не процеса: влезте, потвърдете, че организациите и потребителите присъстват, и стартирайте един тестов клиент срещу дефиниция на сървър, която разпознавате. Не позволявайте на възстановения хост да обявява производствената крайна точка или да приема реални връзки, докато адресите и идентичностите не са умишлени. Тук също откривате, че архивът се нуждае от идентификационни данни, които са живели само на отказалата машина, затова съхранявайте данните за възстановяване на независимо място. Възстановяване, което зависи от хоста, който току-що загубихте, не е план за възстановяване.

Накрая, помнете, че стара снимка възстановява стари решения. Ако администратор е деактивирал идентичност след направянето на дъмпа, възстановяването я активира отново. Съгласуването след възстановяване принадлежи на процедурата, а не на закъснялата мисъл.