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 /

سپس به‌جای فرایند، اشیاء را بررسی کنید: وارد شوید، تأیید کنید سازمان‌ها و کاربران حاضرند و یک کلاینت آزمایشی را در برابر تعریف سروری که می‌شناسید اجرا کنید. نگذارید میزبان بازیابی‌شده نقطهٔ پایانی تولید را اعلام کند یا اتصال‌های واقعی بپذیرد تا نشانی‌ها و هویت‌ها سنجیده شوند. اینجا همچنین کشف می‌کنید که بایگانی به اعتبارنامه‌هایی نیاز دارد که فقط روی ماشین خراب‌شده زندگی می‌کردند، پس اعتبارنامه‌های بازیابی را در جایی مستقل نگه دارید. بازیابی‌ای که به میزبانی وابسته است که همین حالا از دست دادید، برنامهٔ بازیابی نیست.

در پایان، به یاد داشته باشید که یک عکس فوری قدیمی تصمیم‌های قدیمی را بازیابی می‌کند. اگر مدیر یک هویت را پس از گرفتن خروجی غیرفعال کرده باشد، بازیابی دوباره فعالش می‌کند. تطبیق پس از بازیابی بخشی از رویه است، نه اندیشهٔ دیررس.