النسخ الاحتياطي لـVPS واستعادته: مشفر، خارج الموقع، ومختبر فعلياً

اللقطات ليست نسخاً احتياطية — وأنت بحاجة إلى الاثنين معاً

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

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

كما أن نافذة السبعة أيام لا تفيد في نوعي الإخفاق البطيء. فالملف الذي حذفته قبل خمسة أسابيع يكون قد اختفى من كل لقطة قبل أن تلاحظ ذلك بوقت طويل. أما التلف الصامت — تطبيق معطوب يكتب بيانات خاطئة بشكل دقيق، أو عملية ترحيل سيئة، أو عميل مزامنة ينشر خطأً بأمانة — فغالباً ما يُكتشف بعد شهر، وعندها يكون كل نسخة محتفَظ بها قد احتوت على التلف. والنسخ الاحتياطية ذات فترة الاحتفاظ الأطول والتاريخ الحقيقي هي ما يغطي هذين الإخفاقين، وهي تغطيهما تحديداً لأنها ليست مرايا مستمرة للحالة الراهنة.

الإطار الذي يستحق الاستيعاب هنا قديم وما زال صحيحاً. تطالب قاعدة 3-2-1 بثلاث نسخ من البيانات، على نوعين مختلفين من التخزين، تكون إحداهما خارج الموقع. ويضيف الملحق الحديث رقمين آخرين — 3-2-1-1-0 — حيث يمثل الرقم الإضافي نسخة غير قابلة للتغيير أو غير متصلة بالشبكة، ويمثل الصفر عدد الأخطاء في آخر عملية تحقق أجريتها. هذه الأرقام وسيلة مساعدة على الحفظ لا معيار قياسي، لكنها تختزل الخصائص الثلاث التي تهم فعلاً: الاستقلالية، وعدم القابلية للتغيير، والدليل على أن الأمر يعمل. اللقطات كل ساعة تمنحك واحدة من هذه الثلاث.

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

الرقمان اللذان يحددان كل ما عداهما

قبل تثبيت أي أداة، دوِّن رقمين. هدف نقطة الاسترداد (RPO) هو مقدار البيانات التي يمكنك تحمُّل خسارتها، مقيساً بالزمن — فإذا كان عمر آخر نسخة صالحة للاستخدام ست ساعات، فإن RPO الخاص بك هو ست ساعات، وتكون ساعات العمل الست الواقعة بينهما قد ضاعت. أما هدف زمن الاسترداد (RTO) فهو المدة التي يمكنك تحمُّل عدم توفر الخدمة خلالها أثناء إعادة البناء. وكل ما هو لاحق — الجدول الزمني، والطريقة، ومكان إقامة النسخة الثانية، ومقدار الإنفاق — ينبثق من هذين الرقمين، واختيار البرنامج قبل اختيارهما هو الطريقة التي ينتهي بها الناس إلى إجابة معقدة عن سؤال لم يطرحه أحد.

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

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

ذلك الصف الأخير يستحق أن يُقال بصراحة، لأن دليلاً عن النسخ الاحتياطي لديه حافز واضح ألا يقوله. فبعض الأجهزة لا تحتاج إلى نسخة احتياطية على الإطلاق. وكيل بناء تُستمد حالته بالكامل من مستودع git، أو بيئة تجريبية يُستغنى عنها، أو وكيل عكسي عديم الحالة يقيم إعداده في نظام التحكم بالإصدارات — بالنسبة إلى هذه الحالات، تُعد اللقطات كل ساعة المرفقة مع الخطة إجابة كاملة وقابلة للدفاع عنها، والمقدار الصحيح من هندسة النسخ الاحتياطي هو صفر. ومعرفة أي خوادمك تقع في هذه الفئة تستحق أكثر من نسخ جميعها احتياطياً بشكل رديء.

ما الذي يجب نسخه — والكومة الأكبر بكثير التي ينبغي تجاوزها

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

