النسخ الاحتياطي السحابي: ما لا تستطيع AWS استعادته

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

سأكون صريحًا: معظم الشركات التي أعمل معها لا تملك نسخًا احتياطية. تملك شعورًا بالنسخ الاحتياطي. وهما شيئان مختلفان.

"لكنها في السحابة، أليست آمنة؟"

هذا هو الالتباس الأغلى ثمنًا في التقنية اليوم.

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

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

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

هذه ليست فرضية، فقد حدثت مرات عديدة

الحرب تبدو بعيدة. فلنأخذ أمثلة أقرب.

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

في 2014، تعرضت Code Spaces، التي كانت تستضيف الأكواد لشركات أخرى، لهجوم. دخل المهاجم إلى لوحة إدارة AWS ومسح البيانات مع النسخ الاحتياطية، لأن النسخ الاحتياطي والإنتاج كانا في الحساب نفسه وبالبيانات نفسها. أعلنت الشركة إغلاق عملياتها خلال أقل من 24 ساعة.

في 2023، فقد مزوّد كوري جنوبي بيانات عملاء حين شفّر برنامج فدية الإنتاج والنسخ الاحتياطية المتصلة به. النمط يتكرر: النسخة الاحتياطية كانت موجودة، لكنها كانت في متناول المشكلة نفسها.

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

ما تحتاج فعلًا أن تحتفظ به خارج سحابة مزوّدك

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

للشركات الصغيرة والمتوسطة التي تعمل على SaaS، أكيّفها هكذا:

• نسخة خارج المزوّد الأساسي. إذا كان نظامك يعمل على AWS، فلا يمكن أن تكون النسخة الاحتياطية على AWS وحدها. يمكن أن تذهب إلى Google Cloud، أو إلى تخزين رخيص مثل Backblaze، أو حتى إلى جهاز NAS في المكتب.
• نسخة لا يستطيع نظام الإنتاج مسحها. بيانات دخول منفصلة، حساب منفصل، ويفضّل مع منع الحذف لفترة محددة (الثبات). هذا ما ينقذك من برامج الفدية ومن موظف غاضب.
• نسخة بصيغة تستطيع قراءتها دون المزوّد. CSV أو JSON أو PDF أو SQL. إذا كانت نسخة الـ CRM لا تُفتح إلا داخل الـ CRM نفسه، والـ CRM اختفى، فأنت تملك ملفًا جميلًا وعديم الفائدة.

النقطة الثالثة هي الأكثر نسيانًا والأكثر أهمية في SaaS. أنت لست في سحابة البنية التحتية فقط. أنت في Bling، وOmie، وRD Station، وNotion، وClickUp، وWhatsApp Business. كل واحد منها يحفظ جزءًا من عملك. وكل واحد منها قد يحظرك للاشتباه في احتيال بالبطاقة، أو يلغي خطة، أو ببساطة يتعطل.

الاختبار الذي لا يقوم به أحد تقريبًا

إليك السؤال الذي أطرحه في كل اجتماع أول، والذي يوقف الحديث دائمًا تقريبًا: متى آخر مرة استعدت فيها نسخة احتياطية؟

لا "ولّدت". لا "تحققت من وجود الملف". استعدت فعلًا، وفتحت، ونظرت إلى البيانات، وتأكدت أن كل شيء هناك.

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

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

1. هل بيانات الأيام السبعة الأخيرة موجودة؟
2. هل تُفتح المرفقات والصور؟
3. كم استغرق هذا، من الصفر حتى التشغيل؟

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

كم من الوقت وكم من البيانات تتحمل أن تخسر

سؤالان يحلان 90% من التخطيط، ولا واحد منهما تقني.

كم من الوقت يتحمل العمل أن يتوقف؟ ساعة؟ يوم؟ أسبوع؟ متجر إلكتروني متوقف ليومٍ يخسر مبيعات ثم يتعافى. عيادة بلا ملفات مرضى ليومٍ تلغي جدولها كله وتضر بسمعتها.

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

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

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

ما يمكنك فعله هذا الأسبوع

لا تحتاج مشروعًا من ستة أشهر. تحتاج بعد ظهر يوم واحد.

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

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

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

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

حذّرت AWS عملاءها من أن جزءًا من البيانات لن يعود ببساطة. لا "سيتأخر". لن يعود.

معظم الشركات التي أعمل معها لا تملك نسخًا احتياطية. تملك شعورًا بالنسخ الاحتياطي.

السحابة تعتني بالبنية التحتية. بياناتك تبقى مسؤوليتك أنت، وهذا مكتوب في العقد.

والسؤال الذي يوقف الاجتماع دائمًا تقريبًا: متى آخر مرة استعدت فيها نسخة احتياطية فعلًا؟ لا أن تولّدها. أن تستعيدها وتفتحها وتتحقق منها.

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

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

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

#النسخ_الاحتياطي #الحوسبة_السحابية #إدارة_المخاطر #التقنية #الشركات_الصغيرة