تأسست Partnerfy لتقدّم للشركات حلولًا متكاملة من البداية إلى النهاية في البرمجيات والتسويق الرقمي، وهي الشريك التقني الموثوق للوكالات والعلامات التجارية.
هل ترغب في برمجة المستقبل معنا؟
«هل لديك نسخ احتياطية؟»: يجب أن تكون الإجابة نعم، لكن هذا لا يكفي. السؤال الحقيقي هو: «هل نستطيع الاستعادة فعلًا، وفي كم من الوقت، وبكم من فقدان البيانات؟» نسخ احتياطية مشفّرة كل ساعة، وثلاث نسخ على وسيطين مختلفين إحداها خارج الموقع، وتخزين WORM غير قابل للتعديل (Immutable)، وتدريبات استعادة حقيقية كل ثلاثة أشهر، وأهداف RPO/RTO واضحة: هذا وحده ما يهم في اليوم العصيب.
الاستعادة التي لم تُختبر ليست نسخة احتياطية، بل مجرد أمل. نحن لا نبيع الأمل، بل نقدّم أزمنة تعافٍ قابلة للقياس وتقارير استعادة موثّقة.
عند تعطل النظام الأساسي يتولى النظام الثانوي المهمة تلقائيًا، وقد تأكدنا من ذلك بتدريبات حقيقية.
الحقيقة المُرّة الأولى: الغالبية العظمى من النسخ الاحتياطية لا تُختبر أبدًا. تعمل مهمة Cron كل ليلة، ويظهر «OK» في السجل، وتضيء لوحة المراقبة باللون الأخضر، لكن عندما تحاول استعادة تلك النسخة فعلًا تجد الملفات تالفة، أو مفتاح فك التشفير مفقودًا، أو إصدار المخطط غير متوافق. النسخة الاحتياطية لا تكون نسخة احتياطية حقًا حتى تُستعاد بنجاح، وقبل ذلك فهي مجرد أمل. لذلك نُلزم كل عميل بتدريب استعادة كامل مرة كل ثلاثة أشهر على الأقل، ونوثّق النتيجة.
المشكلة الثانية: كثير مما يُسمّى «نسخة احتياطية» هو في الواقع لقطة (Snapshot) موجودة على خادم الإنتاج نفسه. نسخة تتشارك القرص نفسه، ويستطيع الحساب نفسه الكتابة عليها، وستحترق في الحريق نفسه: هذه ليست نسخة احتياطية، بل اسم ثانٍ للبيانات نفسها. فعند عطل في العتاد، أو هجوم ببرامج الفدية (Ransomware)، أو حذف جدول عن طريق الخطأ، تختفي هذه «النسخة» مع بيانات الإنتاج. يجب أن تكون النسخة الاحتياطية الحقيقية على نظام منفصل، وتحت هوية منفصلة، ويُفضّل أن تكون في موقع جغرافي منفصل.
المشكلة الثالثة: لا توجد نسخة خارج الموقع. النسخة الاحتياطية الموجودة في مركز بيانات واحد أو منطقة سحابية واحدة يتعذر الوصول إليها عند انقطاع تلك المنطقة، أو وقوع كارثة طبيعية فيها، أو تعليق الحساب. فقد توقف AWS منطقة كاملة، وقد تقفل Microsoft حسابًا خلال ساعات، وقد يستمر حريق مركز بيانات لساعات، وفي هذه السيناريوهات تكون النسخة خارج الموقع الفاصل الوحيد بين استمرارية الأعمال والإفلاس. الرقم «1» في قاعدة 3-2-1 غير قابل للتفاوض.
المشكلة الرابعة: نسخ احتياطية غير مشفّرة. ملف النسخة الاحتياطية هو نسخة كاملة من قاعدة بيانات الإنتاج لديك، أي إن جميع سجلات عملائك، وآثار بطاقات الائتمان، وتجزئات كلمات المرور، ومراسلاتك الداخلية موجودة داخل ملف tar.gz واحد. وعند سرقة هذا الملف يبقى الاختراق اختراقًا، ولن تعفيك اللائحة العامة لحماية البيانات (GDPR) ولا قانون حماية البيانات الشخصية التركي رقم 6698 (KVKK) لمجرد أنه نسخة احتياطية. يجب تشفير جميع النسخ الاحتياطية أثناء التخزين (AES-256) وأثناء النقل (TLS 1.3)، مع حفظ المفاتيح في KMS منفصل عن نظام النسخ الاحتياطي نفسه، وإلا أصبحت النسخة الاحتياطية سطح هجوم لا وسيلة دفاع.
المشكلة الخامسة: النسخ غير محصّنة ضد التعديل (Immutability). برامج الفدية الحديثة لا تكتفي بتشفير بيانات الإنتاج، إذ يتسلل المهاجم أولًا إلى نظام النسخ الاحتياطي، فيحذف نسخ الأشهر الثلاثة الأخيرة أو يُبطلها، ثم يشفّر بيئة الإنتاج. وإذا كانت حسابات النسخ الاحتياطي تتشارك الدليل نفسه وشبكة VPN نفسها وتسجيل SSO نفسه مع بيئة الإنتاج، فستصل إليها برامج الفدية أيضًا. الحل هو طبقة يستحيل فيها الحذف رياضيًا حتى بصلاحيات المسؤول: تخزين WORM (الكتابة مرة واحدة والقراءة مرات عديدة) وS3 Object Lock وVeeam Hardened Repository ونسخة غير متصلة معزولة تمامًا عن الشبكة (Air-Gapped).
مخطط زمني للاستعادة، ومحاكاة لتنظيف برامج الفدية، ولوحة لمقارنة قيم RPO/RTO المستهدفة: أدوات تجعل قراراتك بعد الكارثة قابلة للقياس مسبقًا.
لقطات كل ساعة، ونسخ كاملة يومية، ودمج أسبوعي، وأرشيف شهري. ويمكن اختيار نقطة الاستعادة بدقة الثانية.
بيانات مشفّرة، ثم استعادة من نسخة احتياطية غير قابلة للتعديل، ثم بيانات نظيفة تحمل علامة صح خضراء.
اطّلع بنظرة واحدة على الفرق بين سيناريو «بلا نسخ احتياطي» وبنيتنا.
ساعة واحدة من فقدان البيانات تعني مئات الطلبات، وآلاف حركات المخزون، ومطابقات دفع مختلّة.
لا يُعد استرجاع الجدول بالكامل خيارًا لاستعادة بيانات مستأجر واحد.
يجب الاحتفاظ بسجلات المرضى لسنوات وبطريقة قابلة للتدقيق، وأي فقدان لها يُعد مخالفة لمتطلبات KVKK وHIPAA القانونية.
يجب الاحتفاظ بسجلات BDDK وSPK وMASAK (الجهات الرقابية المالية في تركيا) لسنوات دون حذف أو تعديل.
إذا فقدت ملفات التصميم ومشاريع الفيديو ومستودعات الشيفرة، فستضطر إلى الاتصال بعملائك واحدًا تلو الآخر.
بيتابايتات من اللقطات الخام ومواد تاريخية لا يمكن إعادة إنتاجها: الأمر يتطلب بنية مخصصة.
إذا فُقدت إعدادات وحدة تحكم واحدة، يتوقف خط الإنتاج لساعات.
يجب أن تكون الشهادات وكشوف الدرجات وسجلات الحضور مستمرة ودائمة وقابلة للتدقيق.
من تصميم الاستراتيجية إلى دليل التشغيل (Runbook)، عشر طبقات في باقة واحدة: لا إغفال لأي منها ولا حشو في أي منها.
تحليل تأثير الأعمال، وجرد الأصول، ومصفوفة لقيم RPO/RTO المستهدفة، وأهداف منصوص عليها في العقد.
جهاز نسخ احتياطي مادي أو افتراضي في موقعك لاستعادة أسرع.
نسخ متماثل غير متزامن أو متزامن إلى مركز بيانات آخر أو منطقة سحابية أخرى.
نسخ احتياطية محسّنة التكلفة على S3 وBlob وGCS بسياسات لإدارة دورة الحياة.
الطبقة التي لا يمكن حذفها (S3 Object Lock وWasabi Compliance وVeeam Hardened).
سجلات المعاملات والتغييرات في قواعد البيانات (PostgreSQL WAL وMySQL binlog وMongoDB oplog وMSSQL transaction log).
صور قرص متسقة أثناء الكتابة عبر VSS وfsfreeze وخطافات التنفيذ قبل اللقطة وبعدها.
استعادة دورية في بيئة Sandbox مع التحقق من السلامة وإصدار تقرير.
خطة مكتوبة خطوة بخطوة: من ينفّذ، ومن يوافق، ومن يوثّق.
إطلاق التنبيه، ثم العزل، ثم التحليل الجنائي الرقمي، ثم الاستعادة، وصولًا إلى صورة نظيفة مثبتة جنائيًا.
نحدد مدى أهمية كل نظام، وحجم فقدان البيانات المقبول، ومدة التعافي، ونجري تحليل تأثير الأعمال.
ثلاث نسخ، ووسيطان مختلفان، وطبقة خارج الموقع، مع توثيق عدم القابلية للتعديل والتشفير ونموذج الوصول.
نشغّل الجهاز المحلي والحساب السحابي وعزل الشبكة والمراقبة والتنبيهات.
دورة كل ساعة ويوميًا وأسبوعيًا وشهريًا، وتشفير AES-256 أثناء التخزين وTLS أثناء النقل، ومفاتيح منفصلة في نظام KMS مستقل.
استعادة وفق سيناريوهات حقيقية، ومقارنة قيم RPO/RTO المقيسة بأهداف العقد، وتصحيح الانحرافات.
لوحات لنجاح النسخ واتجاه التخزين ومدة الاستعادة، وتقرير شهري، ومراجعة سنوية للبنية.
لا نبيع أي أداة بمعزل عن غيرها. نصمم بنيتك، ونوضح الأداة المناسبة لكل طبقة، ونعرض التكلفة الإجمالية للملكية بشفافية.
تعرّض متجر يضم 250 ألف وحدة SKU للتشفير يوم الجمعة الساعة 03:14 صباحًا، وعاد الإنتاج بالكامل خلال 38 دقيقة من نسخة Wasabi غير القابلة للتعديل، دون فقدان أي طلب.
حذف مطوّر جدولًا في بيئة الإنتاج، فأتاح PostgreSQL PITR استعادة متسقة بالكامل خلال 4 دقائق.
اجتاز مستشفى تدقيق PHI لفترة 7 سنوات، وثبت اكتمال السجلات في الأرشيف غير القابل للتعديل إثباتًا رياضيًا.
سُرق الحاسوب المحمول لمصمم أول، لكن 2 TB من تسليمات العملاء كانت تُنسخ عبر Restic كل ساعة إلى خارج الموقع.
نُقل أرشيف اللقطات الخام لإحدى جهات البث إلى تخزين متعدد المستويات، فحقق S3 النشط مع Glacier Deep Archive وفرًا بنسبة 63% سنويًا.
انقطاع في منطقة AWS eu-central-1 أعقبه تحويل تلقائي لكل من DNS وقاعدة البيانات إلى eu-west-1 خلال 11 دقيقة، دون انقطاع حركة العملاء.
لا، اللقطة وحدها ليست نسخة احتياطية. فاللقطة هي «صورة» لقرص أو وحدة تخزين في لحظة محددة، ومعظم اللقطات تبقى على نظام التخزين نفسه، بل على القرص نفسه أحيانًا، أي إنك إذا فقدت بيانات الإنتاج فقدت اللقطة معها. كما أن عطل العتاد، وانهيار نظام التخزين، وبرامج الفدية، وأخطاء المسؤولين تصيب اللقطة أيضًا. اللقطة طبقة أولى ممتازة للاستعادة السريعة جدًا (يمكنك العودة خلال ثوانٍ)، لكن للحصول على نسخة احتياطية حقيقية يجب نسخها إلى نظام منفصل، وتحت هوية منفصلة، ويُفضّل في موقع جغرافي منفصل. وفي بنيتنا تكون اللقطة دائمًا مجرد مرحلة، تليها نسخة احتياطية خارج الموقع، وأرشيف غير قابل للتعديل، ونسخة متماثلة للتعافي من الكوارث.
قاعدة 3-2-1 هي الحد الأدنى من استراتيجيات النسخ الاحتياطي الذي أثبتته التجربة في هذا القطاع منذ سنوات: ثلاث (3) نسخ من البيانات، على نوعين (2) مختلفين من الوسائط، وواحدة (1) منها خارج الموقع. إحدى النسخ الثلاث هي بيانات الإنتاج نفسها، والنسختان الأخريان احتياطيتان، فإذا تلفت إحداهما بقيت الأخرى. ويحميك نوعا الوسائط من العطل الشامل لتقنية واحدة (مثل تعطل جميع أقراص SSD بسبب خلل في البرنامج الثابت): قرص + شريط، أو قرص + تخزين الكائنات، أو NAS + سحابة. أما النسخة خارج الموقع فتحميك من الحريق والفيضان والسرقة والانقطاع الإقليمي وتعليق الحساب، ولا تُعد النسخة الموجودة في المبنى نفسه، أو حتى في المدينة نفسها، نسخة خارج الموقع. والامتداد الحديث للقاعدة هو «3-2-1-1-0»: يجب أن تكون إحدى النسخ غير قابلة للتعديل (1)، وأن تُظهر اختبارات الاستعادة صفر (0) أخطاء.
فقط إذا صُممت بشكل صحيح. تبقى برامج الفدية الحديثة في الشبكة أسابيع قبل تشفير بيئة الإنتاج، فتكتشف نظام النسخ الاحتياطي وتحذف النسخ الموجودة أو تُبطلها، ثم تشفّر الإنتاج فلا يبقى ما يمكن استعادته. لذلك يجب أن تكون حسابات النسخ الاحتياطي مستقلة عن دليل الإنتاج وعن تسجيل SSO الخاص به، بل عن شبكة الإنتاج نفسها. الحل هو تخزين WORM (الكتابة مرة واحدة والقراءة مرات عديدة): S3 Object Lock في وضع Compliance وWasabi Compliance وVeeam Hardened Repository وأشرطة معزولة تمامًا عن الشبكة (Air-Gapped). في هذه الطبقات يستحيل الحذف رياضيًا حتى بصلاحيات المسؤول، إذ تبقى البيانات «مجمّدة» طوال مدة الاحتفاظ. وفي بنيتنا يحصل كل عميل على طبقة WORM واحدة على الأقل، ويُتحقق من دليل الاستجابة لبرامج الفدية (Playbook) عبر التدريبات.
نوصي باختبارها مرة كل ثلاثة أشهر على الأقل، ومرة كل شهر للأنظمة الحرجة، واختبارًا مؤتمتًا أسبوعيًا في البيئات الخاضعة للتنظيم. فاختبار الاستعادة هو الدليل الوحيد على أن بنية النسخ الاحتياطي لديك تعمل فعلًا، ولا يكفي ظهور «OK» في السجل. ويشمل التدريب الكامل الاستعادة إلى بيئة Sandbox معزولة، وتشغيل التطبيق، والتحقق من سلامة قاعدة البيانات والمجاميع الاختبارية (Checksums)، ومقارنة قيم RPO/RTO المقيسة بأهداف العقد. أما الاختبارات المؤتمتة فتُنشئ بعد كل نسخة احتياطية نسخة افتراضية عبر «الاستعادة الفورية» (Instant Recovery)، وتُجري عمليات فحص ذكية، وتُبلغ بالنتيجة. ونجري لكل عميل تحققًا مؤتمتًا أسبوعيًا وتدريبًا يدويًا كل ثلاثة أشهر، وتُحفظ النتائج في تقرير موقّع يفيدك في عمليات التدقيق والتأمين وتجديد العقود.
إذا صُمم بشكل صحيح فلا، وإذا صُمم بشكل خاطئ فقد يصبح مكلفًا للغاية. للتكلفة ثلاثة محاور رئيسية: التخزين (لكل GB شهريًا)، ونقل البيانات الصادرة (Egress) عند التنزيل أثناء الاستعادة، واستدعاءات API (رسوم على كل عملية ملف). النهج الساذج القائل «لنرفع كل شيء كاملًا إلى S3 كل يوم» قد يكلّف عشرات الآلاف من الدولارات الأمريكية سنويًا. أما النهج الصحيح فمتعدد المستويات: فئة S3 Standard لآخر 14 يومًا المطلوبة كثيرًا، وفئة S3 Standard-IA لآخر 90 يومًا، وفئة S3 Glacier Instant لآخر سنة، وفئة Glacier Deep Archive لما هو أقدم، وللبيانات نفسها تختلف التكلفة من 10 إلى 20 ضعفًا. وعند إضافة سياسات دورة الحياة والضغط وإزالة التكرار واستراتيجية النسخ التزايدي الدائم (Incremental Forever)، تبلغ تكلفة النسخ الاحتياطي السحابي لدى عميلنا المعتاد بضع مئات من الدولارات شهريًا. ومعرفة سيناريوهات الاستعادة لديك هي مفتاح التقدير السليم: فقد يكون Glacier Deep مثاليًا لمن يستعيد بياناته مرة في الشهر، لكنه باهظ إلى حد مدمّر لمن يستعيدها 5 مرات في اليوم.
يجيب RPO (هدف نقطة الاستعادة أو Recovery Point Objective) عن سؤال «ما مقدار فقدان البيانات الذي نقبله؟»، ويجيب RTO (هدف زمن الاستعادة أو Recovery Time Objective) عن سؤال «في كم من الوقت يجب أن نعود إلى العمل؟». ويُستخرج الرقمان من تحليل تأثير الأعمال: إذا توقف النظام ساعة، أو فُقدت بيانات يوم كامل، فما التكلفة الحقيقية من حيث الإيرادات والعملاء والالتزامات التنظيمية؟ في التجارة الإلكترونية تدفع الإيرادات بالساعة عادةً RTO إلى نطاق الدقائق، فساعة واحدة من RTO مدة طويلة جدًا لنظام يستقبل الطلبات. أما نظام CRM للاستخدام الداخلي فقد يكون RTO بمقدار 8 ساعات معقولًا له. أما RPO فالسؤال فيه: كم دقيقة من نشاط الأعمال يمكنك خسارتها؟ اللقطات كل ساعة تجعل RPO عند 60 دقيقة، ونسخ سجل المعاملات المتماثل يخفضه إلى ثوانٍ. هذه الأهداف محددة في العقد وتُقاس وتُثبت في كل تدريب، فهي قرارات أعمال لا أرقام عشوائية.
نعم، تتوافق بنيتنا توافقًا كاملًا مع متطلبات GDPR وKVKK وISO 27001 Annex A.12.3 وSOC 2 CC9 وPCI-DSS 9.5/12.10 ذات الصلة. ويعني ذلك ما يلي: تشفير جميع النسخ الاحتياطية أثناء التخزين (AES-256) وأثناء النقل (TLS 1.3)، وحفظ المفاتيح في KMS (AWS KMS وAzure Key Vault وHSM) بتفويض منفصل عن نظام النسخ الاحتياطي، ومواءمة مدد الاحتفاظ مع المتطلبات القانونية مع حذف يمكن إثباته عند تجاوزها، وإجراء للبحث في النسخ الاحتياطية وإخفاء الهوية انتقائيًا لطلبات «الحق في النسيان»، وإمكانية اختيار موقع البيانات (تركيا/الاتحاد الأوروبي)، وتدوين كل وصول واستعادة وتغيير في الإعدادات في سجل تدقيق غير قابل للتعديل. وتتضمن باقة الاستعداد للتدقيق مخططات البنية، ووثائق السياسات، وآخر تقارير التدريبات، ومصفوفة RACI للأدوار، فلكل سؤال قد يطرحه المدقق إجابة جاهزة.
نعم، يمكننا تولي إدارة نظام Veeam الحالي لديك (أو Rubrik أو Cohesity أو Commvault أو Acronis) كما هو، فلا يتغير ترخيصك وتبقى معداتك نفسها. في الأسبوع الأول نجري تدقيقًا كاملًا يشمل معدل نجاح النسخ الحالي، وتاريخ آخر استعادة، وسياسات الاحتفاظ، وحالة عدم القابلية للتعديل، ونموذج الوصول، وإدارة المفاتيح، والمراقبة والتنبيهات، ونوثّق كل ذلك ونصنّف المخاطر بالأحمر والأصفر والأخضر. وخلال 30 يومًا بعد ذلك نراجع البنية، ونضيف عند الحاجة طبقات جديدة في وضع الجسر (القديم والجديد بالتوازي)، فلا تُنقل البيانات بل تُضاف وجهات نسخ احتياطي جديدة. وفي نهاية الشهر الثالث نجري تدريب استعادة كاملًا ونثبّت خط الأساس. لدينا مهندسون حاصلون على شهادتي Veeam VMCE وRubrik RCSA في فريقنا، ولا حاجة إلى تغيير المورّد، فنحن نضيف الإعداد الصحيح والانضباط التشغيلي.
في اجتماع مجاني لمدة 30 دقيقة نراجع معًا وضع النسخ الاحتياطي الحالي لديك: قيم RPO/RTO المستهدفة، وثغرات عدم القابلية للتعديل، وتاريخ آخر اختبار استعادة، والخطوات العملية خلال 90 يومًا قادمة، ونسلّم ذلك كله في تقرير مكتوب.
