SQL Academy · درس

اختبار عمليات الاسترداد

النسخة الاحتياطية التي لا يمكن استعادتها عديمة الفائدة

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

النسخة الاحتياطية التي لا يمكن استعادتها لا قيمة لها

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

يستعرض هذا الدرس منهجية اختبار الاستعادة: كيفية التحقق من عمل نسخك الاحتياطية قبل أن تجبرك كارثة حقيقية على اكتشاف الحقيقة بالطريقة الأصعب.

ما الذي يتضمنه اختبار الاستعادة؟

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

الخطوات هي: 1) الحصول على ملف النسخة الاحتياطية. 2) استعادته إلى بيئة معزولة. 3) تشغيل استعلامات التحقق. 4) مقارنة النتائج ببيئة الإنتاج.

إنشاء لقطة مرجعية للمقارنة

قبل أن تتمكن من التحقق من عملية استعادة، تحتاج إلى خط أساس — مجموعة معروفة من الأعداد وقيم المجموع الاختباري من بيئة الإنتاج، لتتمكن من مقارنتها بالنسخة المستعادة.

شغّل هذا الاستعلام على قاعدة بيانات الإنتاج وسجّل النتائج:

SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

التحقق من أعداد الصفوف بعد الاستعادة

بعد استعادة النسخة الاحتياطية إلى قاعدة بيانات اختبار، شغّل الاستعلام نفسه وقارن الأرقام. إذا تطابقت الأعداد، فهذا يعني أن البنية الأساسية للاستعادة سليمة.

يكشف عدم التطابق هنا فورًا فقدان بيانات أثناء النسخ الاحتياطي أو الاستعادة — قبل أن تقترب من بيئة الإنتاج.

-- Run on the RESTORED test database
SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

التحقق من أحدث البيانات

تؤكد أعداد الصفوف الكمية، لكنها لا تؤكد حداثة البيانات. تحقّق من احتواء قاعدة البيانات المستعادة على سجلات حديثة — إذ ينبغي أن تعكس النسخة الاحتياطية البيانات حتى اللحظة التي أُخذت فيها.

SELECT
  MAX(created_at) AS latest_order,
  MIN(created_at) AS oldest_order,
  COUNT(*)        AS total_orders
FROM orders;

التحقق من التكامل المرجعي

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

استخدم LEFT JOIN لاكتشاف عناصر الطلبات اليتيمة:

SELECT
  oi.id       AS orphaned_item_id,
  oi.order_id AS missing_order_id
FROM order_items oi
LEFT JOIN orders o ON o.id = oi.order_id
WHERE o.id IS NULL;

استخدام المجموع الاختباري لاكتشاف التلف

بالنسبة إلى الجداول المهمة، أنشئ مجموعًا اختباريًا للبيانات لاكتشاف التلف على مستوى البتات. في PostgreSQL، يمكنك الجمع بين MD5 وتحويل الصف بأكمله إلى نوع مناسب.

إذا اختلف المجموع الاختباري من بيئة الإنتاج عن المجموع الخاص بالنسخة المستعادة، فهذا يعني أن البيانات عُدّلت أو تلفت في مرحلة ما.

SELECT
  MD5(string_agg(row_data, ',' ORDER BY row_data)) AS table_checksum
FROM (
  SELECT CAST(ROW(id, customer_id, total, created_at) AS TEXT) AS row_data
  FROM orders
) sub;

إنشاء جدول للتحقق من الاستعادة

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

CREATE TABLE IF NOT EXISTS restore_validation_log (
  id             SERIAL PRIMARY KEY,
  backup_taken_at TIMESTAMP NOT NULL,
  restored_at    TIMESTAMP NOT NULL DEFAULT NOW(),
  table_name     VARCHAR(100) NOT NULL,
  expected_rows  INT NOT NULL,
  actual_rows    INT NOT NULL,
  passed         BOOLEAN NOT NULL
);

إدراج نتيجة التحقق

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

INSERT INTO restore_validation_log
  (backup_taken_at, table_name, expected_rows, actual_rows, passed)
VALUES
  ('2024-06-09 02:00:00', 'orders',      15482, 15482, TRUE),
  ('2024-06-09 02:00:00', 'customers',    8201,  8201,  TRUE),
  ('2024-06-09 02:00:00', 'order_items', 47310, 47310, TRUE);

الاستعلام عن سجل التحقق

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

SELECT
  backup_taken_at,
  table_name,
  expected_rows,
  actual_rows,
  passed,
  CASE
    WHEN passed THEN 'OK'
    ELSE 'MISMATCH - investigate!'
  END AS status
FROM restore_validation_log
ORDER BY backup_taken_at DESC, table_name;

التحقق من الاستعادة إلى نقطة زمنية

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

للتحقق من عمل PITR، استعد قاعدة البيانات إلى طابع زمني معروف، وتحقق من أن سجلًا أُنشئ بعد ذلك الطابع الزمني لا يظهر في قاعدة البيانات المستعادة:

-- After a PITR restore to '2024-06-09 03:00:00',
-- this order (created at 03:45) should NOT exist:
SELECT id, created_at, total
FROM orders
WHERE created_at > '2024-06-09 03:00:00'
ORDER BY created_at
LIMIT 5;
-- Zero rows = PITR worked correctly

اختبار سريع

أيّ من الاستعلامات التالية هو الأكثر فائدة لاكتشاف السجلات الفرعية اليتيمة بعد استعادة نسخة احتياطية؟

مراجعة الدرس: اختبار عمليات الاستعادة

تعلّمت في هذا الدرس سبب كون اختبار الاستعادة جزءًا إلزاميًا من أي استراتيجية للنسخ الاحتياطي، وكيفية تنفيذه باستخدام SQL:

اللقطات المرجعية — سجّل أعداد صفوف الإنتاج قبل الاختبار.
مقارنة أعداد الصفوف — شغّل الاستعلام نفسه على قاعدة البيانات المستعادة وقارن النتائج.
التحقق من الحداثة — تأكد من توافق أحدث السجلات مع فترة النسخ الاحتياطي المتوقعة.
التكامل المرجعي — استخدم LEFT JOIN للعثور على الصفوف الفرعية اليتيمة.
التحقق باستخدام المجموع الاختباري — اكتشف التلف على مستوى البتات باستخدام تجميعات MD5.
جدول سجل التحقق — تتبّع كل عملية اختبار لتكوين سجل قابل للتدقيق.
التحقق من PITR — تأكد من وصول الاستعادة إلى النقطة الزمنية الصحيحة.

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

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

هل درس «اختبار عمليات الاسترداد» مجاني؟

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

ماذا ستتعلم في «اختبار عمليات الاسترداد»؟

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

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

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

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

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

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

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

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

← العودة إلى SQL Academy