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 /

ثم تحقق من الكائنات لا من العملية: سجّل الدخول، وأكّد وجود المؤسسات والمستخدمين، وشغّل عميل اختبار واحدًا مقابل تعريف خادم تعرفه. امنع المضيف المستعاد من الإعلان عن نقطة نهاية الإنتاج أو قبول اتصالات حقيقية حتى تكون العناوين والهويات مقصودة. هنا أيضًا تكتشف أن الأرشيف يحتاج بيانات اعتماد كانت تعيش فقط على الجهاز المعطّل، لذا خزّن بيانات اعتماد الاستعادة في مكان مستقل. الاستعادة التي تعتمد على المضيف الذي فقدته للتو ليست خطة استعادة.

أخيرًا، تذكّر أن اللقطة القديمة تستعيد قرارات قديمة. إذا عطّل مسؤول هوية بعد أخذ التفريغ، فإن الاستعادة تعيد تفعيلها. تنتمي المطابقة بعد الاستعادة إلى الإجراء، لا إلى التفكير المتأخر.