نسخ احتياطي VPS يُمكن استعادته فعلاً

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

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

ما الذي يدمّر السيرفرات فعلياً

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

اقرأ هذا الجدول كقائمة تحقق لا كقائمة مخاوف. نسخة ليلية إلى قرص ثانٍ في الآلة نفسها تجيب على الصف الأول وحده. لقطة (snapshot) في اللوحة نفسها تجيب على الصفين الأول والثاني. نسخة محفوظة في مكان لا يستطيع السيرفر الوصول إليه، تحت مفتاح ما زلت تملكه، هي وحدها من يجيب على الصفوف الخمسة كلها.

اللقطة ليست نسخة احتياطية، ومزوّدك ليس بديلاً عنها أيضاً

اللقطات (snapshots) ممتازة فيما تفعله: فهي تتراجع عن تحديث فشل، في ثوانٍ، دون أي نقل بيانات. ما لا تستطيع فعله هو النجاة من الحدث الذي أطاح بالسيرفر نفسه، لأنها تشارك كل نطاقات الفشل معه — المزوّد نفسه، الحساب نفسه، الدولة نفسها، وغالباً وحدة التخزين نفسها. اللقطة تحميك من نفسك. النسخة الاحتياطية تحميك من كل شيء آخر.

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

قاعدة 3-2-1، مُعاد صياغتها لمن لم يُظهر بطاقة هوية قط

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

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

عملياً، هذا رخيص. وجهة النسخ الاحتياطي لا تحتاج نوى معالجة، وبالكاد تحتاج شبكة — تحتاج قرصاً وعنواناً فقط. أصغر فئة VPS في موقع مختلف من مواقعنا السبعة تصلح كوجهة كفؤة لـrestic أو Borg، وبالنسبة للأرشيفات المقاسة بالتيرابايت، فإن سيرفراً مخصصاً بأقراص حقيقية يكلّف أقل لكل تيرابايت من أي تخزين كائني (object store). حيث تكون البيانات كبيرة فعلاً ونادرة القراءة، تميل الاقتصاديات بفارق كبير نحو العتاد الفعلي (bare metal).

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

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

الدفع، والسحب، والخطأ الذي يجعل ليلة سيئة واحدة تلتهم النسختين معاً

هذا هو الترتيب الذي يبنيه الجميع تقريباً أولاً. مهمة على سيرفر الإنتاج تعمل ليلياً، تحمل مفتاحاً أو رمزاً لوجهة النسخ الاحتياطي، تتصل، وتدفع (push) البيانات. الأمر يعمل، وهو بسيط، وله خاصية لا تظهر إلا في أسوأ يوم في حياة السيرفر: من يتحكم بآلة الإنتاج يتحكم بالنسخ الاحتياطية أيضاً.

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

هناك حلّان نظيفان، وينسجمان جيداً مع التحصين الأساسي الذي يُفترض أنك أجريته بالفعل.

• وجهات إضافة فقط (append-only). تدعم الأداتان الرئيسيتان نمطاً يستطيع فيه العميل إضافة بيانات ولا يستطيع حذفها. تفعل Borg ذلك بتقييد مفتاح SSH على الوجهة بأمر borg serve --append-only؛ وتفعله restic بخادم REST يُشغَّل بخيار --append-only. سيرفر الإنتاج يكتب كل ليلة وهو غير قادر بنيوياً على تدمير التاريخ. تقليم (pruning) اللقطات القديمة يحدث بعد ذلك على جهة الوجهة، في جلسة لا يستطيع سيرفر الإنتاج بدءها.
• السحب بدلاً من الدفع. اعكس الاتجاه: سيرفر النسخ الاحتياطي هو من يتصل بالإنتاج، ويقرأ، ويخزّن. سيرفر الإنتاج لا يحمل أي بيانات اعتماد للوجهة إطلاقاً، فلا شيء يُسرَق. قيّد المفتاح المُستخدم على جهة الإنتاج بخيار restrict وأمر command= إجباري حتى لا يتحول مفتاح نسخ احتياطي مسروق إلى صدفة (shell) كاملة.

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

شفّر عند المصدر، ثم قرّر من يحمل المفتاح

