إنتقل إلى المحتوى الرئيسي

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

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

الأهداف​

المقياسالهدفالمعنى
RPO (أقصى فقدان بيانات)≤ 5 دقيقةاستخدام استعادة نقطة في الوقت (WAL مستمر)، وليس فقط الدفقات الليلية.
RTO (أقصى downtime)≤ 1 ساعةالوقت لاستعادة + إعادة النقطة من التطبيق إلى قاعدة البيانات المستعادة.
الاحتفاظ بالنسخة الاحتياطية≥ 35 يوماًتغطي late-discovered corruption + نوافذ التدقيق الشهرية.
تمرين الاستعادةشهرينسخة احتياطية لم يتم اختبارها ليست نسخة احتياطية.

ما يجب أن يتم نسخه احتياطياً​

  1. قاعدة بيانات Postgres — كل بيانات التطبيق (قاعدة بيانات منطقية واحدة appdb).
  2. حلقة مفاتيح حماية البيانات — مثابتة في قاعدة البيانات (PersistKeysToDbContext<DataContext>) و مشفرة PFX عبر App:DataProtectionCertBase64. يركب مع في النسخة الاحتياطية للقاعدة، لكن الشهادة الحامية + كلمة مرورها (App:DataProtectionCertPassword) هي أسرار مخزنة خارج قاعدة البيانات — احتفظ بها في مدير الأسرار الخاص بك. بدون الشهادة لا يمكنك فك تشفير الأسرار (كلمات مرور cTID و Open API tokens و node secrets و AI key) بعد الاستعادة.

Postgres مُدار (موصى به)​

يوفر مسار IaC السحاب الثنائي Postgres مُدار مع PITR مدمج — تمكين + تحقق من الاحتفاظ:

  • Azure (deploy/azure/main.bicep، Flexible Server): تعيين backup.backupRetentionDays (≥ 35) و geoRedundantBackup حيث يتطلب الامتثال. استعادة مع Point-in-time restore إلى خادم جديد، ثم تحديث سلسلة الاتصال appdb للتطبيق.
  • AWS (deploy/aws, RDS Postgres، Terraform): تعيين backup_retention_period (≥ 35) و backup_window؛ الاحتفاظ بالنسخ الاحتياطية التلقائية + نسخة عبر المنطقة اختيارية. استعادة مع RestoreDBInstanceToPointInTime، ثم إعادة النقطة من التطبيق.

Postgres مُدار PITR يعطي ≤ 5 دقائق RPO بدون تغييرات التطبيق — التطبيق يحتاج فقط إلى سلسلة الاتصال الجديدة (واستراتيجية التنفيذ الموجودة المحاولة، انظر scaling.md، تتحمل blip التقطع).

Postgres مستضاف ذاتياً​

  • الأرشفة المستمرة (PITR): تمكين أرشفة WAL (archive_mode=on، archive_command لتخزين الكائنات) + pg_basebackup دوري. الاستعادة = استعادة النسخة الاحتياطية الأساسية + replay WAL إلى وقت الهدف. هذا ما يلبي هدف RPO.
  • الدفقات المنطقية (ثانوية): pg_dump -Fc appdb الليلية إلى off-box storage للمحمولة / استعادات جزئية. غير كافٍ وحده لهدف RPO.
  • تشفير النسخ الاحتياطية في الراحة؛ مخزن off database host.

تمرين الاستعادة (تشغيل شهري)​

  1. استعادة أحدث نسخة احتياطية (PITR إلى "الآن − 10 دقيقة") إلى قاعدة بيانات scratch، وليس الإنتاج.
  2. اشير مثيل تطبيق يمكن التخلص منه (أو جلسة psql) في ذلك.
  3. التحقق من المخطط: dotnet ef migrations list يعرض لا توجد هجرات في انتظار، التطبيق يبدأ ويصبح /health-ready.
  4. تحقق من سلسلة التدقيق سليمة وغير مكسورة عبر IAuditTrailVerifier (السلسلة المقاومة للعبث AuditChainInterceptor) — سلسلة مكسورة بعد الاستعادة تعني corruption أو tampering.
  5. تأكد من فك تشفير السر يعمل (مثل استئذان Open API فك تشفير) — يثبت حماية البيانات cert + كلمة المرور تم استعادتها بشكل صحيح.
  6. سجل نتيجة الحفر (الوقت المستغرق مقابل RTO) وتدمير قاعدة بيانات scratch.

أتمتة الخطوات 1–4 في CI حيث تسمح البيئة (استعادة نسخة احتياطية منتشرة في Testcontainer، تشغيل dotnet ef migrations list + التحقق من سلسلة التدقيق) لذا يتم اكتشاف regression النسخة الاحتياطية المكسورة قبل أن تحتاج إليها.

بعد استعادة حقيقية​

  1. استعادة DB (PITR إلى قبل الحادثة).
  2. تأكد من حماية البيانات cert + كلمة المرور نفس المستخدمة قبل الحادثة.
  3. أعد نقطة سلسلة الاتصال appdb للتطبيق؛ اللفات الحوالة.
  4. يعمل بدء التشغيل الهجرات تحت القفل الاستشاري (انظر scaling.md) — آمن مع N replicas.
  5. أعادة النسخ/prop-firm supervisors مطالبتهم leases و resync من الوسيط (cTrader هو مصدر الحقيقة)، لذا مواقع مفتوحة reconverge تلقائياً — لا شيء يُثق من حالة محلية قديمة.
  6. التحقق من سلسلة التدقيق + البقعة-فحص البيانات التجارية الأخيرة.