التعافي من الكوارث والترحيل

في الجزء السابع نجا تطبيقنا من فقدان منطقة توفر. بس لو الكارثة أكبر: منطقة كاملة طاحت، أو DELETE بالغلط، أو برنامج فدية؟ والنص الثاني من هذا الجزء: لو تطبيقك لسا مو على AWS، وتبي تجيبه؟

RPO وRTO #

قبل أي قرار تقني، تحتاج رقمين من أصحاب العمل:

كل ما صغر الرقمين، ارتفعت التكلفة. فالسؤال مو "وش الأفضل؟"، بل "كم تسوى ساعة التوقف عندنا؟"

أربع استراتيجيات #

هذي للتعافي في منطقة ثانية، مرتبة من الأرخص للأغلى. والفرق بينها كم شي شغال هناك قبل الكارثة:

• Backup and Restore: نسخ تنتقل لمنطقة ثانية، وكل شي ينبني منها وقت الكارثة. والقوالب تساعد، زي ما بنشوف في الجزء الجاي.
• Pilot Light: البيانات تتنسخ باستمرار، مثل Aurora Global Database أو نسخ S3، والسيرفرات جاهزة بس واقفة.
• Warm Standby: نسخة كاملة صغيرة شغالة وتقدر تستقبل على طول، ثم تكبر بـ Auto Scaling.
• Multi-Site: المنطقتين يخدمون المستخدمين طول الوقت، مثل Route 53 مع Global Tables.

نصائح تفرق #

• اختبر تعافيك. النسخة اللي ما رجعتها ولا مرة مجرد أمل. سوّ تدريبات، واستفد من AWS Fault Injection Service عشان تسبب أعطال متعمدة.
• أتمت. ابن البيئة من قوالب، لأن وقت الكارثة ما أحد يتذكر الخطوات.
• احمِ نسخك من نفسك. حطها في حساب ثاني ومنطقة ثانية، لأن المهاجم اللي يدخل حسابك بيبدأ فيها.
• فكر في Elastic Disaster Recovery. AWS DRS ينسخ سيرفراتك باستمرار لتخزين رخيص، ويشغلها بس لما تحتاجها، بـ RPO ثواني وRTO دقايق.
• راجع الحصص في منطقة الاحتياط. الحصص لكل منطقة، فالنسخة الصغيرة ممكن توصل حدها وقت ما تحتاج تكبر. ارفعها هناك قبلها من صفحة Service Quotas.

AWS Backup: كل شي في مكان واحد #

كل خدمة لها نسخها، بس AWS Backup يديرها مركزياً، لـ EC2 وEBS وS3 وRDS وAurora وDynamoDB وEFS وFSx وغيرها:

وVault Lock أقوى دفاع عندك ضد برامج الفدية وضد اللي معه بيانات مدير مسروقة.

ترحيل قواعد البيانات: DMS #

AWS DMS (Database Migration Service) ينقل قاعدة البيانات وهي مستخدمة: ينسخ البيانات الموجودة، ثم يستمر يرسل التغييرات (تعرف بـ CDC) لين تكون جاهز تحوّل.

والمصادر والوجهات كثيرة، منها قواعد مكتبك وRDS وS3 وDynamoDB وRedshift وOpenSearch. ويقدر يشتغل بـ Multi-AZ مع نسخة احتياطية في منطقة ثانية، أو Serverless عشان ما تحتاج تحدد حجمه.

النقل إلى RDS أو Aurora #

لو تنقل MySQL أو PostgreSQL، عندك طرق أبسط:

ترحيل السيرفرات ومراكز البيانات #

AWS Transform MGN كان اسمه Application Migration Service لين 2026. وكيل على سيرفرك ينسخ أقراصه باستمرار إلى موارد AWS منخفضة التكلفة، وتجرب كم ما تبي، ثم تحوّل في دقايق. وغالباً هو أسرع طريق للخروج من مركز بيانات.

ولو عندك بيانات ضخمة، حسبناها في الجزء الثامن عشر.

عملي: احذف البيانات ورجعها #

