النسخ خارج الموقع والتعافي

نسخ خارج الموقع تنتظر بعد إعادة البناء

عندما تعيد الخطوة 4 بناء عناصر بلا الإعدادات القديمة، تتوقف نسخ خارج الموقع لتلك النطاقات مؤقتاً حتى يُؤكَّد افتراضي الموضع. راجع الموضع لكل عنصر.

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

النسخ خارج الموقع

احتفظ بالنسخة المحلية السريعة وأضف نسخة متماثلة أو أكثر خارج الموقع. اضبط مستودعاً لكل نطاق في صفحة الإعدادات، خارج الموقع. ينسخ BombVault اللقطات الجديدة هناك بـ restic copy على أساس بذل أفضل جهد، فعثرة خارج الموقع لا تُفشل النسخة المحلية أبداً. في هذا الشكل يبقى المستودع المحلي أساسياً والمستودع خارج الموقع نسخة متماثلة، لكن المستودع الأساسي للنطاق لا يلزم أن يكون محلياً على الإطلاق؛ راجع المستودعات الأساسية البعيدة أدناه للنسخ الاحتياطي مباشرة إلى S3 أو rest-server وغيرهما بدلاً من النسخ المتماثل إليها.

• أهداف متعددة خارج الموقع لكل نطاق. يمكن لكل نطاق (الحاويات، الـ VMs، الفلاش، الإعدادات، مجموعات الملفات ومجموعات بيانات ZFS) النسخ إلى عدة وجهات خارج الموقع في آن واحد، لا وجهة واحدة فقط، فيمكنك مثلاً الاحتفاظ بخادم rest-server على جهاز صديق وحاوية S3 بالتوازي. أضف أهدافاً إضافية في الإعدادات، خارج الموقع، لكلٍّ مستودعه الخاص وفئة تخزين S3 وعلامة append-only واحتفاظ وميزانية نمو. يُنقَل إعداد خارج الموقع واحد موجود دون مساس بوصفه الهدف الأول، ويُنسَخ كل هدف لنطاقٍ ما وفق جدول ذلك النطاق خارج الموقع.
• جدول زمني خارج الموقع لكل نطاق (يُحرَّر إلى جانب كل جدول آخر في الإعدادات، الجداول): اتركه فارغاً للنسخ بعد كل نسخة احتياطية محلية، أو اضبط وتيرة (مثلاً weekly Sun 03:00) للإرسال خارج الموقع أقل مما تنسخ احتياطياً محلياً. يغطي زر نسخ الآن عمليات التشغيل عند الطلب.
• الاحتفاظ خارج الموقع يعيش في الإعدادات، الاحتفاظ حتى تحتفظ بالنسخ خارج الموقع أطول كأرشيف. اترك السياسة كلها صفراً لعدم تقليم اللقطات خارج الموقع تلقائياً أبداً.
• حدود النطاق (الإعدادات، خارج الموقع) تحُدّ معدل رفع/تنزيل restic حتى لا يُشبع النسخ شبكة WAN لديك.
• يُظهر مؤشر النسخ أي نطاق يُنسَخ أثناء تشغيله (في صفحته وفي لوحة التحكم). إنه مؤشر نشاط، لا شريط نسبة مئوية، لأن restic copy لا يكشف تقدماً قابلاً للقراءة آلياً.

الاستعادة من أي مكان

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

الوجهات

تبدأ صفحة الإعدادات، خارج الموقع بـالوجهات: الأماكن التي تذهب إليها النسخ خارج الموقع، وتُعَدّ مرة واحدة لكل النطاقات. بعد ذلك تظهر الوجهة زراً في صف الموضع لكل نطاق وعنصر. وعند تفعيلها لنطاق للمرة الأولى، ينشئ BombVault مستودع ذلك النطاق في مجلد تحتها، مثل rclone:onedrive:BombVault/containers. لا يوجد صف الموضع لـ Flash والنسخ الذاتي ومجموعات بيانات ZFS، لذا يعرض قسم خارج الموقع الخاص بها بدلاً من ذلك إضافة من واسم الوجهة.

إضافة وجهة تفتح معالجاً من خمس خطوات:

