Pritunl: status kendali versus profil yang dihasilkan

Satu arsip memulihkan penyebaran Pritunl yang berfungsi; yang lain hanya memulihkan gambarnya. Profil klien, salinan konfigurasi host, dan tarball direktori status semuanya tampak seperti cadangan, dan tidak satu pun sendirian mengembalikan organisasi, pengguna, dan definisi server yang dikelola Pritunl. Perbedaannya adalah kepemilikan: sebagian status milik basis data, sebagian milik host, dan sebagian merupakan keluaran yang dihasilkan ulang. Pilih lapisan yang salah dan pemulihan menghasilkan server yang menyala, mendengarkan, dan tidak tahu apa-apa. Perbandingan ini memisahkan ketiga lapisan agar arsip yang Anda simpan cocok dengan kegagalan yang sedang Anda pulihkan.

Dua objek tampak seperti cadangan dan hanya satu yang memulihkan layanan

Profil klien yang diunduh berisi sertifikat, kunci, dan titik akhir. Itu lengkap untuk satu perangkat itu dan tidak berguna sebagai catatan penyebaran: tidak membawa organisasi, pengguna yang dinonaktifkan, rute server, maupun akun administratif. Memulihkan dari folder profil memberi klien yang tidak dapat mengautentikasi terhadap apa pun.

Salinan konfigurasi host sama-sama parsial. /etc/pritunl.conf menyimpan pengaturan tingkat host, termasuk cara menjangkau basis data, dan tidak memuat objek VPN itu sendiri.

Apa yang dimiliki basis data dan apa yang dimiliki host

Pritunl menyimpan definisi server, pengguna, organisasi, dan kunci di MongoDB. Basis data itu adalah bidang kendali yang berwenang, dan setiap berkas OpenVPN yang dihasilkan di disk adalah keluaran yang diturunkan darinya. Perubahan yang dibuat langsung pada berkas yang dihasilkan bertahan sampai regenerasi berikutnya lalu hilang, itulah sebabnya menyunting berkas runtime bukan perbaikan yang tahan lama. Aturan yang sama berlaku untuk rute dan antarmuka efektif: keduanya menjelaskan apa yang dihasilkan bidang kendali, bukan apa yang seharusnya dihasilkan.

Host menyumbang sekumpulan nilai yang lebih kecil tetapi tidak dapat dipindahkan. Salah satunya adalah /var/lib/pritunl/pritunl.uuid, identitas simpul tertentu itu.

Identitas itu paling penting dalam klaster. Host pengganti memerlukan pendaftarannya sendiri, bukan klon UUID simpul aktif, atau keduanya berebut identitas yang sama. Catat pemetaan antara setiap host, UUID-nya, dan basis data yang dituju, karena satu dump basis data tidak menjelaskan pengaturan host mana yang dimiliki mesin mana. Versi perangkat lunak dan nama titik akhir publik termasuk dalam catatan yang sama.

Buat dump yang konsisten, bukan salinan direktori

Menyalin direktori data MongoDB saat layanan menulis menghasilkan berkas yang mungkin tidak membentuk basis data yang dapat digunakan. Gunakan jalur dump yang didukung basis data, dijalankan terhadap topologi yang benar-benar Anda miliki:

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

Host mandiri menoleransi bentuk sederhana itu. Set replika memerlukan titik waktu yang konsisten, dan dump berbasis oplog memiliki persyaratan yang tidak dimiliki dump biasa. Prosedur yang didukung bergantung pada versi dan topologi MongoDB Anda, jadi jangan menyimpulkannya dari keberadaan direktori data. Arsipkan lapisan host di samping dump, dalam proses yang sama, dengan stempel waktu yang sama.

Latih pemulihan sebelum Anda membutuhkannya

Cadangan yang belum pernah dipulihkan siapa pun adalah hipotesis. Bangun layanan di jaringan terisolasi, pulihkan dump, dan kembalikan berkas host:

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

Lalu verifikasi objeknya, bukan prosesnya: masuk, pastikan organisasi dan pengguna ada, dan jalankan satu klien uji terhadap definisi server yang Anda kenali. Cegah host yang dipulihkan mengiklankan titik akhir produksi atau menerima koneksi nyata sampai alamat dan identitas disengaja. Di sini juga Anda menemukan bahwa arsip memerlukan kredensial yang hanya hidup di mesin yang gagal, jadi simpan kredensial pemulihan di tempat yang independen. Pemulihan yang bergantung pada host yang baru saja Anda hilangkan bukan rencana pemulihan.

Terakhir, ingat bahwa snapshot lama memulihkan keputusan lama. Jika administrator menonaktifkan identitas setelah dump diambil, pemulihan mengaktifkannya kembali. Rekonsiliasi setelah pemulihan termasuk dalam prosedur, bukan dalam renungan belakangan.