> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # حريق OVHcloud في ستراسبورغ: نسخ احتياطية احترقت مع البيانات - URL: https://arabroot.io/articles/حريق-مركز-بيانات-ovhcloud-في-ستراسبورغ/ - Published: 2026-10-09T21:00:00.000Z - Updated: 2026-10-09T09:46:57.000Z - Description: ماذا حدث في حريق مركز بيانات OVHcloud سنة 2021، ولماذا فقد عملاء نسخهم الاحتياطية، وكيف تتأكد أن نسختك خارج الموقع فعلاً. - Author: فريق عرب رووت - Tags: الأدلة التقنية, قصص وتحقيقات, التشغيل والنسخ الاحتياطي, أساسيات, الاستضافة الذاتية في الساعة 03:53 من صباح 10 مارس 2021 كتبت OVHcloud على [صفحة حالة الخدمات](https://travaux.ovh.net/?do=details&id=49471&ref=arabroot.io) جملة لا يحب أي مدير أنظمة أن يقرأها من مزوده: «إذا كانت بيئة الإنتاج عندك في ستراسبورغ، ننصحك بتفعيل خطة التعافي من الكوارث Disaster Recovery Plan». فقد اشتعل حريق في مبنى SBG2 في موقع الشركة على ميناء نهر الراين، ولم يستطع رجال الإطفاء السيطرة عليه، وفصلت الكهرباء عن الموقع كله، فتوقفت المباني الأربعة التي تعمل. وفي الأسابيع التالية اكتشف عدد من العملاء أن النسخة الاحتياطية Backup التي دفعوا مقابلها كانت في نفس المبنى الذي احترق، فضاعت مع البيانات الأصلية. وقد ذكرنا هذه الحادثة في سطرين في [دليل اختيار VPS](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%AE%D8%A7%D8%AF%D9%85%D8%A7-%D8%A7%D9%81%D8%AA%D8%B1%D8%A7%D8%B6%D9%8A%D8%A7-vps/#backups-snapshots)، أما هنا فسوف نرويها كاملة من مصادرها الرسمية: تقرير التحقيق الفرنسي، وبيانات OVHcloud نفسها، وأحكام محكمة الاستئناف في قضايا العملاء الذين فقدوا نسخهم، لأن كل جزء منها يعلمك شيئاً عن مكان نسختك الاحتياطية وعن العقد الذي وقعته. وسوف نناقش في هذا المقال ما يلي: - كيف كان موقع ستراسبورغ مبنياً، ولماذا صمم المبنى SBG2 بالشكل الذي ساعد على انتشار النار. - ما حدث في تلك الليلة بالدقيقة، كما في تقرير مكتب التحقيق الفرنسي BEA-RI. - أين بدأ الحريق، وما الذي يعرف وما لا يعرف عن سببه. - أثر الحريق على العملاء، ولماذا فقد بعضهم بياناتهم مع نسخها. - ماذا قالت المحاكم الفرنسية عن عبارة «معزولة مادياً» في عقد خيار النسخ الاحتياطي. - تجربة عملية Lab: سكربت Python يقرأ إعداداتك ويخبرك هل تنجو أي نسخة احتياطية من خسارة الموقع كله. - الدروس: معنى «خارج الموقع» Off-site في قاعدة 3-2-1، وما تقرؤه في العقد قبل أن تعتمد على نسخ المزود. الصورة التالية تبين المباني الخمسة في الموقع وما أصاب كل واحد منها: ![خمسة مبان: SBG1 من Containers على ثلاثة مستويات تضرر جزئياً واحترقت 4 غرف من 12، SBG2 ستة مستويات على هيكل حديد بأرضيات خشب وواجهات تسمح بدخول الهواء دمر بالكامل وفيه 14,046 سيرفراً، SBG3 مبنى خرساني من ستة طوابق تضرر الممر مع SBG2، SBG4 مستوى واحد لم يحترق ولكنه توقف، SBG5 قيد البناء، وتحتها بطاقتان: لماذا توقف كل شيء، وماذا يعني هذا لنسختك الاحتياطية](https://arabroot.io/content/images/2026/10/ovh-fire-01-campus.webp) المباني مستقلة، ولكنها تشترك في الموقع والكهرباء والإطفاء، لذلك توقفت كلها في نفس الليلة ## كيف كان موقع ستراسبورغ مبنياً؟ المرجع الأساسي لهذا المقال هو [تقرير التحقيق رقم MTE-BEARI-2022-005](https://www.igedd.developpement-durable.gouv.fr/IMG/pdf/rapport%5Fovh%5F67%5Fvdif%5Fcle01cf13.pdf?ref=arabroot.io) الصادر في 24 مايو 2022 عن مكتب التحقيق والتحليل في المخاطر الصناعية BEA-RI التابع لوزارة البيئة الفرنسية، وهو منشور مع ملخصه ورد OVH عليه في [صفحة تحقيقات المكتب](https://www.igedd.developpement-durable.gouv.fr/les-enquetes-techniques-a3022.html?ref=arabroot.io). ولاحظ أن التقرير يقول في مقدمته إن هدفه الوحيد منع الحوادث المستقبلية، وإنه لا يحدد المسؤوليات، فهذا عمل المحاكم. يقول التقرير إن الموقع يتكون من خمسة مبان مستقلة بنيت على مراحل مع نمو الشركة، وإن كل مبنى اختار حلاً إنشائياً مختلفاً، والسبب أن معايير الاختيار كانت السرعة في البناء والتكلفة وكفاءة الطاقة، لأن الكهرباء هي أكبر بند في مصاريف تشغيل مركز البيانات Datacenter، ويقاس ذلك بمؤشر فعالية استخدام الطاقة Power Usage Effectiveness واختصاراً PUE: - **SBG1:** بدأ العمل في 2012، وهو حاويات شحن Shipping Containers فوق بعضها على ثلاثة مستويات، في كل واحدة معدات كهربائية وسيرفرات. - **SBG2:** احتفظ بفكرة المبنى المكون من وحدات، ولكن على ستة مستويات مستندة إلى هيكل من الحديد، والوحدات من جدران خرسانية مسبقة الصنع، والأرضيات من الخشب الخام بعد معالجته بطلاء ينتفخ عند الحرارة Intumescent، والواجهات من ألواح بطبقة واحدة أو شرائح ألمنيوم. والهدف كما يقول التقرير تسهيل تبادل الحرارة مع الهواء الخارجي لتقليل الطاقة المستخدمة في التبريد، أي تبريد السيرفرات بهواء الخارج Free Cooling بدل أجهزة التكييف. - **SBG3:** مبنى تقليدي بهيكل خرساني من ستة طوابق. - **SBG4:** يعمل منذ 2013 على مستوى واحد بخيارات تشبه SBG1. - **SBG5:** كان قيد البناء وقت الحريق، بهيكل خرساني على مستوى واحد. ويذكر التقرير أن الموقع كله لم يكن فيه نظام إطفاء تلقائي Automatic Fire Suppression في أي مبنى، وإنما نظام كشف دخان وموظفون مدربون على طفايات الحريق، وأن الدفاع ضد الحريق في المنطقة يعتمد على الشبكة العامة بخط تغذية واحد وحنفية حريق واحدة، وأن المبنى SBG2 كان فيه 800 بطارية من نوع الرصاص Lead-acid وزن كل منها 30 كيلوغراماً. ## ماذا حدث ليلة 10 مارس 2021؟ الصورة التالية تبين أهم الأحداث كما في القسم الخامس من تقرير BEA-RI، والأوقات بالتوقيت المحلي: ![خط زمني من اليسار إلى اليمين: 00:35 إنذار الحريق ودخان في غرفة الطاقة 2، 00:42 الاتصال بالإطفاء، 00:59 وصول الإطفاء وأقواس كهربائية، 01:13 فصل كهرباء الطوارئ عن SBG2، 01:42 الطابق الأول كله، 01:50 فصل المحطة الرئيسية ثم اشتعال SBG2 كله في 02:00، 02:57 وصول قارب الإطفاء EUROPA، 03:28 لا كهرباء في الموقع، 06:45 السيطرة ثم الإطفاء في 10:02](https://arabroot.io/content/images/2026/10/ovh-fire-02-timeline.webp) ساعة كاملة بين الإنذار وفصل الكهرباء عن مصدرها، وفي هذه الساعة صعدت النار إلى الطوابق العليا 1. في الساعة 00:35 انطلق الإنذار في غرفة الأمن، وفي 00:37 وصل الحارس إلى غرفة الطاقة رقم 2 في الطابق الأرضي من SBG2 فوجد دخاناً أسود كثيفاً، وأخلي المبنى في 00:39، واتصلت الشركة بالإطفاء في 00:42\. ولاحظ أن [صفحة OVHcloud عن الحادثة](https://corporate.ovhcloud.com/en/newsroom/news/informations-site-strasbourg/?ref=arabroot.io) تذكر أن الحريق بدأ في 00:47، والفرق بين الرقمين يعود غالباً إلى ما يعتبره كل مصدر بداية، ونحن نعتمد أوقات التقرير. 2. وصل الإطفاء في 00:59، ووجد أقواساً كهربائية Electric Arcs في غرفة الطاقة، فجهز خرطوم الماء وانتظر فصل الكهرباء، لأن رش الماء على معدات كهربائية تعمل يعرض رجال الإطفاء لخطر الصعق. 3. فصلت OVH كهرباء الطوارئ عن SBG2 في 01:13 وعن بقية المباني في 01:28، ولكن الكهرباء من الشبكة كانت ما زالت تصل. وشركة الكهرباء المحلية رفضت أن تعمل على المحطة الفرعية Substation التي تغذي SBG2 لأنها ملك العميل، ولم تحصل على إذن لفصلها من جهة العميل بسبب الحريق، فقررت فصل المحطة الرئيسية التي قبلها عن بعد، وتم ذلك في 01:50. 4. في 01:42 كانت النار قد انتشرت في الطابق الأول كله، وفي 01:49 طلب الإطفاء قارب الإطفاء EUROPA من نهر الراين، لأن حنفية الحريق الوحيدة كانت تعطي أقل من 60 متراً مكعباً في الساعة، وفي 02:00 اشتعل المبنى كله. 5. وصل القارب في 02:57، ومن 03:28 لم تعد هناك كهرباء في الموقع، وسيطر الإطفاء على النار في 06:45، وأطفئت في 10:02، وانتهى التدخل في 18:13. ولم يصب أحد في الحريق، وكانت النتيجة كما يلخصها التقرير: دمار SBG2 بالكامل، واحتراق 4 غرف من 12 في SBG1، وضرر في الممر بين SBG2 وSBG3، ويشرح التقرير أن SBG3 تضرر أقل من SBG1 لأنه محمي بجدار وباب مقاومين للنار لمدة ساعتين، بينما SBG1 بتصميم الحاويات كان أقل حماية من الحرارة. ## أين بدأ الحريق، ولماذا انتشر بهذه السرعة؟ بدأ الحريق في غرف الطاقة التي تحتوي البطاريات وأجهزة الإمداد غير المنقطع Uninterruptible Power Supply واختصاراً UPS، وهي الأجهزة التي تغذي السيرفرات من البطاريات في الثواني الأولى من انقطاع الكهرباء حتى تعمل المولدات. ويقول التقرير إن كاميرات المراقبة ونظام الإنذار يظهران أن عطلاً كهربائياً حدث بشكل شبه متزامن في الساعة 00:35 في جهاز UPS يسميه التقرير ASI2، وفي البطاريات المتصلة به، مع أنهما لم يكونا في نفس الغرفة. وكان هذا الجهاز قد خضع في الأيام السابقة لعمليات صيانة بسبب تحوله المتكرر وغير المفسر إلى وضع التجاوز Bypass Mode، وآخرها صباح نفس اليوم. أما السبب الدقيق فلم يحدده التقرير، والسبب أن هناك تحقيقاً قضائياً بخبراء يفحص معدات مشابهة، فذكر التقرير عدة فرضيات دون أن يرجح بينها: رطوبة أو سائل من نظام التبريد القريب، فقد سجلت المستشعرات ارتفاعاً غريباً في الرطوبة قبل العطل، أو خلل مرتبط بالصيانة، أو تشغيل الجهاز خارج حدوده المعتادة. ولاحظ أن التقرير يذكر أن OVH لم تكن تملك سجلات تشغيل الجهاز (الجهد والتيار ووضع التشغيل) لحظة العطل، وأن البطاريات لم يكن عليها نظام مراقبة. وبحسب [وثيقة التسجيل السنوية لـ OVHcloud عن 2023](https://corporate.ovhcloud.com/sites/default/files/2024-01/2023-11-20-ovh-groupe-urd-fy23-vdef.pdf?ref=arabroot.io) مدد التحقيق القضائي حتى 30 أغسطس 2024 وكان ما زال جارياً وقت نشرها. والجزء الأهم للمهندس هو سبب الانتشار، فالتقرير يقول إن وصول الإطفاء كان سريعاً، ولكن أربعة عوامل اجتمعت فلم تمنع اشتعال SBG2 كله وانتقال النار إلى المباني المجاورة: - **تصميم المبنى:** خلال 15 دقيقة من بداية الحريق انطلقت أجهزة كشف الدخان في كل طوابق SBG2، وهذا بحسب التقرير يدل على نفاذية كبيرة للمبنى للهواء الخارجي وبالتالي للدخان، فالواجهات المفتوحة التي تخدم التبريد بالهواء الخارجي خدمت النار أيضاً، ومعها الأرضيات الخشبية وعدم وجود امتداد للأرضيات خارج الواجهة يمنع النار من الصعود من طابق إلى الذي فوقه. - **عدم وجود إطفاء تلقائي:** لم يكن في أي مبنى من الخمسة نظام إطفاء تلقائي، ويشرح التقرير أن هذا النظام يسمح باستخدام الماء مبكراً جداً دون انتظار فصل الكهرباء ودون تعريض أحد لخطر الصعق. - **مدة فصل الكهرباء:** أكثر من ساعة بين الاتصال بالإطفاء وفصل المحطة الرئيسية، لأن المحطة الفرعية ملك OVH وشركة الكهرباء لم تتدخل فيها، لذلك أوصى التقرير بإجراءات فصل مكتوبة ومجربة مسبقاً مع الإطفاء. - **كمية الماء:** حنفية حريق واحدة بأقل من 60 متراً مكعباً في الساعة، ولا يوجد خزان ماء خاص بالموقع ولا وسيلة لضخ الماء من القناة، حتى وصل قارب الإطفاء. وأوصى التقرير OVH بأن تأخذ هذه الدروس في تصميم مبانيها وغرف الطاقة فيها، وأن تكتب وتجرب مع الإطفاء إجراءات فصل الكهرباء، وأن تدقق كل مواقعها من حيث خطر الحريق، وقد ردت OVH في [رسالة بتاريخ 25 يوليو 2022](https://www.igedd.developpement-durable.gouv.fr/IMG/pdf/reponse%5Fovh%5Fcle6bf493.pdf?ref=arabroot.io) بالإجراءات التي اتخذتها، وأعلنت في وثيقة 2023 أنها افتتحت مبنى SBG5 الجديد في سبتمبر 2022 ضمن خطة سمتها Hyper Resilience. ## ماذا حدث للعملاء وبياناتهم؟ بحسب [تحديث OVHcloud في 23 أبريل 2021](https://corporate.ovhcloud.com/en/newsroom/news/informations-site-strasbourg/?ref=arabroot.io)، أي بعد ستة أسابيع، تأثرت 120,000 خدمة كلياً أو جزئياً، وأعيد منها 113,000 بالكامل حتى ذلك اليوم، واحترق في SBG2 وحده 14,046 سيرفراً. وأعادت الشركة تشغيل SBG3 وSBG4 ونقلت سيرفرات SBG1 السليمة بعد تنظيفها من السخام، وقدمت لعملاء SBG2 سيرفرات بديلة في مراكز أخرى، ولكن السيرفر البديل فارغ، والذي يملأه هو نسختك الاحتياطية. ![لقطة شاشة لموقع Centre Pompidou في متصفح، وعليها رسالة بالفرنسية والإنجليزية تقول إن الموقع غير متاح بسبب الحريق الذي حدث الليلة الماضية في مركز بيانات OVH في ستراسبورغ، مع روابط لحساباتهم على الشبكات الاجتماعية](https://arabroot.io/content/images/2026/10/ovh-fire-03-pompidou.webp) موقع مركز Pompidou الثقافي في باريس بعد الحريق برسالة تقول إن الموقع غير متاح بسبب حريق مركز بيانات OVH في ستراسبورغ. الصورة: Fraguando، بترخيص [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Falla%5Fde%5Fsitio%5Fweb%5FPompidou%5Fpor%5Fincendio%5Fen%5FOVH.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP). وفي [وثيقة التسجيل لعام 2023](https://corporate.ovhcloud.com/sites/default/files/2024-01/2023-11-20-ovh-groupe-urd-fy23-vdef.pdf?ref=arabroot.io) ذكرت الشركة أنها تلقت حتى 31 أغسطس 2023 عدد 523 شكوى وطلب معلومات من عملاء يقولون إنهم تأثروا، وأن معظم طلبات التعويض لمبالغ صغيرة، وأنها خصصت 20.3 مليون يورو لتغطية آثار الحادثة من تكاليف خبراء ومطالبات. والسؤال الذي يهمنا هو: لماذا فقد بعض العملاء بياناتهم نهائياً؟ والإجابة في الأحكام القضائية التالية، لأنها تذكر بالتفصيل أين كانت النسخ. ## ماذا قالت المحاكم عن النسخ الاحتياطي؟ من القضايا التي وصلت إلى محكمة الاستئناف في Douai قضيتان منشورتان على موقع محكمة النقض الفرنسية، وهما مفيدتان لأنهما تعرضان العقد والوقائع كما أثبتتها المحكمة: ### القضية الأولى: خيار نسخ احتياطي في نفس المبنى بحسب [حكم محكمة الاستئناف في Douai بتاريخ 24 أبريل 2025](https://www.courdecassation.fr/decision/680b1bf2c0f38137e6792a54?ref=arabroot.io)، كانت شركة France Bâti Courtage تدير شبكة امتياز تجاري Franchise تعتمد بالكامل تقريباً على مواقعها على الإنترنت، واستأجرت من OVH سيرفراً افتراضياً VPS، واشتركت في أبريل 2018 في خيار «النسخ الاحتياطي التلقائي» بثلاث نسخ يومية. وكان سيرفرها في SBG1، وفي 3 أبريل 2021 أبلغتها OVH أن النسخ الاحتياطية دمرت أيضاً لأنها كانت في نفس المبنى الذي احترق فيه السيرفر الرئيسي، وطالبت الشركة بتعويض قدرته بـ 6.54 مليون يورو. - في يناير 2023 حكمت محكمة Lille التجارية بأن عبارة العقد «مساحة التخزين المخصصة لخيار Backup معزولة مادياً عن البنية التحتية التي يعمل فيها السيرفر الافتراضي للعميل» تعني مكاناً مختلفاً جغرافياً، وأن OVH أخلت بالعقد، وألغت بنود تحديد المسؤولية. - ولكن محكمة الاستئناف عدلت ذلك، فقالت إن «معزولة مادياً» بمعناها العادي تعني بنية منفصلة لا تتصل بالأخرى، دون أن تكون بالضرورة بعيدة جغرافياً، ولاحظ أن OVH قالت، ولم تعترض الشركة، إن النسخ كانت على سيرفر مختلف وفي خزانة Rack مختلفة وغرفة مختلفة، بشبكة وسعة خاصة بها، ولكن في نفس المبنى. - ورفضت المحكمة أن قاعدة 3-2-1 ملزمة لمزود خيار النسخ، لأن العقد ينص بوضوح على أن العميل هو المسؤول عن سياسة النسخ الاحتياطي، ولاحظت أن OVH كانت تبيع وقتها خدمات أخرى للتعافي من الكوارث والنسخ إلى مكان بعيد، منفصلة عن الخيار الذي اشترته الشركة. - وفي المقابل قالت المحكمة إن تنفيذ النسخ التزام بنتيجة، وإن OVH أخلت بالعقد عندما لم تستطع أن تعطي العميل نسخه، ورفضت أن يكون الحريق قوة قاهرة Force Majeure تعفيها، ولكنها طبقت بند تحديد المسؤولية، فكان التعويض النهائي 1,800.48 يورو. ### القضية الثانية: شهر بدون خدمة وفي [حكم نفس المحكمة بتاريخ 4 يونيو 2026](https://www.courdecassation.fr/decision/6a2263c2cdc6046d47394b5f?ref=arabroot.io) كانت جمعية تقدم دروس دعم لطلاب صعوبات التعلم تشغل كل تطبيق إدارتها على VPS في SBG2، وأبلغت هيئة حماية البيانات الفرنسية CNIL عن حادثة بيانات شخصية، ثم أعادت OVH بناء سيرفرها من نسخة قديمة في 5 أبريل 2021، وعرضت عليها الخدمة مجاناً ستة أشهر، وطالبت الجمعية بأكثر من 570 ألف يورو. وانتهت المحكمة إلى رفض القوة القاهرة مرة أخرى، ولكنها قالت إن OVH عوضت الجمعية بالكامل عن الضرر الوحيد الذي يعود إلى إخلالها، وألزمت الجمعية بمصاريف الاستئناف. ⚠️ الدرس من القضيتين ليس قانونياً فقط: عقود الاستضافة عادة تجعل النسخ الاحتياطي مسؤوليتك أنت، وتحدد مسؤولية المزود بمبلغ صغير مقارنة بقيمة بياناتك، وعبارة مثل «معزولة مادياً» قد تعني غرفة أخرى في نفس المبنى. لذلك اسأل مزودك كتابياً: في أي مبنى وأي مدينة تحفظ النسخ؟ وما سقف تعويضك إذا ضاعت؟ ولا تبن خطتك على تفسير أنت تتمناه للعقد. ## ما معنى «خارج الموقع» فعلاً؟ شرحنا قاعدة 3-2-1 في [مقال النسخ الاحتياطي واختبار الاستعادة](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/#rule-321): ثلاث نسخ من البيانات، على نوعين مختلفين من التخزين، وواحدة منها على الأقل خارج الموقع Off-site. ولاحظ أن عملاء ستراسبورغ الذين فقدوا بياناتهم كان أكثرهم يملك أكثر من نسخة، ويملك نوعين مختلفين أحياناً، والذي نقص هو الشرط الثالث، لأن كلمة «الموقع» فهمت على أنها السيرفر أو الغرفة، وليس المكان الذي يمكن أن يحترق أو تنقطع عنه الكهرباء دفعة واحدة. والصورة التالية تبين مستويات البعد بين الأصل والنسخة وما ينجو منه كل مستوى: ![جدول بستة مستويات لمكان النسخة: 1 نفس القرص أو السيرفر لا ينجو من شيء، 2 سيرفر آخر في نفس الغرفة ينجو من عطل القرص والسيرفر، 3 غرفة أخرى في نفس المبنى وهو حالة SBG ينجو من حريق غرفة فقط، 4 مبنى آخر في نفس الموقع لا ينجو دائماً من حريق مبنى ولا من توقف الموقع، 5 منطقة أخرى لدى نفس المزود تنجو من توقف الموقع ولا تنجو من مشكلة في الحساب، 6 مزود آخر ينجو من كل ذلك](https://arabroot.io/content/images/2026/10/ovh-fire-04-backup-distance.webp) خيار النسخ في قضية Douai كان في المستوى 3، والمستوى المطلوب لنسخة «خارج الموقع» هو 5 على الأقل وقد يتساءل البعض: هل تكفي منطقة Region أخرى لدى نفس المزود؟ والإجابة أنها تحميك من الحريق والفيضان وانقطاع الكهرباء في مدينة واحدة، ولكنها لا تحميك من أشياء تصيب حسابك كله: إيقاف الحساب بسبب مشكلة في الدفع، أو مخترق حصل على مفتاح API يحذف كل شيء، أو خطأ من المزود في كل مناطقه معاً. لذلك ننصح بأن تكون نسخة واحدة على الأقل لدى مزود آخر بحساب وصلاحيات مستقلة، أو على جهاز تملكه أنت، وأن تكون غير قابلة للحذف Immutable كما شرحنا في [قسم Immutability](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/#ransomware). وهذا نفس مبدأ الأعطال التي تصيب النسختين معاً الذي شرحناه في [مقال التوفر العالي](https://arabroot.io/articles/%D9%85%D9%81%D8%A7%D9%87%D9%8A%D9%85-%D8%A7%D9%84%D8%AA%D9%88%D9%81%D8%B1-%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%8A-high-availability-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#spof-correlated). ## التجربة العملية: هل تنجو نسخك من خسارة الموقع؟ الحل البسيط هو أن تثق بما كتبته في وثيقة الخطة قبل سنة، ولكن الإعدادات تتغير: أحدهم ينقل الـ Bucket إلى منطقة أقرب لأنها أرخص، أو يضيف سيرفراً جديداً بنسخ المزود فقط. لذلك سوف نكتب سكربتاً صغيراً بلغة Python يقرأ ملف إعدادات بصيغة TOML يصف مكان السيرفر الرئيسي وكل نسخة، ويحدد مستوى البعد بينهما كما في الجدول السابق، ثم يتحقق من شروط 3-2-1\. ولاحظ أن جدول نقاط النهاية Endpoints في السكربت توضيحي، فاملأه بالقيم الحقيقية لمزوديك، وأن السكربت لا يتصل بأي مزود، وإنما يقرأ ما تكتبه أنت أو ما تولده أداة البنية ككود Infrastructure as Code عندك. ```python # check_backups.py: does any backup survive the loss of the primary site? # Reads backups.toml, works out where each copy lives, and checks the 3-2-1 rule. # The endpoint-to-location table is illustrative: fill it with your providers' real values. import re import sys import tomllib # Where an object-storage endpoint lives (provider, region, site). Illustrative values only. ENDPOINTS = [ (r"^s3\.([a-z]+)\.io\.cloud\.ovh\.net$", lambda m: ("ovhcloud", m.group(1), None)), (r"^s3\.([a-z0-9-]+)\.amazonaws\.com$", lambda m: ("aws", m.group(1), None)), (r"^([a-z0-9-]+)\.your-objectstorage\.com$", lambda m: ("hetzner", m.group(1), None)), ] LEVELS = { 1: "same server", 2: "same room", 3: "same building", 4: "same site (campus)", 5: "other region, same provider", 6: "other provider", } def locate(copy): """Return (provider, region, site, building, room, server) for a copy.""" if "endpoint" in copy: host = re.sub(r"^https?://", "", copy["endpoint"]).split("/")[0] for pattern, build in ENDPOINTS: m = re.match(pattern, host) if m: provider, region, site = build(m) return (provider, region, copy.get("site", site), copy.get("building"), None, None) return (None, None, None, None, None, None) # unknown endpoint return tuple(copy.get(k) for k in ("provider", "region", "site", "building", "room", "server")) def level(primary, backup): """How far is the backup from the primary? 1 = same server ... 6 = other provider, 0 = unknown.""" provider, region, site, building, room, server = backup if provider is None: return 0 if provider != primary[0]: return 6 if region != primary[1] or (site and site != primary[2]): return 5 # another site has its own power, access and fire service if building is None or building != primary[3]: return 4 # same campus: an unknown building counts as a shared fate if room is None or room != primary[4]: return 3 if server is None or server != primary[5]: return 2 return 1 def main(path): with open(path, "rb") as f: cfg = tomllib.load(f) primary = locate(cfg["primary"]) print(f"primary : {cfg['primary']['name']} {primary[0]}/{primary[1]}/{primary[2]}/{primary[3]}") offsite, media = 0, {cfg["primary"].get("media", "disk")} for b in cfg["backup"]: where = locate(b) lv = level(primary, where) media.add(b.get("media", "disk")) label = LEVELS.get(lv, "UNKNOWN location: check the endpoint") survives = "survives a site fire" if lv >= 5 else "LOST with the site" if lv == 0: survives = "cannot tell" offsite += lv >= 5 print(f"backup : {b['name']:<26} level {lv} ({label}) -> {survives}") copies = 1 + sum(1 for b in cfg["backup"] if locate(b)[0] is not None) checks = [ (copies >= 3, f"3 copies of the data : {copies}"), (len(media) >= 2, f"2 different media/systems : {', '.join(sorted(media))}"), (offsite >= 1, f"1 copy off-site (level>=5): {offsite}"), ] for ok, text in checks: print(f"{'PASS' if ok else 'FAIL'} {text}") return 0 if all(ok for ok, _ in checks) else 1 if __name__ == "__main__": sys.exit(main(sys.argv[1] if len(sys.argv) > 1 else "backups.toml")) ``` والملف التالي `backups.toml` يصف الحالة التي رأيناها في ستراسبورغ: سيرفر في SBG2 مع Snapshot ليلي على نفس السيرفر، وخيار النسخ الاحتياطي من المزود في غرفة أخرى من نفس المبنى: ```toml # A VPS in Strasbourg with the provider's backup option and a nightly snapshot. [primary] name = "app.example.com" provider = "ovhcloud" region = "sbg" site = "sbg-campus" building = "SBG2" room = "room-3" server = "vps-42" [[backup]] name = "nightly snapshot" provider = "ovhcloud" region = "sbg" site = "sbg-campus" building = "SBG2" room = "room-3" server = "vps-42" [[backup]] name = "provider backup option" provider = "ovhcloud" region = "sbg" site = "sbg-campus" building = "SBG2" room = "room-7" media = "backup-appliance" ``` نشغل السكربت في Container باسم `lab-disaster-ovh` من ال Image `python:3.13.16-slim`، ولا يحتاج أي مكتبة خارجية لأن `tomllib` موجودة في Python منذ الإصدار 3.11: ```bash docker run --rm --name lab-disaster-ovh -v "$PWD:/lab" -w /lab python:3.13.16-slim python -B check_backups.py backups.toml ``` والمخرج سوف يكون كما يلي: ```text primary : app.example.com ovhcloud/sbg/sbg-campus/SBG2 backup : nightly snapshot level 1 (same server) -> LOST with the site backup : provider backup option level 3 (same building) -> LOST with the site PASS 3 copies of the data : 3 PASS 2 different media/systems : backup-appliance, disk FAIL 1 copy off-site (level>=5): 0 exit=1 ``` في المخرج أعلاه لاحظ التالي: - عدد النسخ 3 وأنواع التخزين اثنان، أي أن نصف القاعدة يبدو مطبقاً، وهذا بالضبط ما يجعل المشكلة خفية: لديك نسخ، ولديك فاتورة لخيار النسخ الاحتياطي. - الـ Snapshot في المستوى 1 لأنه على نفس السيرفر، وخيار المزود في المستوى 3 لأنه في غرفة أخرى من نفس المبنى، وكلاهما يضيع إذا احترق الموقع. - السكربت انتهى برمز خروج 1، فتستطيع أن تشغله في خط CI أو مهمة مجدولة Cron Job، وأن ترسل تنبيهاً عندما يفشل. والآن نضيف نسخة بأداة restic إلى تخزين كائنات Object Storage لدى مزود آخر، كما في [تجربة restic مع S3](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/#lab-offsite)، والملف `backups-fixed.toml`: ```toml # The same server, plus a restic repository in another provider's object storage. [primary] name = "app.example.com" provider = "ovhcloud" region = "sbg" site = "sbg-campus" building = "SBG2" room = "room-3" server = "vps-42" [[backup]] name = "provider backup option" provider = "ovhcloud" region = "sbg" site = "sbg-campus" building = "SBG2" room = "room-7" media = "backup-appliance" [[backup]] name = "restic to object storage" endpoint = "https://fsn1.your-objectstorage.com/backups-example" media = "object-storage" ``` ```bash docker run --rm --name lab-disaster-ovh -v "$PWD:/lab" -w /lab python:3.13.16-slim python -B check_backups.py backups-fixed.toml ``` والمخرج سوف يكون كما يلي: ```text primary : app.example.com ovhcloud/sbg/sbg-campus/SBG2 backup : provider backup option level 3 (same building) -> LOST with the site backup : restic to object storage level 6 (other provider) -> survives a site fire PASS 3 copies of the data : 3 PASS 2 different media/systems : backup-appliance, disk, object-storage PASS 1 copy off-site (level>=5): 1 exit=0 ``` ولاحظ أن السكربت عرف مكان النسخة الجديدة من عنوان ال Endpoint وحده، فالاسم `fsn1.your-objectstorage.com` يطابق نمط مزود آخر، فصار المستوى 6 ونجحت الشروط الثلاثة. وأخيراً نجرب الأخطاء التي تحدث في الواقع: Bucket نقل إلى منطقة المزود في نفس المدينة، وBucket في منطقة أخرى، وعنوان فيه خطأ كتابي، والملف `backups-region.toml`: ```toml # Moving the backup bucket to the same provider's storage in the same city does not help. [primary] name = "app.example.com" provider = "ovhcloud" region = "sbg" site = "sbg-campus" building = "SBG2" [[backup]] name = "bucket, same region" endpoint = "https://s3.sbg.io.cloud.ovh.net/backups-example" site = "sbg-campus" media = "object-storage" [[backup]] name = "bucket, other region" endpoint = "https://s3.gra.io.cloud.ovh.net/backups-example" media = "object-storage" [[backup]] name = "typo in endpoint" endpoint = "https://s3.gra.io.cloud.ovh.example/backups" ``` ```bash docker run --rm --name lab-disaster-ovh -v "$PWD:/lab" -w /lab python:3.13.16-slim python -B check_backups.py backups-region.toml ``` والمخرج سوف يكون كما يلي: ```text primary : app.example.com ovhcloud/sbg/sbg-campus/SBG2 backup : bucket, same region level 4 (same site (campus)) -> LOST with the site backup : bucket, other region level 5 (other region, same provider) -> survives a site fire backup : typo in endpoint level 0 (UNKNOWN location: check the endpoint) -> cannot tell PASS 3 copies of the data : 3 PASS 2 different media/systems : disk, object-storage PASS 1 copy off-site (level>=5): 1 exit=0 ``` في المخرج أعلاه لاحظ التالي: - الـ Bucket في منطقة `sbg` صنف في المستوى 4، لأنه لدى نفس المزود وفي نفس الموقع، والسكربت يعتبر المبنى المجهول مبنى مشتركاً في المصير، وهذا افتراض متحفظ مقصود: إذا لم تعرف أين النسخة بالضبط فلا تفترض أنها بعيدة. - الـ Bucket في منطقة `gra` نجا لأنه في منطقة أخرى، ولكن تذكر أنه ما زال لدى نفس المزود وبنفس الحساب. - العنوان الذي فيه خطأ كتابي صنف بمستوى 0 «غير معروف»، ولم يحسب ضمن النسخ، لأن نسخة لا تعرف أين هي ليست نسخة تعتمد عليها. ولا يوجد ما تحذفه بعد التجربة، لأن ال Container حذف تلقائياً بسبب الخيار `--rm`، والملفات في مجلدك فقط. 💡 السكربت يجيب عن سؤال «أين النسخة؟» فقط، ولا يجيب عن سؤال «هل تعمل الاستعادة؟»، وهذا هو السؤال الأهم، فلا تعتبر خطتك صحيحة حتى تستعيد من النسخة البعيدة على سيرفر فارغ وتقيس الوقت، كما في [قسم اختبار الاستعادة تلقائياً](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/#lab-restore-test). ## ماذا نتعلم كمهندسين؟ - **«خارج الموقع» تعني مكاناً لا يحترق مع الأصل:** ليس سيرفراً آخر ولا غرفة أخرى، ولا حتى مبنى آخر في نفس الموقع، وإنما مدينة أو منطقة أخرى على الأقل، ويفضل مزود آخر بحساب مستقل. - **اقرأ عقد النسخ الاحتياطي قبل أن تعتمد عليه:** عقود الاستضافة تجعل سياسة النسخ مسؤوليتك، وتحدد التعويض بمبلغ صغير، و«معزولة مادياً» قد تعني غرفة أخرى، فاسأل عن المدينة والمبنى كتابياً. - **اعرف أين تحفظ نسخك آلياً:** الإعدادات تتغير مع الوقت، فاجعل مكان كل نسخة جزءاً من الإعدادات المكتوبة، وافحصه في خط CI أو بمهمة مجدولة كما في التجربة. - **جهز خطة التعافي قبل أن يطلبها منك المزود:** رسالة «فعل خطة التعافي» في الساعة الرابعة صباحاً مفيدة فقط إذا كانت عندك خطة مكتوبة ومجربة، فيها من أين تستعيد، وعلى أي سيرفر، وكم يستغرق ذلك. - **التوفر شيء والنسخ الاحتياطي شيء آخر:** حتى من لم يفقد بياناته توقف أسابيع، كما في قضية الجمعية، فإذا كانت خدمتك لا تحتمل التوقف فتحتاج نسخة تعمل في موقع آخر، وليس نسخة محفوظة فقط، وقد شرحنا الفرق في [مقال مفاهيم التوفر العالي](https://arabroot.io/articles/%D9%85%D9%81%D8%A7%D9%87%D9%8A%D9%85-%D8%A7%D9%84%D8%AA%D9%88%D9%81%D8%B1-%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%8A-high-availability-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/). - **إذا كنت تدير مركز بيانات أو غرفة سيرفرات:** تقرير BEA-RI درس مجاني: غرف البطاريات والـ UPS هي مصدر الخطر، والإطفاء التلقائي يعمل قبل فصل الكهرباء، وخطة فصل الكهرباء يجب أن تكتب وتجرب مع الدفاع المدني، وسجلات تشغيل الأجهزة يجب أن تحفظ خارج الغرفة نفسها. ## الخلاصة - في ليلة 10 مارس 2021 اشتعل حريق في غرف الطاقة في مبنى SBG2 في موقع OVHcloud في ستراسبورغ، فدمر المبنى بالكامل و4 غرف من 12 في SBG1، وتوقف الموقع كله بعد فصل الكهرباء، دون إصابات. - تقرير BEA-RI الصادر في مايو 2022 لم يحدد السبب الدقيق للعطل في جهاز UPS والبطاريات، ولكنه شرح سبب الانتشار: مبنى مصمم ليدخله الهواء الخارجي للتبريد، وأرضيات خشبية، ولا يوجد إطفاء تلقائي، وساعة حتى فصل الكهرباء، وحنفية حريق واحدة. - تأثرت 120,000 خدمة بحسب OVHcloud، واحترق 14,046 سيرفراً في SBG2، وفقد بعض العملاء بياناتهم لأن النسخ كانت في نفس الموقع أو لم تكن موجودة أصلاً. - محكمة الاستئناف في Douai قالت في 2025 إن «معزولة مادياً» لا تعني بعيدة جغرافياً، وإن العميل مسؤول عن سياسة النسخ، وطبقت سقف التعويض في العقد، فكان التعويض 1,800.48 يورو مقابل مطالبة بـ 6.54 مليون. - النسخة «خارج الموقع» في قاعدة 3-2-1 يجب أن تكون في منطقة أخرى على الأقل، ويفضل لدى مزود آخر بحساب مستقل، واختبر الاستعادة منها فعلاً. - في التجربة كتبنا سكربتاً يقرأ مكان كل نسخة ويصنفها من المستوى 1 إلى 6، ويفشل إذا لم توجد نسخة تنجو من خسارة الموقع. وإذا أردت أن تكمل من هنا، فهذه المقالات تشرح النسخ الاحتياطي والتوفر واختيار المزود، وبقية كوارث هذه المرحلة: [![](https://arabroot.io/content/images/2026/10/backup-321-cover-cover.webp)دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)[![](https://arabroot.io/content/images/2026/10/backup-tools-compare-cover-cover.webp)دليلأي أداة نسخ احتياطي Backup تناسب سيرفرك؟مقارنة عملية لأشهر أدوات النسخ الاحتياطي مفتوحة المصدر على البيانات نفسها في الوقت والحجم والذاكرة، لتعرف أيها يناسب سيرفرك.](https://arabroot.io/articles/restic-%D8%A3%D9%85-borg-%D8%A3%D9%85-kopia/)[![](https://arabroot.io/content/images/2026/10/ha-concepts-cover-cover.webp)دليلمفاهيم التوفر العالي High Availability للمبتدئينماذا يعني أن تبقى خدمتك تعمل رغم تعطل جزء منها، وكيف تحسب التوفر وتجد نقاط الفشل الواحدة وتقرر متى يستحق ذلك تكلفته.](https://arabroot.io/articles/%D9%85%D9%81%D8%A7%D9%87%D9%8A%D9%85-%D8%A7%D9%84%D8%AA%D9%88%D9%81%D8%B1-%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%8A-high-availability-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/choose-vps-cover-cover-2.webp)دليلكيف تختار خادماً افتراضياً VPSكم تحتاج من المعالج والذاكرة والقرص، وما الذي يميز مزوداً عن آخر غير السعر، حتى تختار VPS يناسب احتياجك.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%AE%D8%A7%D8%AF%D9%85%D8%A7-%D8%A7%D9%81%D8%AA%D8%B1%D8%A7%D8%B6%D9%8A%D8%A7-vps/)[![](https://arabroot.io/content/images/2026/10/att-1990-cover-cover.webp)دليلانهيار شبكة AT&T سنة 1990: تحديث برمجي أسقط 114 مقسماًكيف حول خلل في تحديث برمجي عطلاً عادياً في مقسم واحد إلى انهيار شبكة AT&T تسع ساعات، وماذا تتعلم عن اختبار مسار الاستعادة.](https://arabroot.io/articles/%D8%A7%D9%86%D9%87%D9%8A%D8%A7%D8%B1-%D8%B4%D8%A8%D9%83%D8%A9-att-%D8%B3%D9%86%D8%A9-1990/)[![](https://arabroot.io/content/images/2026/10/mars-climate-orbiter-cover-cover.webp)دليلMars Climate Orbiter: مسبار ضاع بسبب وحدة قياسكيف أضاع رقم بالرطل قرأه برنامج آخر بالنيوتن مسباراً كاملاً على المريخ، وكيف تمنع خطأ الوحدات في واجهات أنظمتك.](https://arabroot.io/articles/%D9%85%D8%B3%D8%A8%D8%A7%D8%B1-mars-climate-orbiter-%D9%88%D9%88%D8%AD%D8%AF%D8%A7%D8%AA-%D8%A7%D9%84%D9%82%D9%8A%D8%A7%D8%B3/)[![](https://arabroot.io/content/images/2026/10/therac-25-cover-cover.webp)دليلTherac-25: حين أصبح خطأ برمجي خطراً على المرضىكيف تسبب سباق بين مهمتين وعداد من بايت واحد في جرعات إشعاع زائدة، وماذا تتعلم منها عن الأنظمة الحرجة وكودك اليومي.](https://arabroot.io/articles/%D8%AC%D9%87%D8%A7%D8%B2-therac-25-%D9%88%D8%A3%D8%AE%D8%B7%D8%A7%D8%A1-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D8%A7%D9%84%D8%AD%D8%B1%D8%AC%D8%A9/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال اعتماداً على تقرير BEA-RI رقم MTE-BEARI-2022-005 ورد OVH عليه، وصفحة حالة الخدمات وصفحة الأخبار في OVHcloud، ووثيقة التسجيل السنوية لـ OVHcloud لعام 2023، وحكمي محكمة الاستئناف في Douai في 24 أبريل 2025 و4 يونيو 2026، مع تجربة عملية على Python 3.13.16، ورسوم توضيحية من عملنا.