بنمثل كارثة صغيرة: جدول، ونسخة، وحذف بالغلط، ثم استعادة. من CloudShell، أنشئ الجدول بطلب واحد:

aws dynamodb create-table --table-name series-orders \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --query TableDescription.TableStatus

aws dynamodb wait table-exists --table-name series-orders

aws dynamodb put-item --table-name series-orders \
  --item '{"id":{"S":"1001"},"total":{"N":"120"}}'

TABLE_ARN=$(aws dynamodb describe-table --table-name series-orders \
  --query Table.TableArn --output text)

AWS Backup يحتاج دور وVault:

cat > trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "backup.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
EOF

ROLE_ARN=$(aws iam create-role --role-name series-backup-role \
  --assume-role-policy-document file://trust.json \
  --query Role.Arn --output text)

aws iam attach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup
aws iam attach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores

aws backup create-backup-vault --backup-vault-name series-vault \
  --query BackupVaultName --output text

ابدأ النسخ، ثم انتظره. ولو جاك خطأ عن الدور، انتظر كم ثانية وأعد الأمر الأول. وهذا ياخذ عادةً كم دقيقة:

JOB=$(aws backup start-backup-job --backup-vault-name series-vault \
  --resource-arn $TABLE_ARN --iam-role-arn $ROLE_ARN \
  --query BackupJobId --output text)

while true; do
  STATE=$(aws backup describe-backup-job --backup-job-id $JOB \
    --query State --output text)
  echo $STATE
  case $STATE in COMPLETED|FAILED|ABORTED|EXPIRED) break ;; esac
  sleep 15
done

POINT=$(aws backup describe-backup-job --backup-job-id $JOB \
  --query RecoveryPointArn --output text)

الحين الكارثة. الطلب راح:

aws dynamodb delete-item --table-name series-orders \
  --key '{"id":{"S":"1001"}}'

aws dynamodb get-item --table-name series-orders \
  --key '{"id":{"S":"1001"}}'

الأمر الثاني ما يطبع شي. استعد النسخة إلى جدول جديد، ولاحظ الوقت اللي تاخذه، لأن هذا هو RTO الحقيقي حقك:

RESTORE=$(aws backup start-restore-job --recovery-point-arn $POINT \
  --iam-role-arn $ROLE_ARN \
  --metadata targetTableName=series-orders-restored,encryptionType=Default \
  --query RestoreJobId --output text)

while true; do
  STATE=$(aws backup describe-restore-job --restore-job-id $RESTORE \
    --query Status --output text)
  echo $STATE
  case $STATE in COMPLETED|FAILED|ABORTED) break ;; esac
  sleep 15
done

aws dynamodb get-item --table-name series-orders-restored \
  --key '{"id":{"S":"1001"}}' --query Item

الطلب رجع. وأي شي انكتب بعد النسخة ضاع، وهذا هو RPO حقك.

aws backup delete-recovery-point --backup-vault-name series-vault \
  --recovery-point-arn $POINT
aws backup delete-backup-vault --backup-vault-name series-vault

aws dynamodb delete-table --table-name series-orders \
  --query TableDescription.TableStatus
aws dynamodb delete-table --table-name series-orders-restored \
  --query TableDescription.TableStatus

aws iam detach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup
aws iam detach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores
aws iam delete-role --role-name series-backup-role

الخلاصة #

• RPO البيانات اللي تخسرها، وRTO وقت توقفك، وأصحاب العمل يحددونهم.
• الاستراتيجيات الأربع: النسخ، وPilot Light، وWarm Standby، وMulti-Site، والتكلفة ترتفع كل ما تحسنت.
• AWS Backup يدير النسخ مركزياً، وVault Lock يحميها.
• DMS ينقل قواعد البيانات وهي شغالة، وAWS Transform MGN ينقل السيرفرات.
• اختبر تعافيك، وإلا ما عندك تعافي.

اختبر نفسك #

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

تطبيقك الحين مبني ومحمي وقابل للتعافي. يبقى سؤال أخير: كم يكلف، وهل هو مصمم صح؟ في الجزء التاسع والعشرين نختم السلسلة بالتكلفة والتصميم الجيد.