0Pricing
SQL Academy · درس

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

‏RPO وRTO وrunbooks

التخطيط للتعافي من الكوارث درس مجاني في SQL Academy على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في SQL Academy، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة SQL Academy 4 دروس في المجموع.

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

التعافي من الكوارث (DR) هو مجموعة السياسات والأدوات والإجراءات المصممة لتمكين استعادة البنية التحتية والأنظمة التقنية الحيوية بعد وقوع كارثة طبيعية أو ناتجة عن فعل بشري.

في سياق قواعد البيانات، يضمن تخطيط التعافي من الكوارث بقاء بياناتك آمنة وإمكانية إعادة أنظمتك إلى العمل ضمن حدود زمنية مقبولة بعد أحداث مثل تعطل الأجهزة، أو الحذف العرضي للبيانات، أو هجمات برمجيات الفدية، أو انقطاع مراكز البيانات.

هدف نقطة الاستعادة (RPO)

يحدد RPO الحد الأقصى المقبول لفقدان البيانات مقاسًا بالوقت. فإذا كان RPO لديك ساعة واحدة، فيجب أن تتمكن من استعادة البيانات حتى نقطة تسبق وقوع الكارثة بساعة واحدة على الأقل.

يتطلب RPO الأقصر نسخًا احتياطية أكثر تكرارًا أو نسخًا متماثلًا مستمرًا. يمكنك الاستعلام عن سجل النسخ الاحتياطي للتحقق من تحقيق هدف RPO.

-- Check the last backup time and calculate data loss window
SELECT
  backup_id,
  backup_type,
  started_at,
  finished_at,
  EXTRACT(EPOCH FROM (NOW() - finished_at)) / 3600 AS hours_since_backup
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at DESC
LIMIT 5;

هدف زمن الاستعادة (RTO)

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

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

-- Track restore durations to validate RTO compliance
SELECT
  restore_id,
  triggered_at,
  completed_at,
  EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 60 AS restore_minutes,
  CASE
    WHEN EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 3600 <= 4
    THEN 'WITHIN RTO'
    ELSE 'RTO BREACHED'
  END AS rto_status
FROM restore_log
ORDER BY triggered_at DESC;

RPO مقابل RTO — الفرق الأساسي

غالبًا ما يحدث خلط بين هذين المقياسين. إليك أبسط طريقة لتذكر الفرق بينهما:

  • RPO = ما مقدار البيانات التي يمكنك تحمّل فقدانها؟ (ينظر إلى الماضي، ويُقاس بالوقت السابق للكارثة)
  • RTO = إلى متى يمكنك تحمّل توقف النظام؟ (ينظر إلى المستقبل، ويُقاس بالوقت اللاحق للكارثة)

يحددان معًا نافذة الاستعادة، ويؤثران مباشرةً في تكرار النسخ الاحتياطي، واستراتيجية النسخ المتماثل، وميزانية البنية التحتية.

-- Store RPO and RTO targets per database in a DR configuration table
CREATE TABLE dr_config (
  db_name       VARCHAR(100) PRIMARY KEY,
  rpo_minutes   INT NOT NULL,
  rto_minutes   INT NOT NULL,
  tier          VARCHAR(20) CHECK (tier IN ('CRITICAL', 'HIGH', 'MEDIUM', 'LOW')),
  updated_at    TIMESTAMP DEFAULT NOW()
);

INSERT INTO dr_config (db_name, rpo_minutes, rto_minutes, tier) VALUES
  ('orders_db',    15,   60, 'CRITICAL'),
  ('analytics_db', 120, 240, 'MEDIUM'),
  ('archive_db',   480, 480, 'LOW');

أنواع النسخ الاحتياطية

