نسخ احتياطية مشفّرة خارج الموقع: قاعدة 3-2-1 على VPS خارجي خاص بك

اللقطة ليست نسخة احتياطية

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

الأمر نفسه ينطبق على الشيئين اللذين يخلط الناس بينهما وبين النسخ الاحتياطية أكثر من غيرهما. RAID ليس نسخة احتياطية: فهو يحمي من تعطّل قرص، وينسخ أمر rm -rf إلى المرآة (mirror) بالسرعة القصوى. والتكرار (replication) ليس نسخة احتياطية للسبب نفسه — فهو مصمَّم لجعل النسخة الثانية مطابقة للأولى بأسرع ما يمكن، حتى عندما تكون النسخة الأولى قد دُمّرت لتوّها. على مضيف بلا KYC، يكون فرع الحساب من هذه القائمة أكثر حدّة منه في أي مكان آخر: فالتسجيل ليس أكثر من اسم مستخدم وكلمة مرور وثمانية رموز استرداد، دون بريد إلكتروني أو مستند في أي مكان من الحلقة، فلا يوجد سلّم دعم فني تتسلّقه إن فقدتها. هذا هو المنتج يعمل كما صُمم. وهذا يعني أيضًا أن النسخة التي تهمّ فعليًا هي تلك غير القابلة للوصول إليها من بيانات الاعتماد التي قد تفقدها.

قاعدة 3-2-1، مُعاد صياغتها لخادم لا يستطيع أحد التعرّف على صاحبه

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

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

شفّر البيانات قبل أن تغادر الجهاز

ينبغي أن تكون الوجهة مكانًا يخزّن بايتات لا يستطيع قراءتها. وهذه ليست سياسة تقبلها من مزوّد، بل خاصية تبنيها أنت بنفسك: تُقسَّم البيانات إلى أجزاء وتُضغَط وتُشفَّر وتُوثَّق على المصدر، وما يعبر السلك يكون معتمًا أصلاً. يشفّر وضعا repokey وkeyfile في Borg كل جزء بخوارزمية AES-256 في نمط العدّاد (counter mode) ويوثّقانه، وتستبدل النسخ ذات اللاحقة -blake2 خوارزمية HMAC-SHA256 بخوارزمية BLAKE2b، الأسرع بشكل ملحوظ على معالجات 64-بت الحديثة. محتويات الملفات وأسماؤها وبيان الأرشيف الذي يسردها، كلها مشفّرة؛ وتحتفظ الوجهة بملفات أجزاء مرقّمة وفهرس لا تستطيع تفسيره. يمنحك restic البنية نفسها بآلية داخلية مختلفة. في الحالتين، النموذج الذهني الصحيح هو أنك تستأجر مساحة قرص، لا ثقة.

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

Borg وrestic وrclone: اختر واحدة واعرف السبب

هناك أداتان تُعدّان إجابتين صحيحتين هنا، والاختيار بينهما يتعلق فعليًا بالوجهة. تقوم Borg بإزالة التكرار على مستوى الأجزاء، والضغط، والتشفير الموثَّق — وهذا هو السبب في أنها المثال العملي أدناه — فهي تأتي بوضع إلحاق فقط حقيقي من جهة الخادم تحصل عليه مجانًا عبر SSH العادي، دون خدمة لتشغيلها ودون منفذ إضافي لفتحه. تحتاج إلى تثبيت borg على الطرفين وتتحدث بروتوكولها الخاص. أما restic فتقدّم الضمانات نفسها مع عدم تقيّدها بخلفية تخزين بعينها: SFTP، أو تخزين كائنات متوافق مع S3، أو Backblaze B2، أو خادمها الخاص rest-server. لا حاجة لتثبيت أي شيء على وجهة SFTP عادية، وهذا مريح، لكن وضع الإلحاق فقط يعتمد عندئذٍ على rest-server --append-only أو على سياسة bucket بدلاً من قيد على SSH. قاعدة عامة: اختر Borg عندما تكون الوجهة خادمًا تتحكم فيه، واختر restic عندما تكون تخزين كائنات أو عندما تريد أداة واحدة تعمل عبر خلفيات متعددة مختلفة تمامًا.

