اللقطات: أفضل الممارسات لتجنب تلف الأجهزة

في العديد من أقسام تقنية المعلومات، يتكرر السيناريو نفسه في كل مرة: قبل تطبيق أي تغيير جوهري في بيئة الإنتاج، يقوم أحدهم بإنشاء نسخة احتياطية من الجهاز الظاهري "احتياطاً" ويشعر بالاطمئنان التام. هذا الشعور الزائف بالأمان الذي توفره هذه النسخ الاحتياطية يؤدي إلى تراكمها لأشهر... إلى أن يمتلئ مخزن البيانات، أو ينخفض ​​الأداء، أو تتلف البيانات.

السؤال الذي يتبادر إلى أذهان العديد من الفرق واضح: هل من الممارسات الجيدة الاحتفاظ بالنسخ الاحتياطية إلى أجل غير مسمى "لأنها لا تسبب أي إزعاج"؟ أم ينبغي حذفها بمجرد انتهاء الحاجة إليها؟ للإجابة على هذا السؤال بشكل مدروس، نحتاج إلى فهم كامل لماهية النسخة الاحتياطية، وكيفية عملها داخليًا، وتأثيرها الحقيقي على الأداء والتخزين والأمان (بما في ذلك برامج الفدية)، ولماذا يجب عدم الخلط بينها وبين النسخ الاحتياطية على الإطلاق.

ما هي اللقطة وما هي ليست لقطة؟

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

من وجهة نظر برنامج إدارة الأجهزة الافتراضية (مثل VMware، وHyper-V، وKVM، وProxmox، وغيرها)، يؤدي إنشاء لقطة إلى تجميد القرص الأساسي في وضع القراءة فقط، وإنشاء قرص تفاضلي (دلتا) جديد تُعاد توجيه جميع عمليات الكتابة اللاحقة إليه . لا تُكرر اللقطة القرص بأكمله، بل تُحدد فقط نقطة فصل التغييرات.

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

تتضمن عملية النسخ الاحتياطي، سواء على مستوى الملفات أو كصورة جهاز افتراضي، إنشاء نسخة كاملة أو جزئية من البيانات على وسيط تخزين مادي آخر (مثل مصفوفة تخزين مختلفة، أو مستودع نسخ احتياطية، أو شريط تخزين، أو سحابة تخزين، إلخ). في بيئات لينكس، من الشائع أتمتة عمليات النسخ الاحتياطي باستخدام أداة rsync . أما اللقطة، من ناحية أخرى، فتعتمد على نفس وحدة التخزين التي يستخدمها الجهاز الأصلي؛ فإذا تعطلت وحدة التخزين هذه، تُفقد اللقطة معها.

تشريح لقطة: الكتل والسلاسل واستهلاك المساحة

لفهم المشكلة الأساسية، تخيل جهازًا افتراضيًا بقرص افتراضي واحد يتكون من عدة كتل بيانات A وB وC وD وE. طالما لا توجد لقطات، يتم كتابة أي تغيير مباشرة إلى هذا القرص الأساسي : إذا تم تعديل A وإضافة F، فإن القرص "الحقيقي" سيحتوي على A' وB وC وD وE وF.