هناك ثلاث استراتيجيات أساسية للنسخ الاحتياطي، توازن كل منها بين السرعة ومساحة التخزين:

  • النسخ الاحتياطي الكامل: لقطة كاملة لقاعدة البيانات بأكملها. أبطأ أنواع النسخ إنشاءً، وأسرعها استعادةً.
  • النسخ الاحتياطي التفاضلي: لا يتضمن إلا التغييرات منذ آخر نسخة احتياطية كاملة. سرعته متوسطة في الإنشاء والاستعادة.
  • النسخ الاحتياطي التزايدي: لا يتضمن إلا التغييرات منذ آخر نسخة احتياطية من أي نوع. الأسرع إنشاءً، والأبطأ استعادةً (إذ يلزم استخدام ملفات متعددة).

تجمع معظم استراتيجيات التعافي من الكوارث بين نسخ احتياطية كاملة أسبوعية ونسخ تزايدية يومية لتحقيق توازن بين RPO وتكلفة التخزين.

-- Log each backup with its type for audit and recovery planning
CREATE TABLE backup_log (
  backup_id   SERIAL PRIMARY KEY,
  db_name     VARCHAR(100) NOT NULL,
  backup_type VARCHAR(20) CHECK (backup_type IN ('FULL', 'DIFFERENTIAL', 'INCREMENTAL')),
  started_at  TIMESTAMP NOT NULL,
  finished_at TIMESTAMP,
  size_mb     NUMERIC(12, 2),
  status      VARCHAR(20) DEFAULT 'IN_PROGRESS'
);

INSERT INTO backup_log (db_name, backup_type, started_at, finished_at, size_mb, status) VALUES
  ('orders_db', 'FULL',        '2024-06-01 01:00:00', '2024-06-01 02:15:00', 45200, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-02 01:00:00', '2024-06-02 01:08:00',   320, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-03 01:00:00', '2024-06-03 01:07:00',   290, 'SUCCESS');

الاستعادة إلى نقطة زمنية (PITR)

تتيح الاستعادة إلى نقطة زمنية استعادة قاعدة البيانات إلى أي لحظة محددة، وليس فقط إلى وقت آخر نسخة احتياطية. ويتحقق ذلك بإعادة تشغيل سجلات المعاملات (WAL في PostgreSQL) فوق نسخة احتياطية أساسية.

تُعد PITR ضرورية عندما تحتاج إلى التعافي من تلف أو حذف عرضي للبيانات حدث في وقت معروف. إذ يمكنك الاستعادة إلى لحظة تسبق وقوع الحدث المتسبب في الضرر مباشرةً.

-- Record WAL archive events for PITR tracking
CREATE TABLE wal_archive_log (
  segment_name  VARCHAR(200) PRIMARY KEY,
  archived_at   TIMESTAMP DEFAULT NOW(),
  size_bytes    BIGINT,
  storage_path  TEXT
);

-- Find all WAL segments archived within a recovery window
SELECT
  segment_name,
  archived_at,
  ROUND(size_bytes / 1024.0 / 1024.0, 2) AS size_mb
FROM wal_archive_log
WHERE archived_at BETWEEN '2024-06-03 09:00:00' AND '2024-06-03 11:00:00'
ORDER BY archived_at;

قواعد البيانات الاحتياطية والنسخ المتماثل

قاعدة البيانات الاحتياطية (النسخة المتماثلة) هي نسخة محدثة باستمرار من قاعدة البيانات الأساسية، وتعمل على أجهزة منفصلة. وتخدم غرضين في التعافي من الكوارث:

  • الاحتياطي الساخن: يمكنه قبول استعلامات القراءة وإجراء التحويل عند التعطل خلال ثوانٍ (RTO يقترب من الصفر).
  • الاحتياطي الدافئ: يبقى متزامنًا لكنه لا يخدم حركة المرور؛ ويستغرق التحويل عند التعطل دقائق.

تُعد مراقبة تأخر النسخ المتماثل أمرًا بالغ الأهمية — فالنسخة المتماثلة المتأخرة تعني أن RPO الفعلي أسوأ من المتوقع.