المجموعة غير القابلة للتعويض هي عادة أربعة أشياء. أولاً، بيانات التطبيق: الـmaildir، ودليل البيانات، ومخزن الوسائط، ومجلد الرفع. ثانياً، قواعد البيانات، التي تحتاج معالجة خاصة بها وتُفرَد لها الفقرة التالية. ثالثاً، الأسرار — وهذه هي الفئة التي ينساها الناس إلى أن تصبح مكلفة. مفاتيح TLS الخاصة ومفتاح حساب ACME، ومفاتيح مضيف SSH إن كنت تفضل ألا تعيد الثقة ببصمة كل عميل من جديد، ومفتاح توقيع DKIM الذي بدونه يبدأ بريدك في الفشل في المصادقة، ومفاتيح WireGuard الخاصة، وقبل كل شيء مفتاح خدمة onion الخاص، الذي هو عنوان .onion نفسه: افقده ويختفِ العنوان نهائياً، دون أي جهة تسجيل يمكن التظلم إليها في أي مكان. رابعاً، الحفنة من الملفات الموجودة تحت /etc التي غيّرتها فعلاً، إضافة إلى وحدات systemd، وإدخالات cron، ومجموعة قواعد جدار الحماية التي تجعل الجهاز يتصرف على النحو الذي يتصرف به.

الكومة التي ينبغي تجاوزها أكبر بكثير وواضحة في معظمها بمجرد ذكرها. فالأنظمة الوهمية للملفات مثل /proc و/sys و/dev هي طرق عرض للنواة لا بيانات فعلية. وذاكرات التخزين المؤقت للحزم، وصور الحاويات، والبيئات الافتراضية، وأدلة التبعيات كلها قابلة لإعادة الاشتقاق من ملف القفل خلال ثوانٍ. أما السجلات التي تتجاوز سياسة الاحتفاظ لديك فهي ضوضاء تُزال تكراريتها بشكل رديء وتُضخِّم كل عملية تشغيل لاحقة. ومجموعات البيانات الكبيرة القابلة لإعادة المزامنة — حالة سلسلة الكتل، ومرآة عامة، ومكتبة وسائط يمكنك استخراجها من جديد — تستحق قراراً صريحاً بدلاً من إعداد افتراضي: فالنسخ الاحتياطي لثلاثمئة غيغابايت من بيانات السلسلة يكلف مالاً حقيقياً كل شهر لتفادي إعادة مزامنة يمكنك إجراؤها مجاناً بينما تظل الخدمة متدهورة الأداء لكنها صالحة للعمل.

الجزء الذي يقصّر فيه الجميع تقريباً هو الإجابة عن سؤال “الاستعادة إلى ماذا؟”. فالبيانات بلا هدف ليست استعادة. وإذا كانت الطريقة التي بُني بها خادمك موجودة فقط في ذاكرتك وفي سجل أوامر صدفة فقدته منذ ذلك الحين، يصبح زمن الاسترداد لديك غير محدود مهما كان المستودع جيداً. والحل رخيص ومملّ: احتفظ بخطوات التجهيز كنص برمجي أو دليل تشغيلي نصي بسيط، وضعه داخل مستودع النسخ الاحتياطي كي يُستعاد مع البيانات، وحدِّثه كلما غيّرت الجهاز. حتى مئة سطر من الملاحظات — الحزم، والإصدارات، ومواقع ملفات الإعداد، وسجلات DNS، والترتيب الذي يجب أن تبدأ به الخدمات — تحوّل أسبوعاً سيئاً إلى بعد ظهر سيئ فقط.

ثمة دقيقة تستحق الإشارة إليها لكل من يشغِّل تشفير القرص الكامل: ترويسة LUKS وخانات مفاتيحها جزء من مجموعتك غير القابلة للتعويض أيضاً. فالترويسة التالفة تحوّل قرصاً سليماً تماماً إلى ضوضاء عشوائية، والترويسة لا تتجاوز بضعة ميغابايتات، ونسخها احتياطياً لا يكلف شيئاً. خزِّنها بالعناية نفسها التي تخزِّن بها عبارة المرور — فمن يملك الاثنين معاً يملك القرص.

قواعد البيانات: الملف الذي تنسخه ليس هو قاعدة البيانات