وما لا ينبغي استخدامه، لأنه الطريقة الأكثر شيوعًا التي يفشل بها هذا الأمر. rclone أداة مزامنة. صحيح أن وجهتها البعيدة من نوع crypt تمنحك تشفيرًا من جهة العميل، لكن المزامنة تنقل عمليات الحذف أيضًا — فالملف الذي فقدته في الساعة 03:00 يُزال بأمانة من الوجهة في الساعة 03:15، وهذا بالضبط هو الفشل الذي كنت تحاول النجاة منه. إنها ممتازة لدفع مستودع Borg أو restic جاهز إلى موقع ثالث؛ لكنها ليست نسخة احتياطية. ينطبق الاعتراض نفسه على أمر rsync --delete مجرّد داخل cron، وهو مرآة ترتدي ثوب نسخة احتياطية. أما tar | gpg إلى مسار بعيد فهي نسخة احتياطية حقيقية، لكن دون إزالة تكرار، ودون منطق احتفاظ، واستعادتها تعني اجتياز سلسلة كاملة من الزيادات لاستعادة ملف واحد فقط. استخدم الأدوات المصمَّمة لهذا الغرض؛ فهي مُحزَّمة في كل توزيعة مذكورة في هذا الدليل.

الإلحاق فقط، وإلا حذف الدخيل نسخك الاحتياطية أيضًا

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

الحل صغير وهو أهم سطر في هذا الدليل بأكمله. على الوجهة، ثبّت المفتاح الآلي على أمر واحد فقط في authorized_keys: command="borg serve --append-only --restrict-to-path /srv/borg",restrict. يستطيع ذلك المفتاح الآن أن يفعل شيئًا واحدًا بالضبط — إضافة بيانات إلى مستودع تحت مسار واحد. لا يستطيع الحصول على shell، ولا توجيه منفذ، ولا سرد نظام ملفاتك، ولا إزالة أرشيف واحد. تُلغي الكلمة المفتاحية restrict (في OpenSSH 7.2 وما بعده) تخصيص pty وكل أنواع التوجيه بكلمة واحدة، فلا يتآكل القيد كلما أُضيفت خيارات جديدة. والآن التحفّظ الصادق الذي تتجاهله معظم الشروحات: بينما وضع الإلحاق فقط سارٍ، يبدو أن borg prune وborg compact ينجحان ولا يُحرّران في الواقع أي مساحة — فعملية الحذف تُسجَّل في معاملة يتراجع عنها جلسة الإلحاق فقط التالية. لذا يحتاج الاحتفاظ إلى مفتاح ثانٍ غير مقيَّد تستخدمه يدويًا من حاسوبك المحمول ولا تخزّنه أبدًا على المصدر. مفتاحان، مهمّتان: المفتاح الليلي لا يستطيع سوى الكتابة؛ ومفتاح الصيانة يستطيع الحذف ويعيش في مكان لا يستطيع الجهاز المخترَق الوصول إليه. احتفظ بذلك المفتاح في متناول يدك لغرض آخر أيضًا — فمهمّة تُقتَل في منتصف تنفيذها تترك قفلاً عالقًا، وأمر borg break-lock عملية كتابة.

أين ينبغي أن تعيش النسخة الثانية

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

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

النسخة الاحتياطية التي لم تستعدها إشاعة

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

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

ما تكلفته، وموقعه ضمن المنظومة

لا مجال للمقارنة اقتصاديًا. VPS ثانٍ ابتداءً من $8.00/شهريًا، يُموَّل من الرصيد المسبق الدفع نفسه بشحنات ابتداءً من $30.00، ويعمل خلال نحو 15 min، مقابل تكلفة فقدان كل ما هو موجود على الجهاز الأول. شغّله جنبًا إلى جنب مع النسخ الاحتياطية من جهة المزوّد لا بدلاً منها: تتكفّل إضافة النسخ الاحتياطية المشفّرة اليومية بحالة حذف المجلد الخطأ دون أي عمل منك ودون تفكير في الساعة الثالثة فجرًا، بينما ما بنيته هنا هو النسخة التي تبقى ملكك عندما يكون الشيء الذي زال هو الحساب أو المنطقة أو المزوّد نفسه. إنهما يغطيان فشلين مختلفين ولا يُغني أحدهما عن الآخر، وهذا بالضبط سبب العدّ إلى ثلاثة.

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

خطوة بخطوة

1. 01

   انشر وجهة النسخ الاحتياطي ولا تمنحها أي عمل آخر

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

   ssh root@198.51.100.7
   apt update && apt full-upgrade -y
   hostnamectl set-hostname vault-01
   apt install -y borgbackup ufw unattended-upgrades
   ufw default deny incoming && ufw default allow outgoing
   ufw limit 22/tcp && ufw enable

