Capacity Tier (یا جیسا کہ ہم اسے Vim - captir کے اندر کہتے ہیں) Veeam Backup اور Replication 9.5 Update 4 کے دنوں میں Archive Tier کے نام سے ظاہر ہوا۔ اس کے پیچھے خیال یہ ہے کہ نام نہاد آپریشنل ریسٹور ونڈو سے نکل کر آبجیکٹ اسٹوریج میں بیک اپ کو منتقل کرنا ممکن بنایا جائے۔ اس سے ان صارفین کے لیے ڈسک کی جگہ صاف کرنے میں مدد ملی جن کے پاس اس کی بہت کم تھی۔ اور اس آپشن کو Move Mode کہا جاتا تھا۔
اس سادہ (جیسا کہ ایسا لگتا ہے) ایکشن کو انجام دینے کے لیے، یہ دو شرائط کو پورا کرنے کے لیے کافی تھا: منتقل کیے گئے بیک اپ کے تمام پوائنٹس اوپر بیان کردہ آپریشنل ریسٹور ونڈو کی حدود سے باہر ہونے چاہئیں، جو UI میں واضح طور پر سیٹ کی گئی ہے۔ اور دوسرا: سلسلہ نام نہاد "سیل شدہ شکل" (سیل شدہ بیک اپ چین یا غیر فعال بیک اپ چین) میں ہونا چاہئے۔ یعنی وقت کے ساتھ اس سلسلہ میں کوئی تبدیلی نہیں آتی۔
لیکن VBR v10 میں، تصور کو نئے فنکشنز کے ساتھ ضمیمہ کیا گیا تھا - کاپی موڈ، سیلڈ موڈ اور ایک چیز جس کا تلفظ مشکل ہے نام Imutability ظاہر ہوا۔
یہ وہ دلچسپ چیزیں ہیں جن کے بارے میں ہم آج بات کریں گے۔ سب سے پہلے، اس نے VBR9.5u4 میں کیسے کام کیا، اور پھر دسویں ورژن میں ہونے والی تبدیلیوں کے بارے میں۔
اور خالص زبان کے چیمپئن مجھے معاف کر دیں، لیکن بہت ساری اصطلاحات ہیں جن کا ترجمہ نہیں کیا جا سکتا۔
تو یہاں انگریزوں کی ایک ٹن ہوگی۔
اور بہت سارے gifs۔
اور تصاویر۔
- بغیر کسی افسوس کے۔ مضمون کا مصنف۔
جیسا کہ تھا
ٹھیک ہے، آئیے آپریشنل ریسٹور ونڈو اور سیل شدہ بیک اپ کا تجزیہ کرکے شروع کرتے ہیں (یا جیسا کہ انہیں غیر فعال بیک اپ چین دستاویزات میں کہا جاتا ہے)۔ ان کی سمجھ کے بغیر مزید وضاحت ممکن نہیں ہوگی۔
جیسا کہ ہم تصویر میں دیکھ رہے ہیں، ہمارے پاس ڈیٹا بلاکس کے ساتھ بیک اپ چین کی ایک قسم ہے، جو کہ ریپوزٹری کے پرفارمنس ٹائر SOBR پر واقع ہے جس سے Capacity Tier منسلک ہے۔ ہماری آپریشنل بیک اپ ونڈو تین دن کی ہے۔
اس کے مطابق، پیر کو بنایا گیا .vbk پچھلی زنجیر کو سیل کرتا ہے، جس کی ونڈو تین دن پر سیٹ کی گئی ہے۔ اور اس کا مطلب ہے کہ آپ ان تین دنوں سے پرانی ہر چیز کو محفوظ طریقے سے شوٹنگ رینج تک لے جانا شروع کر سکتے ہیں۔
لیکن مہر بند چین کا اصل مطلب کیا تھا اور اپ ڈیٹ 4 میں شوٹنگ کی صلاحیت کی حد میں کیا بھیجا جا سکتا ہے؟
فارورڈ انکریمنٹل کے لیے، چین کو سیل کرنے کی علامت ایک نئے مکمل بیک اپ کی تخلیق ہے۔ اور اس سے کوئی فرق نہیں پڑتا کہ یہ مکمل بیک اپ کیسے حاصل کیا جاتا ہے: مصنوعی مکمل اور فعال مکمل بیک اپ دونوں پر غور کیا جاتا ہے۔
ریورس کی صورت میں، یہ تمام فائلیں ہیں جو آپریٹنگ ونڈو میں نہیں آتیں۔
رول بیکس کے ساتھ فارورڈ انکریمنٹ کی صورت میں، یہ تمام رول بیکس اور .vbk ہیں، اگر کارکردگی کی حد پر کوئی اور .vbk ہے
اب بیک اپ کاپی چینز کے ساتھ کام کرنے کے آپشن پر غور کریں۔ صرف GFS برقراری کے تحت آنے والی اشیاء کو یہاں منتقل کیا گیا تھا۔ کیونکہ حالیہ بیک اپ کاپی چینز میں ذخیرہ کردہ ہر چیز کو کسی نہ کسی طریقے سے تبدیل کیا جا سکتا ہے۔
اب ہڈ کے نیچے دیکھتے ہیں. وہاں، پانی کی کمی نامی ایک عمل ہوتا ہے - خالی بیک اپ فائلوں کو حد تک چھوڑنا اور ان فائلوں سے بلاکس کو صلاحیت کی شوٹنگ کی حد تک گھسیٹنا۔ اس عمل کو بہتر بنانے کے لیے، نام نہاد ڈی ہائیڈریشن انڈیکس کا استعمال کیا جاتا ہے، جو آپ کو ان بلاکس کو کاپی کرنے سے بچنے کی اجازت دیتا ہے جو پہلے ہی صلاحیت کی شوٹنگ رینج میں کاپی ہو چکے ہیں۔
آئیے دیکھتے ہیں کہ یہ ایک مثال کے ساتھ کیسا لگتا ہے: آئیے کہتے ہیں کہ ہمارے پاس ایک .vbk ہے جو ٹرانزیکشن ونڈو سے باہر آیا ہے اور اس کا تعلق سیل بند چین سے ہے۔ اس کا مطلب ہے کہ ہمیں اسے صلاحیت کی شوٹنگ رینج میں منتقل کرنے کا پورا حق ہے۔ منتقلی کے وقت، ایک میٹا ڈیٹا فائل کی گنجائش ڈیش اور منتقل شدہ فائل کے بلاکس میں بنتی ہے۔ لنک لیول میٹا ڈیٹا فائل بتاتی ہے کہ ہماری فائل کن بلاکس پر مشتمل ہے۔ تصویر کے معاملے میں، ہماری پہلی فائل بلاکس a, b, c پر مشتمل ہے اور میٹا ڈیٹا ان بلاکس کے لنکس پر مشتمل ہے۔ جب ہمارے پاس دوسری .vbk فائل ہوتی ہے، جو منتقل کرنے کے لیے تیار ہوتی ہے اور بلاکس a، b اور d پر مشتمل ہوتی ہے، ہم ڈی ہائیڈریشن انڈیکس کا تجزیہ کرتے ہوئے سمجھتے ہیں کہ صرف بلاک ڈی کو منتقل کرنے کی ضرورت ہے۔ اور اس کی میٹا ڈیٹا فائل میں دو پچھلے بلاکس اور ایک نئے کے لنکس ہوں گے۔
اس کے مطابق، ان خالی جگہوں کو ڈیٹا سے بھرنے کے عمل کو ری ہائیڈریشن کہا جاتا ہے۔ یہ پہلے سے ہی مقامی کارکردگی کی حد پر سب سے پرانی .vbk فائل پر مبنی اپنا ری ہائیڈریشن انڈیکس استعمال کرتا ہے۔ یعنی، اگر صارف صلاحیت کی شوٹنگ کی حد سے فائل واپس کرنا چاہتا ہے، تو ہم سب سے پہلے سب سے پرانے مکمل بیک اپ کے بلاکس کا انڈیکس بناتے ہیں اور صلاحیت کی شوٹنگ گیلری سے صرف غائب بلاکس کو منتقل کرتے ہیں۔ تصویر میں پیش کردہ کیس میں، FullBackup1.vbk کو ری ہائیڈریشن انڈیکس کے مطابق ری ہائیڈریٹ کرنے کے لیے، ہمیں صرف بلاک سی کی ضرورت ہے، جسے ہم صلاحیت شوٹنگ کی حد سے لیتے ہیں۔ اگر اسٹوریج کلاؤڈ آبجیکٹ صلاحیت کی شوٹنگ رینج کے طور پر کام کرتا ہے، تو یہ آپ کو بہت زیادہ رقم بچانے کی اجازت دیتا ہے۔
یہاں ایسا لگتا ہے کہ یہ ٹیکنالوجی WAN ایکسلریٹر میں استعمال ہونے والی ٹیکنالوجی جیسی ہے، لیکن ایسا لگتا ہے۔ ایکسلریٹروں میں، ڈپلیکیشن عالمی ہے؛ یہاں، مقامی ڈپلیکیشن کو ہر فائل کے اندر ایک مخصوص آفسیٹ پر استعمال کیا جاتا ہے۔ یہ حل کیے جانے والے کاموں میں فرق کی وجہ سے ہوتا ہے: یہاں ہمیں بڑی مکمل بیک اپ فائلوں کو کاپی کرنے کی ضرورت ہے، اور ہماری تحقیق کے مطابق، اگر ان کے درمیان ایک طویل وقت گزر جائے، تب بھی یہ ڈپلیکیشن الگورتھم بہترین نتیجہ دیتا ہے۔
لیکن اشاریہ جات کے خدا کے لیے مزید اشاریہ جات! ڈیٹا ریکوری کے لیے ایک انڈیکس بھی ہے! جب ہم صلاحیت ڈیش میں واقع مشین کو بحال کرنا شروع کرتے ہیں، تو ہم صرف ان منفرد ڈیٹا بلاکس کو پڑھیں گے جو پرفارمنس ڈیش میں نہیں ہیں۔
یہ کیسے ممکن ہوا
تعارفی حصے کے لیے اتنا ہی ہے۔ یہ کافی مفصل ہے، لیکن جیسا کہ اوپر بتایا گیا ہے، ان تفصیلات کے بغیر یہ بتانا ممکن نہیں ہوگا کہ نئے فنکشنز کیسے کام کرتے ہیں۔ لہذا، مزید اڈو کے بغیر، آئیے پہلے کی طرف چلتے ہیں۔
کاپی وضع
یہ زیادہ تر موجودہ ٹیکنالوجیز پر مبنی ہے، لیکن استعمال کی بالکل مختلف منطق رکھتی ہے۔
اس موڈ کا مقصد اس بات کو یقینی بنانا ہے کہ مقامی حد پر موجود تمام ڈیٹا کی صلاحیت ڈیش میں ایک کاپی موجود ہے۔
اگر آپ موو اور کاپی موڈز کا موازنہ کرتے ہیں تو یہ اس طرح نظر آئے گا:
- صرف مہر بند چین کو منتقل کیا جاسکتا ہے۔ کاپی موڈ کی صورت میں، بالکل سب کچھ منتقل ہو جاتا ہے، قطع نظر اس کے کہ بیک اپ جاب میں کیا ہوتا ہے۔
- جب فائلیں آپریشنل بیک اپ ونڈو کی حدود سے باہر جاتی ہیں تو منتقلی کو متحرک کیا جاتا ہے، اور بیک اپ فائل کے ظاہر ہوتے ہی کاپی کرنا شروع ہو جاتا ہے۔
- کاپی کرنے کے لیے نئے ڈیٹا کی نگرانی مسلسل ہوتی ہے، اور اسے منتقل کرنے کے لیے ہر 4 گھنٹے میں ایک بار متحرک کیا جاتا ہے۔
نئے موڈ پر غور کرتے ہوئے، میں سادہ مثالوں سے پیچیدہ مثالوں کی طرف جانے کی تجویز کرتا ہوں۔
سب سے عام صورت میں، ہمارے پاس صرف انکریمنٹ کے ساتھ نئی فائلیں ہوتی ہیں، اور ہم انہیں صرف صلاحیت کی شوٹنگ رینج میں کاپی کرتے ہیں۔ اس بات سے قطع نظر کہ بیک اپ جاب میں کون سا موڈ استعمال کیا جاتا ہے، اس سے قطع نظر کہ اس کا تعلق سلسلہ کے سیل شدہ حصے سے ہے یا نہیں، اس بات سے قطع نظر کہ ہماری آپریٹنگ ونڈو کی میعاد ختم ہو گئی ہے۔ انہوں نے صرف اسے لیا اور اسے نقل کیا۔
اس کے پیچھے کا عمل اب بھی پانی کی کمی ہے جیسا کہ اوپر بیان کیا گیا ہے۔ کاپی موڈ میں، یہ اس بات کو بھی یقینی بناتا ہے کہ ہم ان بلاکس کو کاپی نہ کریں جو ہمارے اسٹوریج پر پہلے سے موجود ہیں۔ فرق صرف یہ ہے کہ اگر مووی موڈ میں ہم اصلی فائلوں کو ڈمی فائلوں سے بدل دیتے ہیں تو یہاں ہم انہیں کسی بھی طرح سے ہاتھ نہیں لگاتے اور ہر چیز کو ویسا ہی چھوڑ دیتے ہیں۔ دوسری صورت میں، یہ بالکل وہی ڈی ہائیڈریشن انڈیکس ہے، جو احتیاط سے آپ کے پیسے اور وقت کو بچانے کی کوشش کرتا ہے۔
سوال پیدا ہوتا ہے - اگر آپ UI کو دیکھیں تو ایک ہی وقت میں دونوں آپشنز کو منتخب کرنے کا موقع موجود ہے۔ اس طرح کا مشترکہ موڈ کیسے کام کرے گا؟
آئیے اس کا پتہ لگائیں۔
آغاز معیاری ہے: بیک اپ فائل فوری طور پر بنائی اور کاپی کی جاتی ہے۔ اس میں ایک انکریمنٹ بنایا جاتا ہے اور کاپی بھی کیا جاتا ہے۔ یہ اس لمحے تک ہوتا ہے جب ہمیں احساس ہوتا ہے کہ فائلوں نے ہماری آپریٹنگ ونڈو کو چھوڑ دیا ہے اور ایک مہر بند سلسلہ ظاہر ہوا ہے۔ اس مقام پر ہم پانی کی کمی کا آپریشن کرتے ہیں اور ان فائلوں کو ڈمی فائلوں سے بدل دیتے ہیں۔ بلاشبہ، ہم صلاحیت کی شوٹنگ کی حد میں دوبارہ کچھ بھی کاپی نہیں کرتے ہیں۔
یہ تمام دلچسپ منطق انٹرفیس میں صرف ایک چیک باکس کے لیے ذمہ دار ہے: جیسے ہی وہ بنتے ہیں آبجیکٹ اسٹوریج میں بیک اپ کاپی کریں۔
ہمیں اس کاپی موڈ کی ضرورت کیوں ہے؟
سوال کو اس طرح دوبارہ بیان کرنا اور بھی بہتر ہے: اس کی مدد سے ہم کن خطرات سے محفوظ رہتے ہیں؟ یہ کونسا مسئلہ حل کرنے میں ہماری مدد کرتا ہے؟
جواب واضح ہے: یقیناً یہ ڈیٹا ریکوری ہے۔ اگر ہمارے پاس آبجیکٹ اسٹوریج پر مقامی ڈیٹا کی مکمل کاپی ہے، تو اس سے کوئی فرق نہیں پڑتا ہے کہ ہمارے پروڈکٹ کے ساتھ کیا ہوتا ہے، ہم ہمیشہ مشروط Amazon میں موجود فائلوں سے ڈیٹا کو بحال کر سکتے ہیں۔
تو آئیے ممکنہ منظرناموں سے گزرتے ہیں، آسان سے زیادہ پیچیدہ تک۔
سب سے آسان بدقسمتی جو ہمارے سروں پر پڑ سکتی ہے وہ بیک اپ چین میں موجود فائلوں میں سے کسی ایک کی ناقابل رسائی ہے۔
ایک افسوسناک کہانی یہ ہے کہ ہمارے SOBR ذخیرے کی ایک حد ٹوٹ گئی۔
یہ اور بھی خراب ہو جاتا ہے جب پورا SOBR ذخیرہ ناقابل رسائی ہو جاتا ہے، لیکن صلاحیت کی شوٹنگ کی حد کام کر رہی ہوتی ہے۔
اور سب کچھ واقعی خراب ہے - یہ تب ہوتا ہے جب بیک اپ سرور مر جاتا ہے اور آپ کی پہلی خواہش یہ ہوتی ہے کہ دس منٹ میں کینیڈا کی سرحد پر بھاگنے کی کوشش کریں۔
اب آئیے ہر صورتحال کو الگ الگ دیکھتے ہیں۔
جب ہم ایک (اور یہاں تک کہ کئی) بیک اپ فائلوں کو کھو دیتے ہیں، تو ہمیں صرف ریپوزٹری کو دوبارہ اسکین کرنے کا عمل شروع کرنے کی ضرورت ہے، اور کھوئی ہوئی فائل کو ڈمی فائل سے بدل دیا جائے گا۔ اور ری ہائیڈریشن کے عمل کا استعمال کرتے ہوئے (جس پر مضمون کے آغاز میں بات کی گئی تھی)، صارف صلاحیت کی شوٹنگ رینج سے مقامی اسٹوریج تک ڈیٹا ڈاؤن لوڈ کر سکے گا۔
اب صورتحال مزید پیچیدہ ہے۔ فرض کریں کہ ہمارا SOBR پرفارمنس موڈ میں چلنے والے دو ایکسٹینٹس پر مشتمل ہے، جس کا مطلب ہے کہ ہمارے .vbk اور .vib ان پر ایک غیر مساوی تہہ میں پھیلے ہوئے ہیں۔ اور کسی وقت، ایک حد تک دستیاب نہیں ہو جاتی ہے، اور صارف کو فوری طور پر مشین کو بحال کرنے کی ضرورت ہوتی ہے، جس کے ڈیٹا کا کچھ حصہ بالکل اسی حد پر ہوتا ہے۔
صارف ریکوری وزرڈ لانچ کرتا ہے، وہ پوائنٹ منتخب کرتا ہے جہاں وہ بحال کرنا چاہتا ہے، اور وزرڈ کام کرتے ہوئے یہ سمجھتا ہے کہ اس کے پاس مقامی طور پر ریکوری کے لیے ضروری تمام ڈیٹا نہیں ہے اور اس لیے اسے کیپسٹی شوٹنگ سے ڈاؤن لوڈ کرنے کی ضرورت ہے۔ گیلری ایک ہی وقت میں، مقامی سٹوریج پر باقی رہنے والے بلاکس کو کلاؤڈ سے ڈاؤن لوڈ نہیں کیا جائے گا۔ بحالی اشاریہ کی شان (جی ہاں، مضمون کے آغاز میں بھی اس کا ذکر کیا گیا تھا)۔
اس کیس کی ایک ذیلی قسم یہ ہے کہ پورا SOBR ذخیرہ ناقابل رسائی ہو گیا ہے۔ اس صورت میں، ہمارے پاس مقامی اسٹوریج سے کاپی کرنے کے لیے کچھ نہیں ہے، اور تمام بلاکس کلاؤڈ سے ڈاؤن لوڈ کیے گئے ہیں۔
اور سب سے دلچسپ صورتحال یہ ہے کہ بیک اپ سرور مر گیا۔ یہاں دو آپشنز ہیں: ایڈمن بہت اچھا ہے اور اس نے کنفیگریشن بیک اپ بنایا ہے، اور ایڈمن خود ایک بری پنوچیو ہے اور اس نے کنفیگریشن بیک اپ نہیں بنایا ہے۔
پہلی صورت میں، اس کے لیے یہ کافی ہو گا کہ وہ VBR کی صاف تنصیب کو کہیں اور اس کے ڈیٹا بیس کو معیاری ذرائع کا استعمال کرتے ہوئے بیک اپ سے بحال کرے۔ اس عمل کے اختتام پر سب کچھ معمول پر آجائے گا۔ یا اسے اوپر کے منظرناموں میں سے کسی ایک کے مطابق بحال کیا جائے گا۔
لیکن اگر ایڈمن یا تو اس کا اپنا دشمن ہے، یا کنفیگریشن بیک اپ بھی ایک مہاکاوی ناکامی کا شکار ہے، تو یہاں بھی ہم اسے قسمت کے رحم و کرم پر نہیں چھوڑیں گے۔ اس معاملے کے لیے، ہم نے ایک نیا طریقہ کار متعارف کرایا ہے جسے Import Object Storage کہتے ہیں۔ یہ آپ کو SOBR ریپوزٹری کو دستی طور پر دوبارہ بنانے کے عمل کو چھوڑنے اور بعد میں دوبارہ اسکین کے ساتھ اس میں صلاحیت کی شوٹنگ رینج کو منسلک کرنے کے عمل کو چھوڑنے کی اجازت دیتا ہے، اور صرف Vim انٹرفیس میں اسٹوریج آبجیکٹ شامل کرنے اور امپورٹ سٹوریج ریپوزٹری کے طریقہ کار کو چلانے کی اجازت دیتا ہے۔ صرف ایک چیز جو آپ اور آپ کے بیک اپ کے درمیان رکاوٹ بن سکتی ہے وہ ہے پاس ورڈ درج کرنے کی درخواست اگر آپ کے بیک اپ انکرپٹڈ تھے۔
یہ شاید کاپی موڈ کے بارے میں ہے اور ہم آگے بڑھتے ہیں۔
مہربند موڈ
مرکزی خیال یہ ہے کہ نئے بیک اپ ریپوزٹری کی منتخب کردہ SOBR حد پر ظاہر نہیں ہوسکتے ہیں۔ v10 سے پہلے، ہمارے پاس صرف مینٹیننس موڈ تھا، جب ریپوزٹری کے ساتھ کوئی بھی کام مکمل طور پر ممنوع تھا۔ سٹوریج کو بند کرنے کے لیے ایک قسم کا ہارڈکور موڈ، جہاں صرف Evacuate بٹن دستیاب ہے، جو بیک اپ کو ایک بار دوسری حد تک لے جاتا ہے۔
اور سیلڈ موڈ ایک قسم کا "نرم" آپشن ہے: ہم نئے بیک اپ بنانے پر پابندی لگاتے ہیں اور بتدریج پرانے کو منتخب کردہ برقراری کے مطابق حذف کر دیتے ہیں، لیکن اس عمل میں ہم ذخیرہ شدہ پوائنٹس سے بحال کرنے کی صلاحیت سے محروم نہیں ہوتے ہیں۔ ایک بہت مفید چیز جب ہمارے پاس یا تو ہارڈ ویئر کا ایک ٹکڑا اس کی زندگی کے اختتام کے قریب ہو اور اسے تبدیل کرنے کی ضرورت ہو، یا ہمیں اسے کسی اور اہم چیز کے لیے خالی کرنے کی ضرورت ہو، لیکن اسے لینے اور سب کچھ ایک ساتھ منتقل کرنے کے لیے کوئی جگہ نہیں ہے۔ یا اسے حذف نہیں کیا جا سکتا۔
اس کے مطابق، آپریشن کا اصول بہت آسان ہے: تمام تحریری کارروائیوں (نئے ڈیٹا کی ظاہری شکل)، پڑھنے (بحالی) اور حذف (برقرار) کو چھوڑنا ضروری ہے۔
دونوں طریقوں کو ایک ساتھ استعمال کیا جا سکتا ہے، لیکن ذہن میں رکھیں کہ مینٹیننس کو زیادہ ترجیح حاصل ہے۔
مثال کے طور پر، ایک SOBR پر غور کریں جو دو حصوں پر مشتمل ہے۔ فرض کریں کہ پہلے چار دنوں کے لیے ہم نے فارورڈ فاریور انکریمنٹل موڈ میں بیک اپ بنائے، اور پھر ہم حد کو سیل کر دیتے ہیں۔ یہ اس حقیقت کی طرف جاتا ہے کہ ہم دوسری دستیاب حد پر ایک نئے ایکٹیو فل کی تخلیق کا آغاز کرتے ہیں۔ اگر ہماری برقراری چار ہے، تو جب مہر بند حد پر واقع پورا سلسلہ اپنی حد سے باہر ہو جائے تو صاف ضمیر کے ساتھ اسے حذف کر دیا جاتا ہے۔
ایسے حالات ہوتے ہیں جب حذف پہلے ہوتا ہے۔ مثال کے طور پر، یہ متواتر فلز کے ساتھ فارورڈ انکریمنٹل ہے۔ اگر ہم نے پہلے دو دنوں کے لیے مکمل بیک اپ بنا لیا، اور جمعرات کو ہم ریپوزٹری کو سیل کرنے کا فیصلہ کرتے ہیں، تو جمعہ کو، جب ایک نیا بیک اپ بنتا ہے، تو پیر کی فائل ڈیلیٹ ہو جائے گی کیونکہ اس مقام پر کوئی انحصار نہیں ہے۔ اور نقطہ خود کسی پر منحصر نہیں ہے۔ پھر ہم اس وقت تک انتظار کرتے ہیں جب تک کہ دستیاب حد پر چار نکات نہ بن جائیں اور باقی تین کو حذف کر دیا جائے، جو ایک دوسرے سے آزادانہ طور پر حذف نہیں ہو سکتے۔
ریورس انکریمنٹل کے ساتھ چیزیں آسان ہیں۔ اس میں، قدیم ترین پوائنٹس کسی چیز پر منحصر نہیں ہیں اور محفوظ طریقے سے حذف کیے جا سکتے ہیں. لہذا، جیسے ہی ایک نئی حد پر ایک نیا .vbk بنایا جائے گا، پرانے .vrbs کو ایک ایک کرکے حذف کردیا جائے گا۔
ویسے، ہم ہر بار ایک نیا .vbk کیوں بناتے ہیں: اگر ہم نے اسے نہیں بنایا، لیکن اضافہ کا پرانا سلسلہ جاری رکھا، تو پرانا .vbk کسی بھی موڈ میں لامحدود طویل عرصے تک منجمد ہو جائے گا، اس کے حذف ہونے سے بچ جائے گا۔ لہذا، یہ فیصلہ کیا گیا کہ جیسے ہی حد پر مہر لگ جائے، ہم مفت حد پر مکمل بیک اپ بنائیں۔
صلاحیت شوٹنگ کی حد کے ساتھ چیزیں زیادہ پیچیدہ ہیں۔
سب سے پہلے، کاپی موڈ کو دیکھتے ہیں. آئیے فرض کریں کہ ہم چار دنوں کے لیے فعال طور پر بیک اپ بنا رہے تھے، اور پھر صلاحیت کی شوٹنگ رینج کو سیل کر دیا گیا۔ ہم کسی بھی چیز کو حذف نہیں کرتے ہیں، لیکن عاجزی کے ساتھ برقرار رکھنے کو برداشت کرتے ہیں، جس کے بعد ہم صلاحیت کی شوٹنگ کی حد سے ڈیٹا کو حذف کر دیتے ہیں۔
تقریباً ایک ہی چیز موو موڈ میں ہوتی ہے - ہم ری ٹچ کا انتظار کرتے ہیں، مقامی اسٹوریج میں پرانے کو ڈیلیٹ کرتے ہیں، اور آبجیکٹ اسٹوریج میں محفوظ کردہ کو ڈیلیٹ کرتے ہیں۔
فاریور فارورڈ انکریمنٹل کے ساتھ ایک دلچسپ مثال۔ ہم تین پوائنٹس پر ریٹینشن انسٹال کرتے ہیں اور پیر کو بیک اپ بنانا شروع کر دیتے ہیں، جو باقاعدگی سے کلاؤڈ پر کاپی کیے جاتے ہیں۔ سٹوریج کو سیل کرنے کے بعد، بیک اپ بنتے رہتے ہیں، تین پوائنٹس کو برقرار رکھتے ہوئے، لیکن کیپسٹی ڈیش میں ذخیرہ شدہ ڈیٹا منحصر رہتا ہے اور اسے حذف نہیں کیا جا سکتا۔ اس لیے، ہم جمعرات تک انتظار کرتے ہیں، جب ہمارا .vbk برقرار رکھنے سے باہر ہو جاتا ہے، اور تب ہی ہم سکون کے ساتھ پوری محفوظ کردہ زنجیر کو حذف کر دیتے ہیں۔
اور ایک چھوٹا سا دستبرداری: یہاں تمام مثالیں ایک مشین کے ساتھ دکھائی گئی ہیں۔ اگر آپ کے بیک اپ میں ان میں سے کئی ہیں، تو ان کا ری ٹچ اس بات پر منحصر ہوگا کہ ایکٹیو فل بنایا گیا تھا یا نہیں۔
بنیادی طور پر یہ سب کچھ ہے۔ تو آئیے سب سے سخت فیچر کی طرف چلتے ہیں -
بدلاؤ
پچھلے نکات کی طرح، پہلی چیز یہ ہے کہ یہ فنکشن کون سا مسئلہ حل کرتا ہے۔ جیسے ہی ہم اپنے بیک اپ کو ذخیرہ کرنے کے لیے کہیں اپ لوڈ کرتے ہیں، ان کی حفاظت کی ضمانت دینے کی شدید خواہش ہوتی ہے، یعنی کسی دی گئی برقراری کے دوران جسمانی طور پر ان کو حذف کرنے اور کسی قسم کی ترمیم کو روکنا ہوتا ہے۔ بشمول ایڈمنز، بشمول ان کے روٹ اکاؤنٹس کے تحت۔ یہ آپ کو انہیں حادثاتی یا جان بوجھ کر پہنچنے والے نقصان سے بچانے کی اجازت دیتا ہے۔ کوئی بھی جو AWS کے ساتھ کام کرتا ہے ہو سکتا ہے کہ وہ آبجیکٹ لاک نامی ایک ایسی ہی خصوصیت دیکھے۔
اب آئیے عام اصطلاحات میں موڈ کو دیکھتے ہیں، اور پھر تفصیلات پر غور کریں۔ ہماری مثال میں، چار دن کی برقراری کے ساتھ ہماری صلاحیت کی شوٹنگ رینج کے لیے ناقابل تبدیلی کو فعال کیا جائے گا۔ اور بیک اپ میں کاپی موڈ فعال ہے۔
تغیر پذیری کسی بھی طرح سے عام برقراری کے ساتھ تعامل نہیں کرتی ہے۔ مثال کے طور پر، یہ اضافی پوائنٹس یا اس طرح کی کوئی چیز شامل نہیں کرتا ہے۔ یہ صرف اتنا ہے کہ کوئی شخص چار دنوں میں بیک اپ فائلوں کو ڈیلیٹ نہیں کر سکتا۔ اگر آپ پیر کو بیک اپ بناتے ہیں، تو آپ صرف جمعہ کو اس کی فائل کو حذف کر سکیں گے۔
پانی کی کمی، اشاریہ جات اور میٹا ڈیٹا کے پہلے بیان کردہ تمام تصورات بالکل اسی طرح کام کرتے رہتے ہیں۔ لیکن ایک شرط کے ساتھ - بلاک نہ صرف ڈیٹا کے لیے، بلکہ میٹا ڈیٹا کے لیے بھی مقرر کیا گیا ہے۔ یہ اس صورت میں کیا جاتا ہے جب کوئی ہوشیار حملہ آور ہمارے میٹا ڈیٹا ڈیٹا بیس کو مٹانے اور ڈیٹا بلاکس کو بیکار بائنری مشت میں تبدیل ہونے سے روکنے کا فیصلہ کرتا ہے۔
اب ہماری بلاک جنریشن ٹیکنالوجی کی وضاحت کرنے کا بہترین وقت ہے۔ یا بلاک نسل۔ ایسا کرنے کے لئے، اس صورت حال پر غور کریں جو اس کی ظاہری شکل کی وجہ سے ہے.
آئیے چھ دن کا ٹائم اسکیل لیں اور اس سے نیچے ہم ناقابل تغیر ہونے کی متوقع میعاد ختم ہونے کے وقت کو نشان زد کریں گے۔ پہلے دن ہم ڈیٹا بلاک اے اور اس کے میٹا ڈیٹا پر مشتمل ایک فائل لیتے اور بناتے ہیں۔ اگر تبدیلی کو تین دن پر سیٹ کیا جاتا ہے، تو یہ سمجھنا منطقی ہے کہ چوتھے دن ڈیٹا کو غیر مقفل اور حذف کر دیا جائے گا۔ دوسرے دن ہم ایک نئی فائل 2 کا اضافہ کریں گے، جس میں اسی سیٹنگز کے ساتھ بلاک بی شامل ہوگا۔ بلاک کو چوتھے دن ہٹانے کی ضرورت ہے۔ لیکن تیسرے دن کچھ خوفناک ہوتا ہے - ایک فائل 3 فائل بنائی جاتی ہے، جس میں ایک نیا بلاک ڈی اور پرانے بلاک اے کا لنک ہوتا ہے۔ اس کا مطلب یہ ہے کہ بلاک اور اس کے غیر متغیر ہونے والے جھنڈے کو ایک نئی تاریخ پر دوبارہ ترتیب دیا جانا چاہیے، جسے چھٹے دن منتقل کیا جاتا ہے۔ اور یہاں ایک مسئلہ پیدا ہوتا ہے - حقیقی بیک اپ میں اس طرح کے بلاکس کی ایک بڑی تعداد موجود ہے. اور ان کی ناقابل تغیر مدت کو بڑھانے کے لیے، آپ کو ہر بار بڑی تعداد میں درخواستیں کرنے کی ضرورت ہے۔ اور درحقیقت، یہ تقریباً نہ ختم ہونے والا روزانہ کا عمل ہوگا، کیونکہ بہت زیادہ امکان کے ساتھ ہمیں ہر ایک کاپی کے ساتھ ڈپلیکیٹ بلاکس کے بھاری ڈھیر ملیں گے۔ آبجیکٹ اسٹوریج فراہم کرنے والوں کی طرف سے درخواستوں کی ایک بڑی تعداد کا کیا مطلب ہے؟ ٹھیک ہے! مہینے کے آخر میں بہت بڑا بل۔
اور کافی رقم کے عوض اپنے پسندیدہ کلائنٹس کو بے نقاب نہ کرنے کے لیے، بلاک جنریشن میکانزم ایجاد کیا گیا۔ یہ ایک اضافی مدت ہے جسے ہم متغیر ہونے کی مقررہ مدت میں شامل کرتے ہیں۔ ذیل کی مثال میں، یہ مدت دو دن ہے۔ لیکن یہ صرف ایک مثال ہے۔ حقیقت میں، وہ اپنا فارمولا استعمال کرتے ہیں، جو ماہانہ لاک کے دوران تقریباً دس اضافی دن دیتا ہے۔
آئیے اسی صورت حال پر غور کرتے رہیں، لیکن بلاک نسل کے ساتھ۔ پہلے دن ہم بلاک اے اور میٹا ڈیٹا سے فائل 1 بناتے ہیں۔ ہم جنریشن کی مدت اور تغیر پذیری کو شامل کرتے ہیں - اس کا مطلب ہے کہ فائل کو ڈیلیٹ کرنے کا موقع چھٹے دن ہوگا۔ اگر دوسرے دن ہم فائل 2 بناتے ہیں، جس میں بلاک بی اور ایک کو بلاک کرنے کا ایک لنک ہوتا ہے، تو حذف کرنے کی متوقع تاریخ سے کچھ نہیں ہوتا۔ وہ چھٹے دن کی طرح کھڑی رہی۔ اور اس طرح ہم درخواستوں کی تعداد پر رقم بچانے کی کوشش کر رہے ہیں۔ واحد صورت حال جب ڈیڈ لائن کو منتقل کیا جا سکتا ہے اگر جنریشن کی مدت ختم ہو گئی ہو۔ یعنی، اگر تیسرے دن نئی فائل 3 میں اے کو بلاک کرنے کا لنک ہے، تو جنریشن 2 کو شامل کیا جائے گا کیونکہ Gen1 کی میعاد ختم ہو چکی ہے۔ اور بلاک اے کو حذف کرنے کی متوقع تاریخ آٹھویں دن منتقل ہو جائے گی۔ اس سے ہمیں ڈپلیکیٹ شدہ بلاکس کی زندگی کو بڑھانے کے لیے درخواستوں کی تعداد کو ڈرامائی طور پر کم کرنے کی اجازت ملتی ہے، جس سے کلائنٹس کو ایک ٹن رقم کی بچت ہوتی ہے۔
یہ ٹیکنالوجی خود S3 اور S3 کے موافق ہارڈ ویئر کے صارفین کے لیے دستیاب ہے، جس کے مینوفیکچررز اس بات کی ضمانت دیتے ہیں کہ ان کا نفاذ Amazon سے مختلف نہیں ہے۔ لہذا اس جائز سوال کا جواب کہ Azure کی حمایت کیوں نہیں کی جاتی ہے - ان میں ایک جیسی خصوصیت ہے، لیکن یہ کنٹینرز کی سطح پر کام کرتی ہے، انفرادی اشیاء کی نہیں۔ ویسے، ایمیزون خود دو طریقوں میں آبجیکٹ لاک رکھتا ہے: تعمیل اور حکمرانی۔ دوسری صورت میں، اس بات کا امکان باقی رہتا ہے کہ ایڈمنز کے اوپر سب سے بڑا ایڈمن اور روٹ کے اوپر روٹ، آبجیکٹ لاک کے باوجود، ڈیٹا کو حذف کر دیتا ہے۔ تعمیل کے معاملے میں، ہر چیز کو مضبوطی سے کیل دیا جاتا ہے اور کوئی بھی بیک اپ کو حذف نہیں کرسکتا ہے۔ یہاں تک کہ ایمیزون کے منتظمین (ان کے سرکاری بیانات کے مطابق)۔ یہ وہ موڈ ہے جس کی ہم حمایت کرتے ہیں۔
اور، ہمیشہ کی طرح، کچھ مفید لنکس:
- کے بارے میں ہر تفصیل میں.
- کے بارے میں تمام معلومات بہترین طریقے پر
- О تفصیل کے ساتھ
ماخذ: www.habr.com