هذه هي الطريقة الأكثر شيوعاً على الإطلاق التي يتضح بها أن نسخة احتياطية كفؤة من جميع النواحي الأخرى عديمة القيمة. يحتفظ محرك قاعدة البيانات بحالته في الذاكرة، وفي سجل كتابة مسبقة أو سجل إعادة تنفيذ، وفي ملفات بيانات تُعدَّل باستمرار. ونسخ تلك الملفات أثناء عمل المحرك يلتقطها في لحظات مختلفة — الصفحة الرابعة من جدول قبل معاملة ما، والصفحة الخامسة بعدها — والنتيجة مجموعة ملفات سليمة كل على حدة ولكنها غير متسقة مجتمعة. والجزء القاسي هو أن مثل هذه النسخة تُستعاد غالباً. فهي تعمل، وتجيب عن الاستعلامات، ثم يظهر الضرر بعد أسابيع في هيئة فهرس تالف أو صف ينتهك قيداً يُقسم المحرك أنه يفرضه. النسخة الاحتياطية التي تفشل بصخب أفضل بكثير من نسخة تفشل بصمت.

يعتمد النهج الصحيح على المحرك، وهو موثَّق جيداً في كل حالة. بالنسبة إلى MariaDB وMySQL، يكون التفريغ المنطقي الذي يؤخذ ضمن معاملة واحدة متسقة مناسباً لأي حجم يصل إلى بضع عشرات من الغيغابايتات؛ وبعد ذلك، تقوم Mariabackup بأخذ نسخة فعلية ساخنة أثناء عمل الخادم. أما بالنسبة إلى PostgreSQL، فإن pg_dump يمنحك لقطة منطقية قابلة للنقل، بينما يمنحك pg_basebackup مقترناً بسجلات كتابة مسبقة مؤرشفة استرداداً إلى نقطة زمنية محددة — أي القدرة على الاستعادة إلى الساعة 14:32 بدلاً من الاستعادة إلى وقت تشغيل آخر تفريغ مهما كان. أما بالنسبة إلى SQLite، فاستخدم النسخ الاحتياطي الحي المدمج أو VACUUM INTO؛ واستخدام cp على ملف قاعدة بيانات حي هو تحديداً الخطأ الموصوف أعلاه، وSQLite هو المحرك الذي يرتكب فيه الناس هذا الخطأ الأكثر شيوعاً لأنه يبدو كملف عادي.

الاتساق بين قاعدة البيانات والملفات التي تصفها هو النصف الثاني من المشكلة، وهو النصف الذي يضر تحديداً ببرمجيات مزامنة الملفات والمنتديات. تقول قاعدة البيانات إن ملفاً موجود في مسار ما؛ ونظام الملفات هو حيث تقيم البايتات فعلياً؛ فإذا فرَّغت قاعدة البيانات في الساعة 02:00 ونسخت دليل البيانات في الساعة 02:40، فإن كل ما أُنشئ بين الوقتين يوجد إما كبايتات بلا صف، أو كصف بلا بايتات. والتطبيقات التي توفر وضع صيانة — وNextcloud أوضح مثال عليها — تحل هذه المشكلة برفض الكتابة لفترة وجيزة أثناء التقاط الاثنين معاً. وحيث يكون ذلك غير مقبول، تمنحك لقطة نظام ملفات أو وحدة تخزين تُؤخذ في لحظة واحدة زوجاً متسقاً يمكنك النسخ منه براحتك، وهذه هي الحيلة نفسها التي تستخدمها اللقطات كل ساعة.

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

أخيراً، قرِّر بشكل واعٍ ما إذا كنت بحاجة إلى الاسترداد إلى نقطة زمنية محددة، لأنه الإجابة عن إخفاق لا يستطيع التفريغ اليومي معالجته. فإذا نفَّذ أحدهم استعلاماً مدمِّراً في الساعة 14:32 واكتشفت ذلك في الساعة 17:00، فإن استعادة تفريغ الليلة الماضية تفقدك يوم عمل كاملاً. أما الأرشفة المستمرة فتعيد تشغيل السجل حتى الساعة 14:31 بدلاً من ذلك. وهي تكلف مساحة تخزين أكبر وتعقيداً تشغيلياً أكبر بشكل ملموس، لذا فهي ليست خياراً افتراضياً — لكن في أي حالة يستطيع فيها شخص لديه صلاحية كتابة أن يدمر البيانات أسرع مما يمكنك ملاحظته، تكون هي الفارق بين حادثة وكارثة.

شفِّر البيانات قبل أن تغادر: restic وborg والمفتاح الذي يجب ألا تفقده