1. أين يجب أن تذهب النسخ الاحتياطية؟ تُعرض كل خدمة بشعارها، في أربع مجموعات: خدمات تخزين بحاويات S3 (Backblaze B2 وWasabi وCloudflare R2 وHetzner Object Storage وAmazon S3 وغيرها)، وخادم S3 خاص بك (Garage وSeaweedFS وRustFS وSilo وCeph وJuiceFS وVersity S3 Gateway)، وخادمك الخاص والمشاركات (rest-server وHetzner Storage Box وSFTP وSMB وWebDAV ومسار مركَّب)، والتخزين السحابي (OneDrive وGoogle Drive وDropbox وpCloud وNextcloud وبقية ما يدعمه rclone). وتذكر كل خدمة مدى ملاءمتها للنسخ الاحتياطي: تبطؤ محركات السحابة مع كثرة الطلبات، لذا تستغرق النسخة الأولى والتقليم وقتاً أطول هناك.
2. تسجيل الدخول. تختلف الحقول بحسب الخدمة: مفتاح وصول لـ S3، واسم مستخدم وكلمة مرور لـ WebDAV وSMB، وكلمة مرور تطبيق حيث يمنع تسجيل الدخول بخطوتين كلمة المرور العادية، ومفتاح SSH العام الخاص بـ BombVault لـ SFTP وStorage Box، أو رمز للخدمات التي تسجّل الدخول عبر المتصفح. لهذه الأخيرة يعرض المعالج أمر rclone authorize لتشغيله على جهاز فيه متصفح، ويوضع الرمز الذي يطبعه في الحقل. اختبار الاتصال يتحقق من تسجيل الدخول قبل حفظ أي شيء.
3. اختر مجلداً. يسرد المعالج المجلدات على الوجهة، مع مجلد جديد لإنشاء واحد والمساحة الحرة حيث تُبلغ بها الخدمة. المجلد الفارغ هو الأسلم.
4. الحماية من الحذف. يقول المعالج بوضوح ما تستطيعه الخدمة. يرفض rest-server في وضع append-only الحذف، ويتحقق اختبار العبث من ذلك. يمكن لحاوية S3 الاحتفاظ بالإصدارات القديمة عبر الإصدارات وقفل الكائنات، وهذا ما لا يستطيع BombVault التحقق منه بعد. أما محرك السحابة فلا يستطيع رفض الحذف إطلاقاً: من يدخل إلى الخادم يدخل إلى تلك النسخة أيضاً. فعّل غير قابل للتغيير (append-only) فقط حيث يرفض الطرف البعيد الحذف فعلاً؛ عندئذ لا يقلّم BombVault هناك أبداً.
5. للطوارئ. تسرد حقيبة الاستعادة كل وجهة مع مستودع كل نطاق تحتها. يعود تسجيل الدخول مع نسخة إعدادات BombVault الاحتياطية؛ وعلى تثبيت جديد بدونها، أعِدّ الوجهة من جديد في المكان نفسه.

تعمل خدمات S3 عبر خلفية S3 الخاصة بـ restic، وهذا ما يتيح تطبيق فئة التخزين وقفل الكائنات. وتعمل كل خدمة أخرى عبر rclone الذي يأتي مع BombVault، ويظهر جهازها البعيد عندئذ في إعدادات rclone تحت الإعدادات، الوصول السحابي. يحمل تصدير الإعدادات الوجهات؛ ومع تضمين بيانات الاعتماد يحمل تسجيل الدخول إليها أيضاً.

يظهر خادم الاستقبال الذي تشغّله نسخة أخرى من مجموعتك في المعالج تحت من مجموعتك؛ راجع خادم الاستقبال.

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

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

الموضع لكل عنصر

تحتوي كل بطاقة حاوية أو VM أو مجموعة مجلدات على صف الموضع من أزرار: محلي وزر واحد لكل هدف خارج الموقع في النطاق، ثم الوجهات التي ليس للنطاق هدف تحتها بعد. الأزرار المضاءة تحصل على نسخ العنصر الاحتياطية.

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

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

تحت الصف تقول البطاقة إلى أين يذهب العنصر وما الموجود فعلاً: في كم موقع يُحفظ، ومتى شُوهد كل هدف آخر مرة، وما إذا كانت قاعدة 3-2-1 مستوفاة. الموقع هو الخادم الذي يحمل البيانات الأصلية، وكل هدف خارج الموقع، وكل مستودع مُعلَّم خارج المبنى. يتحقق BombVault من النسخ والمواقع؛ ولا يتحقق من جزء "الوسيطين" في قاعدة 3-2-1.

افتراضيات الموضع

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

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

المستودعات المباشرة

إطفاء محلي لعنصر، بحيث يصبح هدف بلا مستودع مباشر موطنه، يفتح حواراً بموضع مقترَح بجانب الهدف، مثلاً s3:https://s3.eu-central-003.backblazeb2.com/bucket/containers-direct، واختبار اتصال لا ينشئ شيئاً. إنشاء واستخدام ينشئ المستودع ويوجّه العنصر إليه. يأخذ المستودع المباشر مفتاح الهدف وفئة التخزين والحدود وإعداد append-only والاحتفاظ، ويتغير معها؛ تُظهره بطاقة المستودعات للقراءة فقط. حين لا يستطيع مفتاح جديد للهدف فتحه، يحتفظ المستودع المباشر بالمفتاح الذي لديه، ويقول الحفظ ذلك. يُنسخ العنصر الموجود على مستودع مباشر من هناك إلى بقية الأهداف المضاءة، ولا يُنسخ أبداً إلى الهدف الذي يتبع له المستودع. تحمل لقطاته الوسم bv:direct، وكل تمرير احتفاظ آخر يُبقيها، فمستودع مباشر فقد صلته بهدفه لا يشيخ أبداً وفق القواعد المحلية. تُستخدم B2 عبر نقطة نهاية S3 الخاصة بها، بإدخال معرّف المفتاح ومفتاح التطبيق كبيانات اعتماد S3؛ ومفتاح مقتصر على مجلد الهدف نفسه لا يستطيع الوصول إلى المجلد المجاور له، لذا اقصر المفتاح بدلاً من ذلك على المجلد الذي يعلو الهدف.

