كيفية إعداد الإرسال والاستقبال في Btrfs لإجراء نسخ احتياطية تزايدية خارج الموقع

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

على ZimaOS، أكّد أولًا أن كلًّا من المصدر والوجهة خارج الموقع هما فعلًا نظاما ملفات Btrfs، وأن الوصول عبر SSH متاح. يسرد دليل تنسيقات الأقراص في ZimaSpace دعم القراءة والكتابة لـ BTRFS حاليًا، ويوضح دليل SSH في ZimaOS كيفية تفعيل الوصول إلى الطرفية من وضع المطوّر.

افهم سلسلة النسخ الاحتياطي قبل البدء

إن Btrfs send/receive هو نسخ متماثل لوحدات التخزين الفرعية، وليس أمرًا عامًا لنسخ المجلدات. يجب أن يكون المصدر وحدة تخزين فرعية في Btrfs، وكل لقطة مستخدمة بواسطة btrfs send يجب أن تكون للقراءة فقط. ولا يُعدّ التحميل للقراءة فقط بديلًا عن لقطة وحدة تخزين فرعية للقراءة فقط.

يصف توثيق btrfs send الرسمي وضعين. يرسل الإرسال الكامل اللقطة بأكملها. ويستخدم الإرسال التزايدي -p أو -c مع لقطات متاحة بالحالة نفسها على كلٍّ من المُرسِل والمستقبِل.

بالنسبة إلى سلسلة بسيطة خارج الموقع، استخدم أصلًا واحدًا صريحًا مع -p:

snapshot-A  --full send-->  off-site snapshot-A
snapshot-B  --send -p A-->  off-site snapshot-B
snapshot-C  --send -p B-->  off-site snapshot-C

لا تحذف الأصل الحالي أو تعدّله حتى يكتمل النقل التزايدي التالي ويتم التحقّق منه.

تحقّق من أن المصدر وحدة تخزين فرعية في Btrfs

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

findmnt -no FSTYPE --target /mnt/pool/data
sudo btrfs subvolume show /mnt/pool/data
sudo btrfs version

ينبغي أن يعرض الأمر الأول btrfs. يجب أن يحدّد الثاني بنجاح /mnt/pool/data كوحدة تخزين فرعية. إذا كان مجرد مجلد عادي، فتوقّف هنا: btrfs send لا يمكنه إرسال مجلد عشوائي.

أجرِ فحص نظام الملفات نفسه على النظام خارج الموقع لموقع الاستلام. btrfs receive يجب إنشاء وحدة التخزين الفرعية المنسوخة على نظام ملفات Btrfs.

إعداد SSH قبل بث بيانات النسخ الاحتياطي

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

ssh backup@backup.example.net

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

أنشئ دليل الوجهة أثناء جلسة إدارية تفاعلية:

ssh -t backup@backup.example.net \
  'sudo mkdir -p /mnt/backup/btrfs-recv'

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

إنشاء أول لقطة للقراءة فقط

أنشئ لقطة ثابتة للقراءة فقط من وحدة تخزين المصدر الفرعية المباشرة. إن -r تكتسب العلامة أهمية لأن الإرسال التزايدي في Btrfs يعتمد على لقطات لا يمكن أن تتغير أثناء عملية الإرسال.

sudo mkdir -p /mnt/pool/.snapshots

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260831-1000

أكّد الخاصية قبل الإرسال:

sudo btrfs property get \
  /mnt/pool/.snapshots/data-20260831-1000 ro

النتيجة المتوقعة هي ro=true.

إرسال اللقطة الكاملة الأولية إلى موقع خارج الموقع

لا تحتوي عملية النقل الأولى على أصل، لذا فهي إرسال كامل. في صدفة متوافقة مع Bash، فعّل pipefail يجعل فشل أي من جانبي مسار الأنابيب ظاهرًا للصدفة المستدعية.

set -o pipefail

sudo btrfs send \
  /mnt/pool/.snapshots/data-20260831-1000 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

إذا sudo -n يفشل على المضيف البعيد، فأصلح إعدادات الامتيازات البعيدة قبل إعادة المحاولة. لا تستبدله بمطالبة بكلمة مرور داخل مسار التدفق.

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

تحقّق من اللقطة المستلمة قبل استخدامها كأصل

لا تفترض أن انتهاء جلسة SSH يعني أن سلسلة النسخ الاحتياطي سليمة. افحص اللقطتين:

sudo btrfs subvolume show \
  /mnt/pool/.snapshots/data-20260831-1000

ssh backup@backup.example.net \
  'sudo -n btrfs subvolume show \
  /mnt/backup/btrfs-recv/data-20260831-1000'

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

بعد هذا التحقق فقط ينبغي data-20260831-1000 ليصبح الأصل للنسخة الاحتياطية التزايدية التالية.

أنشئ وأرسل اللقطة التزايدية التالية

بعد تغيّر البيانات المباشرة، أنشئ لقطة جديدة للقراءة فقط:

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260901-0200

ثم أرسل التغييرات فقط منذ اللقطة السابقة:

set -o pipefail

sudo btrfs send \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

ينجح ذلك لأن اللقطة الأصلية من الإرسال الأول لا تزال موجودة بالشكل المطابق على كلا النظامين. بعد استلام اللقطة الجديدة والتحقق منها بنجاح، data-20260901-0200 يمكن أن تصبح الأصل للتشغيل التالي.

أبقِ اللقطات الأصلية متطابقة

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

