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 /

Затым праверце аб’екты, а не працэс: увайдзіце, пацвердзіце, што арганізацыі і карыстальнікі прысутнічаюць, і запусціце аднаго тэставага кліента супраць вызначэння сервера, якое вы пазнаеце. Не дазваляйце адноўленаму хосту абвяшчаць вытворчы канчатковы пункт або прымаць рэальныя злучэнні, пакуль адрасы і ідэнтычнасці не стануць наўмыснымі. Тут жа вы выявіце, што архіву патрэбны ўліковыя даныя, якія жылі толькі на зламанай машыне, таму захоўвайце ўліковыя даныя для аднаўлення ў незалежным месцы. Аднаўленне, якое залежыць ад хоста, які вы толькі што страцілі, — не план аднаўлення.

Нарэшце, памятайце, што стары здымак аднаўляе старыя рашэнні. Калі адміністратар адключыў ідэнтычнасць пасля здымка дампа, аднаўленне зноў уключае яе. Згадненне пасля аднаўлення належыць працэдуры, а не позняй думцы.