النسخ الاحتياطي والاستعادة والتعافي من الكوارث

يفترض كل موضوع سبق أن البنية التحتية تبقى حيث وضعتها وأن البيانات التي فيها صحيحة. ويعالج هذا الموضوع الافتراضين معاً: كيف تنجو من عطل يزيل منطقة توفر بكاملها، وكيف تعود بالبيانات إلى ما قبل عبارة DELETE معطوبة، وكيف تختار بين أربع استراتيجيات تعافٍ تتباين كلفتها بمقدار رتبة كاملة. وهذان سؤالان مختلفان يخلط بينهما كثيرون: التوفر العالي يحميك من أن تنكسر الأشياء، والتعافي من الكوارث يحميك من أن تكون خاطئة، ويفصل Task 2.2 في دليل الاختبار بينهما باستمرار.

ما الذي يغطّيه هذا الموضوع

• ما منطقة التوفر فيزيائياً، وتصنيف الموارد إلى موارد منطقة توفر وموارد منطقة وموارد عالمية، والثبات الساكن وحسبة السعة الاحتياطية AZ+1
• أشكال نشر قواعد البيانات الثلاثة: Multi-AZ DB instance وMulti-AZ DB cluster وAurora، وما تفعله وما لا تفعله
• كيف تخزّن لقطات EBS بياناتها تزايدياً، والفرق بين المتّسق عند الانهيار والمتّسق على مستوى التطبيق
• الاختيار بين Amazon Data Lifecycle Manager وAWS Backup، وخطط النسخ والخزائن والنسخ عبر المناطق والحسابات، وVault Lock بوضعَيه، واختبار الاستعادة
• الاستعادة إلى نقطة زمنية في RDS وآليتها، واللقطات اليدوية، واستنساخ Aurora وBacktrack، وPITR في DynamoDB وما تسقطه كل استعادة
• versioning في S3 وعلامات الحذف وObject Lock، وS3 Replication وما يرفض نسخه بصمت، وBatch Replication وReplication Time Control
• استراتيجيات التعافي الأربع وقيمتا RTO وRPO اللتان تختارانها، وقاعدة مستوى البيانات قبل مستوى التحكّم في آلية التبديل

لماذا هذا مهم

أسئلة هذا الموضوع تعطيك رقمين وميزانية ثم تسألك عن بنية. RPO بخمس دقائق مع RTO بأربع ساعات يقود إلى تصميم، وRPO بأربع وعشرين ساعة يقود إلى تصميم أرخص بكثير، والخيار الأغلى جواب خاطئ حتى لو كان الأمتن تقنياً. وتحته طبقة ثانية من الحدود الدقيقة: هل حُدّد معرّف إصدارة في طلب الحذف، وهل فُعّل Backtrack عند إنشاء العنقود، وهل ينسخ النسخ المتماثل الكائنات التي كانت موجودة قبل القاعدة.

والعمل اليومي هو ذاته. فحين يحذف أحدهم جدولاً بالخطأ أو يفشل نشر ويكتب بيانات تالفة، تقرّر معرفتُك بأقرب نقطة استعادة ممكنة وبما ستسقطه تلك الاستعادة بصمت هل يستغرق الحادث عشرين دقيقة أم يوماً كاملاً.