Pritunl: keadaan kawalan berbanding profil yang dijana

Satu arkib memulihkan penggunaan Pritunl yang berfungsi; yang lain hanya memulihkan gambarannya. Profil klien, salinan konfigurasi hos dan tarball direktori keadaan semuanya kelihatan seperti sandaran, dan tiada satu pun daripadanya sahaja yang mengembalikan organisasi, pengguna dan definisi pelayan yang diuruskan Pritunl. Perbezaannya ialah pemilikan: sebahagian keadaan milik pangkalan data, sebahagian milik hos, dan sebahagian ialah output yang dijana semula. Pilih lapisan yang salah dan pemulihan menghasilkan pelayan yang bermula, mendengar dan tidak tahu apa-apa. Perbandingan ini memisahkan tiga lapisan supaya arkib yang anda simpan sepadan dengan kegagalan yang anda pulihkan.

Dua objek kelihatan seperti sandaran dan hanya satu memulihkan perkhidmatan

Profil klien yang dimuat turun mengandungi sijil, kunci dan titik akhir. Ia lengkap untuk peranti tunggal itu dan tidak berguna sebagai rekod penggunaan: ia tidak membawa organisasi, pengguna yang dilumpuhkan, laluan pelayan atau akaun pentadbiran. Memulihkan daripada folder profil memberi klien yang tidak dapat mengesahkan diri terhadap apa-apa.

Salinan konfigurasi hos juga separa. /etc/pritunl.conf menyimpan tetapan peringkat hos, termasuk cara mencapai pangkalan data, dan tidak mengandungi objek VPN itu sendiri.

Apa yang dimiliki pangkalan data dan apa yang dimiliki hos

Pritunl menyimpan definisi pelayan, pengguna, organisasi dan kunci dalam MongoDB. Pangkalan data itu ialah satah kawalan yang berwibawa, dan setiap fail OpenVPN yang dijana pada cakera ialah output yang diperoleh daripadanya. Perubahan yang dibuat terus pada fail yang dijana bertahan sehingga penjanaan semula seterusnya dan kemudian hilang, sebab itulah menyunting fail masa jalan bukan pembetulan yang tahan lama. Peraturan yang sama terpakai kepada laluan dan antara muka berkesan: ia menerangkan apa yang dihasilkan oleh satah kawalan, bukan apa yang sepatutnya dihasilkan.

Hos menyumbang set nilai yang lebih kecil tetapi tidak boleh dipindahkan. Salah satunya ialah /var/lib/pritunl/pritunl.uuid, identiti nod tertentu itu.

Identiti itu paling penting dalam kelompok. Hos pengganti memerlukan pendaftarannya sendiri dan bukannya klon UUID nod aktif, jika tidak kedua-duanya berebut identiti yang sama. Catat pemetaan antara setiap hos, UUID-nya dan pangkalan data yang ditujunya, kerana satu dump pangkalan data tidak menerangkan tetapan hos mana milik mesin mana. Versi perisian dan nama titik akhir awam tergolong dalam rekod yang sama.

Buat dump yang konsisten, bukan salinan direktori

Menyalin direktori data MongoDB semasa perkhidmatan menulis menghasilkan fail yang mungkin tidak membentuk pangkalan data yang boleh digunakan. Gunakan laluan dump yang disokong pangkalan data, dijalankan terhadap topologi yang anda benar-benar ada:

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

Hos berdiri sendiri bertolak ansur dengan bentuk mudah itu. Set replika memerlukan titik masa yang konsisten, dan dump berasaskan oplog mempunyai keperluan yang tidak dimiliki dump biasa. Prosedur yang disokong bergantung pada versi dan topologi MongoDB anda, jadi jangan simpulkannya daripada kehadiran direktori data. Arkibkan lapisan hos di sebelah dump, dalam larian yang sama, dengan cap masa yang sama.

Berlatih pemulihan sebelum anda memerlukannya

Sandaran yang tiada siapa pernah memulihkan ialah hipotesis. Bina perkhidmatan dalam rangkaian terasing, pulihkan dump dan letakkan semula fail hos:

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

Kemudian sahkan objek dan bukan proses: log masuk, sahkan bahawa organisasi dan pengguna hadir, dan lancarkan satu klien ujian terhadap definisi pelayan yang anda kenali. Halang hos yang dipulihkan daripada mengiklankan titik akhir pengeluaran atau menerima sambungan sebenar sehingga alamat dan identiti disengajakan. Di sini juga anda mendapati bahawa arkib memerlukan kelayakan yang hanya hidup pada mesin yang gagal, jadi simpan kelayakan pemulihan di tempat yang bebas. Pemulihan yang bergantung pada hos yang baru anda hilang bukan pelan pemulihan.

Akhir sekali, ingat bahawa coretan lama memulihkan keputusan lama. Jika pentadbir melumpuhkan identiti selepas dump diambil, pemulihan mengaktifkannya semula. Penyesuaian selepas pemulihan tergolong dalam prosedur, bukan dalam renungan kemudian.