عند إنشاء اللقطة الأولى، يُصبح القرص الأصلي للقراءة فقط، ويُنشئ برنامج إدارة الأجهزة الافتراضية قرصًا تفاضليًا. ومنذ تلك اللحظة، تُحفظ جميع عمليات الكتابة (على سبيل المثال، التغييرات التي تطرأ على A' وB أو ظهور G) على هذا القرص الجديد . لكن القرص الأساسي يحتفظ بمحتوياته السابقة.

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

إذا كررت العملية وأنشأت لقطة ثانية فوق الأولى، فإن التغيير السابق يصبح للقراءة فقط، مما يُنشئ قرصًا تفاضليًا ثالثًا. وتؤدي التغييرات اللاحقة (A''، D، E، H، إلخ) إلى زيادة حجم سلسلة الأقراص هذه تدريجيًا حتى يتجاوز حجم المساحة التي تشغلها اللقطات في كثير من الحالات الحجم الأصلي للجهاز الظاهري بكثير.

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

تأثير سلاسل اللقطات على الأداء والموثوقية

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

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

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

علاوة على ذلك، كلما طالت مدة نمو اللقطة (خاصة على الأجهزة ذات النشاط العالي، مثل قواعد البيانات)، كلما أصبحت عملية الدمج أكثر تعقيدًا وبطئًا . عند حذف السلسلة، يجب على النظام دمج تغييرات كل دلتا مع الأصل، واحدًا تلو الآخر، مما يؤدي إلى عمليات قراءة/كتابة متعددة ويزيد من خطر حدوث مشاكل في حال انقطاع العملية.

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

أنواع اللقطات وخصائصها المحددة حسب المنصة

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

في برنامج VMware، على سبيل المثال، يمكنك إنشاء لقطات ذاكرة ذات حالة، تُعرف أيضًا باسم لقطات "التوقف المؤقت". تلتقط لقطة الذاكرة بدقة ما هو موجود في ذاكرة الوصول العشوائي (RAM) ووحدة المعالجة المركزية (CPU) في تلك اللحظة . وهذا مفيد جدًا للعودة إلى حالة سابقة بعد ترقية النظام أو تثبيت معقد.

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

في Hyper-V، المفهوم هو نفسه، على الرغم من أن مايكروسوفت هي من شاع استخدام مصطلح "نقطة التحقق". من الناحية الفنية، هي لقطة تضع قرص VHD/VHDX الأصلي في وضع القراءة فقط وتنشئ قرصًا واحدًا أو أكثر من أقراص التفاضل المتسلسلة.

في عالم التخزين، بالإضافة إلى برنامج إدارة الأجهزة الافتراضية، توجد أيضًا لقطات على مستوى مصفوفة التخزين أو نظام الملفات (مثل ZFS، وأنظمة NAS، وSAN، وما إلى ذلك). تعمل هذه اللقطات على كتل التخزين، وليس على أجهزة افتراضية محددة ، وعادةً ما يتم تنفيذها باستخدام طريقتين رئيسيتين: النسخ عند الكتابة (COW) وإعادة التوجيه عند الكتابة (ROW).

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

في نظام ROW، المستخدم على نطاق واسع في الأنظمة الحديثة مثل ZFS ومصفوفات التخزين الفلاشية بالكامل، تُكتب البيانات الجديدة مباشرةً إلى موقع فعلي مختلف ويتم تحديث المؤشرات، بينما تحتفظ اللقطة بمراجع للكتل الأقدم. لا يؤثر إنشاء اللقطات وكتابتها إلا بشكل طفيف على الأداء، ولكن ذلك يأتي على حساب زيادة التجزئة، مما قد يُشكل مشكلة على محركات الأقراص الصلبة التقليدية (HDDs).

اللقطات مقابل النسخ الاحتياطية: لماذا لا يمكن استبدال أحدهما بالآخر؟

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

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

تتضمن عملية النسخ الاحتياطي الحقيقية اتباع مبادئ مثل قاعدة 3-2-1: وجود ثلاث نسخ على الأقل من البيانات، على وسيطين مختلفين، مع تخزين إحداها خارج الموقع . وهذا يعني عادةً وجود مستودع نسخ احتياطي مخصص، أو موقع منفصل، أو شريط تخزين، أو خدمة سحابية، أو مزيج منها، وغالبًا ما يتضمن ذلك طبقات من الحماية ضد التغيير.

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

تتكامل حلول النسخ الاحتياطي للبيئات الافتراضية (مثل Veeam وVinchin Backup & Recovery) مع برنامج إدارة الأجهزة الافتراضية (Hypervisor) لإنشاء لقطات مؤقتة ، واستخراج نسخة متناسقة منها إلى مستودع منفصل، ثم حذف تلك اللقطات. تُعدّ اللقطة أداة مؤقتة فقط ضمن عملية النسخ الاحتياطي؛ أما شبكة الأمان الحقيقية فهي النسخة الاحتياطية الخارجية.

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

أفضل الممارسات لاستخدام اللقطات دون إتلاف الأجهزة

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

القاعدة الأولى، البسيطة ولكنها بالغة الأهمية، هي الوقت: لا ينبغي الاحتفاظ بنسخة احتياطية من بيئة الإنتاج لأكثر من 24-72 ساعة . على سبيل المثال، تنصح VMware صراحةً بعدم ترك نسخة احتياطية واحدة نشطة بعد هذه المدة، لأن حجمها سيستمر في الازدياد وسيؤثر ذلك سلبًا على مخزن البيانات.

الكمية مهمة أيضاً. فبينما يمكنك نظرياً ربط ما يصل إلى 32 لقطة لكل جهاز افتراضي، يُنصح في بيئات العمل الفعلية بالحد من ذلك إلى 2 أو 3 كحد أقصى لتقليل زمن الاستجابة وتعقيد عملية الدمج. كل قرص إضافي يُضيف طبقة أخرى للقراءة والدمج.

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

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

والأهم من ذلك، لا تخلط بين اللقطات وسياسات الامتثال والنسخ الاحتياطي . ففي عمليات التدقيق وفقًا لمعايير ISO 27001 وENS وPCI-DSS أو ما شابهها، لا تُعتبر اللقطات نسخًا احتياطية أو سجلات تاريخية معتمدة. إنها آلية تشغيلية، وليست إجراءً للتحكم في استمرارية الأعمال.

اللقطات وبرامج الفدية: "آلة الزمن"... مع بعض الفروقات الدقيقة

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

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

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

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

عند اكتشاف أي حادثة، تتضمن الإجراءات المعتادة اختيار لقطة من قبل بدء التشفير، ثم إعادة تحميل وحدة التخزين أو استعادتها إلى تلك النقطة. وسواء كان حجم مجموعة البيانات 1 تيرابايت أو 100 تيرابايت، فلا فرق : بما أنه يتم إعادة توجيه المؤشرات إلى الكتل القديمة فقط، فإن وقت الاستعادة (RTO) قصير جدًا مقارنةً بالاستعادة الكاملة.

في الواقع، تستخدم العديد من الحلول الحديثة اللقطات ليس فقط بشكل سلبي ولكن أيضًا كآلية دفاع استباقية . فهي تحلل إنتروبيا الكتل المكتوبة في الوقت الفعلي (يبدو الملف المشفر مشابهًا جدًا للبيانات العشوائية)، وفي مواجهة الارتفاعات غير الطبيعية في الإنتروبيا وعمليات الكتابة الضخمة، تقوم تلقائيًا بتشغيل لقطات غير قابلة للتغيير أو قطع اتصالات الكتابة المشبوهة (SMB/NFS).

لقطات غير قابلة للتغيير، وWORM، وإدارة الامتيازات الآمنة

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

هنا تبرز أهمية اللقطات غير القابلة للتغيير أو تقنيات WORM (الكتابة مرة واحدة، القراءة عدة مرات). فبمجرد قفل اللقطة لفترة محددة (على سبيل المثال، 7 أيام) ، لا يمكن لأحد - ولا حتى مدير النظام الذي يتمتع بأقصى الصلاحيات - تعديلها أو حذفها حتى انقضاء تلك الفترة.

تحوّل هذه الآليات اللقطات إلى نوع من الخزنة المؤقتة: فحتى لو سرق المهاجم بيانات اعتماد عالية المستوى ، فسيجد نسخًا لا يمكنه الوصول إليها. وهذا يضمن على الأقل بعض نقاط الاستعادة الآمنة.

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

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

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

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

متى نستخدم اللقطات ومتى نستخدم النسخ الاحتياطية؟

في الواقع، لا تتنافس اللقطات والنسخ الاحتياطية، بل تُكمّل كلٌّ منهما الأخرى. يكمن السرّ في استخدام كل أداة للغرض المُخصّص لها ، وعدم تغيير الأدوار بدافع الراحة أو نقص المعرفة.

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

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

تُصبح النسخ الاحتياطية ضرورية عندما نتحدث عن استمرارية الأعمال الحقيقية:

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

كما يوفر حل النسخ الاحتياطي الحديث للبيئات الافتراضية مزايا إضافية: النسخ الاحتياطي التزايدي، والتحقق من السلامة، والضغط، وإزالة التكرار، والنسخ الاحتياطي بدون شبكة محلية ، والاستعادة الفورية عن طريق تحميل النسخ الاحتياطية مباشرة، والترحيل بين منصات المحاكاة الافتراضية، وما إلى ذلك.

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

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