Pritunl: د کنټرول حالت او جوړ شوی پروفایل

یو آرشیف یو فعال Pritunl ځای پرځای کول بحالوي؛ بل یوازې د هغې انځور بحالوي۔ د کلاینټ پروفایل، د کوربه ترتیب کاپي او د حالت فولډر tarball ټول د بیک اپ په څېر ښکاري او هیڅ یو یې یوازې هغه سازمانونه، کاروونکي او سرور تعریفونه چې Pritunl یې مدیریت کوي بیرته نه راوړي۔ توپیر په مالکیت کې دی: د حالت یوه برخه د معلوماتو اډې، یوه برخه د کوربه او یوه برخه بیا جوړ شوی تولید دی۔ ناسمه طبقې وټاکئ او بحالول هغه سرور جوړوي چې پیلېږي، اورېدل کوي او هېڅ نه پوهېږي۔ دا پرتله درې طبقې جلا کوي ترڅو ستاسو ساتل شوی آرشیف هغه نیمګړتیا سره سمون ولري چې تاسو ترې بحالیږئ۔

دوه شیان د بیک اپ په څېر ښکاري او یوازې یو یې خدمت بحالوي

ډاونلوډ شوی کلاینټ پروفایل سند، کیلي او پای ټکی لري۔ دا د هغه یو آلې لپاره بشپړ دی او د ځای پرځای کولو د ریکارډ په توګه بې ګټې دی: هېڅ سازمان، غیر فعال کاروونکي، د سرور لارې یا اداري حسابونه نه لري۔ د پروفایلونو له فولډر څخه بحالول هغه کلاینټونه ورکوي چې د هېڅ شي په وړاندې تصدیق نه شي کولی۔

د کوربه د ترتیب کاپي هم هماغه اندازه جزوي ده۔ /etc/pritunl.conf د کوربه کچې تنظیمات لري، په شمول د معلوماتو اډې ته د رسېدو لاره، او پخپله د VPN شیان نه لري۔

معلوماتو اډه څه لري او کوربه څه لري

Pritunl د سرور تعریفونه، کاروونکي، سازمانونه او کیلي په MongoDB کې ساتي۔ هغه معلوماتو اډه باوري کنټرول الوتکه ده او په ډیسک کې جوړ شوی هر OpenVPN فایل له هغې اخیستل شوی تولید دی۔ په جوړ شوي فایل کې مستقیمه بدلون تر بلې بیا جوړونې پورې ژوندی پاتې کېږي او بیا ورکېږي، نو د اجرا وخت فایلونو سمول تلپاتې سمون نه دی۔ هماغه قاعده د اغېزمنو لارو او انټرفیسونو لپاره هم ده: دوی بیانوي چې کنټرول الوتکې څه جوړ کړل، نه چې څه باید جوړ کړي۔

کوربه یوه کوچنۍ خو نه انتقالېدونکې ټولګه ارزښتونو ورزیاتوي۔ یو له هغو /var/lib/pritunl/pritunl.uuid دی، د هماغه ځانګړي نوډ پیژندنه۔

دا پیژندنه په کلسټر کې تر ټولو مهمه ده۔ بدیل کوربه د فعال نوډ UUID د کاپي پرځای خپله ثبت ته اړتیا لري، که نه دواړه د یوې پیژندنې لپاره جګړه کوي۔ د هر کوربه، د هغې UUID او هغه معلوماتو اډې ترمنځ نقشه ثبت کړئ چې هغه ته اشاره کوي، ځکه چې د معلوماتو اډې یو ډمپ نه بیانوي چې کوم کوربه تنظیمات کوم ماشین ته اړ وو۔ د سافټویر نسخې او د پای ټکي عام نومونه په هماغه ریکارډ کې دي۔

دوامداره ډمپ واخلئ، د فولډر کاپي نه

د معلوماتو اډې د ډېټا فولډر کاپي کول په داسې وخت کې چې خدمت لیکي، هغه فایلونه جوړوي چې کېدای شي کارېدونکې معلوماتو اډه جوړه نه کړي۔ پرځای یې د معلوماتو اډې ملاتړ شوې ډمپ لاره وکاروئ، چې هغه ټوپولوژي ته مقابل اجرا شي چې تاسو واقعاً لرئ:

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 /

بیا د پروسې پرځای شیان تایید کړئ: ننوځئ، تایید کړئ چې سازمانونه او کاروونکي شته، او یو ازموینه کلاینټ د هغه سرور تعریف په وړاندې چې پېژنئ چل کړئ۔ بحال شوی کوربه له دې منع کړئ چې د تولید پای ټکی اعلان کړي یا ریښتیني اړیکې ومني ترڅو پته او پیژندنې په قصد وي۔ دلته تاسو دا هم مومئ چې آرشیف هغه اسناد ته اړتیا لري چې یوازې په ناکام ماشین کې وو، نو د بحالولو اسناد په خپلواک ځای کې وساتئ۔ هغه بحالول چې په هماغه کوربه ولاړ وي چې تاسو همدا اوس له لاسه ورکړی، د بحالولو پلان نه دی۔

په پای کې، په یاد ولرئ چې زوړ سنیپ شاټ زاړه پرېکړې بحالوي۔ که یو مدیر د ډمپ له اخیستلو وروسته یوه پیژندنه غیر فعاله کړې وي، بحالول یې بیا فعالوي۔ له بحالولو وروسته همغږي د پروسې برخه ده، نه د ناوخته فکر۔