 |
| أمازون تعلن فقدان بيانات نهائيًا.. ماذا حدث لـAWS في البحرين والإمارات؟ |
في تطور صادم يكشف أحد أخطر جوانب الاعتماد على الخدمات السحابية، أكدت Amazon Web Services (AWS) أنها لم تعد قادرة على استعادة بعض البيانات والموارد الخاصة بالعملاء في البحرين وإحدى مناطق توافر الخدمات في الإمارات، بعد تعرض البنية التحتية لأضرار كبيرة.
لكن القصة ليست أن «أمازون فقدت كل بيانات عملائها»، كما قد توحي بعض العناوين المتداولة، وإنما تتعلق بالبيانات التي كانت موجودة حصريًا داخل البنية المتضررة ولم تكن لها نسخة أخرى متاحة للاستعادة.
وتكشف الواقعة درسًا مهمًا لأي شركة تعتمد على السحابة: وجود البيانات على خوادم شركة ضخمة مثل AWS لا يعني تلقائيًا أن لديك نسخة احتياطية مستقلة عنها.
ماذا حدث لبيانات AWS في البحرين والإمارات؟
بحسب تقرير نشرته وكالة رويترز في 15 سبتمبر 2026، قالت AWS إنها غير قادرة على استعادة الوصول إلى بنيتها السحابية في البحرين، كما لم تتمكن من استعادة الموارد والبيانات الموجودة حصريًا في إحدى مناطق توافر الخدمات داخل الإمارات، والمعروفة باسم mec1-az2.
وأوضحت AWS أن الأضرار في البحرين امتدت إلى عدة مناطق توافر، وتجاوزت المستوى الذي صُممت خدماتها الإقليمية وخدمات التكرار متعددة المناطق لتحمله.
أما في الإمارات، فما زالت AWS تعمل على استعادة الموارد في بقية المنطقة، بينما أصبحت البيانات والموارد التي كانت موجودة حصريًا في المنطقة المتضررة غير قابلة للاستعادة.
تقرير رويترز عن حادث AWS في البحرين والإمارات
هل فقدت أمازون بيانات جميع عملاء AWS؟
لا. هذه أهم نقطة يجب توضيحها حتى لا يتحول الخبر إلى معلومة مضللة.
الفقدان يتعلق بالبيانات والموارد التي كانت موجودة بشكل حصري في البنية المتضررة ولم تكن هناك نسخة أخرى يمكن استخدامها لاستعادتها.
أما العملاء الذين كانت لديهم نسخ احتياطية أو نسخ مكررة في مناطق أخرى، فقد تمكنوا من استخدام هذه النسخ لإعادة تشغيل أعمالهم أو نقل عملياتهم إلى مناطق AWS بديلة.
وقالت AWS إن معظم العملاء المتأثرين تمكنوا من إعادة تشغيل عملياتهم في مناطق أخرى باستخدام النسخ الاحتياطية المتاحة أو حلول بديلة.
لماذا لم تكن السحابة كافية لحماية هذه البيانات؟
هنا تكمن أهم نقطة في القصة.
عندما يسمع المستخدم عبارة «البيانات محفوظة على السحابة»، قد يتخيل أن هناك نسخًا لا نهائية من ملفاته موزعة في جميع أنحاء العالم. لكن الواقع أكثر تعقيدًا.
طريقة حماية البيانات تعتمد على كيفية إعداد الخدمة من جانب العميل، وعلى المنطقة التي اختارها، وعلى ما إذا كان يستخدم التكرار بين المناطق أو يحتفظ بنسخ احتياطية مستقلة.
ولهذا فإن الاعتماد على بنية سحابية واحدة لا يعني بالضرورة أن البيانات يمكن استعادتها إذا تعرضت البنية بأكملها لحدث استثنائي واسع النطاق.
وهذه الفكرة ترتبط بما تناولناه سابقًا في TechStar حول مدى اعتماد العالم الحديث على البنية الرقمية والخدمات المتصلة بالإنترنت في مقال ماذا سيحدث لو اختفى الإنترنت من العالم لمدة 24 ساعة؟، لكن حادث AWS يقدم هذه المرة مثالًا واقعيًا على هشاشة بعض أجزاء هذه البنية.
ما المقصود بـ Availability Zone؟
لفهم ما حدث، يجب أولًا معرفة معنى Availability Zone.
تستخدم AWS هذا المصطلح للإشارة إلى مناطق منفصلة داخل المنطقة السحابية الواحدة، وتضم كل منطقة توافر بنية تحتية مستقلة نسبيًا من مراكز البيانات والطاقة والتبريد والاتصالات.
الفكرة الأساسية هي تقليل تأثير الأعطال؛ فإذا تعرض جزء من البنية لمشكلة، يمكن للخدمات المصممة بشكل صحيح الاستمرار باستخدام أجزاء أخرى.
لكن الضرر الذي حدث في البحرين امتد إلى عدة Availability Zones، وهو ما جعل نطاق المشكلة أكبر من الأعطال التقليدية التي صُممت البنية متعددة المناطق للتعامل معها.
وثائق AWS الرسمية حول المناطق ومناطق التوافر
التكرار ليس هو النسخ الاحتياطي
من أكثر الأخطاء شيوعًا في التعامل مع البيانات السحابية الخلط بين Replication وBackup.
التكرار يعني وجود البيانات أو الخدمة في أكثر من مكان بهدف استمرار التشغيل وتقليل تأثير الأعطال.
أما النسخ الاحتياطي فهو إنشاء نسخة يمكن الرجوع إليها عند فقدان البيانات الأصلية، ويفضل أن تكون النسخة معزولة أو بعيدة عن البنية الأساسية الأصلية.
وهذا الفرق مهم للغاية؛ لأن وجود عدة نسخ داخل النطاق نفسه قد لا يكون كافيًا إذا تعرض النطاق بأكمله لحدث استثنائي.
ماذا حدث للبيانات التي لم تكن لها نسخة أخرى؟
قالت AWS إنها أجرت تقييمًا للبنية التحتية المتضررة، وخلصت إلى أنها استنفدت الخيارات المتاحة لاستعادة البيانات والموارد التي لم يتم نقلها قبل توقف المنطقة المتضررة.
وهذا يعني أن بعض البيانات التي كانت موجودة حصريًا في تلك البنية لم يعد بالإمكان استعادتها من جانب AWS.
وفي الإمارات، يتركز هذا الوضع في منطقة mec1-az2، بينما تستمر أعمال الاستعادة في الموارد الموجودة في بقية المناطق المتأثرة.
لماذا يعتبر الخبر مهمًا لمراكز بيانات الذكاء الاصطناعي؟
لا تتعلق أهمية الخبر بالتخزين السحابي فقط، بل تمتد إلى مستقبل مراكز البيانات التي أصبحت أساسًا لتشغيل خدمات الذكاء الاصطناعي.
وفي سبتمبر 2026، نشر TechStar تقريرًا عن دخول كوالكوم وأمازون في سباق شرائح الذكاء الاصطناعي ومراكز البيانات، وهو ما يوضح مدى توسع استثمارات أمازون في البنية التحتية الحاسوبية.
لكن كلما زاد الاعتماد على مراكز البيانات، أصبحت مسألة حماية هذه المراكز واستمراريتها أكثر أهمية، خصوصًا عندما تحتوي على كميات هائلة من بيانات العملاء والأنظمة التي تعتمد عليها الشركات.
هل يمكن أن يتأثر المستخدم العادي بمشكلة مثل هذه؟
قد يعتقد المستخدم العادي أن الحادث بعيد عنه لأنه لا يستخدم AWS بشكل مباشر، لكن الكثير من التطبيقات والمواقع والخدمات الرقمية تعتمد على البنية السحابية في الخلفية.
ومع ذلك، لا يعني ذلك أن كل تطبيق يستخدم AWS معرض لفقدان بياناته.
التأثير يعتمد على تصميم الخدمة، ومكان تخزين البيانات، وطريقة النسخ الاحتياطي، وما إذا كانت الشركة تستخدم أكثر من منطقة أو تمتلك نسخة مستقلة يمكن استعادتها.
ما الذي يجب أن تتعلمه الشركات من حادث AWS؟
الدرس الأهم ليس أن الخدمات السحابية غير آمنة، وإنما أن خطة استعادة البيانات يجب ألا تعتمد على مزود الخدمة وحده.
الشركات التي تعتمد على قواعد بيانات أو ملفات أو أنظمة تشغيلية مهمة تحتاج إلى وضع خطة للتعامل مع أسوأ السيناريوهات، وليس فقط الأعطال البسيطة.
- الاحتفاظ بنسخ احتياطية خارج المنطقة الجغرافية الأساسية.
- استخدام أكثر من Availability Zone عندما يكون ذلك مناسبًا.
- تقييم الحاجة إلى النسخ بين مناطق AWS المختلفة.
- اختبار استعادة النسخ الاحتياطية بصورة دورية.
- الاحتفاظ بنسخة مستقلة للبيانات شديدة الأهمية.
- تحديد البيانات التي لا يمكن للشركة تحمل فقدانها.
هل السحابة أكثر أمانًا من التخزين المحلي؟
لا توجد إجابة واحدة تناسب جميع الحالات.
الخدمات السحابية توفر إمكانات ضخمة للتكرار والاستمرارية والاستعادة، وتستثمر شركات مثل AWS مبالغ هائلة في البنية التحتية التي يصعب على الشركات الصغيرة بناء مثيل لها.
لكن الحماية النهائية تعتمد أيضًا على طريقة إعداد الخدمة من جانب العميل.
فإذا اختار العميل تخزين بياناته في منطقة واحدة فقط ولم ينشئ نسخة مستقلة أو خطة استعادة مناسبة، فإن اسم مزود الخدمة وحده لا يضمن إمكانية استعادة البيانات بعد كارثة واسعة النطاق.
أمازون لم تفقد كل بيانات عملائها
من الضروري التفريق بين ما أكدته AWS وبين العناوين المبالغ فيها.
AWS أكدت عدم قدرتها على استعادة بعض الموارد والبيانات التي كانت موجودة حصريًا في البنية المتضررة في البحرين، وكذلك في منطقة mec1-az2 بالإمارات.
وفي المقابل، تمكن معظم العملاء المتأثرين من نقل عملياتهم إلى مناطق أخرى، باستخدام النسخ الاحتياطية أو حلول بديلة عندما كانت متاحة.
لذلك فإن الصياغة الأدق للخبر هي أن بعض بيانات AWS أصبحت غير قابلة للاستعادة، وليس أن أمازون فقدت بيانات جميع عملائها.
ما الدرس الأكبر من حادث AWS؟
قد يكون أهم درس في هذه القصة بسيطًا جدًا:
لا تسأل فقط أين توجد بياناتك، بل اسأل أين توجد النسخة التي ستستخدمها إذا اختفى المكان الأول.
الاعتماد على السحابة يمكن أن يمنح الشركات مرونة هائلة، لكن المرونة الحقيقية تحتاج إلى تصميم صحيح للنسخ الاحتياطي والتعافي من الكوارث.
فإذا كانت كل نسخ البيانات مرتبطة في النهاية بالبنية نفسها أو بالمنطقة نفسها، فإن الشركة قد تكتشف في أسوأ لحظة أن «وجود نسخة» لا يعني بالضرورة امتلاك نسخة يمكن استخدامها.
الخلاصة
أكدت AWS في سبتمبر 2026 أنها لم تعد قادرة على استعادة بعض البيانات والموارد الموجودة حصريًا في بنيتها المتضررة في البحرين، إضافة إلى الموارد والبيانات الموجودة حصريًا في منطقة mec1-az2 داخل الإمارات.
لكن الحادث لا يعني فقدان بيانات جميع عملاء AWS؛ فقد تمكن معظم العملاء المتأثرين من استعادة عملياتهم باستخدام نسخ احتياطية أو نقل أعمالهم إلى مناطق أخرى.
القصة تقدم درسًا مهمًا للشركات والمستخدمين: السحابة ليست بديلًا عن النسخ الاحتياطي.
وكلما أصبحت البيانات أكثر أهمية، يجب أن تكون هناك خطة واضحة للإجابة عن سؤال واحد: ماذا سنفعل إذا اختفت المنطقة التي تحتوي على بياناتنا بالكامل؟
المصادر
- Reuters – Amazon AWS غير قادرة على استعادة بعض بيانات البحرين والإمارات
- AWS Documentation – Regions and Availability Zones
- AWS Health Dashboard
تاريخ التحديث: سبتمبر 2026
