كل نسخة احتياطية تعمل إلى أن يأتي اليوم الذي تحتاجها فيه. اللقطة موجودة على المنصة التي تعطّلت للتو. أرشيف tar الليلي يفشل بصمت منذ أن امتلأ قرص في مارس. تفريغ قاعدة البيانات كان نسخة ملف أُخذت في منتصف عملية الكتابة، ولا يمكن استعادته إلى شيء. النسخ الاحتياطي هو الجزء الوحيد من الخادم الذي لا يمكنك الحكم عليه بالنظر إليه — بل باستعادته فقط. إليك كيف تبني نسخة احتياطية تنجو من عطل العتاد، ومن يديك أنت، ومن شخص آخر يملك بيانات اعتمادك، دون تسليم نسخة قابلة للقراءة من الجهاز لمن يخزّنها.
أربعة أشياء تدمّر الخادم، وكل واحد منها يحتاج شيئًا مختلفًا
صمّم النسخ الاحتياطي حول سيناريو الفشل، لا حول الأداة. أربعة سيناريوهات تفسّر تقريبًا كل خسارة حقيقية، وكل واحد منها يتطلب من النسخة التي تحتفظ بها شيئًا مختلفًا. الإعداد الذي يعالج واحدًا منها يبدو كافيًا تمامًا إلى أن يواجه سيناريو آخر.
عطل العتاد أو المضيف
يتعطل القرص، أو العقدة، أو مركز البيانات. أي نسخة محفوظة في مكان آخر تُنقذك هنا. وهذا هو الفشل الوحيد الذي تتعامل معه اللقطة على المنصة نفسها بشكل موثوق، وهو بالضبط سبب اعتقاد كثير من الناس أن اللقطات كافية.
يداك أنت
علم (flag) خاطئ في أمر، أو سكربت ترحيل وُجِّه إلى بيئة الإنتاج، أو عملية تنظيف حذفت أكثر مما كان مقصودًا. الضرر ينتشر فورًا إلى كل ما يُطابق الأصل، لذا ما يُنقذك هو التاريخ — نسخة من قبل الخطأ، لا نسخة حالية من بعده.
الاختراق وبرامج الفدية
مهاجم يملك صلاحيات root له بالضبط النطاق نفسه الذي تملكه مهمة النسخ الاحتياطي لديك: بيانات الاعتماد نفسها، والوجهة نفسها، والجدول الزمني نفسه. وإن كان بإمكان الخادم حذف نسخه الاحتياطية الخاصة، فستُحذف. والنجاة هنا تتوقف على أن تكون النسخة غير قابلة للحذف (append-only) أو بعيدة عن المتناول كليًا.
فقدان الحساب، لا الخادم
تعثر في الفوترة، أو حساب مُعلَّق، أو أمر إزالة (takedown) في ولاية قضائية غير مناسبة. العتاد بخير، لكنك ببساطة لا تستطيع الوصول إليه. لا يفيد هنا سوى نسخة محفوظة لدى مزوّد مختلف، بمسار دفع مختلف.
دوّن أيًا من هذه الأربعة تدافع عنه فعليًا قبل أن تختار أي شيء. نسخة ليلية إلى مجلد ثانٍ على القرص نفسه تغطي واحدًا منها بالضبط — وهو الأقل احتمالًا — بينما تبدو تمامًا وكأنها نسخة احتياطية كاملة. معظم الإعدادات التي تفشل في بيئة الإنتاج تفشل لأن أحدًا لم يحدد السيناريو المقصود قط.
اللقطات ليست نسخًا احتياطية
تُستخدم الكلمتان وكأنهما مترادفتان، لكنهما تصفان شيئين مختلفين بمجالات فشل مختلفة. ومعرفة أيهما تملك فعليًا هي ما يحدد إن كنت تملك أي شيء على الإطلاق.
استخدم اللقطات فيما تتفوق فيه حقًا: تراجع في خمس ثوانٍ قبل أن تلمس النواة، أو محمّل الإقلاع (bootloader)، أو مخطط قاعدة بيانات. خذ لقطة، نفّذ الأمر الخطر، ثم احذفها حين ينجح. وما يجب ألا تفعله أبدًا هو أن تدع عبارة "توجد لقطة" تصبح سببًا لعدم وجود نسخة احتياطية — فاللقطة تشارك مصيرها مع المنصة التي تحتفظ بها، والحساب المُعلَّق يأخذ الاثنين معًا دفعة واحدة.
قاعدة 3-2-1، والرقمان اللذان يتجاهلهما الجميع
هذه القاعدة القديمة ما زالت صامدة لأنها تصف الاستقلالية لا نظام أرشفة: ثلاث نسخ من البيانات، على نوعين مختلفين من التخزين، واحدة منها في مكان آخر. وإضافتان تعالجان إخفاقات كانت نادرة حين كُتبت القاعدة، وأصبحت اليوم روتينية.
- ثلاث نسخ. البيانات الحية زائد نسختين احتياطيتين. نسختان فقط تعنيان أنك على بعد استعادة فاشلة واحدة من ألا تملك شيئًا.
- نوعان من الوسائط، أو مزوّدان. على بنية تحتية مستأجرة، تعني "الوسائط" فعليًا استقلالية إدارية — فنسخة ثانية تحت الحساب نفسه، على المنصة نفسها، ومدفوعة من الرصيد نفسه، ليست سوى النسخة الأولى بخطوات إضافية.
- واحدة خارج الموقع. مبنى مختلف، وشبكة مختلفة، وولاية قضائية مختلفة إن كان ذلك يهمّك. و/locations هي النسخة العملية من هذا المبدأ: اختر منطقة تفشل بشكل مستقل عن المنطقة التي تحمي بياناتها.
- واحدة غير قابلة للتغيير أو غير متصلة بالشبكة. نسخة لا يستطيع الخادم نفسه حذفها، لأن من يملك الخادم يملك بيانات اعتماده أيضًا.
- صفر عمليات استعادة غير مُتحقَّق منها. النسخة الاحتياطية التي لم تستعدها قط مجرد فرضية. والرقم الذي يهم هو عدد عمليات الاستعادة التي أنجزتها فعليًا، لا عدد المهام التي أبلغت عن نجاحها.
انسخ البيانات احتياطيًا، وأعد بناء الباقي
الغريزة الأولى هي أخذ صورة لكل شيء. وهذا مكلف، وبطيء عند الاستعادة، ويحافظ بأمانة على الملف الثنائي المخترَق، وحالة الحزم المعطوبة، وانحراف الإعدادات (config drift) الذي لم تعد تتذكر كيف نشأ. الخادم يحتوي على ثلاثة أنواع من المحتوى، واحد منها فقط ينتمي إلى النسخة الاحتياطية.
- أدرِج /etc، و/home، و/root، و/srv، وجذر الويب الخاص بك، ومجلد حالة تطبيقك، وأحجام الحاويات المسمّاة، ومجلدًا يضم تفريغات قاعدة بيانات حديثة.
- أدرِج وصفة النشر نفسها — ملفات compose، وسكربتات Ansible أو الشل (shell)، والملاحظات التي كتبتها في الثانية صباحًا. احتفظ بها في نظام التحكم بالإصدارات أيضًا، لكن ضع نسخة منها في النسخة الاحتياطية حتى لا تعتمد الاستعادة أبدًا على إمكانية الوصول إلى خدمة ثانية.
- استبعِد /proc، و/sys، و/dev، و/run والمجلدات المؤقتة. فهذه واجهات للنواة ومساحات عمل مؤقتة؛ ونسخها يهدر الوقت أو يُعلّق المهمة كليًا.
- استبعِد ذواكر الحزم المؤقتة، ومجلدات البناء، وأشجار التبعيات، والبيئات الافتراضية (virtualenvs) — أي شيء تعيد خطوة بناء توليده. وعلى خادم تطبيقات نموذجي، هذا يمثّل معظم القرص.
- استبعِد ملفات قاعدة البيانات الحية إن كنت تُفرِّغ قاعدة البيانات بالطريقة الصحيحة. فنسخ الاثنين احتياطيًا يعني أن النسخة الأكبر وعديمة الفائدة هي التي سيستعيدها أحدهم في الثالثة صباحًا.
- لا تستبعد الملفات المخفية. فنصف ما يهم على جهاز لينكس يبدأ بنقطة.
قواعد البيانات لن تنجو من نسخ الملفات مباشرة
هذا هو السبب الأكثر شيوعًا وراء فشل عمليات الاستعادة. قاعدة البيانات قيد التشغيل تحتفظ بحالتها في الذاكرة وتكتب بترتيب غير متسلسل؛ ونسخ ملفاتها أثناء عملها يلتقط حالة ممزقة ومكتوبة جزئيًا، قد تُستعاد، أو تُستعاد بفساد صامت، أو لا تُستعاد على الإطلاق. خذ تفريغًا صحيحًا لقاعدة البيانات، ثم انسخ ذلك التفريغ احتياطيًا.
- PostgreSQL: استخدم pg_dump لكل قاعدة بيانات على حدة، أو pg_dumpall للعنقود (cluster) بأكمله بما في ذلك الأدوار (roles). وحيث يكون فقدان يوم كامل غير مقبول، أضف أرشفة WAL حتى تتمكن من الاستعادة إلى نقطة زمنية محددة بدلًا من ليلة الأمس فقط.
- MySQL أو MariaDB: يمنحك mysqldump مع --single-transaction لقطة متسقة على InnoDB دون حجب عمليات الكتابة. لكنه لا يفعل ذلك على MyISAM — سبب إضافي لعدم استخدام MyISAM. وللمجموعات الكبيرة من البيانات، تستعيد أداة نسخ فعلي (physical) مثل mariabackup بسرعة أكبر بكثير من إعادة تشغيل تفريغ.
- SQLite: لا تنسخ الملف مطلقًا. استخدم أمر .backup أو VACUUM INTO، فكلاهما يأخذ القفل (lock) بالطريقة الصحيحة. نسخ قاعدة بيانات لها سجل كتابة استباقي نشط مقامرة ستخسرها عاجلًا أم آجلًا.
- Redis: فعِّل حفظًا في الخلفية (background save) وانسخ احتياطيًا ملف اللقطة الناتج، أو شغِّله في وضع append-only وانسخ السجل احتياطيًا. نسخ لقطة حية في منتصف الكتابة يمنحك ملفًا مبتورًا يُحمَّل كمجموعة بيانات فارغة.
- الحاويات: الحجم هو البيانات. أوقِف المكدّس (stack) للثواني التي تستغرقها عملية النسخ، أو شغِّل أداة التفريغ داخل الحاوية — لكن لا تضغط (tar) حجم قاعدة بيانات قيد التشغيل وتسمّي ذلك نسخة احتياطية.
- أي شيء آخر له عملية دائمة — فهارس البحث، وطوابير الرسائل، وخدمات دفاتر الحسابات (ledger daemons) — له أمر تصدير متسق خاص به. اعثر عليه الآن، لا أثناء الانقطاع.
تحل لقطات نظام الملفات هذه المشكلة من الاتجاه المعاكس: يجمّد LVM وZFS وbtrfs عرضًا متسقًا للحجم خلال أجزاء من الثانية، فتنسخ احتياطيًا ذلك العرض المجمَّد بينما تستمر قاعدة البيانات في الخدمة. هذا هو الحل الصحيح لمجموعات البيانات التي يستغرق تفريغها ساعات. لكنه ليس سببًا لتخطي التفريغ في قاعدة بيانات بحجم 200 MB، حيث يكون التفريغ أبسط، وقابلًا للنقل بين إصدارات المحرك، وقابلًا للقراءة من إنسان حين يحدث خطأ غريب.
اختيار الأداة
أربع أدوات تغطي كل حالة تقريبًا. والخاصية الأهم هي أين يحدث التشفير. فإن كانت البيانات مشفَّرة فقط أثناء النقل، ثم أثناء السكون من قِبل مزوّد التخزين، فإن مزوّد التخزين يستطيع قراءتها — وتكون النسخة الاحتياطية قد تحوّلت بصمت إلى أضعف نقطة في نظام حصّنته في كل مكان آخر.
أيًا كان اختيارك، يجب أن توجد عبارة المرور أو المفتاح في مكان آخر غير الخادم الذي يُنسخ احتياطيًا. وهذا هو الفخ الذي يقع فيه حتى الحريصون: مفتاح المستودع مخزَّن في /root، ومنسوخ احتياطيًا بأمانة داخل المستودع نفسه الذي يفتحه. اطبعه، أو احتفظ به في مدير كلمات مرور يمكنك فتحه من جهاز ما زال يعمل. فالمستودع الذي لا تستطيع فك تشفيره لا يختلف عن عدم وجود نسخة احتياطية أصلًا.
أين ينبغي أن تعيش النسخة الثانية
الوجهة هي ولاية قضائية وعلاقة فوترة بقدر ما هي مساحة قرص. أربعة خيارات، مرتّبة تقريبًا بحسب مدى استقلاليتها عن الخادم الذي تحميه.
خادم ثانٍ في منطقة أخرى
الإجابة المباشرة: نسخة (instance) رخيصة في بلد مختلف، يمكن الوصول إليها عبر SSH، ولا تشغّل شيئًا سوى sshd ومستودع. خطة /vps بذاكرة 1 GB تكفي لاستيعاب نسخ احتياطية لأسطول صغير من الخوادم، ويمكن تقييد الحساب بأمر إجباري واحد حتى لا يفتح مفتاح مسروق أي واجهة سطر أوامر (shell).
قرص من فئة التخزين
بمجرد أن تصل مجموعة البيانات إلى مئات الغيغابايتات، تصبح تكلفة سعة أقراص HDD على رابط شبكي غير محدود (unmetered) أقل بكثير للتيرابايت الواحد من NVMe، وكتابة النسخ الاحتياطي لا تحتاج أصلًا إلى زمن استجابة NVMe. و/storage مصمَّم لهذا بالذات: قرص محمي بـRAID من فئة التيرابايت، وصلاحيات جذر كاملة، ودون أي فحص للمحتوى.
تخزين كائنات متوافق مع S3
مريح، وسعره محسوب بالغيغابايت، وغالبًا يدعم قفل الكائنات (object lock) الذي يمنح عدم قابلية حقيقية للتغيير. اطّلع على تسعير حركة البيانات الصادرة (egress) قبل الاعتماد عليه — فسحب تيرابايت كامل في حالة طارئة ليس اللحظة المناسبة لاكتشاف تكلفة الاسترجاع.
عتاد تملكه أنت
قرص خارجي أو جهاز في المنزل، يُسحَب (pulled) إليه لا يُدفَع (pushed). أبطأ ويدوي، والنسخة الوحيدة في هذه القائمة التي لا يستطيع أي مزوّد أو أمر قضائي أو نزاع فوترة الوصول إليها. تستحق الاحتفاظ بها لبيانات لا يمكنك إعادة إنشائها فعليًا، حتى لو تأخرت أسبوعًا عن البقية.
طابِق خصائص خصوصية النسخة الاحتياطية مع خصائص الخادم نفسه. فتشفير قرص بـLUKS ثم إرسال نسخ احتياطية نصية صريحة كل ليلة إلى دلو تخزين مسجَّل ببطاقتك يُبطل التمرين برمّته: تصبح البيانات قابلة للقراءة الآن، ومسجَّلة باسمك. وإن كان الخادم يستحق الدفع من أجله بهوية مجهولة، فكذلك تستحق النسخة الاحتياطية — شفّر من جهة العميل، واشترِ الوجهة بالطريقة نفسها التي اشتريت بها المصدر.
بناؤه، خطوة بخطوة
- 1
احسم الرقمين أولًا
كمية البيانات التي يمكنك تحمّل خسارتها — أي الفجوة بين مرات التشغيل — والمدة التي يمكنك تحمّل توقفك خلالها. كل شيء آخر ينبني على هاتين الإجابتين. فالنسخ الاحتياطي كل ساعة لموقع ثابت (static) مجرد مسرحية؛ والنسخ الاحتياطي الليلي لقاعدة بيانات طلبات قرار يجب اتخاذه بوعي، لا وراثته من درس تعليمي.
- 2
أنشئ الوجهة
نسخة ثانية في منطقة أخرى، بمفتاح SSH خاص بها ومستخدم مخصص بلا صلاحيات يكون مجلده الرئيسي هو المستودع. لا يعمل أي شيء آخر هناك. قيّد المفتاح بأمر إجباري حتى لا تستطيع بيانات اعتماد مسروقة سوى إلحاق نسخ احتياطية جديدة، لا فتح واجهة سطر أوامر أبدًا.
- 3
ولِّد المفتاح واحفظه في مكان آخر
عبارة مرور عشوائية طويلة، مدوَّنة في مكان ينجو من فقدان الخادم. هيّئ المستودع (initialise)، ثم أثبت أنك تستطيع سرد محتوياته من جهاز ثالث باستخدام ما دوّنته فقط. وإن لم تستطع، أصلح ذلك قبل كتابة أول نسخة احتياطية.
- 4
فرِّغ قواعد البيانات أولًا
سكربت قصير يكتب تفريغات متسقة إلى مجلد مؤقت (staging)، ويخرج برمز غير صفري إن فشل أي منها — يعمل قبل نسخ الملفات احتياطيًا، لا بالتوازي معه. المهمة التي تستمر بعد فشل التفريغ هي كيف ينتهي الأمر بالناس إلى ثلاثين يومًا من ملفات بحجم صفر بايت.
- 5
انسخ احتياطيًا المسارات المهمة
وجّه الأداة إلى قائمة المسارات المُدرَجة، وطبّق الاستثناءات، وتحقّق من سلامة أول تشغيل. فإن انتهى مستودع جديد لخادم بحجم 40 GB إلى 300 MB، فهناك شيء يُتخطى بصمت؛ وإن انتهى إلى 38 GB، فاستثناءاتك لا تعمل.
- 6
جدوِله واجعل الفشل صاخبًا
مؤقّت systemd بتأخير عشوائي، أو cron إن كانت تلك عادتك المعتادة. ثم اجعل المهمة تُبلِّغ: نبضة (heartbeat) إلى أداة مراقبة عند النجاح، وتنبيه حين تتوقف تلك النبضة عن الوصول. الفشل الصامت هو نمط الفشل الطبيعي للنسخ الاحتياطي، لأن لا شيء يتعطل بشكل ظاهر حين تتوقف — إلى أن يتعطل كل شيء دفعة واحدة.
- 7
اضبط مدة الاحتفاظ ونفِّذ التقليم فعليًا
كل ساعة لمدة يوم، ويوميًا لمدة أسبوعين، وأسبوعيًا لشهرين تقريبًا، وشهريًا لمدة سنة. ثم نفّذ عملية التقليم (prune) وتأكد من أن المستودع توقف عن النمو. فسياسة احتفاظ مضبوطة لكن لم تُنفَّذ قط تملأ الوجهة وتُسقط النسخ الاحتياطية معها.
- 8
استعِد شيئًا اليوم
ليست مهمة اختبار — بل ملف حقيقي، إلى مجلد مؤقت، يُفتح ويُتحقَّق منه. ثم ضع موعدًا في التقويم للجهاز بأكمله. أول استعادة كاملة تكشف دائمًا عن شيء ما: مسار مفقود، أو صلاحية، أو شهادة، أو مستخدم قاعدة بيانات لم يكن موجودًا إلا على الجهاز القديم.
إن دفعت (push) النسخة الاحتياطية من الخادم إلى الخارج، فأنت تكون قد قبلت بأن أي شخص يملك صلاحيات root عليه يستطيع تدمير كل نسخة. شغّلها بالاتجاه المعاكس — يتصل مضيف النسخ الاحتياطي إلى الداخل، ويسحب (pull)، ثم يقطع الاتصال — وعندها لا يستطيع خادم مخترَق الوصول إلى المستودع على الإطلاق، لأنه لا يحمل أي بيانات اعتماد له. إعداد السحب يتطلب عملًا أكبر، لكنه أكبر تحسين منفرد يمكن لمعظم الإعدادات إجراءه.
مدة الاحتفاظ، ولماذا تكون فترة أطول أرخص مما تبدو
عادةً ما تُضبط مدة الاحتفاظ بحسب ما يناسب مساحة القرص، ثم تُنسى. وهي تستحق تفكيرًا واعيًا واحدًا على الأقل، لأنها تحدد أي الأخطاء يمكن تداركها. نافذة من سبعة أيام تلتقط ملفًا حُذف يوم الثلاثاء. لكنها لا تلتقط فسادًا بدأ قبل ستة أسابيع وظهر حين خرج تقرير بأرقام خاطئة، أو مقتحِمًا جلس بهدوء على الجهاز لشهر كامل قبل أن يتحرك.
تجعل إزالة التكرار هذا أرخص بكثير مما يوحي به الجدول: فالتشغيل الثاني على خادم لم يتغير في معظمه يخزّن فقط ما تغيّر، لذا فإن سنة كاملة من نقاط الاستعادة الشهرية على جهاز بحجم 40 GB تكلّف عادةً بضعة غيغابايتات لا نصف تيرابايت. اضبط السياسة بناءً على ما تحتاج إلى التعافي منه، ثم تحقق من الفاتورة. ستجد عادةً أن بإمكانك تحمّل النسخة السخية.
عدم القابلية للتغيير: الجزء الذي يوقف برامج الفدية
كل ما سبق يفترض أن الخصم هو الانتروبيا (entropy). أما إن كان الخصم شخصًا يملك صلاحيات root، فإن مهمة النسخ الاحتياطي العادية تصبح دليل تعليمات جاهزًا له — فبيانات الاعتماد موجودة على الجهاز، والوجهة مذكورة في الإعدادات، ويُمحى المستودع قبل أن يبدأ التشفير. أربع آليات تكسر هذه السلسلة، وأي واحدة منها تغيّر النتيجة.
- مستودعات append-only. وضع append-only من جهة الخادم في Borg، أو خادم REST الخاص بـrestic في وضع append-only، يقبلان بيانات جديدة ويرفضان عمليات الحذف. يستطيع الخادم الكتابة؛ وأنت وحدك، من مكان آخر، من يستطيع التقليم.
- نسخ احتياطي بنمط السحب (pull). مضيف النسخ الاحتياطي هو من يبدأ الاتصال ويحمل بيانات الاعتماد الوحيدة. أما خادم الإنتاج فلا يملك مفتاحًا، ولا عنوان وجهة، ولا أي طريق إلى المستودع على الإطلاق.
- قفل الكائنات. تخزين متوافق مع S3 بمدة احتفاظ مفروضة على مستوى الدلو، حيث تُرفض عملية الحذف من طبقة التخزين نفسها بصرف النظر عمّا قد تسمح به بيانات الاعتماد لولا ذلك.
- بيانات اعتماد منفصلة لكل مضيف. لا ينبغي لجهاز واحد مخترَق أن يكشف تاريخ كل جهاز آخر. مفاتيح مستقلة، ومسارات مستقلة، وقيود مستقلة.
- نسخة واحدة غير متصلة بالشبكة فعليًا. القرص غير الموصول محصَّن ضد كل هجوم عن بُعد كُتب على الإطلاق. أسلوب غير عصري، لكنه لم يُهزَم قط.
تمرين الاستعادة
الاستعادة إجراء، والإجراء الذي لم يُنفِّذه أحد قط مجرد خيال. نفِّذ هذا مرة الآن ومرة كل ستة أشهر، ودوّن ما تتعلّمه — فالملاحظات تنتهي بأن تصبح لا تقل قيمة عن البيانات نفسها.
- 1
انشر نسخة فارغة
الإصدار نفسه من نظام التشغيل، دون تثبيت أي شيء آخر. يكفي VPS قصير العمر، وتكلفة التمرين بأكمله أقل من ثمن وجبة غداء.
- 2
استعِد باستخدام ما دوّنته فقط
عنوان المستودع، وعبارة المرور، والأوامر. وإن احتجت إلى شيء موجود فقط على الخادم الذي تتظاهر بأنه ميت، فقد وجدت للتو الثغرة — في يوم لا يكلّفك اكتشافها فيه شيئًا.
- 3
أعِد البيانات قبل التطبيق
حمّل تفريغ قاعدة البيانات، وضع الملفات في مكانها الصحيح، ثم أصلح الملكية والصلاحيات (modes). الملكية هي المفاجأة المعتادة: فمعرّفات المستخدمين الرقمية من الجهاز القديم نادرًا ما تتطابق على الجهاز الجديد.
- 4
شغّل الخدمة واستخدمها فعليًا
لا أمر حالة فقط — بل سجّل الدخول، وحمّل صفحة، ونفّذ استعلامًا، وأرسل رسالة. الخدمة التي تبدأ ليست الشيء نفسه كالخدمة التي تعمل.
- 5
احسب الوقت المستغرق ودوّن الرقم
كم استغرقت العملية بأكملها؟ هذا هو وقت التعافي الحقيقي لديك، وهو غالبًا أضعاف التقدير الأولي. احتفظ بالملاحظات بجانب عبارة المرور، وحدّث الاثنتين كلما تغيّر المكدّس (stack).
ما الذي يكلّفه النسخ الاحتياطي فعليًا، بصراحة
النسخ الاحتياطي هو أرخص تأمين في البنية التحتية، ومع ذلك يُتجاهل بشكل روتيني بسبب السعر. إليك بعض الأرقام الملموسة لخادم صغير، بافتراض أن البيانات تُضغَط وتُزال تكرارها كما تفعل البيانات العادية.
قارِن أيًا من هذه الأرقام بتكلفة الانقطاع الذي تمنعه. وتسمية الرقم هو بيت القصيد — فالحجة ضد النسخ الاحتياطي لا تتعلق فعليًا بالمال أبدًا بمجرد أن يُكتب ذلك المبلغ.
أين يقع المضيف من هذه الصورة
لخطة النسخ الاحتياطي الاعتماديتان نفسهما اللتان للخادم الذي تحميه: مكان مستقل لوضع النسخة فيه، وطريقة للدفع مقابله لا تُنشئ سجلًا جديدًا يكشف هويتك. وكلا الأمرين يهمّان هنا أكثر من أهميتهما عند المصدر، لأن النسخة الاحتياطية نسخة كاملة من كل ما كان المصدر يحميه.
كل خطة /vps و/storage هنا تُنشَر من رصيد عملات رقمية مدفوع مسبقًا بلا KYC، عبر 15 موقعًا مُدرجة على /locations — بحيث يمكن للنسخة الثانية أن تقع تحت ولاية قضائية مختلفة عن الأولى دون أي فحص هوية ثانٍ في أي نقطة من السلسلة. تُضمَّن اللقطات الفورية في كل نسخة من أجل التراجع في خمس ثوانٍ، ويعني النطاق الترددي غير المحدود أن لا أول رفعة ولا استعادة طارئة تُعدّ حدثًا محسوبًا بالاستهلاك، ويضيف /storage قرصًا محميًا بـRAID من فئة التيرابايت ابتداءً من $8.99/mo دون أي فحص للمحتوى. يغطي /pay-with العملات المقبولة، ويوضّح /offshore-hosting ما الذي تغيّره الولاية القضائية فعليًا، ويضم /guides المقالات المكمّلة حول تشفير القرص وحول ما يستطيع المضيف رؤيته وما لا يستطيعه بشأن أي جهاز.
قائمة التحقق
- حدّد سيناريو الفشل الذي تدافع عنه قبل اختيار أي أداة.
- تعامل مع اللقطات كزر تراجع، لا كنسخة احتياطية أبدًا.
- انسخ احتياطيًا البيانات والإعدادات؛ وأعد بناء نظام التشغيل من سكربت.
- فرِّغ كل قاعدة بيانات بأمر التصدير المتسق الخاص بها، وانسخ احتياطيًا ذلك التفريغ.
- شفّر من جهة العميل، قبل أن يغادر أي شيء الجهاز.
- احتفظ بعبارة مرور المستودع في مكان ينجو من فقدان الخادم.
- ضع نسخة واحدة على الأقل لدى مزوّد مختلف، وفي منطقة مختلفة، وبمسار دفع مختلف.
- اجعل نسخة واحدة append-only، أو بنمط السحب (pull)، أو غير متصلة بالشبكة، حتى لا يستطيع root مخترق محوها.
- أطلق تنبيهًا عند غياب تشغيل ناجح — فالإخفاقات صامتة، والصمت هو العَرَض.
- استعِد ملفًا اليوم، والجهاز بأكمله مرتين في السنة. احسب الوقت ودوّنه.
هل تكفي لقطات المزوّد وحدها؟
لا، وهذه هي الثغرة الأكثر شيوعًا في إعدادات حريصة في كل شيء آخر. فاللقطة تعيش على المنصة نفسها التي يوجد عليها الحجم الذي تنسخه، لذا فهي لا تنجو من عطل على مستوى المنصة، أو تعليق حساب، أو تعثر في الفوترة — وهي ثلاثة من السيناريوهات التي تحتاجها فيها أكثر ما تحتاج. كما أنها عادةً تحتفظ بتاريخ قصير فقط، فلن تستعيد لك ملفًا حُذف الشهر الماضي أو فسادًا بدأ قبل ستة أسابيع. اللقطات ممتازة كزر تراجع في خمس ثوانٍ قبل تغيير محفوف بالمخاطر: احتفظ بها، واستخدمها يوميًا، واحتفظ بنسخة احتياطية حقيقية في مكان آخر.
restic أم Borg — أيهما يجب أن أستخدم؟
استخدم restic إن كانت الوجهة تخزين كائنات أو مجرد حساب SSH، لأنه لا يحتاج إلى تثبيت أي شيء على الطرف البعيد ويتحدث S3 بشكل أصلي. واستخدم Borg إن كانت الوجهة جهاز لينكس تتحكم فيه وتريد وضع الخادم append-only الخاص به وضغطًا أكثر إحكامًا قليلًا. كلاهما يزيل التكرار، وكلاهما يشفّر ويوثّق من جهة العميل، وكلاهما ناضج ومنتشر على نطاق واسع، وأي منهما خيار يمكن الدفاع عنه. والإجابة الخاطئة هي قضاء شهر كامل في المقارنة بينهما بينما الخادم بلا نسخة احتياطية على الإطلاق — اختر واحدًا بعد ظهر اليوم، وغيّر رأيك لاحقًا إن كان ذلك مهمًا فعلًا.
كم مرة يجب أن أنسخ VPS احتياطيًا؟
الفاصل الزمني هو ببساطة أقصى قدر من العمل تقبل إعادة إنجازه. بالنسبة لموقع ثابت، فإن التكرار الأسبوعي صادق بما يكفي. أما لأي شيء يكتب إليه المستخدمون، فالتكرار الليلي هو الحد الأدنى، والتكرار كل ساعة رخيص بمجرد أن تتولى إزالة التكرار العمل — فالتشغيل الثاني في اليوم عادةً لا يخزّن سوى بضعة ميغابايتات. زِن قيمة بيانات يوم واحد مقابل تكلفة تخزين أربع وعشرين نقطة استعادة بدلًا من نقطة واحدة، والإجابة عادةً واضحة.
هل يجب أن أنسخ القرص بأكمله احتياطيًا أم بياناتي فقط؟
البيانات والإعدادات، في كل حالة تقريبًا. فصورة القرص الكاملة تستعيد الجهاز تمامًا كما كان، بما في ذلك الاختراق الذي تحاول التعافي منه وحالة الحزم التي لم تعد تفهمها، وهي أبطأ في كل من الإنشاء والاستعادة معًا. أما النسخ الاحتياطي على مستوى الملفات لـ/etc، وبيانات تطبيقك، وتفريغات قاعدة بياناتك، مقترنًا بسكربت يعيد بناء نظام التشغيل، فيستعيد بشكل أسرع وأنظف. خذ صورة للقرص حين تحتاج إلى حفظ جنائي مطابق تمامًا (bit-exact)، أو حين يكون الجهاز صندوقًا أسود بناه شخص آخر.
مزوّدي يقول إن الأقراص مشفَّرة — فهل نسختي الاحتياطية مشفَّرة؟
ليس بأي معنى يفيدك. فالتشفير من جهة المزوّد يحمي من إخراج قرص من الرف فعليًا؛ لكن المزوّد يملك المفتاح، لذا تبقى البيانات قابلة للقراءة من قِبل المزوّد ومن قِبل أي جهة تستطيع إجباره. أما التشفير من جهة العميل — عبر restic، أو Borg، أو طبقة crypt في rclone، أو أرشيف مشفَّر — فيعني أن ما يصل إلى الوجهة عديم المعنى دون عبارة مرور لم تغادر جهازك قط. وبالنسبة لمكدّس حسّاس من ناحية الخصوصية، هذا الفارق هو بيت القصيد كله، لأن النسخة الاحتياطية نسخة كاملة من كل ما كان الخادم يحميه.
كيف أمنع برامج الفدية من تشفير نسخي الاحتياطية أيضًا؟
افترض أن أي شيء يستطيع الخادم الوصول إليه، يستطيع مهاجم يملك صلاحيات root تدميره — فبيانات الاعتماد والوجهة والجدول الزمني، كلها موجودة على الجهاز. اكسر ذلك الوصول بإحدى ثلاث طرق: مستودع append-only يقبل الكتابة لكنه يرفض الحذف، أو نموذج سحب يتصل فيه مضيف النسخ الاحتياطي إلى الداخل بينما لا يحمل الخادم أي بيانات اعتماد على الإطلاق، أو تخزين كائنات بقفل تفرضه طبقة التخزين نفسها. ثم أضف مدة احتفاظ طويلة، حتى لا يخرج اختراق بطيء وصامت من النافذة الزمنية ببساطة قبل أن يلاحظه أحد، واحتفظ بنسخة واحدة غير متصلة بالشبكة بحيث لا يستطيع أي هجوم عن بُعد الوصول إليها.