الخاصية التي تجعل كل ما عداها في هذا الدليل ممكناً هي التشفير من جانب العميل: تُشفَّر البيانات على الجهاز الذي أنتجها، قبل أن تعبر بايتة واحدة الشبكة، باستخدام مفتاح لا تراه الوجهة أبداً. هذا القرار التصميمي الوحيد يحوّل هدف النسخ الاحتياطي إلى مساحة تخزين غير موثوقة، ومساحة التخزين غير الموثوقة يمكنها الإقامة في أي مكان — خادم رخيص في بلد آخر، أو خدمة تخزين كائنات، أو جهاز NAS تابع لصديق — دون أن يكون أي منها في موضع يتيح له قراءة بياناتك. أما المزوِّدون الذين يشفِّرون من جانب الخادم فهم يحمونك من مجموعة مختلفة وأضيق بكثير من التهديدات، ويكون الفارق أكثر أهمية بالضبط في المواقف التي تشتري الاستضافة الخارجية لتنجو منها.

يقوم كل من Restic وBorg بهذا الأمر على نحو صحيح، والاختيار بينهما متقارب فعلاً. فـRestic ملف تنفيذي ثابت واحد بلا أي تبعيات، يتحدث أصلاً قائمة طويلة من الخلفيات — SFTP، وتخزين كائنات متوافق مع S3، ومسارات محلية عادية — وهو الأسهل بين الأداتين تشغيلاً من داخل حاوية أو صورة نظام مصغّرة. أما Borg فهو الأداة الأقدم والأدق من بعض النواحي، بخيارات ضغط أقوى، ودعم ممتاز لوضع الإلحاق فقط على جانب الخادم، وتنسيق مستودع يجده كثيرون أسهل فهماً؛ غير أنه يتطلب تثبيت borg على الطرفين عند الاتصال عبر SSH، وهو قيد صغير يحسم الأمر أحياناً.

أياً كان اختيارك، فإن عبارة المرور هي كل ما يتوقف عليه الأمر الآن، وتستحق أن تُعامَل كما تُعامل عبارة استرداد محفظة عملات مشفرة. يجب ألا تبقى محفوظة على الآلة التي تحميها وحدها — فعبارة مرور محفوظة إلى جانب البيانات التي تشفّرها لا تحميك من شيء على الإطلاق، لأن كل سيناريو يستولي فيه أحدهم على الخادم يأخذ المفتاح معه. ضعها في مدير كلمات مرور على جهاز مختلف، أو على ورق في مبنى مختلف، والأفضل كلا الأمرين معاً. يتيح لك Borg تصدير مفتاح المستودع إلى ملف منفصل، ويتيح restic لمستودع واحد حمل عدة مفاتيح مستقلة، وكلتا الآليتين تمنحك طريقاً بديلاً للدخول لا يعتمد على تذكُّر سلسلة أحرف. لا يوجد استرداد، ولا رابط لإعادة التعيين، ولا تذكرة دعم فني تُبطل هذا الأمر: فالمستودع المشفَّر بلا مفتاحه لا يمكن تمييزه عن بيانات عشوائية، وهذا بالضبط هو المغزى.

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

الإلحاق فقط، وإلا فهي مجرد نسخة لا نسخة احتياطية

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

الضابط الذي يغلق هذه الثغرة هو فرض الإلحاق فقط على الجانب المستقبِل. وبهذا الضبط، يستطيع العميل إنشاء لقطات جديدة ولا يستطيع حذف القديمة أو إعادة كتابتها — والقيد تفرضه العملية القائمة على مضيف النسخ الاحتياطي، لا حسن نية العميل. تطبِّق Borg هذا عبر borg serve --append-only، مثبَّتاً على المفتاح في ملف authorized_keys الخاص بالوجهة بحيث لا يستطيع العميل طلب أي شيء آخر. ولدى Restic البنية نفسها عبر rest-server باستخدام --append-only. أما في تخزين الكائنات فالمكافئ هو تفعيل تعدد الإصدارات مع سياسة احتفاظ بقفل الكائنات، وهو ما يحقق النتيجة ذاتها بآلية مختلفة.

