یہ نوٹ بیک اپ کے بارے میں سائیکل کو مکمل کرتا ہے۔ یہ ایک وقف شدہ سرور (یا VPS) کی منطقی تنظیم پر تبادلہ خیال کرے گا، جو بیک اپ کے لیے آسان ہے، اور کسی آفت کی صورت میں زیادہ وقت کے بغیر بیک اپ سے سرور کو تیزی سے بحال کرنے کا آپشن بھی پیش کرے گا۔
ماخذ کا ڈیٹا
ایک سرشار سرور میں اکثر کم از کم دو ہارڈ ڈرائیوز ہوتی ہیں جو فرسٹ لیول RAID سرنی (آئینہ) کو منظم کرنے کے لیے کام کرتی ہیں۔ اگر ایک ڈسک ناکام ہو جاتی ہے تو سرور کو چلانے کے لیے یہ ضروری ہے۔ اگر یہ ایک باقاعدہ سرشار سرور ہے تو، SSD پر ایکٹو کیشنگ ٹیکنالوجی کے ساتھ ایک علیحدہ ہارڈ ویئر RAID کنٹرولر ہو سکتا ہے، تاکہ باقاعدہ ہارڈ ڈرائیوز کے علاوہ، ایک یا زیادہ SSDs کو منسلک کیا جا سکے۔ بعض اوقات سرشار سرور پیش کیے جاتے ہیں، جس میں صرف مقامی ڈسکیں SATADOM ہوتی ہیں (چھوٹی ڈسکیں، ساختی طور پر ایک فلیش ڈرائیو جو SATA پورٹ سے منسلک ہوتی ہے)، یا یہاں تک کہ ایک عام چھوٹی (8-16GB) فلیش ڈرائیو کسی خاص اندرونی بندرگاہ سے منسلک ہوتی ہے، اور ڈیٹا سٹوریج سسٹم سے لیا جاتا ہے، جو ایک وقف شدہ سٹوریج نیٹ ورک (ایتھرنیٹ 10G، FC، وغیرہ) کے ذریعے منسلک ہوتا ہے، اور ایسے سرشار سرورز ہوتے ہیں جو براہ راست اسٹوریج سسٹم سے لوڈ ہوتے ہیں۔ میں ایسے آپشنز پر غور نہیں کروں گا، کیونکہ ایسے معاملات میں سرور کو بیک اپ کرنے کا کام آسانی سے اس ماہر کو جاتا ہے جو سٹوریج سسٹم کو برقرار رکھتا ہے؛ عام طور پر اسنیپ شاٹس بنانے، بلٹ ان ڈپلیکیشن اور سسٹم ایڈمنسٹریٹر کی دیگر خوشیوں کے لیے مختلف ملکیتی ٹیکنالوجیز ہوتی ہیں۔ اس سلسلے کے پچھلے حصوں میں بحث کی گئی ہے۔ سرور سے منسلک ڈسکوں کی تعداد اور سائز پر منحصر ہے، ایک سرشار سرور کی ڈسک سرنی کا حجم کئی دسیوں ٹیرابائٹس تک پہنچ سکتا ہے۔ VPS کے معاملے میں، حجم زیادہ معمولی ہوتے ہیں: عام طور پر 100GB سے زیادہ نہیں ہوتے ہیں (لیکن اس سے زیادہ بھی ہوتے ہیں)، اور ایسے VPS کے ٹیرف آسانی سے ایک ہی ہوسٹر کے سب سے سستے وقف سرورز سے زیادہ مہنگے ہو سکتے ہیں۔ VPS میں اکثر ایک ڈسک ہوتی ہے، کیونکہ اس کے نیچے اسٹوریج سسٹم (یا کچھ ہائپر کنورجڈ) ہوتا ہے۔ بعض اوقات ایک VPS میں مختلف خصوصیات کے ساتھ کئی ڈسکیں ہوتی ہیں، مختلف مقاصد کے لیے:
- چھوٹا نظام - آپریٹنگ سسٹم کو انسٹال کرنے کے لیے؛
- بڑے صارف کے ڈیٹا کو ذخیرہ کرنا۔
جب آپ کنٹرول پینل کا استعمال کرتے ہوئے سسٹم کو دوبارہ انسٹال کرتے ہیں تو، صارف کے ڈیٹا والی ڈسک کو اوور رائٹ نہیں کیا جاتا ہے، لیکن سسٹم ڈسک کو مکمل طور پر ری فل کر دیا جاتا ہے۔ اس کے علاوہ، VPS کے معاملے میں، ہوسٹر ایک بٹن پیش کر سکتا ہے جو VPS (یا ڈسک) کی حالت کا سنیپ شاٹ لیتا ہے، لیکن اگر آپ اپنا آپریٹنگ سسٹم انسٹال کرتے ہیں یا VPS کے اندر مطلوبہ سروس کو چالو کرنا بھول جاتے ہیں، تو کچھ ڈیٹا کا اب بھی ضائع ہو سکتا ہے۔ بٹن کے علاوہ، ڈیٹا سٹوریج سروس عام طور پر پیش کی جاتی ہے، اکثر اوقات بہت محدود۔ عام طور پر یہ ایک اکاؤنٹ ہوتا ہے جس میں FTP یا SFTP کے ذریعے رسائی ہوتی ہے، بعض اوقات SSH کے ساتھ، سٹرپڈ-ڈاؤن شیل (مثال کے طور پر، rbash)، یا مجاز_کیز (بذریعہ ForcedCommand) کے ذریعے کمانڈ چلانے پر پابندی ہوتی ہے۔
ایک سرشار سرور 1 Gbps کی رفتار کے ساتھ دو بندرگاہوں کے ذریعے نیٹ ورک سے منسلک ہوتا ہے، بعض اوقات یہ 10 Gbps کی رفتار والے کارڈ بھی ہو سکتے ہیں۔ VPS میں اکثر ایک نیٹ ورک انٹرفیس ہوتا ہے۔ اکثر، ڈیٹا سینٹرز ڈیٹا سینٹر کے اندر نیٹ ورک کی رفتار کو محدود نہیں کرتے ہیں، لیکن وہ انٹرنیٹ تک رسائی کی رفتار کو محدود کرتے ہیں۔
اس طرح کے سرشار سرور یا VPS کا عام بوجھ ایک ویب سرور، ایک ڈیٹا بیس، اور ایک ایپلیکیشن سرور ہے۔ بعض اوقات مختلف اضافی معاون خدمات انسٹال کی جا سکتی ہیں، بشمول ویب سرور یا ڈیٹا بیس: سرچ انجن، میل سسٹم، وغیرہ۔
ایک خاص طور پر تیار کردہ سرور بیک اپ کاپیوں کو ذخیرہ کرنے کے لیے جگہ کا کام کرتا ہے؛ ہم اس کے بارے میں مزید تفصیل سے بعد میں لکھیں گے۔
ڈسک سسٹم کی منطقی تنظیم
اگر آپ کے پاس RAID کنٹرولر ہے، یا ایک ڈسک والا VPS ہے، اور ڈسک سب سسٹم کے آپریشن کے لیے کوئی خاص ترجیحات نہیں ہیں (مثال کے طور پر، ڈیٹا بیس کے لیے ایک علیحدہ فاسٹ ڈسک)، تمام خالی جگہ کو اس طرح تقسیم کیا گیا ہے: ایک پارٹیشن بنایا جاتا ہے، اور اس کے اوپر ایک LVM والیوم گروپ بنایا جاتا ہے، اس میں کئی والیوم بنائے جاتے ہیں: ایک ہی سائز کے 2 چھوٹے، روٹ فائل سسٹم کے طور پر استعمال ہوتے ہیں (فوری رول بیک کے امکان کے لیے اپ ڈیٹس کے دوران ایک ایک کرکے تبدیل کیا جاتا ہے، یہ خیال کیلکولیٹ لینکس ڈسٹری بیوشن سے اٹھایا گیا تھا)، ایک اور ایک سویپ پارٹیشن کے لیے ہے، باقی خالی جگہ کو چھوٹے حجم میں تقسیم کیا جاتا ہے، مکمل کنٹینرز کے لیے روٹ فائل سسٹم کے طور پر استعمال ہوتا ہے، ورچوئل مشینوں کے لیے ڈسک، فائل /home میں اکاؤنٹس کے لیے سسٹمز (ہر اکاؤنٹ کا اپنا فائل سسٹم ہوتا ہے)، ایپلیکیشن کنٹینرز کے لیے فائل سسٹم۔
اہم نوٹ: جلدیں مکمل طور پر خود ساختہ ہونی چاہئیں، یعنی ایک دوسرے پر یا روٹ فائل سسٹم پر انحصار نہیں کرنا چاہئے۔ ورچوئل مشینوں یا کنٹینرز کے معاملے میں، یہ نقطہ خود بخود دیکھا جاتا ہے۔ اگر یہ ایپلیکیشن کنٹینرز یا ہوم ڈائرکٹریز ہیں، تو آپ کو ویب سرور اور دیگر سروسز کی کنفیگریشن فائلوں کو اس طرح الگ کرنے کے بارے میں سوچنا چاہیے کہ جہاں تک ممکن ہو حجم کے درمیان انحصار کو ختم کیا جا سکے۔ مثال کے طور پر، ہر سائٹ اپنے صارف سے چلتی ہے، سائٹ کی کنفیگریشن فائلیں صارف کی ہوم ڈائرکٹری میں ہوتی ہیں، ویب سرور کی ترتیبات میں، سائٹ کنفیگریشن فائلیں /etc/nginx/conf.d/ کے ذریعے شامل نہیں ہوتی ہیں۔.conf، اور، مثال کے طور پر، /home//configs/nginx/*.conf
اگر کئی ڈسکیں ہیں، تو آپ ایک سافٹ ویئر RAID اری بنا سکتے ہیں (اور ضرورت اور موقع ہونے پر اس کی کیشنگ کو SSD پر ترتیب دے سکتے ہیں)، جس کے اوپر آپ اوپر تجویز کردہ اصولوں کے مطابق LVM بنا سکتے ہیں۔ اس صورت میں بھی، آپ ZFS یا BtrFS استعمال کر سکتے ہیں، لیکن آپ کو اس بارے میں دو بار سوچنا چاہیے: دونوں کو وسائل کے لیے بہت زیادہ سنجیدہ نقطہ نظر کی ضرورت ہوتی ہے، اور اس کے علاوہ، ZFS لینکس کرنل کے ساتھ شامل نہیں ہے۔
استعمال شدہ اسکیم سے قطع نظر، ڈسک میں تبدیلیاں لکھنے کی تخمینی رفتار کا پہلے سے اندازہ لگانا اور پھر اسنیپ شاٹس بنانے کے لیے خالی جگہ کی مقدار کا حساب لگانا ہمیشہ قابل ہے۔ مثال کے طور پر، اگر ہمارا سرور 10 میگا بائٹس فی سیکنڈ کی رفتار سے ڈیٹا لکھتا ہے، اور پورے ڈیٹا سرنی کا سائز 10 ٹیرا بائٹس ہے تو - مطابقت پذیری کا وقت ایک دن تک پہنچ سکتا ہے (22 گھنٹے - یہ اتنا ہے کہ اتنی مقدار کو منتقل کیا جائے گا۔ نیٹ ورک پر 1 Gbps) - یہ تقریباً 800 GB محفوظ کرنے کے قابل ہے۔ حقیقت میں، اعداد و شمار چھوٹا ہو گا؛ آپ اسے محفوظ طریقے سے منطقی حجم کی تعداد سے تقسیم کر سکتے ہیں.
بیک اپ اسٹوریج سرور ڈیوائس
بیک اپ کاپیاں ذخیرہ کرنے کے لیے سرور کے درمیان بنیادی فرق اس کی بڑی، سستی اور نسبتاً سست ڈسک ہے۔ چونکہ جدید HDD پہلے ہی ایک ڈسک میں 10TB بار کو عبور کر چکے ہیں، اس لیے ضروری ہے کہ فائل سسٹم یا RAID کو چیکسم کے ساتھ استعمال کیا جائے، کیونکہ صف کی دوبارہ تعمیر یا فائل سسٹم کی بحالی کے دوران (کئی دن!) دوسری ڈسک ناکام ہو سکتی ہے۔ بوجھ میں اضافہ کرنے کے لئے. 1TB تک کی صلاحیت والی ڈسکوں پر یہ اتنا حساس نہیں تھا۔ وضاحت کی سادگی کے لیے، میں فرض کرتا ہوں کہ ڈسک کی جگہ کو تقریباً برابر سائز کے دو حصوں میں تقسیم کیا گیا ہے (دوبارہ، مثال کے طور پر، LVM کا استعمال کرتے ہوئے):
- صارف کے ڈیٹا کو ذخیرہ کرنے کے لیے استعمال کیے جانے والے سرورز سے مماثل حجم (آخری بیک اپ ان پر تصدیق کے لیے تعینات کیا جائے گا)؛
- BorgBackup repositories کے طور پر استعمال ہونے والی جلدیں (بیک اپ کے لیے ڈیٹا براہ راست یہاں جائے گا)۔
آپریشن کا اصول یہ ہے کہ BorgBackup ریپوزٹریز کے لیے ہر سرور کے لیے الگ الگ حجم بنائے جاتے ہیں، جہاں جنگی سرورز سے ڈیٹا جائے گا۔ ریپوزٹریز صرف ضمیمہ کے موڈ میں کام کرتی ہیں، جو جان بوجھ کر ڈیٹا کو حذف کرنے کے امکان کو ختم کرتی ہے، اور پرانے بیک اپ سے ریپوزٹریوں کی نقل اور وقتاً فوقتاً صفائی کی وجہ سے (سالانہ کاپیاں باقی رہتی ہیں، پچھلے سال کے لیے ماہانہ، پچھلے مہینے کے لیے ہفتہ وار، روزانہ پچھلے ہفتے، ممکنہ طور پر خاص معاملات میں - آخری دن کے لیے فی گھنٹہ: کل 24 + 7 + 4 + 12 + سالانہ - ہر سرور کے لیے تقریباً 50 کاپیاں)۔
BorgBackup ریپوزٹریز صرف اپنڈ موڈ کو فعال نہیں کرتی ہیں؛ اس کے بجائے، .ssh/authorized_keys میں ایک ForcedCommand کچھ اس طرح استعمال کیا جاتا ہے:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......مخصوص راستے میں بورگ کے اوپر ایک ریپر اسکرپٹ ہوتا ہے، جو بائنری کو پیرامیٹرز کے ساتھ لانچ کرنے کے علاوہ، ڈیٹا ہٹانے کے بعد بیک اپ کاپی کو بحال کرنے کا عمل بھی شروع کرتا ہے۔ ایسا کرنے کے لیے، ریپر اسکرپٹ متعلقہ ریپوزٹری کے آگے ایک ٹیگ فائل بناتا ہے۔ ڈیٹا بھرنے کا عمل مکمل ہونے کے بعد بنایا گیا آخری بیک اپ خود بخود متعلقہ منطقی حجم میں بحال ہو جاتا ہے۔
یہ ڈیزائن آپ کو وقتاً فوقتاً غیر ضروری بیک اپ کو صاف کرنے کی اجازت دیتا ہے، اور جنگی سرورز کو بیک اپ اسٹوریج سرور پر موجود کسی بھی چیز کو حذف کرنے سے بھی روکتا ہے۔
بیک اپ کا عمل
بیک اپ کا آغاز کرنے والا خود سرشار سرور یا VPS ہوتا ہے، کیونکہ یہ اسکیم اس سرور کی جانب سے بیک اپ کے عمل پر زیادہ کنٹرول دیتی ہے۔ سب سے پہلے، فعال روٹ فائل سسٹم کی حالت کا ایک سنیپ شاٹ لیا جاتا ہے، جسے BorgBackup کا استعمال کرتے ہوئے بیک اپ اسٹوریج سرور پر نصب اور اپ لوڈ کیا جاتا ہے۔ ڈیٹا کیپچر مکمل ہونے کے بعد، سنیپ شاٹ ان ماؤنٹ اور ڈیلیٹ ہو جاتا ہے۔
اگر ایک چھوٹا ڈیٹا بیس ہے (ہر سائٹ کے لیے 1 جی بی تک)، ایک ڈیٹا بیس ڈمپ بنایا جاتا ہے، جسے مناسب منطقی حجم میں محفوظ کیا جاتا ہے، جہاں اسی سائٹ کے لیے باقی ڈیٹا موجود ہوتا ہے، لیکن تاکہ ڈمپ ہو ویب سرور کے ذریعے قابل رسائی نہیں ہے۔ اگر ڈیٹا بیسز بڑے ہیں، تو آپ کو "ہاٹ" ڈیٹا ہٹانے کو ترتیب دینا چاہیے، مثال کے طور پر، MySQL کے لیے xtrabackup استعمال کرتے ہوئے، یا PostgreSQL میں archive_command کے ساتھ WAL کے ساتھ کام کریں۔ اس صورت میں، ڈیٹا بیس کو سائٹ کے ڈیٹا سے الگ سے بحال کیا جائے گا۔
اگر کنٹینرز یا ورچوئل مشینیں استعمال کی جاتی ہیں، تو آپ کو qemu-گیسٹ-ایجنٹ، CRIU یا دیگر ضروری ٹیکنالوجیز کو ترتیب دینا چاہیے۔ دوسرے معاملات میں، اضافی ترتیبات کی اکثر ضرورت نہیں ہوتی ہے - ہم صرف منطقی حجم کے اسنیپ شاٹس بناتے ہیں، جو کہ پھر روٹ فائل سسٹم کی حالت کے سنیپ شاٹ کی طرح پروسیس ہوتے ہیں۔ ڈیٹا لینے کے بعد، تصاویر کو حذف کر دیا جاتا ہے۔
مزید کام بیک اپ اسٹوریج سرور پر کیا جاتا ہے:
- ہر ذخیرہ میں بنایا گیا آخری بیک اپ چیک کیا جاتا ہے،
- مارک فائل کی موجودگی کی جانچ پڑتال کی جاتی ہے، جس سے ظاہر ہوتا ہے کہ ڈیٹا اکٹھا کرنے کا عمل مکمل ہو گیا ہے،
- ڈیٹا کو اسی مقامی حجم تک بڑھایا جاتا ہے،
- ٹیگ فائل کو حذف کر دیا گیا ہے۔
سرور کی بازیابی کا عمل
اگر مرکزی سرور مر جاتا ہے، تو اسی طرح کا سرشار سرور شروع کیا جاتا ہے، جو کسی معیاری تصویر سے بوٹ ہوتا ہے۔ زیادہ تر امکان ہے کہ ڈاؤن لوڈ نیٹ ورک پر ہو گا، لیکن سرور کو ترتیب دینے والا ڈیٹا سینٹر ٹیکنیشن فوری طور پر اس معیاری تصویر کو کسی ایک ڈسک میں کاپی کر سکتا ہے۔ ڈاؤن لوڈ RAM میں ہوتا ہے، جس کے بعد بازیابی کا عمل شروع ہوتا ہے:
- ایک بلاک ڈیوائس کو iscsinbd یا اسی طرح کے کسی دوسرے پروٹوکول کے ذریعے متوفی سرور کے روٹ فائل سسٹم پر مشتمل منطقی حجم سے منسلک کرنے کی درخواست کی جاتی ہے۔ چونکہ روٹ فائل سسٹم چھوٹا ہونا چاہیے، اس لیے یہ مرحلہ چند منٹوں میں مکمل ہو جانا چاہیے۔ بوٹ لوڈر بھی بحال ہو گیا ہے۔
- مقامی منطقی حجم کی ساخت کو دوبارہ بنایا جاتا ہے، منطقی حجم بیک اپ سرور سے dm_clone کرنل ماڈیول کا استعمال کرتے ہوئے منسلک ہوتے ہیں: ڈیٹا کی بازیافت شروع ہوتی ہے، اور تبدیلیاں فوری طور پر مقامی ڈسکوں پر لکھی جاتی ہیں۔
- ایک کنٹینر تمام دستیاب فزیکل ڈسکوں کے ساتھ لانچ کیا گیا ہے - سرور کی فعالیت مکمل طور پر بحال ہو گئی ہے، لیکن کم کارکردگی کے ساتھ؛
- ڈیٹا سنکرونائزیشن مکمل ہونے کے بعد، بیک اپ سرور سے منطقی حجم منقطع ہو جاتے ہیں، کنٹینر بند ہو جاتا ہے، اور سرور دوبارہ شروع ہو جاتا ہے۔
ریبوٹ کے بعد، سرور کے پاس وہ تمام ڈیٹا موجود ہوگا جو بیک اپ بنانے کے وقت موجود تھا، اور اس میں وہ تمام تبدیلیاں بھی شامل ہوں گی جو بحالی کے عمل کے دوران کی گئی تھیں۔
سیریز کے دیگر مضامین
بیک اپ حصہ 7: نتائج
میں آپ کو تبصرے میں مجوزہ آپشن پر بات کرنے کی دعوت دیتا ہوں، آپ کی توجہ کا شکریہ!
ماخذ: www.habr.com