2. 02

   أنشئ حساب borg مقيَّدًا بمفتاحين

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

   # on the source
   ssh-keygen -t ed25519 -N "" -f /root/.ssh/borg_job -C "job@edge-01"
   # on your laptop
   ssh-keygen -t ed25519 -f ~/.ssh/borg_maint -C "maint@laptop"
   
   # on the target
   adduser --disabled-password --gecos "" borg
   install -d -m 700 -o borg -g borg /home/borg/.ssh /srv/borg
   cat > /home/borg/.ssh/authorized_keys <<'EOF'
   command="borg serve --append-only --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...job@edge-01
   command="borg serve --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...maint@laptop
   EOF
   chown borg:borg /home/borg/.ssh/authorized_keys
   chmod 600 /home/borg/.ssh/authorized_keys

3. 03

   هيّئ المستودع، ثم أخرج المفتاح من كلا الجهازين

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

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   borg init --encryption=repokey-blake2
   
   borg key export :: /tmp/edge-01.borgkey
   borg key export --paper :: /tmp/edge-01.paper
   # move both off this machine, then shred the copies
   shred -u /tmp/edge-01.borgkey /tmp/edge-01.paper

4. 04

   جمّد حالة التطبيق قبل أن تقرأ القرص

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

   install -d -m 700 /var/backups/dumps
   mariadb-dump --single-transaction --quick --all-databases \
     > /var/backups/dumps/mariadb.sql
   # PostgreSQL:
   # sudo -u postgres pg_dumpall > /var/backups/dumps/pg.sql
   chmod 600 /var/backups/dumps/*.sql

5. 05

   اكتب مهمّة النسخ الاحتياطي وضعها على مؤقّت

   أبقِ السكربت مملاً ودعه يفشل بصخب. تأتي عبارة المرور من ملف بصلاحية 600 عبر BORG_PASSCOMMAND، فلا تظهر أبدًا في قائمة العمليات. سمِّ الأرشيفات باسم المضيف وطابع زمني بصيغة ISO حتى تُرتَّب. لاحظ ما ليس موجودًا في هذا السكربت: لا prune، ولا delete — فمفتاح المهمّة لا يستطيع تنفيذهما أصلاً. يلحق المؤقّت ذو Persistent=true بما فاته بعد إعادة التشغيل، ويمنع تأخير عشوائي كل أجهزتك من الرفع في الثانية نفسها.

   cat > /usr/local/sbin/borg-backup.sh <<'EOF'
   #!/bin/bash
   set -euo pipefail
   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i /root/.ssh/borg_job -o BatchMode=yes'
   export BORG_PASSCOMMAND='cat /root/.config/borg/passphrase'
   borg create --stats --compression zstd,6 --one-file-system \
     --exclude-caches --exclude '/var/cache/*' \
     --exclude '/var/lib/mysql' --exclude '/home/*/.cache' \
     ::'{hostname}-{now:%Y-%m-%dT%H:%M}' \
     /etc /root /home /srv /var/www /var/backups/dumps
   EOF
   chmod 700 /usr/local/sbin/borg-backup.sh
   
   cat > /etc/systemd/system/borg-backup.service <<'EOF'
   [Unit]
   Description=Off-site Borg backup
   [Service]
   Type=oneshot
   Nice=10
   IOSchedulingClass=idle
   ExecStart=/usr/local/sbin/borg-backup.sh
   EOF
   
   cat > /etc/systemd/system/borg-backup.timer <<'EOF'
   [Unit]
   Description=Nightly off-site Borg backup
   [Timer]
   OnCalendar=*-*-* 03:17:00
   RandomizedDelaySec=900
   Persistent=true
   [Install]
   WantedBy=timers.target
   EOF
   systemctl daemon-reload
   systemctl enable --now borg-backup.timer

6. 06

   قلِّم بمفتاح الصيانة، وادمج على الهدف

   لا يمكن تشغيل الاحتفاظ من المصدر، لأن مفتاح المصدر إلحاق فقط وستتراجع عمليات حذفه بصمت. شغّله بدلاً من ذلك من حاسوبك المحمول، بأي وتيرة تناسبك — شهريًا كافٍ تمامًا. يقرر prune أي الأرشيفات يُبقيها؛ أما compact فهو ما يستعيد مساحة القرص فعليًا. نفّذ --dry-run أولاً واقرأ القائمة قبل أن تسمح له بحذف أي شيء.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   
   borg prune --dry-run --list \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg prune --list --stats \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg compact --progress

7. 07

   نفّذ تمرين الاستعادة، ثم دوِّن دليل التشغيل

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

   borg list ::
   mkdir -p /var/tmp/drill && cd /var/tmp/drill
   borg extract --list ::edge-01-2026-08-31T03:17 etc/nginx
   diff -r etc/nginx /etc/nginx && echo 'restore OK'
   
   # on the target, no key needed:
   borg check --repository-only /srv/borg/edge-01
   find /srv/borg/edge-01/data -type f -mmin -1500 | head -1   # empty = stale