ظرفيت جو درجو (يا جيئن اسان ان کي اندر سڏيندا آهيون Vim - captir) ويم بيڪ اپ ۽ نقل 9.5 اپڊيٽ 4 جي ڏينهن ۾ آرڪائيو ٽائر جي نالي هيٺ ظاهر ٿيو. ان جي پويان خيال اهو آهي ته اهو ممڪن بڻائڻ آهي ته بيڪ اپ کي منتقل ڪيو وڃي جيڪي نام نهاد آپريشنل بحالي ونڊو مان ڪڍيا ويا آهن اعتراض اسٽوريج ڏانهن. اهو انهن صارفين لاءِ ڊسڪ اسپيس کي صاف ڪرڻ ۾ مدد ڪئي جن وٽ ٿورو ئي هو. ۽ هي اختيار سڏيو ويو موڊ موڊ.
ھن سادي عمل کي انجام ڏيڻ لاءِ (جيئن اھو لڳي ٿو) ٻن شرطن کي پورو ڪرڻ لاءِ ڪافي آھي: منتقل ٿيل بيڪ اپ مان سڀئي پوائنٽون مٿي ڄاڻايل آپريشنل بحالي ونڊو جي حدن کان ٻاھر ھجن، جيڪو واضح طور تي UI ۾ مقرر ٿيل آھي. ۽ ٻيو: زنجير لازمي طور تي "سيل ٿيل فارم" ۾ هجڻ گهرجي (سيل ٿيل بيڪ اپ چين يا غير فعال بيڪ اپ چين). يعني هن سلسلي ۾ وقت گذرڻ سان ڪابه تبديلي نه ايندي آهي.
پر VBR v10 ۾، تصور کي نون ڪمن سان پورو ڪيو ويو - ڪاپي موڊ، سيل ٿيل موڊ ۽ ھڪڙي شيء سان گڏ ھڪڙو ڏکيو نالو جو نالو Imutability ظاهر ٿيو.
اهي دلچسپ شيون آهن جن بابت اسين اڄ ڳالهائينداسين. پهرين، ڪيئن ان VBR9.5u4 ۾ ڪم ڪيو، ۽ پوء ڏهين ورزن ۾ تبديلين جي باري ۾.
۽ پاڪ ٻولي جا چيمپيئن مون کي معاف ڪن، پر اهڙا ڪيترائي اصطلاح آهن جن جو ترجمو نٿو ڪري سگهجي.
تنهن ڪري هتي اينگليزم جو هڪ ٽين هوندو.
۽ گھڻا GIFs.
۽ تصويرون.
- بغير ڪنهن افسوس جي. مضمون جو مصنف.
جيئن هو
خير، اچو ته تجزيي سان شروع ڪريون آپريشنل بحالي ونڊو ۽ سيل ٿيل بيڪ اپ (يا جيئن اهي غير فعال بيڪ اپ زنجير دستاويزن ۾ سڏيو وڃي ٿو). انهن جي سمجھ کان سواء، وڌيڪ وضاحت ممڪن نه ٿيندو.
جيئن اسان تصوير ۾ ڏسون ٿا، اسان وٽ ڊيٽا بلاڪ سان گڏ هڪ قسم جو بيڪ اپ زنجير آهي، جيڪو مخزن جي پرفارمنس ٽائر SOBR تي واقع آهي جنهن سان ظرفيت ٽائر ڳنڍيل آهي. اسان جي آپريشنل بيڪ اپ ونڊو ٽي ڏينهن آهي.
ان مطابق، سومر تي ٺاهيل .vbk اڳئين زنجير کي سيل ڪري ٿو، جنهن جي ونڊو ٽن ڏينهن تائين مقرر ڪئي وئي آهي. ۽ انهي جو مطلب آهي ته توهان محفوظ طور تي انهن ٽن ڏينهن کان پراڻي هر شي کي شوٽنگ جي حد تائين منتقل ڪرڻ شروع ڪري سگهو ٿا.
پر ڇا واقعي هڪ مهربند زنجير جو مطلب هو ۽ اپڊيٽ 4 ۾ ظرفيت جي شوٽنگ جي حد تائين ڇا موڪلي سگهجي ٿو؟
اڳتي وڌڻ لاءِ، زنجير کي سيل ڪرڻ جي نشاني هڪ نئين مڪمل بيڪ اپ جي پيدائش آهي. ۽ اهو مسئلو ناهي ته هي مڪمل بيڪ اپ ڪيئن حاصل ڪيو وڃي: ٻئي مصنوعي مڪمل ۽ فعال مڪمل بيڪ اپ سمجهيا وڃن ٿا.
ريورس جي صورت ۾، اهي سڀئي فائلون آهن جيڪي آپريٽنگ ونڊو ۾ نه اينديون آهن.
رول بيڪ سان اڳتي وڌڻ جي صورت ۾، اهي سڀئي رول بيڪ آهن ۽ .vbk، جيڪڏهن ڪارڪردگي جي حد تي ٻيو .vbk آهي.
هاڻي اچو ته ڪم ڪرڻ جي اختيار تي غور ڪريو بيڪ اپ ڪاپي زنجيرن سان. صرف GFS برقرار رکڻ جي تحت هيٺيون شيون هتي منتقل ڪيون ويون آهن. ڇاڪاڻ ته سڀ ڪجهه محفوظ ٿيل وڌيڪ تازو بيڪ اپ ڪاپي زنجيرن ۾ هڪ طريقو يا ٻئي ۾ تبديل ٿي سگهي ٿو.
هاڻي اچو ته هود هيٺ ڏسو. اتي، هڪ عمل جنهن کي ڊيهائيڊريشن سڏيو ويندو آهي - ان حد تائين خالي بيڪ اپ فائلن کي ڇڏڻ ۽ انهن فائلن مان بلاڪ کي ڇڪڻ جي گنجائش واري حد تائين. هن عمل کي بهتر ڪرڻ لاء، نام نهاد ڊيهائيڊريشن انڊيڪس استعمال ڪيو ويو آهي، جيڪو توهان کي بلاڪ جي نقل ڪرڻ کان بچڻ جي اجازت ڏئي ٿو جيڪي اڳ ۾ ئي ظرفيت جي شوٽنگ جي حد تائين نقل ڪيا ويا آهن.
اچو ته ڏسون ته هي ڇا نظر اچي ٿو مثال سان: اچو ته چئون ته اسان وٽ هڪ .vbk آهي جيڪو ٽرانزيڪشن ونڊو مان نڪرندو آهي ۽ سيل ٿيل زنجير سان تعلق رکي ٿو. هن جو مطلب اهو آهي ته اسان وٽ هر حق آهي ته ان کي گنجائش جي شوٽنگ جي حد تائين منتقل ڪرڻ لاء. منتقل ٿيڻ جي وقت، هڪ ميٽا ڊيٽا فائل ٺاهي وئي آهي ظرفيت ڊيش ۽ منتقل ٿيل فائل جي بلاڪ ۾. لنڪ-سطح ميٽا ڊيٽا فائل بيان ڪري ٿي ته اسان جي فائل ۾ ڪهڙي بلاڪ شامل آهن. تصوير جي صورت ۾، اسان جي پهرين فائل بلاڪن تي مشتمل آهي a، b، c ۽ ميٽا ڊيٽا انهن بلاڪن جي لنڪ تي مشتمل آهي. جڏهن اسان وٽ هڪ سيڪنڊ .vbk فائل آهي، منتقل ڪرڻ لاء تيار آهي ۽ بلاڪ a، b ۽ d تي مشتمل آهي، اسان، ڊيهائيڊريشن انڊيڪس جو تجزيو ڪندي، سمجھندا آهيون ته صرف بلاڪ ڊي کي منتقل ڪرڻ جي ضرورت آهي. ۽ ان جي ميٽا ڊيٽا فائل ۾ ٻه پوئين بلاڪ ۽ هڪ نئين جي لنڪ شامل هوندي.
ان جي مطابق، انهن خالي هنڌن کي واپس ڊيٽا سان ڀرڻ جي عمل کي ريهائيڊريشن سڏيو ويندو آهي. اهو اڳ ۾ ئي استعمال ڪري ٿو پنهنجي ريهائيڊريشن انڊيڪس، مقامي ڪارڪردگي جي حد تي پراڻي .vbk فائل جي بنياد تي. اهو آهي، جيڪڏهن صارف ظرفيت جي شوٽنگ رينج مان هڪ فائل واپس ڪرڻ چاهي ٿو، اسان پهريان سڀ کان پراڻي مڪمل بيڪ اپ جي بلاڪ جي انڊيڪس ٺاهيندا آهيون ۽ صرف گم ٿيل بلاڪ کي گنجائش جي شوٽنگ گيلري مان منتقل ڪندا آهيون. تصوير ۾ پيش ڪيل صورت ۾، ريهائيڊريشن انڊيڪس جي مطابق FullBackup1.vbk کي ريهائيڊريٽ ڪرڻ لاءِ، اسان کي صرف بلاڪ سي جي ضرورت آهي، جيڪا اسان ظرفيت جي شوٽنگ جي حد مان وٺون ٿا. جيڪڏهن هڪ اسٽوريج ڪلائوڊ شئي ڪم ڪري ٿي ظرفيت جي شوٽنگ رينج جي طور تي، اهو توهان کي وڏي مقدار ۾ پئسا بچائڻ جي اجازت ڏئي ٿو.
هتي اهو لڳي سگھي ٿو ته هي ٽيڪنالاجي هڪجهڙائي آهي جيڪا WAN Accelerators ۾ استعمال ڪئي وئي آهي، پر اهو صرف ايترو ئي لڳي ٿو. تيز رفتار ۾، نقل ڪرڻ عالمي آهي؛ هتي، مقامي ڊيپليڪيشن استعمال ڪيو ويندو آهي هر فائل اندر هڪ مخصوص آفسيٽ تي. اهو حل ٿيڻ واري ڪم ۾ فرق جي ڪري ٿئي ٿو: هتي اسان کي وڏين مڪمل بيڪ اپ فائلن کي نقل ڪرڻ جي ضرورت آهي، ۽ اسان جي تحقيق جي مطابق، جيتوڻيڪ انهن جي وچ ۾ هڪ ڊگهو وقت گذري ٿو، هي ڊيپليڪيشن الگورتھم بهترين نتيجو ڏئي ٿو.
پر انڊيڪس جي ديوتا لاء وڌيڪ انڊيڪس! ڊيٽا جي وصولي لاء هڪ انڊيڪس پڻ آهي! جڏهن اسان ظرفيت واري ڊيش ۾ واقع هڪ مشين کي بحال ڪرڻ شروع ڪندا آهيون، اسان صرف منفرد ڊيٽا بلاڪ پڙهي سگهنداسين جيڪي ڪارڪردگي ڊيش ۾ نه آهن.
اهو ڪيئن ٿيو؟
اهو سڀ ڪجهه تعارفي حصي لاءِ آهي. اهو ڪافي تفصيلي آهي، پر جيئن مٿي ذڪر ڪيو ويو آهي، انهن تفصيلن کان سواء اهو ممڪن نه ٿيندو ته اهو بيان ڪرڻ ممڪن آهي ته نوان ڪم ڪيئن ڪم ڪن. تنهن ڪري، وڌيڪ اشتهارن کان سواء، اچو ته پهرين ڏانهن وڃو.
ڪاپي موڊ
اهو گهڻو ڪري موجوده ٽيڪنالاجيز تي ٻڌل آهي، پر استعمال جي مڪمل طور تي مختلف منطق آهي.
هن موڊ جو مقصد اهو يقيني بڻائڻ آهي ته مقامي حد تي واقع سڀني ڊيٽا کي ظرفيت واري ڊيش ۾ ڪاپي آهي.
جيڪڏھن توھان موازنہ ڪريو موو ۽ ڪاپي موڊس ھيڊ آن، اھو ھن طرح نظر ايندو:
- صرف سيل ٿيل زنجير کي منتقل ڪري سگهجي ٿو. ڪاپي موڊ جي صورت ۾، بلڪل سڀڪنھن شيء کي منتقل ڪيو ويو آهي، قطع نظر ته بيڪ اپ نوڪري ۾ ڇا ٿئي.
- حرڪت تڏهن ٿيندي آهي جڏهن فائلون آپريشنل بيڪ اپ ونڊو جي حدن کان ٻاهر نڪري وينديون آهن، ۽ ڪاپي ڪرڻ شروع ٿيندي آهي جيئن ئي بيڪ اپ فائل ظاهر ٿئي ٿي.
- نقل ڪرڻ لاء نئين ڊيٽا جي نگراني مسلسل ٿيندي آهي، ۽ ان کي منتقل ڪرڻ لاء هر 4 ڪلاڪن ۾ هڪ ڀيرو شروع ڪيو ويو آهي.
نئين موڊ تي غور ڪندي، مان سمجهان ٿو ته سادي مثالن کان پيچيده نمونن ڏانهن.
سڀ کان عام صورت ۾، اسان وٽ صرف واڌايون سان نيون فائلون آهن، ۽ اسان صرف انهن کي نقل ڪريون ٿا ظرفيت جي شوٽنگ جي حد تائين. ان کان سواءِ ته ڪهڙي موڊ کي بيڪ اپ نوڪري ۾ استعمال ڪيو ويو آهي، قطع نظر ته اهو سلسلو جي سيل ٿيل حصي سان تعلق رکي ٿو يا نه، قطع نظر ته اسان جي آپريٽنگ ونڊو ختم ٿي وئي آهي. انهن صرف ان کي ورتو ۽ ان کي نقل ڪيو.
ان جي پويان عمل اڃا به dehydration آهي جيئن مٿي بيان ڪيو ويو آهي. ڪاپي موڊ ۾، اهو پڻ يقيني بڻائي ٿو ته اسان بلاڪ کي نقل نه ڪندا آهيون جيڪي اڳ ۾ ئي اسان جي اسٽوريج تي آهن. فرق صرف اهو آهي ته جيڪڏهن مووي موڊ ۾ اسان حقيقي فائلن کي ڊمي فائلن سان تبديل ڪيو، هتي اسان انهن کي ڪنهن به طريقي سان هٿ نه ٿا ڪريون ۽ هر شيء کي ڇڏي ڏيو. ٻي صورت ۾، اهو بلڪل ساڳيو dehydration انڊيڪس آهي، جيڪو احتياط سان توهان جي پئسا ۽ وقت بچائڻ جي ڪوشش ڪري ٿو.
سوال پيدا ٿئي ٿو - جيڪڏهن توهان UI تي نظر اچن ٿا، اتي هڪ ئي وقت ٻنهي اختيارن کي چونڊڻ جو موقعو آهي. اهڙو گڏيل موڊ ڪيئن ڪم ڪندو؟
جي ان کي منهن ڏي.
شروعات معياري آهي: هڪ بيڪ اپ فائل ٺاهي وئي آهي ۽ فوري طور تي نقل ڪئي وئي آهي. ان ۾ واڌارو پيدا ڪيو ويو آهي ۽ نقل پڻ ڪيو ويو آهي. اهو ان وقت تائين ٿيندو آهي جڏهن اسان محسوس ڪندا آهيون ته فائلون اسان جي آپريٽنگ ونڊو ڇڏي چڪيون آهن ۽ هڪ سيل ٿيل زنجير ظاهر ٿيو آهي. هن نقطي تي اسان هڪ dehydration آپريشن انجام ڏيون ٿا ۽ انهن فائلن کي ڊمي فائلن سان تبديل ڪريو. يقينا، اسان ٻيهر ڪا به نقل نه ڪندا آهيون ظرفيت جي شوٽنگ جي حد تائين.
هي تمام دلچسپ منطق انٽرفيس ۾ صرف هڪ چيڪ بڪس لاءِ ذميوار آهي: بيڪ اپ کي نقل ڪريو اعتراض اسٽوريج تي جيئن ئي اهي ٺاهيا وڃن.
اسان کي هن ڪاپي موڊ جي ضرورت ڇو آهي؟
اهو اڃا به بهتر آهي ته هن سوال کي ٻيهر بيان ڪيو وڃي: اسان ان جي مدد سان ڪهڙن خطرن کان محفوظ آهيون؟ ڪهڙو مسئلو اسان کي حل ڪرڻ ۾ مدد ڪري ٿو؟
جواب پڌرو آهي: يقينا، هي ڊيٽا واپس آڻڻ آهي. جيڪڏهن اسان وٽ آهي مقامي ڊيٽا جي مڪمل ڪاپي آبجیکٹ اسٽوريج تي، پوءِ ڪابه پرواهه ناهي ته اسان جي پراڊڪٽ کي ڇا ٿئي، اسان هميشه شرطي Amazon ۾ موجود فائلن مان ڊيٽا بحال ڪري سگهون ٿا.
تنهن ڪري اچو ته ممڪن منظرنامن جي ذريعي وڃو، آسان کان وڌيڪ پيچيده تائين.
آسان ترين بدقسمتي جيڪا اسان جي سر تي ڪري سگهي ٿي بيڪ اپ زنجير ۾ فائلن مان هڪ جي رسائي آهي.
هڪ افسوسناڪ ڪهاڻي اها آهي ته اسان جي SOBR مخزن جي حدن مان هڪ ڀڄي ويو.
اهو اڃا به وڌيڪ خراب ٿئي ٿو جڏهن سمورو SOBR مخزن ناقابل رسائي بڻجي ويو آهي، پر گنجائش جي شوٽنگ جي حد ڪم ڪري رهي آهي.
۽ سڀ ڪجهه واقعي خراب آهي - اهو آهي جڏهن بيڪ اپ سرور مري وڃي ٿو ۽ توهان جي پهرين خواهش آهي ته ڏهن منٽن ۾ ڪئناڊا جي سرحد ڏانهن هلڻ جي ڪوشش ڪريو.
هاڻي اچو ته هر صورتحال کي الڳ الڳ ڏسو.
جڏهن اسان هڪ وڃائي ڇڏيو آهي (۽ اڃا به ڪيترائي) بيڪ اپ فائلون، پوء اسان کي صرف ڪرڻ جي ضرورت آهي مخزن جي ريسڪان عمل کي شروع ڪرڻ، ۽ گم ٿيل فائل کي ڊمي فائل سان تبديل ڪيو ويندو. ۽ ريهائيڊريشن جي عمل کي استعمال ڪندي (جيڪو مضمون جي شروعات ۾ بحث ڪيو ويو)، صارف ڊيٽا کي ڊائون لوڊ ڪرڻ جي قابل هوندو ظرفيت جي شوٽنگ جي حد کان مقامي اسٽوريج تائين.
هاڻي صورتحال وڌيڪ پيچيده آهي. اچو ته فرض ڪريون ته اسان جو SOBR پرفارمنس موڊ ۾ هلندڙ ٻن حدن تي مشتمل آهي، جنهن جو مطلب اهو آهي ته اسان جي .vbk ۽ .vib انهن جي مٿان هڪ اڻ برابري پرت ۾ پکڙيل آهن. ۽ وقت ۾ ڪجهه نقطي، حدن مان هڪ دستياب نه ٿي سگهي ٿي، ۽ صارف کي فوري طور تي مشين کي بحال ڪرڻ جي ضرورت آهي، جنهن جي ڊيٽا جو حصو هن حد تائين صحيح آهي.
صارف وصولي وزرڊ کي لانچ ڪري ٿو، ان نقطي کي منتخب ڪري ٿو جنهن کي هو بحال ڪرڻ چاهي ٿو، ۽ جادوگر، ڪم ڪرڻ دوران، اهو محسوس ڪري ٿو ته هن وٽ مقامي طور تي وصولي لاءِ گهربل سمورو ڊيٽا موجود نه آهي ۽ ان ڪري ظرفيت جي شوٽنگ مان ڊائون لوڊ ڪرڻ جي ضرورت آهي. گيلري ساڳئي وقت، بلاڪ جيڪي مقامي اسٽوريج تي رهندا آهن اهي بادل مان ڊائون لوڊ نه ڪيا ويندا. بحالي واري انڊيڪس کي پاڪائي (ها، اهو پڻ آرٽيڪل جي شروعات ۾ ذڪر ڪيو ويو آهي).
هن ڪيس جو هڪ ذيلي قسم اهو آهي ته سمورو SOBR مخزن ناقابل رسائي بڻجي ويو. انهي حالت ۾، اسان وٽ مقامي اسٽوريج مان نقل ڪرڻ لاء ڪجھ به ناهي، ۽ سڀئي بلاڪ بادل تان ڊائون لوڊ ڪيا ويا آهن.
۽ سڀ کان وڌيڪ دلچسپ صورتحال اها آهي ته بيڪ اپ سرور مري ويو. هتي ٻه آپشن آهن: منتظم عظيم آهي ۽ ٺاهيل ڪنفيگريشن بيڪ اپ، ۽ منتظم پاڻ هڪ بڇڙو Pinocchio آهي ۽ ڪنفيگريشن بيڪ اپ نه ڪيو آهي.
پهرين صورت ۾، هن لاء ڪافي ٿيندو ته صرف VBR جي صاف تنصيب کي ترتيب ڏيو ۽ معياري ذريعن کي استعمال ڪندي بيڪ اپ مان ان جي ڊيٽابيس کي بحال ڪريو. هن عمل جي آخر ۾، سڀڪنھن شيء کي معمول ڏانهن موٽندو. يا اهو مٿي ڏنل منظرنامن مان هڪ جي مطابق بحال ڪيو ويندو.
پر جيڪڏهن منتظم يا ته ان جو پنهنجو دشمن آهي، يا ان جي جوڙجڪ جو بيڪ اپ به هڪ مهاڀاري ناڪامي جو شڪار ٿيو ته پوءِ هتي به کيس قسمت جي رحم ڪرم تي نه ڇڏينداسين. هن معاملي لاء، اسان هڪ نئون طريقو متعارف ڪرايو آهي جنهن کي Import Object Storage سڏيو ويندو آهي. اهو توهان کي دستي طور تي SOBR مخزن کي ٻيهر ٺاهڻ جي عمل کي ڇڏڻ جي اجازت ڏئي ٿو ۽ ان سان گڏ هڪ گنجائش جي شوٽنگ رينج کي بعد ۾ ريسڪان سان ڳنڍيو، ۽ صرف هڪ اسٽوريج اعتراض شامل ڪريو Vim انٽرفيس ۾ ۽ درآمد اسٽوريج ريپوزٽري پروسيس کي هلائڻ. صرف هڪ شيء جيڪا توهان جي ۽ توهان جي بيڪ اپ جي وچ ۾ بيٺو ٿي سگهي ٿي هڪ پاسورڊ داخل ڪرڻ جي درخواست آهي جيڪڏهن توهان جا بيڪ اپ انڪوڊ ٿيل هئا.
اهو شايد سڀ ڪجهه ڪاپي موڊ جي باري ۾ آهي ۽ اسان اڳتي وڌون ٿا
مهربند موڊ
بنيادي خيال اهو آهي ته نون بيڪ اپ ظاهر نه ٿي سگھن ٿيون منتخب ٿيل SOBR حد تائين مخزن جي. v10 کان اڳ، اسان وٽ صرف سار سنڀال جو طريقو هو، جڏهن مخزن سان ڪو به ڪم مڪمل طور تي ممنوع هو. اسٽوريج کي بند ڪرڻ لاءِ هڪ قسم جو هارڊڪور موڊ، جتي صرف Evacuate بٽڻ موجود آهي، جيڪو هڪ دفعي ٻئي حد تائين بيڪ اپ منتقل ڪري ٿو.
۽ مهربند موڊ هڪ قسم جو "نرم" اختيار آهي: اسان نئين بيڪ اپ ٺاهڻ کان منع ڪريون ٿا ۽ آهستي آهستي ختم ڪريون ٿا پراڻين کي منتخب ٿيل برقرار رکڻ جي مطابق، پر عمل ۾ اسان ذخيرو ٿيل پوائنٽن مان بحال ڪرڻ جي صلاحيت نه وڃايو. هڪ تمام مفيد شيءِ جڏهن اسان وٽ يا ته هارڊويئر جو هڪ ٽڪرو ان جي زندگيءَ جي پڄاڻيءَ جي ويجهو آهي ۽ ان کي تبديل ڪرڻ جي ضرورت آهي، يا اسان کي صرف ان کي وڌيڪ اهم شيءِ لاءِ آزاد ڪرڻ جي ضرورت آهي، پر ان کي کڻڻ ۽ هر شيءِ کي هڪ ئي وقت منتقل ڪرڻ لاءِ ڪٿي به ناهي. يا ان کي ختم نٿو ڪري سگهجي.
انهي جي مطابق، آپريشن جو اصول بلڪل سادو آهي: اهو ضروري آهي ته سڀني لکڻين جي عملن کي منع ڪرڻ (نئين ڊيٽا جي ظاهر)، پڙهڻ کي ڇڏي ڏيو (بحالي) ۽ حذف ڪريو (رکڻ).
ٻئي طريقن سان گڏ استعمال ڪري سگھجن ٿيون، پر ياد رکو ته سار سنڀال کي اعلي ترجيح ڏني وئي آھي.
مثال طور، هڪ SOBR تي غور ڪريو جنهن ۾ ٻه حدون شامل آهن. اچو ته فرض ڪريون ته پهرين چئن ڏينهن لاءِ اسان Forward Forever Incremental mode ۾ بيڪ اپ ٺاهيا، ۽ پوءِ حد کي سيل ڪيو. اهو ان حقيقت ڏانهن وٺي وڃي ٿو ته اسان ٻئي دستياب حد تي هڪ نئين فعال مڪمل ٺاهڻ جي شروعات ڪريون ٿا. جيڪڏهن اسان جي برقراري چار آهي، ته پوءِ جڏهن مهربند حد تي واقع سڄو سلسلو پنهنجي حدن کان ٻاهر نڪري وڃي ته صاف ضمير سان ختم ٿي وڃي.
اتي حالتون آهن جڏهن ختم ٿيڻ کان اڳ ٿيندي آهي. مثال طور، هي Forward incremental آهي دورانديشي پورين سان. جيڪڏهن اسان پهرين ٻن ڏينهن لاءِ مڪمل بيڪ اپ ٺاهيا، ۽ خميس تي اسان مخزن کي سيل ڪرڻ جو فيصلو ڪيو، ته جمعه تي، جڏهن هڪ نئون بيڪ اپ ٺاهيو ويندو، سومر جي فائل کي ختم ڪيو ويندو ڇاڪاڻ ته هن نقطي تي ڪو به انحصار نه آهي. ۽ نقطي پاڻ ڪنهن تي منحصر نه آهي. ان کان پوء اسان انتظار ڪندا آهيون جيستائين چار نقطا موجود حد تي ٺاهيا ويا آهن ۽ باقي ٽن کي ختم ڪري ڇڏيندا آهن، جيڪي هڪ ٻئي کان آزاديء سان ختم نه ٿي سگهن.
Reverse Incremental سان شيون آسان آھن. ان ۾، پراڻن پوائنٽون ڪنهن به شيء تي منحصر نه آهن ۽ محفوظ طور تي ختم ڪري سگھجن ٿيون. تنهن ڪري، جيئن ئي هڪ نئين حد تي نئين .vbk ٺاهي ويندي، پراڻي .vrbs هڪ هڪ ڪري ختم ٿي وينديون.
رستي ۾، اسان هر ڀيري هڪ نئون .vbk ڇو ٺاهيندا آهيون: جيڪڏهن اسان ان کي نه ٺاهيو آهي، پر واڌ جي پراڻي زنجير کي جاري رکون ٿا، ته پوء پراڻي .vbk ڪنهن به موڊ ۾ لامحدود ڊگهي وقت تائين منجمد ٿي ويندو، ان جي حذف ٿيڻ کي روڪيو. تنهن ڪري، اهو فيصلو ڪيو ويو ته جيترو جلدي حد تائين سيل ڪيو ويو آهي، اسان مفت حد تي مڪمل بيڪ اپ ٺاهيندا آهيون.
ظرفيت جي شوٽنگ جي حد سان شيون وڌيڪ پيچيده آهن.
اچو ته پهرين ڪاپي موڊ کي ڏسو. اچو ته فرض ڪريو ته اسان فعال طور تي چار ڏينهن تائين بيڪ اپ ٺاهي رهيا هئاسين، ۽ پوء گنجائش جي شوٽنگ جي حد کي سيل ڪيو ويو. اسان ڪجھ به حذف نه ڪندا آهيون، پر عاجزي سان برقرار رکون ٿا، جنهن کان پوء اسان ظرفيت جي شوٽنگ رينج مان ڊيٽا کي حذف ڪريون ٿا.
لڳ ڀڳ ساڳي شيءِ موو موڊ ۾ ٿئي ٿي - اسان ٻيهر ٽچ جو انتظار ڪريون ٿا، مقامي اسٽوريج ۾ پراڻي کي حذف ڪريو، ۽ اعتراض واري اسٽوريج ۾ ذخيرو ٿيل هڪ کي حذف ڪريو.
هميشه لاءِ اڳتي وڌڻ واري سان هڪ دلچسپ مثال. اسان ٽن پوائنٽن تي برقرار رکڻ کي نصب ڪيو ۽ سومر تي بيڪ اپ ٺاهڻ شروع ڪيو، جيڪي باقاعدي طور تي بادل ڏانهن نقل ڪيا ويا آهن. اسٽوريج کي سيل ڪرڻ کان پوء، بيڪ اپ ٺاهيا ويندا آهن، ٽن پوائنٽن کي برقرار رکندي، پر ظرفيت واري ڊيش ۾ محفوظ ڪيل ڊيٽا انحصار رهي ٿي ۽ ختم نه ٿي ڪري سگھجي. تنهن ڪري، اسان خميس تائين انتظار ڪندا آهيون، جڏهن اسان جي .vbk برقرار رکڻ کان ٻاهر آهي، ۽ صرف پوء اسان آرام سان مڪمل محفوظ ڪيل زنجير کي حذف ڪريون ٿا.
۽ ھڪڙو ننڍڙو اعلان: سڀ مثال ھتي ھڪڙي مشين سان ڏيکاريا ويا آھن. جيڪڏهن توهان وٽ انهن مان ڪيترائي آهن توهان جي بيڪ اپ ۾، پوءِ انهن جي بحالي مختلف هوندي ان تي منحصر آهي ته ڇا Active Full ڪيو ويو يا نه.
بنيادي طور تي اهو سڀ ڪجهه آهي. تنهن ڪري اچو ته سڀ کان وڌيڪ سخت خصوصيت ڏانهن وڃو -
بي نظير
جيئن ته پوئين پوائنٽن سان، پهرين شيء اها آهي ته هي فنڪشن ڪهڙو مسئلو حل ڪري ٿو. جيئن ئي اسان اپلوڊ ڪندا آهيون اسان جا بيڪ اپ ڪنهن جاءِ تي اسٽوريج لاءِ، اتي هڪ مضبوط خواهش هوندي آهي ته انهن جي حفاظت جي ضمانت ڏني وڃي، يعني جسماني طور تي انهن کي حذف ڪرڻ ۽ ڪنهن به تبديليءَ کي روڪڻ لاءِ. منتظمين سميت، انهن جي روٽ اڪائونٽن جي تحت. هي توهان کي انهن کي حادثاتي يا ارادي نقصان کان بچائڻ جي اجازت ڏئي ٿو. ڪو به ماڻهو جيڪو AWS سان ڪم ڪري ٿو شايد هڪ اهڙي خاصيت ۾ آيو هجي جنهن کي Object Lock سڏيو ويندو آهي.
ھاڻي اچو ته موڊ کي عام اصطلاحن ۾ ڏسو، ۽ پوءِ تفصيل سان غور ڪريو. اسان جي مثال ۾، اسان جي ظرفيت جي شوٽنگ جي حد تائين چار ڏينهن جي برقرار رکڻ سان Imutability کي فعال ڪيو ويندو. ۽ ڪاپي موڊ کي بيڪ اپ ۾ فعال ڪيو ويو آهي.
عدم استحڪام ڪنهن به طريقي سان عام برقرار رکڻ سان رابطو نٿو ڪري. مثال طور، اهو اضافي پوائنٽن يا انهي وانگر ڪجهه شامل نٿو ڪري. اهو صرف اهو آهي ته هڪ شخص چار ڏينهن اندر بيڪ اپ فائلن کي ختم نٿو ڪري سگهي. جيڪڏهن توهان سومر تي بيڪ اپ ٺاهيو ٿا، توهان صرف جمعه تي ان جي فائل کي حذف ڪرڻ جي قابل هوندا.
ڊيهائيڊريشن، انڊيڪسس ۽ ميٽاڊيٽا جا سڀ اڳ بيان ڪيل تصور ساڳيا ڪم ڪندا رهن ٿا. پر ھڪڙي شرط سان - بلاڪ نه رڳو ڊيٽا لاء، پر ميٽاداٽ لاء پڻ مقرر ڪيو ويو آھي. اهو ان صورت ۾ ڪيو ويندو آهي جڏهن هڪ چالاڪ حملو ڪندڙ اسان جي ميٽا ڊيٽا ڊيٽابيس کي ختم ڪرڻ ۽ ڊيٽا بلاڪ کي بيڪار بائنري مچ ۾ تبديل ڪرڻ کان روڪڻ جو فيصلو ڪري ٿو.
هاڻي اسان جي بلاڪ نسل ٽيڪنالاجي جي وضاحت ڪرڻ لاء هڪ بهترين وقت آهي. يا بلاڪ نسل. هن کي ڪرڻ لاء، ان صورتحال تي غور ڪريو جيڪو ان جي ظاهر ٿيڻ جو سبب بڻيو.
اچو ته ڇهن ڏينهن جو ٽائم اسڪيل وٺون ۽ هيٺ اسين بي ترتيبيت جي متوقع ختم ٿيڻ جي وقت کي نشانو بڻائينداسين. پهرين ڏينهن تي اسان هڪ فائل ٺاهي ۽ ٺاهيندا آهيون جنهن ۾ ڊيٽا بلاڪ اي ۽ ان جي ميٽا ڊيٽا شامل هوندي. جيڪڏهن عدم استحڪام کي ٽن ڏينهن تائين مقرر ڪيو ويو آهي، اهو منطقي طور تي فرض آهي ته چوٿين ڏينهن تي ڊيٽا انلاڪ ۽ ختم ٿي ويندي. ٻئي ڏينهن تي اسان هڪ نئين فائل 2 شامل ڪنداسين، جنهن ۾ ساڳئي سيٽنگن سان بلاڪ بي شامل آهي. بلاڪ هڪ اڃا به چوٿين ڏينهن تي هٽائڻ جي ضرورت آهي. پر ٽئين ڏينهن تي ڪجهه خوفناڪ ٿئي ٿو - هڪ فائل 3 فائل ٺاهي وئي آهي، جنهن ۾ هڪ نئين بلاڪ ڊي ۽ پراڻي بلاڪ اي جي لنڪ شامل آهي. هن جو مطلب آهي ته هڪ بلاڪ ۽ ان جي immutability پرچم لاء هڪ نئين تاريخ، جنهن ڇهين ڏينهن ڏانهن منتقل ڪيو وڃي ٿو ري سيٽ ڪيو وڃي. ۽ هتي هڪ مسئلو پيدا ٿئي ٿو - حقيقي بيڪ اپ ۾ اهڙا ڪيترائي بلاڪ آهن. ۽ انهن جي غير مستحڪم مدت کي وڌائڻ لاء، توهان کي هر وقت درخواستن جي وڏي تعداد ٺاهڻ جي ضرورت آهي. ۽ حقيقت ۾، اهو هڪ لڳ ڀڳ لامحدود روزاني عمل هوندو، ڇاڪاڻ ته هڪ اعلي درجي جي امڪان سان اسان کي هر هڪ ڪاپي سان ٺهڪندڙ بلاڪ جا وڏا اسٽيڪ ملندا. اعتراض اسٽوريج فراهم ڪندڙن کان وڏي تعداد ۾ درخواستن جو ڇا مطلب آهي؟ ساڄو! مهيني جي آخر ۾ وڏو بل.
۽ انهي لاءِ ته نيري کان ٻاهر نه نڪرڻ لاءِ توهان جي پسنديده گراهڪن کي ڪافي پئسن لاءِ ، بلاڪ نسل جو ميڪانيزم ايجاد ڪيو ويو. هي هڪ اضافي عرصو آهي جنهن کي اسان مقرر ٿيل غير متحرڪ مدت ۾ شامل ڪندا آهيون. هيٺ ڏنل مثال ۾، هي عرصو ٻه ڏينهن آهي. پر هي صرف هڪ مثال آهي. حقيقت ۾، اهي پنهنجو فارمولا استعمال ڪندا آهن، جيڪو هڪ مهيني تالا دوران لڳ ڀڳ ڏهه اضافي ڏينهن ڏئي ٿو.
اچو ته ساڳئي صورتحال تي غور ڪرڻ جاري رکون، پر بلاڪ نسل سان. پهرين ڏينهن تي اسان ٺاهيندا آهيون فائل 1 بلاڪ اي ۽ ميٽا ڊيٽا مان. اسان نسل جي مدت ۽ غير موثريت کي وڌايو - هن جو مطلب آهي ته فائل کي ختم ڪرڻ جو موقعو ڇهين ڏينهن تي هوندو. جيڪڏهن ٻئي ڏينهن تي اسان ٺاهيندا آهيون File2، جنهن ۾ بلاڪ بي ۽ بلاڪ الف کي هڪ لنڪ شامل آهي، پوءِ ختم ٿيڻ جي متوقع تاريخ تائين ڪجهه به نه ٿيندو. هوءَ بيٺي هئي جيئن هوءَ ڇهين ڏينهن ڪئي هئي. ۽ اهڙيء طرح اسان درخواستن جي تعداد تي پئسا بچائڻ جي ڪوشش ڪري رهيا آهيون. صرف اها صورتحال آهي جڏهن آخري وقت کي منتقل ڪري سگهجي ٿو جيڪڏهن نسل جي مدت ختم ٿي وئي آهي. اهو آهي، جيڪڏهن ٽئين ڏينهن تي نئين فائل 3 ۾ هڪ لنڪ شامل آهي بلاڪ اي، پوء نسل 2 شامل ڪيو ويندو ڇاڪاڻ ته Gen1 اڳ ۾ ئي ختم ٿي چڪو آهي. ۽ بلاڪ اي کي حذف ڪرڻ جي متوقع تاريخ اٺين ڏينهن تي شفٽ ٿيندي. هي اسان کي اجازت ڏئي ٿو ڊرامائي طور تي درخواستن جي تعداد کي گهٽائڻ لاءِ ڊبل ٿيل بلاڪ جي زندگي کي وڌائڻ لاءِ، جيڪو گراهڪن کي هڪ ٽين پيسا بچائي ٿو.
ٽيڪنالاجي خود S3 ۽ S3-مطابقت رکندڙ هارڊويئر جي استعمال ڪندڙن لاءِ دستياب آهي، جن جي ٺاهيندڙن جي ضمانت آهي ته انهن تي عمل درآمد Amazon کان مختلف ناهي. تنهن ڪري جائز سوال جو جواب ڇو Azure سپورٽ نه ڪيو ويو آهي - انهن وٽ هڪ جهڙي خاصيت آهي، پر اهو ڪنٽينرز جي سطح تي ڪم ڪري ٿو، انفرادي شيون نه. رستي جي ذريعي، Amazon پاڻ کي ٻن طريقن ۾ اعتراض لاڪ ڪيو آهي: تعميل ۽ حڪمراني. ٻي صورت ۾، اهو امڪان رهي ٿو ته سڀ کان وڏو منتظم منتظم جي مٿان ۽ روٽ مٿان روٽ، اعتراض جي تالا جي باوجود، اڃا به ڊيٽا کي حذف ڪري ٿو. تعميل جي صورت ۾، سڀڪنھن شيء کي مضبوطيء سان nailed آهي ۽ ڪو به بيڪ اپ کي حذف ڪري سگهو ٿا. جيتوڻيڪ Amazon منتظمين (انهن جي سرڪاري بيانن جي مطابق). هي اهو طريقو آهي جنهن کي اسان سپورٽ ڪندا آهيون.
۽، هميشه وانگر، ڪجهه مفيد لنڪس:
- تي هر تفصيل ۾.
- جي باري ۾ سڀ معلومات ان جي بهترين تي
- О تفصيل ۾
جو ذريعو: www.habr.com