تُشفّر كلتا الأداتين الجادتين على الآلة التي يُنسخ منها احتياطياً، قبل أن يعبر أي شيء الشبكة. الوجهة تخزّن كتلاً (blobs) لا تستطيع تفسيرها — وهذا بالتحديد ما يجعل النسخة عبر مزوّد آخر آمنة. سيرفرك الثاني لا يحتاج أن يكون موثوقاً، ولا حتى ودوداً؛ يحتاج فقط أن يكون قابلاً للوصول وأن يملك قرصاً. هذه الخاصية الوحيدة هي ما يحوّل "سيرفراً في دولة لا أعرف عنها شيئاً" من مخاطرة إلى بنية تحتية.

هذه آلية مختلفة عن تشفير قرص السيرفر نفسه، والاثنتان تجيبان عن سؤالين مختلفين — يشرح دليلنا عن التشفير الكامل للقرص على VPS ما يحميه تشفير القرص وما لا يحميه أثناء عمل الآلة. تشفير النسخ الاحتياطي أسهل وأكثر قيمة من الاثنين، لأن نموذج التهديد صادق: البيانات ساكنة، على عتاد لا تتحكم به، والمفتاح لا يذهب إلى هناك أبداً.

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

• احتفظ بعبارة المرور على السيرفر فقط كملف يقرؤه root وحده، مُشار إليه بخيار --password-file، حتى لا تظهر أبداً في قائمة عمليات (process list) أو في سجل الأوامر.
• احتفظ بنسخة قابلة للقراءة البشرية خارج كل آلة معنية. ورقة في درج تتفوق فعلياً على مدير كلمات مرور يتزامن مع حساب قد تفقد الوصول إليه أيضاً.
• أضف مفتاحاً ثانياً إلى المستودع — عبر restic key add، أو مفتاح Borg مُصدَّر — بحيث تكون عبارة مرور واحدة منسية مجرد إزعاج لا نهاية الأرشيف.

والقاعدة الكامنة خلف العادات الثلاث: إذا كانت النسخة الوحيدة من المفتاح تعيش على الآلة نفسها التي وُجدت النسخة الاحتياطية لتعويضها، فأنت لا تملك نسخة احتياطية. أنت تملك كومة مشفّرة من الكتل وقصة عنها.

اختيار أداة، في جدول واحد

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

بالنسبة لسيرفر واحد، فإن استخدام restic لنسخ البيانات إلى VPS ثانٍ هو أقصر طريق إلى نتيجة صحيحة. أما بالنسبة لـseedbox، أو أرشيف وسائط، أو أي شيء يحتوي ملفات كبيرة متشابهة كثيرة، فإن إزالة التكرار في Borg هي الفارق بين قرص ممتلئ وقرص مريح — يشرح دليل إعداد الـseedbox جانب التخزين من هذا الحمل بتفصيل أكبر.

كل ما هو قيد التشغيل ليس ملفاً

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

ثلاث طرق للخروج من هذا، بترتيب تصاعدي للجهد. فرّغها (dump): يمنحك mysqldump --single-transaction تفريغاً متسقاً لـInnoDB دون قفل الكاتبين، ويفعل pg_dump الأمر نفسه لـPostgreSQL. التقط لقطة لها: جمّد نظام الملفات أو خذ لقطة LVM أو ZFS، انسخ من اللقطة، ثم حرّرها — هكذا تتعامل مع مجموعات بيانات كبيرة جداً لتفريغها كل ليلة. أو أوقفها: بالنسبة لخدمة صغيرة، دقيقتان من التوقف عند 04:00 استراتيجية اتساق محترمة تماماً، وهي الوحيدة بلا حالات استثنائية.

المنطق نفسه يتجاوز قواعد البيانات. الطبقة القابلة للكتابة في الحاوية (container) قابلة للتخلص منها، لكن أحجامها (volumes) ليست كذلك، وكذلك ملف docker compose وملفات البيئة المرافقة له — نسخة احتياطية تستعيد البيانات دون التعريف تتركك تُعيد بناء الحزمة من الذاكرة. طوابير الرسائل، وRedis مع تفعيل الاستمرارية (persistence)، وصندوق بريد يكتب إليه MTA، كلها تستحق المعاملة نفسها: هدّئها، أو التقط لها لقطة، أو فرّغها، لكن لا تنسخها مباشرة أملاً في الأفضل.