-- Monitor replication lag on a PostgreSQL primary
SELECT
  client_addr,
  application_name,
  state,
  sent_lsn,
  replay_lsn,
  (sent_lsn - replay_lsn) AS lag_bytes,
  EXTRACT(EPOCH FROM (NOW() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication
ORDER BY lag_bytes DESC;

أدلة التشغيل: توثيق إجراءات الاستعادة

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

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

-- Store runbook metadata in the database for audit tracking
CREATE TABLE runbook (
  runbook_id   SERIAL PRIMARY KEY,
  title        VARCHAR(200) NOT NULL,
  scenario     VARCHAR(100),
  version      VARCHAR(20) DEFAULT '1.0',
  last_tested  DATE,
  owner        VARCHAR(100),
  doc_url      TEXT
);

INSERT INTO runbook (title, scenario, version, last_tested, owner, doc_url) VALUES
  ('Full Database Restore from S3', 'total_loss',     '2.1', '2024-05-15', 'dba_team', 'https://wiki.internal/dr/full-restore'),
  ('Failover to Hot Standby',       'primary_down',   '1.4', '2024-04-20', 'dba_team', 'https://wiki.internal/dr/failover'),
  ('PITR to Specific Timestamp',    'data_corruption','1.2', '2024-03-10', 'dba_team', 'https://wiki.internal/dr/pitr');

تسجيل تنفيذ دليل التشغيل

في كل مرة يُنفّذ فيها دليل التشغيل — سواء أثناء كارثة حقيقية أو تدريب — ينبغي تسجيل ذلك. تتيح لك سجلات التنفيذ قياس المدة الفعلية للاستعادة (للتحقق من RTO)، وتحديد الخطوات البطيئة أو المعرضة للأخطاء، وإثبات الامتثال للمدققين.

-- Log each runbook execution for RTO validation and audit
CREATE TABLE runbook_execution (
  execution_id  SERIAL PRIMARY KEY,
  runbook_id    INT REFERENCES runbook(runbook_id),
  triggered_by  VARCHAR(100),
  is_drill      BOOLEAN DEFAULT FALSE,
  started_at    TIMESTAMP NOT NULL,
  completed_at  TIMESTAMP,
  outcome       VARCHAR(20) CHECK (outcome IN ('SUCCESS', 'PARTIAL', 'FAILED'))
);

-- Report average restore time per runbook
SELECT
  r.title,
  COUNT(*) AS executions,
  ROUND(AVG(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60), 1) AS avg_minutes,
  MAX(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60) AS max_minutes
FROM runbook_execution e
JOIN runbook r ON r.runbook_id = e.runbook_id
WHERE e.outcome = 'SUCCESS'
GROUP BY r.title;

اختبار التعافي من الكوارث: تدريبات منتظمة

خطة التعافي من الكوارث التي لم تُختبر قط ليست خطة — بل مجرد أمنية. تُعد التدريبات المنتظمة إلزامية لضمان قدرة فريقك الفعلية على تنفيذ أدلة التشغيل ضمن RTO المحدد، وللتأكد من إمكانية استعادة النسخ الاحتياطية فعلًا.

يؤدي جدولة التدريبات وتتبعها في قاعدة البيانات إلى إنشاء مسار تدقيق، ويساعدك على اكتشاف أدلة التشغيل التي تأخر موعد اختبارها.

-- Find runbooks that have not been drilled in over 90 days
SELECT
  r.runbook_id,
  r.title,
  r.scenario,
  MAX(e.completed_at) AS last_drill,
  CURRENT_DATE - MAX(e.completed_at::DATE) AS days_since_drill
FROM runbook r
LEFT JOIN runbook_execution e
  ON e.runbook_id = r.runbook_id
  AND e.is_drill = TRUE
  AND e.outcome = 'SUCCESS'
GROUP BY r.runbook_id, r.title, r.scenario
HAVING MAX(e.completed_at) IS NULL
    OR CURRENT_DATE - MAX(e.completed_at::DATE) > 90
ORDER BY days_since_drill DESC NULLS FIRST;

سياسات الاحتفاظ بالنسخ الاحتياطية

تحدد سياسات الاحتفاظ مدة الاحتفاظ بالنسخ الاحتياطية. ف الاحتفاظ بكل نسخة احتياطية إلى الأبد يهدر مساحة التخزين، بينما يؤدي حذفها بسرعة كبيرة إلى مخالفة متطلبات RPO والامتثال.

من السياسات الشائعة: الاحتفاظ بالنسخ التزايدية اليومية لمدة 7 أيام، والنسخ الكاملة الأسبوعية لمدة 4 أسابيع، والنسخ الكاملة الشهرية لمدة 12 شهرًا. يمكنك فرض سياسة الاحتفاظ والتدقيق فيها باستخدام استعلامات SQL على سجل النسخ الاحتياطي.

-- Identify backups that are outside their retention window and ready to purge
SELECT
  backup_id,
  db_name,
  backup_type,
  finished_at,
  CURRENT_DATE - finished_at::DATE AS age_days,
  CASE backup_type
    WHEN 'INCREMENTAL' THEN 7
    WHEN 'DIFFERENTIAL' THEN 28
    WHEN 'FULL'         THEN 365
  END AS retention_days,
  CASE
    WHEN (CURRENT_DATE - finished_at::DATE) >
         CASE backup_type
           WHEN 'INCREMENTAL' THEN 7
           WHEN 'DIFFERENTIAL' THEN 28
           WHEN 'FULL'         THEN 365
         END
    THEN 'PURGE'
    ELSE 'KEEP'
  END AS action
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at;

تحقق سريع

اختبروا مدى فهمكم لتعريفَي RPO وRTO.

مراجعة: التخطيط للتعافي من الكوارث

استكشفتم في هذا الدرس أسس التخطيط للتعافي من كوارث قواعد البيانات:

  • RPO يحدد أقصى مدة زمنية لفقدان البيانات يمكن تحمّلها؛ ويتطلب RPO الأقصر نسخًا احتياطيًا بوتيرة أعلى أو نسخًا متماثلًا مستمرًا.
  • RTO يحدد السرعة التي يجب استعادة النظام بها؛ ويتطلب RTO الأقصر خوادم احتياطية ساخنة (hot standbys) والتبديل التلقائي عند التعطل (failover).
  • توفر أنواع النسخ الاحتياطية — الكاملة، والتفاضلية، والتزايدية — موازنات مختلفة بين مساحة التخزين وسرعة الإنشاء وسرعة الاستعادة.
  • يستخدم PITR (Point-in-Time Recovery) سجلات المعاملات للاستعادة إلى أي لحظة زمنية دقيقة، مما يحمي من التغييرات العرضية.
  • توثّق أدلة التشغيل (Runbooks) كل خطوة من خطوات إجراء الاستعادة؛ ويساعد تسجيل عمليات التنفيذ على التحقق من إمكانية تحقيق RTO عمليًا.
  • تُعد اختبارات DR الدورية الوسيلة الوحيدة للتأكد من إمكانية استعادة النسخ الاحتياطية ومن قدرة فريقكم على تحقيق أهداف RPO وRTO تحت ضغط حقيقي.
  • توازن سياسات الاحتفاظ بين تكلفة التخزين ومتطلبات الامتثال والتعافي.

تُعد خطة DR المختبرة جيدًا من أكثر الاستثمارات قيمةً التي يمكن لفريق قواعد البيانات القيام بها.

الأسئلة الشائعة

هل درس «التخطيط للتعافي من الكوارث» مجاني؟

نعم — نص درس «التخطيط للتعافي من الكوارث» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة SQL Academy، انتقل إلى CoddyKit PRO. تتضمن دورة SQL Academy 4 دروس في المجموع.

ماذا ستتعلم في «التخطيط للتعافي من الكوارث»؟

‏RPO وRTO وrunbooks تتمرن على SQL Academy مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ SQL Academy؟

لا تُشترط خبرة سابقة. SQL Academy على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.

كم من الوقت يستغرق درس «التخطيط للتعافي من الكوارث»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس SQL Academy هذا؟

نعم. كل درس في SQL Academy يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. النسخ الاحتياطية المنطقية مقابل الفعلية
  2. الاسترداد إلى نقطة زمنية
  3. اختبار عمليات الاسترداد
  4. التخطيط للتعافي من الكوارث
← العودة إلى SQL Academy