خارج المبنى

يمكن تعليم مستودع مسمّى بـخارج المبنى على بطاقة المستودعات. تبدأ المستودعات البعيدة معلَّمة؛ أطفئها لخادم rest-server في المبنى نفسه. لا تُحتسب العلامة إلا في المواقع وقاعدة 3-2-1 على البطاقات. لا تغيّر أي نسخة.

بعد إعادة البناء

تعيش خيارات النسخ في إعدادات BombVault الخاصة. بعد إعادة البناء عبر اكتشاف النسخ الاحتياطية دون /config مستعاد، تختفي هذه الخيارات، ونسخ كل شيء سيرسل من جديد إلى B2 العناصر التي كنت قد استبعدتها. لذلك تتوقف نسخ خارج الموقع لكل نطاق أُعيد بناؤه مؤقتاً. يظهر ذلك في لوحة التحكم باللون الكهرماني، وتعرض افتراضيات الموضع تأكيد القيمة الافتراضية بمعاينة لما سينسخه التشغيل التالي وأسماء العناصر في النسخ الاحتياطية التي لا يوجد لها عنصر، يمكنك استبعادها هناك. التأكيد وحده ينهي التوقف؛ استيراد ملف إعدادات يعيد القواعد والافتراضيات لكنه لا ينهي التوقف.

المستودعات الأساسية البعيدة

