أداتان لا تعدان بالوعد نفسه
اللقطة تجمّد حالة قرص في لحظة معينة لتعود إليها بسرعة. أما النسخة الاحتياطية فتنسخ البيانات إلى مكان آخر مع سجل تاريخي لتتمكن من إعادة البناء بعد الفقدان. تستعمل لوحات الاستضافة الكلمتين كأنهما مترادفتان، ومن هنا يبدأ سوء الفهم: زر اللقطة يطمئن، لكنه لا يجيب إلا عن جزء من الحوادث.
بالنسبة لوكالة تستضيف مواقع عملائها على خوادم VPS، لهذا الفارق كلفة مباشرة. يوم يختفي الخادم لا يسأل العميل هل كانت هناك لقطة، بل يسأل متى يعود موقعه وبأي بيانات. تقدم هذه المقالة معياراً بسيطاً للاختيار، خادماً بخادم، بين التراجع وإعادة البناء، ثم طريقة لكتابة ذلك في العقد.
ما تفعله اللقطة على أكمل وجه
- تراجع خلال دقائق — قبل ترقية إصدار أو تغيير إعداد أو ترحيل، تكون العودة إلى الحالة السابقة سريعة.
- نقطة مرجعية مؤرخة — تعرف بالضبط إلى أي لحظة تعود، مما يسهّل التشخيص بعد حادثة.
- لا إعادة بناء مطلوبة — يعمل الخادم كما كان، بما في ذلك إعدادات النظام.
- إجراء متاح — نقرة أو أمر واحد في اللوحة، دون أداة تُثبَّت ودون مستودع يُضبط.
- مناسبة للتجارب — اختبار تحديث على موقع عميل مع الاحتفاظ بمخرج طوارئ.
- مفيدة قبل أي تدخل بشري — يمكن تصحيح خطأ إداري دون استعادة طويلة.
الاعتراض: «لدي لقطات بالفعل»
تعيش اللقطة غالباً عند المزوّد نفسه، وعلى التخزين نفسه، وتحت الحساب نفسه الذي يعمل عليه الخادم. لذلك تتشارك معه الأعطال. إذا حُذفت الآلة الافتراضية، بخطأ أو بسبب فاتورة غير مسددة، فقد تختفي اللقطات المرتبطة بها معها بحسب المزوّد. وإذا اختُرق حساب الاستضافة، يستطيع من يدخل حذف الخادم ولقطاته بحركة واحدة. وإذا وقعت حادثة في التخزين الأساسي، سقطت النسخة والأصل معاً.
ويضاف حدّان آخران. اللقطة متسقة على مستوى القرص لا على مستوى التطبيق: قد تظهر فيها قاعدة بيانات كانت تكتب في تلك اللحظة بحالة غير مكتملة. واللقطة ليست دليلاً على الاستعادة أبداً: ما لم تُقرأ مجدداً تبقى فرضية.
وفي المقابل اعتراض صادق: لا شيء من هذا يجعل اللقطة بلا فائدة. تبقى أسرع أداة للتراجع قبل عملية محفوفة بالمخاطر. لا ينبغي التخلي عنها، بل التوقف عن مطالبتها بما لا تقدر عليه.
اللقطة والنسخة الاحتياطية خارج الخادم، معياراً بمعيار
مرّر الجدول أفقيًا
| المعيار | اللقطة | النسخة الاحتياطية خارج الخادم |
|---|---|---|
| الموقع | غالباً عند المزوّد نفسه وعلى التخزين نفسه | خارج مزوّد الآلة الافتراضية وعلى تخزين منفصل |
| النجاة من حذف الآلة الافتراضية | تختلف: بحسب العرض قد تختفي مع الخادم | نعم، النسخة موجودة بمعزل عن الخادم |
| النجاة من اختراق حساب الاستضافة | لا، بيانات الدخول نفسها | نعم، إذا كان الوصول إلى المستودع منفصلاً عن حساب الاستضافة |
| اتساق التطبيق | اتساق القرص فقط | ممكن بتصدير للتطبيق يُنجز قبل النسخ |
| مدة الاحتفاظ | قصيرة، وغالباً بضع نقاط حديثة | طويلة، مع سجل تاريخي ومدة احتفاظ تختارها |
| سرعة التراجع | سريعة جداً | أبطأ: يجب نسخ البيانات من جديد |
| التشفير قبل النقل | نادراً ما يكون تحت سيطرتك | ممكن، بمفتاح تحتفظ به أنت |
| إثبات الاستعادة | لا شيء حتى يُجرى اختبار | لا شيء حتى يُجرى اختبار، ومن هنا الاختبار المجدول |
اتساق التطبيق: فخ قاعدة البيانات
نسخ قرص بينما قاعدة بيانات تكتب أشبه بتصوير صفحة أثناء تقليبها. نظام الملفات سليم، لكن القاعدة قد تحوي معاملة نصف مكتوبة، وهي تتعافى أحياناً بعد مرحلة إصلاح وأحياناً لا. العلاج هو إنتاج تصدير متسق للقاعدة قبل اللقطة أو قبل النسخ، ثم ضمّه إلى ما يُنسخ احتياطياً.
في PostgreSQL الأمر الموثق هو pg_dump، وهو ينتج تصديراً متسقاً حتى أثناء خدمة القاعدة للاستعلامات. وفي MySQL وMariaDB مع جداول InnoDB، يقرأ الأمر mysqldump --single-transaction حالة متسقة دون حجب عمليات الكتابة. وفي الحالتين ينضم ملف التصدير إلى النسخة الاحتياطية، وهو الملف الذي تستعيده أولاً. وينطبق هذا على اللقطة كما ينطبق على نسخ الملفات: القرص وحده لا يضمن شيئاً عن الحالة المنطقية للقاعدة.
أربع حوادث وأربع حمايات
مرّر الجدول أفقيًا
| الحادثة | ما يحمي | السبب |
|---|---|---|
| تحديث يعطّل النظام | لقطة مأخوذة قبله مباشرة | تراجع سريع إلى حالة معروفة |
| ملف أو جدول حُذف بالخطأ واكتُشف بعد أيام | نسخة احتياطية ذات سجل تاريخي | اللقطة الحديثة تحوي الخطأ أصلاً: تحتاج إلى نقطة أقدم |
| حذف الآلة الافتراضية أو اختراق حساب الاستضافة | نسخة احتياطية خارج المزوّد | النسخة لا تعتمد على الخادم ولا على الحساب |
| تلف صامت اكتُشف متأخراً | نسخة احتياطية بمدة احتفاظ طويلة | يجب الرجوع إلى ما قبل تاريخ بدء تدهور البيانات |
قاعدة القرار في جملة واحدة
اللقطة: تراجع قصير قبل عملية محفوفة بالمخاطر. النسخة الاحتياطية: القدرة على إعادة البناء بعد فقدان الخادم أو الحساب.
إذا كان السؤال «هل أستطيع التراجع عما سأفعله خلال الساعة»، فاللقطة تجيب. وإذا كان السؤال «ماذا يبقى إن لم يعد هذا الخادم أو هذا الحساب موجوداً غداً»، فالنسخة الاحتياطية خارج الخادم وحدها تجيب. لذلك يملك أي VPS جاد لعميل الاثنين معاً، بدورين لا يتداخلان.
الاثنان لا يتنافسان. تؤخذ اللقطة قبل التدخل وتُحذف بعد التحقق من النتيجة، بينما تعمل النسخة الاحتياطية وفق جدول ثابت لا يحتاج أحد إلى إطلاقه يدوياً. الخلط بين هذين الإيقاعين سبب معظم المفاجآت السيئة: لقطة منسية لأسابيع تشغل مساحة ولا تحمي إلا القليل، ونسخة لا تُطلق إلا قبل الأعمال الكبرى تترك فجوات في السجل التاريخي.
تطبيق القاعدة على كل VPS لعميل
جرد الخوادم وما تحمله
سجّل لكل خادم المواقع وقواعد البيانات والملفات المرفوعة ودرجة أهميته للعميل.
تحديد فقدان البيانات المقبول
اسأل كم ساعة من البيانات يمكن للعميل أن يخسر. هذه القيمة هي RPO وهي تحدد وتيرة النسخ الاحتياطي.
تحديد مهلة الاستعادة المقبولة
اسأل كم من الوقت يمكن للموقع أن يبقى متوقفاً. هذه القيمة هي RTO وهي تحدد طريقة إعادة البناء.
وضع النسخة خارج مزوّد الآلة الافتراضية
استخدم تخزيناً منفصلاً ببيانات دخول مختلفة عن حساب الاستضافة، وشفّر قبل الإرسال بمفتاح تحتفظ به أنت.
إضافة تصدير القاعدة قبل كل نسخ
شغّل
pg_dumpأوmysqldump --single-transactionبحسب المحرك، وضمّ الملف الناتج إلى المجموعة المنسوخة.تخصيص اللقطة للعمليات المحفوفة بالمخاطر
خذ لقطة قبل كل ترقية إصدار أو تغيير كبير، ثم احذفها بعد التحقق من النتيجة.
اختبار الاستعادة: دون اختبار تبقى فرضية
النسخة الاحتياطية التي لم تُستعد قط في اختبار ليست سوى فرضية. والفرق بين اللقطة والنسخة الاحتياطية يظهر في الإثبات أيضاً: لا يخبرك إن كان الموقع سيعمل وكم سيستغرق ذلك إلا تمرين استعادة مقيس بالزمن.
يشرح دليلنا الخاص بإجراء اختبار الاستعادة للوكالات التمرين الفصلي على VPS مؤقت، وقياس RTO وRPO المرصودين، والسجل الذي يُسلَّم للعميل. لا نعيد وصفه هنا. احتفظ بالمبدأ: جدولة الاختبار وتأريخه وإصلاح ما يكشفه، سواء كان صلاحيات ناقصة أو أسراراً غائبة أو إصدار برنامج مختلفاً.
ولتنفيذ أداة بعينها، يلخص دليل استراتيجية 3-2-1 مع Restic وS3 في فقرة واحدة ما لا تضمنه لقطة المزوّد، ثم يعرض نسخة خارج المزوّد عملياً. تبقى هذه المقالة نظرية عن قصد: هي للقرار لا للتثبيت.
كتابة القاعدة في العقد
يستفيد عقد الوكالة إذا ذكر ما هو محمي وبأي آلية وبأي هدف، بدل الوعد بـ«نسخ احتياطية». تكفي ثلاثة عناصر: RPO أي الحد الأقصى المقبول لفقدان البيانات؛ وRTO أي المهلة المستهدفة لإعادة الخدمة؛ والآلية التي تحقق القيمتين.
مثال افتراضي، يُكيَّف ولا يُنسخ كما هو: «تُنسخ بيانات الموقع كل ليلة إلى تخزين يقع خارج مستضيف الخادم، مع احتفاظ لعدة أشهر. يلتزم المزوّد بـ RPO قدره 24 ساعة وRTO قدره 8 ساعات بعد قرار الاستعادة. تؤخذ لقطة قبل كل تحديث كبير وتُحذف بعد التحقق. تُجرى استعادة تجريبية كل فصل ويُسلَّم سجلها للعميل.»
هذه الأرقام مختلقة للتوضيح. يجب أن تنتج أرقامك من قياسات الاستعادة الخاصة بك لا من نية.
قبل العملية المحفوفة بالمخاطر: لقطة ونسخة تم التحقق منها
قبل ترقية إصدار، خذ اللقطة، لكن تحقق أيضاً من أن آخر نسخة احتياطية خارج الخادم حديثة وقابلة للقراءة. تنفع اللقطة إذا فشلت العملية سريعاً. وتنفع النسخة إذا ظهرت المشكلة بعد ثلاثة أيام، حين تكون اللقطة قد حُذفت.
سياسة لكل عميل، وما تضعه ServOrbit في متناولك
يمكن للوكالة أن تدوّن سياسة النسخ الاحتياطي في جدول بسيط: سطر لكل عميل، مع RPO وRTO والآلية وتاريخ آخر اختبار.
في استضافة الويب، النسخ الاحتياطية أسبوعية في الباقات الأساسية، ويومية في باقة Pro وفي جميع باقات الموزّعين، مع نسخة يومية مميزة متاحة كخيار. أما في VPS فوجود اللقطات وشروطها يعتمدان على عرض مزوّدك: تحقق من وثائق اللوحة قبل كتابتها في عقد، ولا تعدّها أبداً نسختك الوحيدة.