ما الذي تنسخه احتياطياً، والأجزاء التي ينساها الجميع

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

• /etc بالكامل، إضافة إلى وحدات ومؤقتات systemd التي كتبتها، وأي جداول cron تعيش خارجه.
• شهادات TLS ومفاتيحها الخاصة، أو على الأقل مفتاح حساب ACME، حتى تتجدد الشهادات بدلاً من البدء من الصفر.
• قواعد جدار الحماية وقائمة الحزم، التي تُعيد معاً بناء شكل الآلة أسرع من أي ذاكرة عنها.
• أسرار التطبيق وملفات البيئة — تلك المُستبعدة عمداً من مستودع الشيفرة، وبالتالي غير موجودة في أي مكان آخر.
• سجلات DNS مُصدَّرة كنص، بما فيها إدخالات reverse-DNS وPTR، التي تعيش لدى المزوّد لا على السيرفر.

الاستعادة التي لم تختبرها مجرد شائعة

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

ابدأ بفحوصات السلامة الرخيصة — restic check --read-data-subset=5% أو borg check --verify-data على جدول زمني — وافهم أنها تتحقق من الأرشيف، لا من قدرتك على استخدامه. التمرين الحقيقي مختلف ويستغرق بعد ظهر يوم واحد، مرة واحدة. اطلب سيرفراً جديداً بالساعة في موقع لا تستخدمه عادة. استعد إليه بلا شيء سوى عنوان المستودع، وعبارة المرور، وملاحظاتك الخاصة. شغّل الخدمة. احسب زمن العملية كاملة. ثم دمّر الآلة. التكلفة الإجمالية: بضعة دولارات، وهو التمرين الوحيد الذي ينتج رقماً يمكنك الوثوق به.

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

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

أتمِتها لتستمر في الحدوث

شغّل المهمة من مؤقّت systemd بدلاً من cron. تحصل على السجلات في مكان واحد، وسجل حقيقي لآخر تشغيل، وجدول زمني ينجو من إعادة التشغيل — وهذا كله لا يمنحك إياه cron دون عمل إضافي. أبقِ عبارة المرور خارج ملف الوحدة (unit file) نفسه، الذي يستطيع أي شخص لديه وصول إلى الصدفة (shell) قراءته مباشرة عبر systemctl cat.

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

اضبط مدة الاحتفاظ عمداً لا بالإعداد الافتراضي. شيء مثل --keep-daily 7 --keep-weekly 4 --keep-monthly 6 يغطي الأخطاء التي تلاحظها الليلة والفساد الذي تلاحظه في الربيع، دون أن ينمو إلى الأبد. شغّل عملية التقليم على جهة الوجهة إذا كنت قد اعتمدت وضع append-only، وهذا هو الهدف من اعتماده أصلاً. حجم النقل نادراً ما يكون القيد على شبكتنا — النطاق الترددي غير محدود في كل خطة — لذا خطّط للاتساق لا للحصة، وتحقق من التوقيت مقابل ساعاتك الهادئة الخاصة. العادات الأوسع حول كل هذا مشروحة في دليل الأمن التشغيلي للسيرفر.

النسخة المختصرة

إذا لم تفعل شيئاً آخر من هذه الصفحة، فافعل هذه الأمور الستة، بهذا الترتيب تقريباً:

• ضع نسخة واحدة لدى مزوّد ثانٍ، في ولاية قضائية ثانية، مدفوعة بالطريقة الخاصة نفسها كالأولى.
• اجعل تلك النسخة إضافة فقط (append-only)، أو اسحبها من الوجهة، حتى لا يستطيع سيرفر مُخترَق تدميرها.
• دع الأداة تُشفّر عند المصدر، وأبقِ المفتاح بعيداً عن كلتا الآلتين المعنيتين.
• فرّغ قواعد البيانات وأوقف أو التقط لقطة لكل ما هو قيد التشغيل؛ لا تنسخ حالة حيّة مباشرة أبداً.
• انسخ مفاتيح الهوية احتياطياً بشكل منفصل — onion، وWireGuard، وDKIM، وبذور العقد — لأن هذه لا يمكن إعادة توليدها.
• استعد مرة واحدة إلى سيرفر يُستهلك ويُرمى، احسب الزمن، ودوّن ما كان ناقصاً.

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