تحذّر إرشادات Btrfs الرسمية بشأن علامات وحدات التخزين الفرعية ومعرّفات UUID المستلمة من أن تغيير لقطة مستلمة من القراءة فقط إلى القراءة والكتابة يخرق الافتراضات المستخدمة في الإرسال التزايدي.

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

sudo btrfs subvolume snapshot \
  /mnt/backup/btrfs-recv/data-20260901-0200 \
  /mnt/restore/data-20260901-0200

تكون لقطة الاسترداد الجديدة قابلة للكتابة افتراضيًا، بينما تظل لقطة الاستلام الأصلية سليمة لعمليات الإرسال التزايدية المستقبلية.

استخدم قاعدة آمنة للاحتفاظ باللقطات

لا تحتاج إلى الاحتفاظ بكل لقطة قديمة إلى الأبد، لكن يجب أن تحتفظ باللقطة الأصلية المطلوبة للإرسال التالي على كلا النظامين. وتتمثل إحدى قواعد التدوير البسيطة في:

1. أنشئ لقطة المصدر الجديدة للقراءة فقط.
2. أرسلها باستخدام اللقطة السابقة التي نجح إرسالها باعتبارها -p.
3. تحقّق من لقطة الاستلام الجديدة خارج الموقع.
4. رقِّ اللقطة الجديدة لتصبح الأصل التالي.
5. فقط بعد ذلك أزل نقاط الاسترداد الأقدم وفقًا لسياسة الاحتفاظ لديك.

يمكن أن يوفر الاحتفاظ بعدة لقطات تاريخية نقاطًا مفيدة للرجوع، لكن تذكّر أن اللقطة الموجودة على نظام الملفات نفسه ليست نسخة احتياطية مستقلة. وتكتسب النسخة المتماثلة خارج الموقع قيمتها لأنها تضع نسخة أخرى على نظام وموقع منفصلين. يشرح دليل النسخ الاحتياطي 3-2-1 من ZimaSpace سبب حماية النسخة خارج الموقع من الأعطال التي لا يمكن للتكرار المحلي تغطيتها.

عالج وحدات تخزين Btrfs الفرعية المتداخلة بشكل منفصل

لقطات Btrfs ليست تكرارية عبر وحدات التخزين الفرعية المتداخلة. إذا كانت /mnt/pool/data تحتوي على وحدة تخزين فرعية أخرى، فإن اللقطة الأصلية تحتوي على عنصر نائب لوحدة التخزين الفرعية بدلًا من لقطة كاملة للبيانات المتداخلة.

اعرض وحدات التخزين الفرعية قبل وضع خطة النسخ الاحتياطي في صيغتها النهائية:

sudo btrfs subvolume list /mnt/pool

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

اعرف متى تستخدم ‎-p ومتى تستخدم ‎-c

بالنسبة إلى سجل نسخ احتياطي خطي، -p هو الخيار الأبسط والأسهل للتدقيق. أما -c يمكن للخيار إضافة مصدر استنساخ واحد أو أكثر، ما يتيح لـ Btrfs إعادة استخدام الامتدادات المتطابقة من لقطات إضافية، لكن يجب أن تكون مصادر الاستنساخ هذه موجودة أيضًا بالحالة نفسها تمامًا على الطرفين.

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

اختياري: استخدام البروتوكول 2 للامتدادات المضغوطة

في إصدارات Linux وbtrfs-progs الحديثة بما يكفي، يمكن لبروتوكول إرسال Btrfs 2 نقل الامتدادات المضغوطة بكفاءة أكبر باستخدام --compressed-data. توضح وثائق الإرسال الرسمية أن البروتوكول 2 يتطلب btrfs-progs 6.0 أو إصدارًا أحدث على المرسل والمستقبل، وLinux 6.0 أو إصدارًا أحدث على المرسل.

sudo btrfs send \
  --proto 2 \
  --compressed-data \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

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

استكشاف الأخطاء الشائعة في عمليات الإرسال والاستقبال التزايدية

يقول أمر الإرسال إن اللقطة ليست للقراءة فقط

أعِد إنشاء اللقطة باستخدام btrfs subvolume snapshot -r. إن مجرد تركيب لقطة قابلة للكتابة من خلال تركيب للقراءة فقط لا يفي بمتطلبات الإرسال.

لا يمكن للإرسال التزايدي العثور على الأصل أو استخدامه

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

يقول btrfs إن وحدة التخزين الفرعية الوجهة موجودة بالفعل

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

تم تعديل أب الاستلام بعد وصوله

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

الملفات الموجودة داخل دليل متداخل مفقودة من اللقطة

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

ينقطع اتصال WAN أو SSH أثناء النقل

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

احمِ جهة الاستلام من التدفقات غير الموثوقة

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

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

استخدم قائمة التحقق هذه لكل تشغيل تزايدي

• تأكد من أن كلا الطرفين يستخدمان Btrfs.
• أنشئ لقطة المصدر الجديدة باستخدام -r.
• أبقِ الأب السابق الناجح دون تغيير على النظامين.
• أرسِل باستخدام btrfs send -p OLD NEW.
• استلم البيانات عبر اتصال SSH موثّق ومشفّر.
• تحقق من النجاح وقارن معرّف UUID للمصدر بمعرّف UUID المُستلَم لدى المستقبل.
• أبقِ لقطة النسخة الاحتياطية المستلَمة للقراءة فقط.
• أنشئ لقطة منفصلة قابلة للكتابة عندما تحتاج إلى استعادة البيانات أو اختبارها.
• دوّر اللقطات القديمة فقط بعد التحقق من الأب الجديد.
• انسخ وحدات التخزين الفرعية المتداخلة باستخدام سلاسل منفصلة.

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