إعداد SSH الذي يحمل هذا يستحق أن يُضبط بدقة تامة، لأنه السطر الحامل للبنية كلها. في ملف authorized_keys الخاص بمستخدم النسخ الاحتياطي، أضِف قبل مفتاح العميل أمراً إلزامياً والقيود التي يوثقها دليل sshd: command="borg serve --append-only --restrict-to-path /srv/backups/web01",restrict. هذا السطر وحده يعني أن مفتاحاً مسروقاً من العميل لا يستطيع فتح shell، ولا توجيه منفذ، ولا لمس مستودع مضيف آخر، ولا حذف أي شيء. امنح كل عميل مفتاحه الخاص ومساره الخاص.

وهذا يطرح سؤالاً بديهياً: إذا كان العميل لا يستطيع الحذف أبداً، فما الذي يزيل اللقطات القديمة؟ يحدث التقليم في مكان آخر، وفق جدول زمني، ببيانات اعتماد لم تحملها الآلة المحمية قط. عملياً، يعني هذا أن مضيف النسخ الاحتياطي يُقلِّم مستودعاته الخاصة من مهمة cron محلية، أو أن آلة ثالثة صغيرة تحمل المفتاح المميَّز وتُشغِّل عملية الاحتفاظ أسبوعياً. ولدى Borg مطبٌّ معروف هنا — إذ يحتاج المستودع الذي يعمل بوضع الإلحاق فقط إلى تشغيل عملية ضغطه على جانب الخادم لا من طرف العميل — ومعاملة مضيف النسخ الاحتياطي بوصفه مالك عملية الاحتفاظ يحل هذه المسألة بشكل نظيف. والمبدأ قابل للتعميم: يجب ألا تكون الآلة التي تكتب النسخ الاحتياطية هي نفسها الآلة القادرة على إتلافها.

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

أين تذهب النسخة الثانية حين لا يستطيع أحد التعرف على هويتك

يؤدي مبدأ «خارج الموقع» دوراً كبيراً في قاعدة 3-2-1، وهو يعني لدى مزوّد لا يعتمد التحقق من الهوية (KYC) شيئاً أكثر تحديداً من «مبنى آخر». إنه يعني نسخة لا يتوقف بقاؤها على الشركة نفسها، ولا الحساب نفسه، ولا علاقة الدفع نفسها، ولا الولاية القضائية نفسها التي تخضع لها النسخة الأصلية. خادمان في حساب واحد هما خادمان بمصير واحد، مهما تباعدت مراكز البيانات: فإغلاق الحساب لأي سبب يأخذهما معاً، وأي إجراء قانوني يُبلَّغ به كيان واحد يطال كل ما يملكه ذلك الكيان. الاستقلالية خاصية في العلاقة، لا في الجغرافيا وحدها.

النسخة العملية من هذا أسهل مما تبدو، لأن اللوحة نفسها تُتيح أصلاً أربع ولايات قضائية. نسخة إنتاجية في هولندا يُدفَع مستودعها إلى فئة Starter في آيسلندا تكلف $8.50 شهرياً، وتضع استردادك خارج متناول أي إجراء وطني واحد — ولأن الولايات القضائية تختلف فيما تقاومه فعلياً، فإن هذا الاقتران يستحق لحظة تفكير لا رمية عملة معدنية. وبما أن المستودع مُشفَّر قبل أن يغادر المصدر، فإن مضيف النسخ الاحتياطي غير موثوق به بحكم التصميم: ما تشتريه بالموقع الثاني هو التوافر والمسافة القانونية، لا السرية. أما السرية فأنت تملكها أصلاً.

للحصول على نسخة ثالثة مستقلة حقاً، تعكس البنية الأقوى اتجاه الاتصال. فبدلاً من أن يدفع الخادم البيانات إلى وجهة يحمل بيانات اعتمادها، تقوم آلة تتحكم بها أنت — جهاز في المنزل، أو NAS، أو حاسوب محمول يستيقظ وفق جدول — بـسحب البيانات من الخادم. عندئذٍ لا تحمل الآلة الإنتاجية أي بيانات اعتماد لأي وجهة نسخ احتياطي على الإطلاق، وهذا يجعل سيناريو الاختراق الموصوف في القسم السابق مستحيلاً من حيث البنية لا مجرد مخفَّف الأثر. يكلفك هذا امتلاك آلة يجب أن تكون قابلة للوصول أو مستيقظة وفق جدول، ولهذا فهو يكمِّل نسخة مدفوعة خارج الموقع لا يحل محلها.

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