مسار النسخ لأي نطاق (الإعدادات، التخزين) لا يقتصر على مجلد محلي: وجّهه مباشرة إلى مستودع restic بعيد (s3:...، rest:http://host:8000/repo، sftp:user@host:/repo، rclone:remote:bucket/path) وسينسخ BombVault إليه مباشرة، بلا نسخة محلية منفصلة وبلا خطوة نسخ متماثل. هذا شكل مختلف حقًا عن النسخ خارج الموقع أعلاه: هناك يكون المستودع المحلي هو الأساسي والمستودع خارج الموقع أرشيفًا له بأفضل جهد؛ أما هنا فالمستودع البعيد هو الأساسي، وهو النسخة الوحيدة ما لم تُعدّ لهذا النطاق نسخًا خارج الموقع أيضًا (أو مستودعًا بعيدًا ثانيًا).

كل حقل من حقول المسار الستة (Containers، VMs، Flash، النسخ الذاتي، المجلدات، مجموعات بيانات ZFS) يحمل بجانبه مباشرة مفتاح محلي / بعيد:

• محلي يعرض متصفح المجلدات المعتاد.
• بعيد يستبدله بحقل عنوان بسيط، مع زر يفتح نفس نافذة اختبار الاتصال وبيانات الاعتماد التي تستخدمها الوجهات خارج الموقع، لكن مضبوطة لهذا المستودع الأساسي. ومن هناك تحصل على:
  • اختبار اتصال على المسار الحقيقي، قبل أن تعتمد عليه.
  • حدود لعرض النطاق (رفعًا وتنزيلًا) حتى لا تُشبع نسخة مجدولة إلى مستودع أساسي بعيد وصلتك الواسعة: الخياران نفساهما في restic، --limit-upload و--limit-download، اللذان يستخدمهما النسخ خارج الموقع، مطبَّقين هنا على النسخ ذاته.
  • حماية الإضافة فقط (عدم القابلية للتغيير)، متحققًا منها باختبار العبث النشط نفسه (محاولة DELETE حقيقية على الطرف البعيد) الذي تحصل عليه الوجهات خارج الموقع. وعند تفعيلها يرفض BombVault تقليم المستودع بنفسه: فما دام لا توجد خلفه نسخة محلية منفصلة، يجب ألا تكون بيانات الاعتماد على هذا الجهاز قادرة على حذف النسخة الوحيدة.
  • تنبيه ميزانية النمو، مأخوذًا من الاتجاه نفسه لحجم المستودع الذي تتابعه بطاقة التخزين أصلًا.

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

بيانات اعتماد السحابة وREST مشتركة

يستوثق المستودع الأساسي البعيد ببيانات اعتماد S3/REST نفسها المضبوطة في الإعدادات، الوصول السحابي، بيانات اعتماد السحابة المشتركة. ولا يوجد مخزن منفصل لبيانات اعتماد المستودعات الأساسية.

SMB وWebDAV دون تركيب على المضيف

في الإعدادات، الوصول السحابي، rclone نموذج لمشاركة Windows أو Samba ولخادم WebDAV (Nextcloud أو ownCloud أو SharePoint أو أي خادم آخر). املأ اسماً قصيراً، والمضيف والمشاركة (SMB) أو الرابط ونوع الخادم (WebDAV)، والمستخدم وكلمة المرور، فيكتب BombVault قسم rclone نيابة عنك. يموّه rclone كلمة المرور بنفسه قبل تخزينها؛ وإضافة وجهة باسم موجود مسبقاً تستبدل ذلك القسم بدلاً من إضافة قسم ثانٍ.

يرد النموذج بالموقع الجاهز، مثل rclone:nas:backups. ضعه في مسار نسخ احتياطي أو في وجهة خارج الموقع وأضف مجلداً فرعياً إن أردت (rclone:nas:backups/bombvault). المشاركة هي أول مقطع في المسار، وليست جزءاً من الاسم.

هذا طريق أفضل من تركيب المشاركة على Unraid: ينصح restic بعدم إبقاء مستودع على مشاركة CIFS مركَّبة، وهنا لا يُركَّب شيء. لا يوجد NFS في النموذج لأنه لا restic ولا rclone يملك خلفية NFS؛ أما لـ NFS فركّب التصدير على المضيف ووجّه مسار نسخ احتياطي إليه.

نسخة خارج الموقع غير قابلة للتغيير (append-only)

علّم مستودعاً خارج الموقع بأنه append-only حتى لا تستطيع برامج الفدية، أو مضيف مخترَق، حذف نسخك الاحتياطية أو إعادة كتابتها. يفرض ذلك الطرفُ البعيد (خادم restic/rest-server يعمل في وضع --append-only). ولا يفعل BombVault سوى التحقق منه، ولا يُظهر الأخضر بناءً على مجرد ادعاء إعداد.

يرشدك معالج الإعداد الموجَّه لخارج الموقع من اختيار الخلفية (rest-server / rclone / S3) عبر مقتطف نشر rest-server جاهز للّصق، واختبار اتصال، ومفتاح عدم القابلية للتغيير (الذي يشغّل اختبار العبث فوراً)، واستراتيجية احتفاظ، فيكون خارج الموقع append-only قابلاً للوصول دون تحرير الإعدادات يدوياً.

الحذف الناجح ضمن /locks/ سلوك متوقع

الوضع append-only لا يعني أنه لم يعد بالإمكان حذف أي شيء. يحتاج restic إلى إنشاء أقفاله وتحريرها، لذلك يبقى /locks/ قابلاً للكتابة والحذف عن قصد. اللقطات والبيانات خلفها، أي ما تستهدفه برامج الفدية تحديداً، لا يمكن إزالتها. إذا اختبرت الطرف البعيد بنفسك، فإن عملية حذف تنجح ضمن /locks/ هي السلوك الصحيح وليست ثغرة في الحماية.

المستودعات غير القابلة للتغيير لا تُقلَّم أبداً من هذا الجهاز

نسخة خارج الموقع غير قابلة للتغيير لا تُقلِّم اللقطات القديمة عمداً أبداً. اضبط لها إنذار ميزانية نمو حتى تُنبَّه قبل أن ينفلت حجم المستودع.

اختبار العبث

يثبت BombVault دورياً ضمانة append-only بمحاولة حذف فعلية على المستودع خارج الموقع، موجَّهة إلى كائن غير موجود:

• الرفض يعني محميّاً.
• القبول يعني غير محميّ.
• النتيجة غير الحاسمة (الخادم غير قابل للوصول، خطأ مصادقة) لا تقلب الحكم المخزَّن أبداً.

انقلاب حقيقي من محميّ إلى غير محميّ يُطلق تنبيهاً واحداً.

تمارين التعافي من الكوارث

يقدّم BombVault مستويين من إثبات أن نسخك الاحتياطية قابلة للاستعادة فعلاً، لا مجرد موجودة.

• تمارين التحقق من الاستعادة (محلي). يشغّل BombVault دورياً restic check --read-data-subset (محدودة، وليست استعادة كاملة تملأ القرص أبداً) ويُظهر شارة تم التحقق من قابلية الاستعادة لكل نطاق. تعيش الوتيرة في الإعدادات، الجداول؛ والشارة في الإعدادات، السلامة.
• تمارين التعافي من الكوارث (خارج الموقع). يستعيد BombVault هدفاً حقيقياً من المستودع خارج الموقع إلى بيئة اختبار قابلة للتخلص، ويتحقق منه ملفاً بملف وبايتاً ببايت، ثم ينظّف. يثبت هذا قدرتك على التعافي من خارج الموقع، لا مجرد أن المستودع يستجيب.

تجمع بطاقة تقييم الحماية من برامج الفدية في لوحة التحكم هذا في وضعية خضراء / كهرمانية / حمراء لكل نطاق، مع قائمة تحقق مؤرَّخة العمر (خارج الموقع مُعَدّ، append-only مُتحقَّق منه، النسخ حديث، تمرين الاستعادة نجح، التشفير مفعَّل، استراتيجية التقليم مضبوطة). يرتبط كل صف أحمر مباشرة بالإصلاح، ولا تتحول البطاقة إلى الأخضر إلا على حقائق مُتحقَّق منها.

إقران نُسخ BombVault

يتحدث كل من المُستقبِل، ومصدر السحب، وصفحة المثيلات، وMesh خارج الموقع إلى نسخة BombVault أخرى. تفعل ذلك بوصفها أعضاء في مجموعة إقران واحدة، وتنضم النسخة إلى المجموعة باثنتي عشرة كلمة.

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

من يعرف الكلمات يستطيع الانضمام إلى المجموعة، فعاملها كما تعامل كلمة مرور.

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

• مُرحِّل المشروع (الافتراضي): parleyport.halleluja.design، المُرحِّل نفسه الذي يستخدمه KnightLoader أيضاً. لا شيء لإعداده.
• مُرحِّل خاص: حاوية ParleyPort من Unraid Community Apps، أو إحدى نسخك التي تكون بالفعل قابلة للوصول من الخارج ومفتاح العمل كمُرحِّل فيها مُشغَّل. تجيب تلك النسخة عندئذ على /relay/connect على عنوانها الخاص، خلف الوكيل العكسي والشهادة اللذين تملكهما بالفعل، ولا تدخل سوى مجموعتك. أدخل عنوان المُرحِّل على كل نسخة يجب أن تستخدمه.
• بلا مُرحِّل: يجد الأعضاء بعضهم بعضاً تلقائياً على الشبكة نفسها فقط، وليس في أي مكان آخر.

ما يراه المُرحِّل. كل مكالمة بين الأعضاء مختومة بـ AES-256-GCM بمفتاح مُشتق من الكلمات الاثنتي عشرة، ولا يغادر ذلك المفتاح نسخك أبداً. يعرف المُرحِّل بصمة تُجمِّع الاتصالات، ولأي نسخة رسالة ما، وحجمها، ووقت مرورها. المكالمة المباشرة على الشبكة المحلية مختومة بالطريقة نفسها وموقَّعة أيضاً، فلا يعتمد شيء على الشهادة ذاتية التوقيع التي تقدمها نسخة.

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

إدخالات من قبل الإقران. النسخ المُضافة برمز fleet، والمُستقبِلون ومصادر السحب المُعدَّة بـ APP_KEY الخاص بالنسخة الأخرى، تبقى بعد التحديث وتُعلَّم بـ إعادة الاقتران. يستمر المُستقبِلون ومصادر السحب في العمل: عند أول تشغيل يستبدل BombVault كل APP_KEY مخزَّن بكلمة مرور restic المُشتقة منه. اقرن النسختين، ثم عدِّل الإدخال واختر نسخته. تستعيد نسخة كهذه بطاقتها القديمة بمجرد ظهور نسخة بالاسم نفسه في المجموعة.

المكان الوحيد الذي ما زال يأخذ APP_KEY يدوياً هو الاستعادة من مستودع BombVault آخر، لحالة اختفاء النسخة الأخرى وعجزها عن الرد ضمن مجموعة.

لوحة تحكم المُستقبِل (الجانب المُستقبِل)

الجانب المستقبِل، مراقَب للقراءة فقط، مع فحص سلامة يُنفَّذ على هذا الجهاز.

كل ما سبق هو الجانب المُرسِل. على الجهاز الذي يستقبل نسخاً غير قابلة للتغيير خارج الموقع من BombVault آخر، تمنحك لوحة تحكم المُستقبِل مراقبة مستقلة للقراءة فقط لتلك المستودعات على الجهاز المُستقبِل، فلا يمر فشل صامت في الطرف البعيد دون ملاحظة.

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

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

المُستقبِل للقراءة فقط بصرامة. لا يكتب أبداً إلى المستودع المستقبَل، فلا يمكنه أبداً كسر ضمانة append-only التي يعتمد عليها المُرسِل.

خادم الاستقبال

يستطيع جهاز الاستقبال أيضًا أن يشغّل rest-server الذي ينسخ إليه الآخرون. يطلب إعداد خادم الاستقبال في أعلى تبويب المستقبِل مجلدًا على مشاركة، مع مجلد جديد لإنشاء واحد، ومنفذًا (8000 ما لم تستخدمه حاوية أخرى). ثم يقوم BombVault بما يلي:

1. يرفض المتابعة إذا كانت هناك حاوية باسم rest-server أو إذا كانت حاوية أخرى تحجز المنفذ؛
2. يسحب restic/rest-server ويشغّله عبر مقبس Docker في وضع append-only مع مستودعات خاصة وملف تسجيل دخول في المجلد؛
3. يكتب قالب Unraid الخاص به على قرص الفلاش، فتبقى الحاوية قابلة للتعديل في تبويب Docker، أو يعرض القالب للتنزيل عندما يتعذر الوصول إلى قرص الفلاش؛
4. يشغّل اختبار العبث عليه ويُظهر هل يرفض الحذف.

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

لا تستطيع نسخة تصل إلى جهاز الاستقبال عبر المُرحِّل فقط أن تستخدم الخادم، لأن المُرحِّل لا ينقل نسخًا احتياطية. أضف عنوان جهاز الاستقبال تحت الإعدادات ← الاقتران أولًا. وعندما يعمل BombVault على عنوان IP خاص به (على br0 مثلًا)، املأ العنوان للشركاء، لأن الخادم يستمع على عنوان المضيف.

مثال كامل: جهازا Unraid من البداية إلى النهاية

ما سبق يشرح القطع. هنا إعداد كامل واحد بقيم حقيقية، لأن تركيب القطع يصبح أسهل بكثير بعد رؤيتها مركّبة مرة واحدة.

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

1. على VAULT، جهّز خادم الإضافة-فقط. في BombVault على TOWER انتقل إلى الإعدادات ← خارج الموقع ← إعداد، اختر rest-server وولّد الوصفة. انسخ تبويب قالب Unraid (XML)، واحفظه على VAULT باسم /boot/config/plugins/dockerMan/templates-user/my-rest-server.xml، ثم Docker ← Add Container واختر rest-server من قائمة القوالب. قبل تشغيله، اكتب سطر htpasswd المعروض في /mnt/user/appdata/rest-server/.htpasswd على VAULT. كلمة المرور لمرة واحدة تُعرض مرة واحدة ولا تُحفظ أبدًا، فانسخها الآن. يحمل ذلك السطر كلمة المرور نفسها، مُجزّأة بـ bcrypt نيابةً عنك: النص الظاهر يوضع في بيانات اعتماد REST على TOWER، والسطر المُجزّأ في .htpasswd على VAULT. لا حاجة لأن تُجزّئ شيئًا بنفسك.

اترك `--append-only` في حقل OPTIONS. هذا هو جوهر الأمر كله: بدونه يعود VAULT مجرد مشاركة عادية.

2. على TOWER، وجّه المستودع الخارجي إليه. عنوان المستودع يتبع النمط الذي تطبعه الوصفة:

rest:http://VAULT:8000/bombvault-containers/containers

الجزء الأول من المسار هو مستخدم htpasswd، والثاني هو المستودع. أدخل المستخدم وكلمة المرور المولَّدين كبيانات اعتماد REST للوجهة، ثم شغّل اختبار الاتصال.

3. على TOWER فعّل «غير قابل للتغيير». يعمل اختبار العبث فورًا ويجب أن يقول محمي. معنى النتائج:

النتيجة	ما الذي حدث
محمي	رفض VAULT الحذف. هذه هي الحالة الناجحة الوحيدة.
غير محمي	قبل VAULT عملية حذف. --append-only مفقود أو أُزيل.
غير حاسم	لا هذا ولا ذاك. غالبًا لأن العنوان ليس العنوان الذي يستخدمه restic نفسه، أو أن بيانات الاعتماد تغيّرت. لا يُسجَّل شيء ولا يُطلق أي تنبيه.

4. على VAULT، راقب ما يصل. اقرن الجهازين (إقران نُسخ BombVault)، فعّل الإعدادات ← عام ← المستقبِل، افتح تبويب المستقبِل وسجّل المستودع للقراءة فقط مع TOWER بوصفه النسخة المُرسِلة.

الموقع مسار داخل الحاوية، ويُكتب نسبةً إلى نقطة ضم المضيف

أدخل user/appdata/rest-server/bombvault-containers/containers، وليس /mnt/user/appdata/…. يعمل BombVault داخل حاوية يكون فيها /mnt الخاص بالمضيف مضمومًا في مكان آخر؛ فالمسار المطلق للمضيف غير موجود هناك. إن لصقت واحدًا فسيخبرك BombVault الآن بالمسار النسبي الذي ينبغي استخدامه.

يحصل VAULT على كلمة مرور restic الخاصة بـ TOWER عبر المجموعة عند الحفظ؛ لا أحد يكتب مفتاحاً.

5. اجعلها متبادلة إن أردت. كرّر الخطوات الخمس نفسها في الاتجاه المعاكس: خادم rest-server على TOWER يستقبل نسخة VAULT. عندئذ يفرض كل جهاز عدم القابلية للتغيير على الآخر، ولا يستطيع أي منهما حذف نسخ الآخر.

التعافي الموجَّه

يرشد تبويب الاستعادة مخصَّص تثبيتاً جديداً أو مُعاد بناؤه عبر حالة الكارثة، في مكان واحد:

1. يستعيد إعدادات BombVault الخاصة أولاً، فتأتي مسارات النسخ الاحتياطي والأهداف خارج الموقع وبيانات الاعتماد التي تحتاجها بقية السير معبّأة مسبقاً (تُطبَّق عبر إعادة تشغيل ذاتية على مقبس Docker، فلا تُكتَب البيانات فوق قاعدة بيانات الإعدادات الحية تحت مقبض مفتوح).
2. يتحقق من أن BombVault يستطيع قراءة نسخك الاحتياطية (فخّ مفتاح التشفير مقدَّماً).
3. يتيح لك التوجيه إلى مستودعك الموجود (محلي أو خارج الموقع).
4. يكتشف الحاويات والـ VMs ومجموعات الملفات ومجموعات بيانات ZFS المخزَّنة فيه.
5. يستعيد الحاويات والـ VMs دفعة واحدة (متوقفة، فتشغّلها عمداً)، ويعرض مجموعات الملفات وعناصر ZFS لتستعيدها واحداً تلو الآخر؛ تعود عناصر ZFS مُطفأة. حقيبة الاستعادة الخاصة بك على بُعد نقرة.

هجرة مخطَّطة مقابل كارثة

يستعيد التعافي الموجَّه إعدادات BombVault الخاصة من نسخة احتياطية. لانتقال مخطَّط إلى جهاز جديد، يمكنك بدلاً من ذلك نقل إعداداتك مباشرة ببطاقة تصدير / استيراد الإعدادات (ملف JSON محمول). راجع الإعدادات.

الاستعادة من مستودع BombVault آخر

تفتح بطاقة منفصلة في تبويب الاستعادة مستودعَ نسخة BombVault مختلفة (مشاركة مركَّبة ضمن /mnt، أو رابط بعيد) باستخدام APP_KEY الخاص بتلك النسخة، في جلسة لمرة واحدة للقراءة فقط. تصفّح الحاويات والـ VMs ومجموعات الملفات المخزَّنة هناك، اختر لقطة واستعِدها، فيصبح الكائن المُستعاد حاوية أو VM أو مجموعة ملفات محلية عادية. لا يُكتَب شيء أبداً إلى المستودع الآخر، وتبقى إعدادات نسخك الاحتياطية دون مساس (تعيش الجلسة في الذاكرة وتنتهي صلاحيتها بنفسها). نقل حاوية من الخادم A إلى الخادم B لا يعني إعادة توجيه إعدادات مستودعك وعكسها بعد ذلك. هذه البطاقة لمرة واحدة: تفتح جلسة، وتستعيد ما تختاره، ثم تنسى النسخة الأخرى. وإذا أردت بدلاً من ذلك ترتيباً دائماً يجلب فيه هذا الجهاز لقطات نسخة أخرى إلى مستودعه الخاص وفق جدول زمني، فهذا هو تبويب سحب في صفحة المثيلات.

الحاوية التي لا توجد شبكتها على هذا الخادم، مثل شبكة br0 من Unraid على مضيف Docker عادي، يظهر تحت صفّها منتقٍ للشبكة. ينشئها BombVault على الشبكة التي تختارها، مع شبكاتها الأخرى. عنوان IP الثابت وعنوان MAC كانا تابعين للشبكة القديمة فيُحذفان، وتمنحهما الشبكة الجديدة.

حقيبة استعادة مفتاح التشفير

هذا هو الجزء الذي يجعل التعافي من الكوارث ممكناً حتى عندما لا يوجد BombVault يعمل.

تنزّل نقرة واحدة المفتاح الرئيسي، وكلمة مرور restic المشتقة، ومواقع المستودعات وأوامرها بالضبط، فيمكنك الاستعادة مباشرة بأداة restic على سطر الأوامر على أي جهاز. يظل تذكير في لوحة التحكم يلحّ حتى تخزّنها.

خزّن حقيبة الاستعادة خارج الخادم

تحتوي الحقيبة على السر الذي يفك تشفير نسخك الاحتياطية. احفظها في مكان آمن ومنفصل عن الخادم (مدير كلمات مرور، نسخة مطبوعة في خزنة). إذا فقدت كلاً من BombVault وAPP_KEY دون حقيبة استعادة، فلا يمكن استرداد نسخك الاحتياطية المشفّرة.

أحدث لقطة ليست دائمًا التي يجب استعادتها

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

ختم الحقيبة

إذا فعّلت تشفير age لعمليات التصدير النصية (الإعدادات)، فإن الحقيبة تُختَم به أيضاً وتُنزَّل باسم bombvault-recovery-kit.md.age. وهي بصيغة ASCII-armored لا ثنائية، فتبقى نصاً عادياً: لصقها في مدير كلمات مرور أو طباعتها يعمل تماماً كما من قبل، غير أن محتواها لا يُقرأ دون مفتاحك.

لا تحفظ مفتاح age داخل الحقيبة

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

مع تفعيل التشفير وعدم ضبط مستلم صالح للاستخدام، يُرفَض التنزيل مباشرة. لا يرجع BombVault أبداً إلى تسليم المفتاح الرئيسي نصاً واضحاً.

إذا لم تكن حقيبة الاسترداد في متناولك

كلمة المرور ليست مخزَّنة في أي مكان، بل تُحسب من APP_KEY. وبوجود المفتاح وصدفة أوامر يمكنك إعادة إنتاجها بنفسك:

printf 'bombvault:restic-repo' \
  | openssl dgst -sha256 -mac HMAC -macopt hexkey:$APP_KEY -r \
  | cut -d' ' -f1

إنها HMAC-SHA256 على السلسلة الثابتة bombvault:restic-repo، والمفتاح هو البايتات الخام لقيمة APP_KEY الست عشرية، والناتج 64 حرفًا ست عشريًا صغيرًا. القيمة نفسها موجودة في الحقيبة باسم كلمة مرور restic المشتقة؛ وهذا القسم لليوم الذي تكون فيه الحقيبة في مكان غير مكانك.

في المستودع المستلَم استخدم مفتاح النسخة المُرسِلة

المستودع الذي وصل إلى هنا عبر النسخ خارج الموقع أنشأته الآلة التي أرسلته، بـAPP_KEY الخاص بها. والاشتقاق من مفتاح الآلة المستقبِلة يعطي كلمة مرور يرفضها restic، وهو ما يبدو تمامًا كمستودع تالف دون أن يكون كذلك. هذا هو السبب المعتاد لأن يظل restic check على مستودع مستلَم يسأل عن كلمة المرور مرارًا.

لأن تعريفات الاستعادة تعيش داخل كل مستودع (<repo>/def، <repo>/vm-def)، يكون مجلد مستودع منسوخ مكتفياً ذاتياً بالكامل، فالحقيبة مع المستودع هما كل ما تحتاجه استعادة من الصفر.

استرجاع تفريغ قاعدة بيانات

تفريغ قاعدة البيانات نقطة استعادة قائمة بذاتها في مستودع الحاويات، يحمل الوسم dbdump:<container> ويضم ملفاً واحداً هو /dbdump/<container>.sql. يعرض BombVault هذه التفريغات وينزّلها ويستوردها ضمن النسخ الاحتياطية؛ وفي ما يلي الخطوات نفسها بـ restic وحده، ليوم لا يكون فيه BombVault حاضراً.

restic -r <repo> snapshots --tag dbdump:<container>
restic -r <repo> dump --tag dbdump:<container> latest /dbdump/<container>.sql > <container>.sql

يقول الوسمان dbversion: وdbname: على كل تفريغ من أي إصدار خادم جاء وأي قواعد بيانات يحتوي. وينتهي الملف الكامل بـ -- PostgreSQL database cluster dump complete أو -- Dump completed.

استورده إلى حاوية بالإصدار نفسه أو أحدث (PostgreSQL)، أو بالإصدار الرئيسي نفسه (MySQL وMariaDB)، بعد تشغيلها مرة واحدة بمجلد بيانات فارغ حتى تهيّئ نفسها. لا يحتاج المضيف إلى عميل قاعدة بيانات، فالحاوية تملك واحداً:

docker exec -i <container> sh -c 'exec psql -X -U "${POSTGRES_USER:-postgres}" -d postgres' < <container>.sql
docker exec -i <container> sh -c 'exec mariadb -uroot -p"$MARIADB_ROOT_PASSWORD"' < <container>.sql
docker exec -i <container> sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD"' < <container>.sql

ولاستخراج قاعدة بيانات واحدة من تفريغ كامل، يقبل MySQL وMariaDB الخيار --one-database <name> في أمر العميل. أما تفريغ PostgreSQL فله قسم لكل قاعدة بيانات، يبدأ كل قسم بسطر \connect <name>: انسخ القسم إلى ملف خاص به واستورده بـ -d <name> بعد إنشاء قاعدة البيانات.

التفريغ المأخوذ بحساب root يحمل معه مستخدمي الخادم

التفريغ الكامل لـ MySQL أو MariaDB المأخوذ بحساب root يحتوي قاعدة النظام mysql، فاستيراده يستبدل حسابات الخادم الجديد، وكلمة مرور root بينها، بحسابات التفريغ. وفي PostgreSQL، رسالة role ... already exists عن المستخدم الذي أنشأته الحاوية نفسها متوقعة وغير ضارة.