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 /

তারপর প্রক্রিয়ার বদলে বস্তু যাচাই করুন: লগ ইন করুন, নিশ্চিত করুন যে সংস্থা ও ব্যবহারকারী উপস্থিত, এবং আপনার চেনা একটি সার্ভার সংজ্ঞার বিরুদ্ধে একটি পরীক্ষা ক্লায়েন্ট চালু করুন। পুনরুদ্ধার করা হোস্টকে উৎপাদন এন্ডপয়েন্ট বিজ্ঞাপন বা বাস্তব সংযোগ গ্রহণ থেকে বিরত রাখুন যতক্ষণ না ঠিকানা ও পরিচয় ইচ্ছাকৃত হয়। এখানেই আপনি আবিষ্কার করেন যে সংরক্ষণাগারের এমন ক্রেডেনশিয়াল দরকার যা কেবল ব্যর্থ মেশিনে ছিল, তাই পুনরুদ্ধার ক্রেডেনশিয়াল স্বাধীন জায়গায় রাখুন। যে পুনরুদ্ধার আপনার এইমাত্র হারানো হোস্টের উপর নির্ভর করে তা পুনরুদ্ধার পরিকল্পনা নয়।

শেষে মনে রাখবেন যে পুরনো স্ন্যাপশট পুরনো সিদ্ধান্ত পুনরুদ্ধার করে। যদি প্রশাসক ডাম্প নেওয়ার পরে একটি পরিচয় নিষ্ক্রিয় করেন, পুনরুদ্ধার তা আবার সক্রিয় করে। পুনরুদ্ধারের পরে সমন্বয় পদ্ধতির অংশ, পরে ভাবনার নয়।