التمرين، وكيف تكتشف أنه توقف عن العمل

لا تفشل مهام النسخ الاحتياطي عادة بشكل درامي. إنها تفشل بالتدريج: نمط استبعاد يُوسَّع أثناء عملية تنظيف، أو بيانات اعتماد تُجدَّد على جانب واحد فقط، أو قرص يمتلئ على الوجهة، أو إدخال cron يضيع أثناء ترقية التوزيعة. في كل واحدة من هذه الحالات تستمر الآلة في العمل، ولا يصدر أي تنبيه، ويتوقف المستودع بهدوء عن النمو. التصميم الذي يلتقط هذا ليس «التنبيه عند الفشل» — فمهمة لم تعد تعمل لا يمكنها الإبلاغ عن فشلها الخاص — بل التنبيه عند غياب النجاح. اجعل كل عملية تشغيل ناجحة تُرسل نبضة إلى نقطة نهاية من نوع «مفتاح الرجل الميت»، واجعل تلك النقطة تُطلق إنذاراً حين لا تصل النبضة في موعدها. الأمر يستغرق عشر دقائق من الإعداد، وهو الفارق بين ملاحظة المشكلة خلال يوم وملاحظتها أثناء عملية استعادة.

التحقق من السلامة هو النصف الثاني. تستطيع كلتا الأداتين التحقق من أن البيانات الوصفية للمستودع متماسكة، والأهم من ذلك التحقق من أن القطع المخزَّنة تُفَك تشفيرها فعلاً وتطابق قيم التجزئة الخاصة بها. قراءة كل شيء مكلفة من حيث النطاق الترددي، لذا تقدم الأداتان صيغة جزئية — يفحص restic نسبة مئوية من البيانات في كل تشغيل، ويتحقق borg من البيانات عند الطلب — والوتيرة المعقولة هي فحص كامل للبيانات الوصفية أسبوعياً وفحص جزئي للبيانات شهرياً، بحجم يجعل المرور الكامل يحدث على مدى ربع سنة. فالتخزين يتآكل فعلاً، والغرض من التحقق هو معرفة ذلك بينما لا تزال لديك نسخة أخرى.

لا شيء من هذا دليل على أنك تستطيع الاستعادة فعلاً. لهذا الدليل مصدر واحد فقط، هو الاستعادة نفسها. جهِّز نسخة جديدة — أصغر فئة تكلف $8.50 وستتلفها خلال الساعة — واستعد المستودع إليها، ثم افعل الجزء الذي يتجاهله الناس: شغِّل التطبيق وانظر إلى بيانات حقيقية. سجِّل الدخول. افتح مستنداً من الشهر الماضي. أرسل رسالة اختبار عبر خادم البريد. استعلم عن جدول ينبغي أن يحتوي صفوف الأمس. وجود الملفات ليس هو الاختبار؛ بل عمل الخدمة فوقها هو الاختبار. افعل هذا أول مرة تُعِدُّ فيها النسخ الاحتياطي، ثم كرره على فترة تقويمية تلتزم بها فعلاً، لأن التمرين يتحقق أيضاً من دليل التشغيل، ودليل التشغيل يتقادم أسرع من البيانات.

يستحق دليل التشغيل فقرة خاصة به لأنه أرخص عنصر هنا وأكثرها غياباً. اكتب، بالترتيب: أين يقيم المستودع وكيف تصل إليه، وأين تُحفظ عبارة المرور، وكيف تُجهِّز آلة بديلة، وأي الحزم والإصدارات تُثبَّت، وماذا تستعيد وبأي ترتيب، وأي سجلات DNS يجب تغييرها، وكيف تتأكد من أن الأمر نجح. احتفظ به خارج الآلة التي يصفها — في المستودع نفسه، أو في مدير كلمات مرور، أو على ورق — وافترض أن الشخص الذي يقرؤه متعب، ويعمل في ساعة غير مريحة، وربما ليس أنت. هذا الافتراض الأخير هو ما يحوّل مجموعة ملاحظات إلى شيء يستطيع زميل أو أحد أفراد العائلة تنفيذه.

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