ظهرت طبقة السعة (أو كما نسميها داخل Vim - captir) في أيام Veeam Backup and Replication 9.5 Update 4 تحت اسم Archive Tier. الفكرة وراء ذلك هي تمكين نقل النسخ الاحتياطية التي سقطت من نافذة الاستعادة التشغيلية المزعومة إلى مخزن الكائنات. وقد ساعد هذا في توفير مساحة على القرص للمستخدمين الذين لم يكن لديهم سوى القليل منها. وكان هذا الخيار يسمى وضع النقل.
لتنفيذ هذا الإجراء البسيط (كما يبدو)، كان يكفي تلبية شرطين: يجب أن تكون جميع النقاط من النسخة الاحتياطية المنقولة خارج حدود نافذة الاستعادة التشغيلية المذكورة أعلاه، والتي تم تعيينها بشكل صريح في واجهة المستخدم. وثانياً: يجب أن تكون السلسلة في ما يسمى "بالشكل المختوم" (سلسلة احتياطية مختومة أو سلسلة احتياطية غير نشطة). أي أنه لا تحدث أي تغييرات في هذه السلسلة مع مرور الوقت.
ولكن في VBR v10، تم استكمال المفهوم بوظائف جديدة - ظهر وضع النسخ والوضع المختوم وشيء يحمل اسمًا يصعب نطقه عدم القابلية للتغيير.
هذه هي الأشياء الرائعة التي سنتحدث عنها اليوم. أولاً، حول كيفية عمله في VBR9.5u4، ثم حول التغييرات في الإصدار العاشر.
وليعذرني أبطال اللغة النقية، لكن هناك الكثير من المصطلحات التي لا يمكن ترجمتها.
لذلك سيكون هناك الكثير من المفردات الإنجليزية هنا.
والكثير من الصور المتحركة.
والصور.
- دون أدنى ندم. مؤلف المقال.
كما كان
حسنًا، لنبدأ بتحليل نافذة الاستعادة التشغيلية والنسخ الاحتياطي المختوم (أو كما يطلق عليهما في وثائق سلسلة النسخ الاحتياطي غير النشطة). وبدون فهمهم، لن يكون من الممكن تقديم مزيد من التوضيح.
كما نرى في الصورة، لدينا نوع من سلسلة النسخ الاحتياطي مع كتل البيانات، والتي تقع على مستوى الأداء SOBR للمستودع الذي تتصل به طبقة السعة. نافذة النسخ الاحتياطي التشغيلي لدينا هي ثلاثة أيام.
وبناء على ذلك، فإن .vbk الذي تم إنشاؤه يوم الاثنين يختم السلسلة السابقة، والتي تم ضبط نافذتها على ثلاثة أيام. وهذا يعني أنه يمكنك البدء بأمان في نقل كل شيء أقدم من هذه الأيام الثلاثة إلى ميدان الرماية.
ولكن ما المقصود بالضبط بالسلسلة المختومة وما الذي يمكن إرساله إلى نطاق الرماية في التحديث 4؟
بالنسبة إلى Forward Incremental، علامة إغلاق السلسلة هي إنشاء نسخة احتياطية كاملة جديدة. ولا يهم كيفية الحصول على هذه النسخة الاحتياطية الكاملة: يتم أخذ النسخ الاحتياطية الاصطناعية الكاملة والنشطة في الاعتبار.
في حالة العكس، هذه كلها ملفات لا تقع في نافذة التشغيل.
في حالة الزيادة الأمامية مع التراجعات، تكون هذه كلها عمليات تراجع و.vbk، إذا كان هناك .vbk آخر في نطاق الأداء
الآن دعونا نفكر في خيار العمل مع سلاسل النسخ الاحتياطية. تم نقل العناصر التي تندرج تحت الاحتفاظ بـ GFS هنا فقط. لأن كل شيء مخزن في سلاسل النسخ الاحتياطية الأحدث يمكن تغييره بطريقة أو بأخرى.
الآن دعونا ننظر تحت غطاء محرك السيارة. هناك، تحدث عملية تسمى الجفاف - ترك ملفات النسخ الاحتياطي الفارغة على المدى وسحب الكتل من هذه الملفات إلى نطاق التصوير السعة. لتحسين هذه العملية، يتم استخدام ما يسمى بمؤشر الجفاف، والذي يسمح لك بتجنب نسخ الكتل التي تم نسخها بالفعل إلى نطاق الرماية بالقدرة.
دعونا نرى كيف يبدو هذا من خلال مثال: لنفترض أن لدينا ملف .vbk خرج من نافذة المعاملة وينتمي إلى سلسلة مختومة. وهذا يعني أن لدينا كل الحق في نقله إلى نطاق الرماية. في وقت النقل، يتم إنشاء ملف بيانات التعريف في لوحة السعة وكتل الملف المنقول. يصف ملف البيانات التعريفية على مستوى الارتباط العناصر التي يتكون منها ملفنا. في الحالة التي تظهر في الصورة، يتكون ملفنا الأول من الكتل a وb وc وتحتوي البيانات الوصفية على روابط لهذه الكتل. عندما يكون لدينا ملف .vbk ثانٍ، جاهز للنقل ويتكون من الكتل a وb وd، فإننا، عند تحليل مؤشر الجفاف، ندرك أن الكتلة d فقط هي التي يجب نقلها. وسيحتوي ملف البيانات الوصفية الخاص به على روابط إلى كتلتين سابقتين وواحدة جديدة.
وبناء على ذلك، فإن عملية ملء هذه المساحات الفارغة مرة أخرى بالبيانات تسمى إعادة التميؤ. فهو يستخدم بالفعل فهرس الإماهة الخاص به، استنادًا إلى أقدم ملف .vbk على نطاق الأداء المحلي. أي أنه إذا أراد المستخدم إرجاع ملف من نطاق التصوير بالسعة، فإننا نقوم أولاً بإنشاء فهرس للكتل الخاصة بأقدم نسخة احتياطية كاملة ونقل الكتل المفقودة فقط من معرض التصوير بالسعة. في الحالة المعروضة في الصورة، من أجل إعادة ترطيب FullBackup1.vbk وفقًا لمؤشر الإماهة، نحتاج فقط إلى الكتلة C، التي نأخذها من نطاق الرماية بالقدرة. إذا كان كائن سحابة التخزين بمثابة نطاق تصوير ذو سعة، فهذا يسمح لك بتوفير مبالغ هائلة من المال.
هنا قد يبدو أن هذه التقنية مطابقة لتلك المستخدمة في مسرعات WAN، ولكن يبدو الأمر كذلك. في المسرّعات، يكون إلغاء البيانات المكررة عامًا؛ وهنا، يتم استخدام إلغاء البيانات المكررة محليًا داخل كل ملف بإزاحة محددة. يحدث هذا بسبب الاختلاف في المهام التي يتم حلها: هنا نحتاج إلى نسخ ملفات نسخ احتياطي كاملة وكبيرة، ووفقًا لبحثنا، حتى لو مرت فترة زمنية طويلة بينهما، فإن خوارزمية إلغاء البيانات المكررة هذه تعطي أفضل نتيجة.
ولكن المزيد من الفهارس لإله الفهارس! هناك أيضًا فهرس لاستعادة البيانات! عندما نبدأ في استعادة جهاز موجود في لوحة السعة، سنقرأ فقط كتل البيانات الفريدة غير الموجودة في لوحة الأداء.
كيف اصبح
هذا كل شيء بالنسبة للجزء التمهيدي. إنها مفصلة تمامًا، ولكن كما ذكرنا أعلاه، بدون هذه التفاصيل لن يكون من الممكن شرح كيفية عمل الوظائف الجديدة. لذلك، دون مزيد من اللغط، دعونا ننتقل إلى الأول.
وضع النسخ
وهو يعتمد إلى حد كبير على التقنيات الحالية، ولكنه يحمل منطق استخدام مختلفًا تمامًا.
الغرض من هذا الوضع هو التأكد من أن جميع البيانات الموجودة على النطاق المحلي لها نسخة في لوحة السعة.
إذا قمت بمقارنة وضعي النقل والنسخ بشكل مباشر، فسوف يبدو الأمر كما يلي:
- يمكن فقط نقل السلسلة المختومة. في حالة وضع النسخ، يتم نقل كل شيء على الإطلاق، بغض النظر عما يحدث في مهمة النسخ الاحتياطي.
- يتم تشغيل النقل عندما تتجاوز الملفات حدود نافذة النسخ الاحتياطي التشغيلية، ويتم تشغيل النسخ بمجرد ظهور ملف النسخ الاحتياطي.
- تتم مراقبة البيانات الجديدة للنسخ باستمرار، ولنقلها يتم تشغيلها مرة واحدة كل 4 ساعات.
عند النظر في الوضع الجديد، أقترح الانتقال من الأمثلة البسيطة إلى الأمثلة المعقدة.
في الحالة الأكثر شيوعًا، لدينا ببساطة ملفات جديدة بزيادات، ونقوم ببساطة بنسخها إلى نطاق التصوير بالقدرة. بغض النظر عن الوضع المستخدم في مهمة النسخ الاحتياطي، وبغض النظر عما إذا كان ينتمي إلى الجزء المختوم من السلسلة أم لا، وبغض النظر عما إذا كانت نافذة التشغيل الخاصة بنا قد انتهت صلاحيتها. لقد أخذوها فقط ونسخوها.
العملية وراء ذلك لا تزال هي الجفاف كما هو موضح أعلاه. في وضع النسخ، يتأكد أيضًا من عدم نسخ الكتل الموجودة بالفعل على وحدة التخزين الخاصة بنا. والفرق الوحيد هو أنه إذا قمنا في وضع الفيلم باستبدال الملفات الحقيقية بملفات وهمية، فإننا هنا لا نلمسها بأي شكل من الأشكال ونترك كل شيء كما هو. بخلاف ذلك، فهو بالضبط نفس مؤشر الجفاف، الذي يحاول بعناية توفير أموالك ووقتك.
السؤال الذي يطرح نفسه - إذا نظرت إلى واجهة المستخدم، فمن الممكن تحديد كلا الخيارين في نفس الوقت. كيف سيعمل هذا الوضع المشترك؟
دعونا الصفقة.
البداية قياسية: يتم إنشاء ملف نسخة احتياطية ونسخه على الفور. يتم إنشاء زيادة عليه ونسخه أيضًا. يحدث هذا حتى اللحظة التي ندرك فيها أن الملفات قد غادرت نافذة التشغيل الخاصة بنا وظهرت سلسلة مختومة. في هذه المرحلة نقوم بإجراء عملية التجفيف واستبدال هذه الملفات بملفات وهمية. بالطبع، نحن لا ننسخ أي شيء مرة أخرى إلى نطاق الرماية.
كل هذا المنطق الرائع مسؤول عن مربع اختيار واحد فقط في الواجهة: نسخ النسخ الاحتياطية إلى وحدة تخزين الكائنات بمجرد إنشائها.
لماذا نحتاج إلى وضع النسخ هذا؟
ومن الأفضل إعادة صياغة السؤال بهذه الطريقة: ما هي المخاطر التي نحمي منها بمساعدتها؟ ما هي المشكلة التي تساعدنا على حلها؟
الجواب واضح: بالطبع، هذا هو استعادة البيانات. إذا كانت لدينا نسخة كاملة من البيانات المحلية على وحدة تخزين الكائنات، فبغض النظر عما يحدث لمنتجنا، يمكننا دائمًا استعادة البيانات من الملفات الموجودة في منطقة أمازون الشرطية.
لذلك دعونا نستعرض السيناريوهات المحتملة، من الأبسط إلى الأكثر تعقيدًا.
إن أبسط مصيبة يمكن أن تقع على رؤوسنا هي عدم إمكانية الوصول إلى أحد الملفات الموجودة في سلسلة النسخ الاحتياطي.
القصة الأكثر حزنًا هي أن أحد نطاقات مستودع SOBR الخاص بنا قد انكسر.
ويزداد الأمر سوءًا عندما يتعذر الوصول إلى مستودع SOBR بأكمله، لكن سعة نطاق الرماية تعمل.
وكل شيء سيء حقًا - وذلك عندما يموت خادم النسخ الاحتياطي وتكون رغبتك الأولى هي محاولة الركض إلى الحدود الكندية في عشر دقائق.
الآن دعونا نلقي نظرة على كل موقف على حدة.
عندما نفقد ملفًا واحدًا (أو حتى عدة) من ملفات النسخ الاحتياطي، فكل ما يتعين علينا فعله هو بدء عملية إعادة فحص المستودع، وسيتم استبدال الملف المفقود بملف وهمي. وباستخدام عملية إعادة التميؤ (التي تمت مناقشتها في بداية المقال)، سيتمكن المستخدم من تنزيل البيانات من سعة نطاق الرماية إلى التخزين المحلي.
الآن أصبح الوضع أكثر تعقيدا. لنفترض أن SOBR الخاص بنا يتكون من نطاقين يعملان في وضع الأداء، مما يعني أن .vbk و.vib منتشران فوقهما في طبقة غير متساوية إلى حد ما. وفي وقت ما، يصبح أحد النطاقات غير متاح، ويحتاج المستخدم بشكل عاجل إلى استعادة الجهاز، الذي يقع جزء من بياناته على وجه التحديد في هذا النطاق.
يقوم المستخدم بتشغيل معالج الاسترداد، ويحدد النقطة التي يريد الاستعادة إليها، ويدرك المعالج، أثناء العمل، أنه ليس لديه جميع البيانات اللازمة للاسترداد محليًا وبالتالي يحتاج إلى تنزيلها من القدرة على التصوير صالة عرض. وفي الوقت نفسه، لن يتم تنزيل الكتل المتبقية على وحدة التخزين المحلية من السحابة. المجد لمؤشر الاستعادة (نعم، تم ذكره أيضًا في بداية المقال).
أحد الأنواع الفرعية لهذه الحالة هو أن مستودع SOBR بأكمله أصبح غير قابل للوصول. في هذه الحالة، ليس لدينا ما ننسخه من وحدة التخزين المحلية، ويتم تنزيل جميع الكتل من السحابة.
والموقف الأكثر إثارة للاهتمام هو أن خادم النسخ الاحتياطي قد مات. هناك خياران هنا: المشرف رائع وقام بعمل نسخ احتياطية للتكوين، والمسؤول هو بينوكيو الشرير بنفسه ولم يقم بعمل نسخ احتياطية للتكوين.
في الحالة الأولى، سيكون كافيا له ببساطة نشر التثبيت النظيف لـ VBR في مكان ما واستعادة قاعدة البيانات الخاصة به من نسخة احتياطية باستخدام الوسائل القياسية. وفي نهاية هذه العملية، سيعود كل شيء إلى طبيعته. أو سيتم استعادته وفقًا لأحد السيناريوهات أعلاه.
ولكن إذا كان المسؤول إما عدوه، أو أن النسخة الاحتياطية للتكوين عانت أيضًا من فشل ذريع، فحتى هنا لن نتركه تحت رحمة القدر. في هذه الحالة، قمنا بتقديم إجراء جديد يسمى استيراد تخزين الكائنات. فهو يسمح لك بتخطي عملية إعادة إنشاء مستودع SOBR يدويًا وإرفاق نطاق التصوير بالسعة به مع إعادة المسح اللاحقة، وإضافة كائن تخزين ببساطة إلى واجهة Vim وتشغيل إجراء استيراد مستودع التخزين. الشيء الوحيد الذي يمكن أن يقف في الطريق بينك وبين النسخ الاحتياطية هو طلب إدخال كلمة مرور إذا كانت النسخ الاحتياطية الخاصة بك مشفرة.
ربما يكون هذا كل ما يتعلق بوضع النسخ وننتقل إليه
الوضع المختوم
الفكرة الرئيسية هي أن النسخ الاحتياطية الجديدة لا يمكن أن تظهر على نطاق SOBR المحدد للمستودع. قبل الإصدار 10، لم يكن لدينا سوى وضع الصيانة، عندما كان أي عمل مع المستودع محظورًا تمامًا. نوع من الوضع المتشدد لإيقاف تشغيل وحدة التخزين، حيث يتوفر زر الإخلاء فقط، والذي ينقل النسخ الاحتياطية إلى مدى آخر لمرة واحدة.
والوضع المختوم هو نوع من الخيار "الناعم": نحن نحظر إنشاء نسخ احتياطية جديدة ونحذف النسخ القديمة تدريجيًا وفقًا للاحتفاظ المحدد، ولكن في هذه العملية لا نفقد القدرة على الاستعادة من النقاط المخزنة. شيء مفيد للغاية عندما يكون لدينا قطعة من الأجهزة تقترب من نهاية عمرها الافتراضي وتحتاج إلى استبدالها، أو نحتاج فقط إلى تحريرها لشيء أكثر أهمية، ولكن لا يوجد مكان لأخذها ونقل كل شيء مرة واحدة. أو لا يمكن حذفه.
وفقا لذلك، فإن مبدأ التشغيل بسيط للغاية: من الضروري حظر جميع عمليات الكتابة (ظهور بيانات جديدة)، وترك القراءة (الاستعادة) والحذف (الاحتفاظ).
يمكن استخدام كلا الوضعين في وقت واحد، ولكن ضع في اعتبارك أن الصيانة لها أولوية أعلى.
على سبيل المثال، فكر في SOBR الذي يتكون من نطاقين. لنفترض أنه خلال الأيام الأربعة الأولى قمنا بإنشاء نسخ احتياطية في الوضع Forward Forever Incremental، ثم قمنا بإغلاق النطاق، وهذا يؤدي إلى حقيقة أننا بدأنا في إنشاء نسخة نشطة كاملة جديدة على النطاق الثاني المتاح. فإذا كان احتفاظنا أربعة، فمتى تجاوزت السلسلة الواقعة على المدى المختوم حدودها، حذفت بضمير مرتاح.
هناك حالات يحدث فيها الحذف مبكرًا. على سبيل المثال، يعد هذا تزايديًا للأمام مع عمليات ملء دورية. إذا قمنا بإنشاء نسخ احتياطية كاملة لليومين الأولين، وقررنا يوم الخميس إغلاق المستودع، ففي يوم الجمعة، عندما يتم إنشاء نسخة احتياطية جديدة، سيتم حذف ملف يوم الاثنين لأنه لا توجد تبعيات إلى هذه النقطة. والنقطة في حد ذاتها لا تعتمد على أحد. ثم ننتظر حتى يتم إنشاء أربع نقاط على المدى المتاح وحذف الثلاث المتبقية، والتي لا يمكن حذفها بشكل مستقل عن بعضها البعض.
الأمور أسهل مع التزايدي العكسي. فيه أقدم النقاط لا تعتمد على أي شيء ويمكن حذفها بأمان. لذلك، بمجرد إنشاء .vbk جديد على نطاق جديد، سيتم حذف .vrbs القديم واحدًا تلو الآخر.
بالمناسبة، لماذا نقوم بإنشاء .vbk جديد في كل مرة: إذا لم نقم بإنشائه، لكننا واصلنا سلسلة الزيادات القديمة، فسيتم تجميد .vbk القديم لفترة طويلة بلا حدود في أي وضع، مما يمنع حذفه. لذلك، تقرر أنه بمجرد إغلاق النطاق، نقوم بإنشاء نسخة احتياطية كاملة على النطاق الحر.
الأمور أكثر تعقيدًا مع سعة نطاق الرماية.
أولاً، دعونا نلقي نظرة على وضع النسخ. لنفترض أننا كنا نشطين في إنشاء نسخ احتياطية لمدة أربعة أيام، ثم تم إغلاق نطاق الرماية بالقدرة. نحن لا نحذف أي شيء، ولكننا نتحمل الاحتفاظ بكل تواضع، وبعد ذلك نقوم بحذف البيانات من نطاق الرماية.
يحدث نفس الشيء تقريبًا في وضع النقل - ننتظر التنقيح، ونحذف القديم الموجود في وحدة التخزين المحلية، ونحذف المخزن في مخزن الكائنات.
مثال مثير للاهتمام مع Forever Forever Forever Incremental. نقوم بتثبيت الاحتفاظ في ثلاث نقاط ونبدأ في عمل النسخ الاحتياطية يوم الاثنين، والتي يتم نسخها بانتظام إلى السحابة. بعد إغلاق وحدة التخزين، يستمر إنشاء النسخ الاحتياطية، مع الحفاظ على ثلاث نقاط، لكن البيانات المخزنة في لوحة السعة تظل تابعة ولا يمكن حذفها. لذلك، ننتظر حتى يوم الخميس، عندما يتجاوز .vbk الخاص بنا مرحلة الاحتفاظ، وعندها فقط نقوم بحذف السلسلة المحفوظة بأكملها بهدوء.
وإخلاء صغير للمسؤولية: جميع الأمثلة هنا معروضة بجهاز واحد. إذا كان لديك العديد منها في النسخة الاحتياطية، فسوف يختلف تنقيحها اعتمادًا على ما إذا تم إجراء Active Full أم لا.
هذا في الأساس كل ما في الأمر. لذلك دعونا ننتقل إلى الميزة الأكثر صعوبة -
ثبات
كما هو الحال مع النقاط السابقة، أول شيء هو المشكلة التي تحلها هذه الوظيفة. بمجرد أن نقوم بتحميل النسخ الاحتياطية الخاصة بنا في مكان ما للتخزين، تكون هناك رغبة قوية في ضمان سلامتها، أي حظر حذفها وأي تعديل أثناء الاحتفاظ بها. بما في ذلك المسؤولين، بما في ذلك الحسابات الجذرية الخاصة بهم. يتيح لك ذلك حمايتهم من التلف العرضي أو المتعمد. ربما يكون أي شخص يعمل مع AWS قد صادف ميزة مشابهة تسمى Object Lock.
الآن دعونا نلقي نظرة على الوضع بشكل عام، ثم نتعمق في التفاصيل. في مثالنا، سيتم تمكين الثبات لنطاق الرماية الخاص بنا مع الاحتفاظ لمدة أربعة أيام. ويتم تمكين وضع النسخ في النسخة الاحتياطية.
لا تتفاعل الثبات مع الاحتفاظ العام بأي شكل من الأشكال. على سبيل المثال، لا يضيف نقاطًا إضافية أو أي شيء من هذا القبيل. إنه مجرد أنه لا يمكن لأي شخص حذف ملفات النسخ الاحتياطي في غضون أربعة أيام. إذا قمت بعمل نسخة احتياطية يوم الاثنين، فلن تتمكن من حذف الملف إلا يوم الجمعة.
تستمر جميع مفاهيم الجفاف والفهارس والبيانات الوصفية الموضحة مسبقًا في العمل بنفس الطريقة تمامًا. ولكن بشرط واحد - لم يتم تعيين الكتلة للبيانات فحسب، بل أيضًا للبيانات الوصفية. يتم ذلك في حالة ما إذا قرر مهاجم ماكر مسح قاعدة بيانات التعريف الخاصة بنا ومنع كتل البيانات من التحول إلى هريسة ثنائية عديمة الفائدة.
الآن هو الوقت المناسب لشرح تقنية إنشاء الكتل لدينا. أو كتلة الجيل. للقيام بذلك، النظر في الوضع الذي أدى إلى ظهوره.
لنأخذ مقياسًا زمنيًا مدته ستة أيام، وسنحدد أدناه وقت انتهاء الصلاحية المتوقع للثبات. في اليوم الأول، نأخذ وننشئ ملفًا يتكون من كتلة البيانات a والبيانات الوصفية الخاصة بها. إذا تم ضبط الثبات على ثلاثة أيام، فمن المنطقي افتراض أنه في اليوم الرابع سيتم إلغاء قفل البيانات وحذفها. في اليوم الثاني سوف نقوم بإضافة ملف 2 جديد يتكون من الكتلة ب بنفس الإعدادات. لا يزال الحظر بحاجة إلى إزالته في اليوم الرابع. ولكن في اليوم الثالث يحدث شيء فظيع - يتم إنشاء ملف File3، يتكون من كتلة جديدة d ورابط إلى الكتلة القديمة a. هذا يعني أنه بالنسبة للكتلة وعلامة عدم قابليتها للتغيير يجب إعادة تعيينها إلى تاريخ جديد، والذي يتم نقله إلى اليوم السادس. وهنا تنشأ مشكلة - يوجد في النسخ الاحتياطية الحقيقية عدد كبير من هذه الكتل. ومن أجل تمديد فترة ثباتها، تحتاج إلى تقديم عدد كبير من الطلبات في كل مرة. وفي الواقع، ستكون هذه عملية يومية لا نهاية لها تقريبًا، لأنه مع وجود درجة عالية من الاحتمال، سنجد أكوامًا ضخمة من الكتل المكررة مع كل نسخة. ماذا يعني العدد الكبير من الطلبات من موفري تخزين الكائنات؟ يمين! فاتورة ضخمة في نهاية الشهر.
ومن أجل عدم تعريض عملائك المفضلين مقابل أموال كبيرة فجأة، تم اختراع آلية إنشاء الكتل. هذه فترة إضافية نضيفها إلى فترة الثبات المحددة. في المثال أدناه، هذه الفترة هي يومين. ولكن هذا مجرد مثال. في الواقع، يستخدمون صيغتهم الخاصة، والتي تعطي ما يقرب من عشرة أيام إضافية خلال القفل الشهري.
دعونا نستمر في النظر في نفس الموقف، ولكن مع إنشاء الكتلة. في اليوم الأول نقوم بإنشاء الملف 1 من الكتلة أ والبيانات الوصفية. نقوم بإضافة فترة الإنشاء والثبات - وهذا يعني أن فرصة حذف الملف ستكون في اليوم السادس. إذا قمنا في اليوم الثاني بإنشاء ملف 2، يتكون من الكتلة ب ورابط للكتلة أ، فلن يحدث شيء لتاريخ الحذف المتوقع. وقامت كما فعلت في اليوم السادس. وبالتالي نحاول توفير المال على عدد الطلبات. الموقف الوحيد الذي يمكن فيه تغيير الموعد النهائي هو إذا انتهت فترة الإنشاء. أي أنه إذا كان الملف 3 الجديد يحتوي في اليوم الثالث على رابط للحظر أ، فستتم إضافة الجيل 2 نظرًا لأن Gen1 قد انتهت صلاحيته بالفعل. والموعد المتوقع لحذف البلوك أ سوف يتحول إلى اليوم الثامن. وهذا يسمح لنا بتقليل عدد الطلبات بشكل كبير لإطالة عمر الكتل المكررة، مما يوفر للعملاء الكثير من المال.
التكنولوجيا نفسها متاحة لمستخدمي الأجهزة المتوافقة مع S3 وS3، والتي يضمن مصنعوها أن تنفيذها لا يختلف عن تطبيق Amazon. ومن هنا جاءت الإجابة على السؤال المشروع لماذا لا يتم دعم Azure - فهي تتمتع بميزة مشابهة، ولكنها تعمل على مستوى الحاويات، وليس على مستوى الكائنات الفردية. بالمناسبة، تمتلك أمازون نفسها خاصية قفل الكائنات في وضعين: الامتثال والحوكمة. في الحالة الثانية، يظل هناك احتمال أن المسؤول الأعظم فوق المسؤولين والجذر فوق الجذور، على الرغم من قفل الكائن، لا يزال يحذف البيانات. في حالة الامتثال، يتم تثبيت كل شيء بإحكام ولا يمكن لأحد حذف النسخ الاحتياطية. حتى مسؤولي أمازون (حسب تصريحاتهم الرسمية). هذا هو الوضع الذي ندعمه.
وكالعادة بعض الروابط المفيدة:
- حول بكل التفاصيل.
- جميع المعلومات عنها في أفضل حالاتها
- О بالتفصيل
المصدر: www.habr.com