تشغيل Proxmox Backup Server على VPS كنسخة خارجية

ما الذي يوفّره Proxmox Backup Server فعلياً على VPS

يعمل Proxmox Backup Server (PBS) على VPS كهدف نسخ احتياطي خارج الموقع، ويستخدم البروتوكول نفسه الذي تستخدمه مجموعة Proxmox VE (البيئة الافتراضية) لديك، لذلك تكون كل نسخة احتياطية بعد النسخة الأولى تزايدية، وإزالة التكرار فيها مشتركة بين الضيوف، ومشفّرة قبل مغادرة الخادم لموقعك، ويمكن التحقق منها بعد ذلك. تستأجر VPS مع وحدة تخزين كتلية، وتثبّت PBS على Debian 13، وتنشئ مخزن بيانات واحداً على تلك الوحدة، ثم تضيفه في Proxmox VE كتخزين من النوع pbs. يستغرق التثبيت عشر دقائق. لكن ما يحدد قيمة النسخ الاحتياطي بعد عام هو كل ما يأتي بعد ذلك: مساحات الأسماء، وجمع البيانات غير الضرورية، وحيازة المفاتيح، وتنفيذ عملية استعادة فعلية.

السبب في استخدام PBS بدلاً من نسخ ملفات vzdump إلى قرص مستأجر هو مخزن الأجزاء. يقسم العميل قرص الضيف إلى أجزاء بحجم يقارب 4 MiB، ويحسِب قيمة التجزئة لكل جزء، ثم يرفع الأجزاء التي لا يحتوي عليها مخزن البيانات مسبقاً فقط. بالنسبة إلى آلة افتراضية قيد التشغيل، يتتبع QEMU الكتل التي تغيّرت باستخدام dirty bitmap بعد النسخة الاحتياطية الأولى، ولذلك تقرأ العملية التالية هذه الكتل فقط من القرص المحلي. إذا كان حجم الضيف 200 GB ويتغير فيه 3 GB يومياً، فسيُرسَل نحو 3 GB يومياً. هذا ما يجعل وصلة الإنترنت المنزلية ووحدة التخزين المستأجرة تعملان معاً، ولذلك يتفوق استخدام VPS كهدف نسخ احتياطي خارج الموقع على قرص احتياطي في منزل صديق. وإذا كنت لا تزال تقرر أين يجب أن تستضيف الـhypervisor نفسه، فإن Proxmox في المنزل مقابل VPS مستأجر يتناول هذا السؤال بشكل منفصل.

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

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

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

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

يستخدم ضيف البريد في المثال 120 GB، ويتغيّر بمقدار يقارب 3.0 GB يومياً. لذلك تحتاج 30 لقطة يومية إلى نحو 210 GB: نسخة كاملة واحدة، إضافة إلى تغيّرات 30 يوماً. اجمع العمود الأخير لكل الضيوف وعددهم 3، فيكون الإجمالي نحو 619 GB. أضف خُمس هذه القيمة للفهارس والبيانات الوصفية والمساحة اللازمة لعمل جمع البيانات المهملة، وهذا يشير إلى استخدام وحدة تخزين بسعة 1 TB.

أما بقية الخطة فبسيطة. يعمل PBS جيداً مع 2 GB من الذاكرة، ويعمل براحة أكبر مع 4 GB، لأن العمليات المكلفة تحدث على مستوى العنقود: إذ يقرأ عقدة Proxmox VE أقراص الضيوف، ثم تنفّذ تقسيم البيانات إلى كتل وحساب التجزئة. يقتصر عمل VPS على كتابة الكتل وتشغيل المهمتين الثقيلتين: جمع البيانات المهملة والتحقق. استأجر مخزن البيانات بوصفه وحدة تخزين كتلية منفصلة بدلاً من استخدام قرص root كبير واحد، لأنك تستطيع زيادة حجم الوحدة لاحقاً من دون إعادة إنشاء الخادم.

ثبّت Proxmox Backup Server على Debian 13

اعتباراً من أغسطس 2026، الإصدار المتوافق الحالي هو Proxmox Backup Server 4 على Debian 13، الذي يحمل الاسم trixie. تربط الأدلة القديمة PBS 2 مع Debian 11، كما أن الاسم جزء من تعريف المستودع. لذلك، يؤدي نسخ اسم إصدار قديم إلى خطأ من apt يفيد بعدم وجود ملف الإصدار. ابدأ من صورة Debian 13 خالصة. نفّذ جميع الأوامر أدناه بصلاحيات root، أو باستخدام sudo كما هو مكتوب.

sudo apt update && sudo apt install -y wget
sudo wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

يجب أن تكون القيمة الناتجة هي 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45. إذا لم تكن كذلك، فتوقف. يعني keyring غير الصحيح أنك على وشك تثبيت حزم موقّعة من جهة لم تتحقق منها.

اكتب /etc/apt/sources.list.d/pbs.sources مع مستودع no-subscription، وهو المستودع المناسب لخادم لا يملك عقد دعم:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update
sudo apt install -y proxmox-backup-server

تستجيب واجهة الويب عبر HTTPS على المنفذ 8007. سجّل الدخول باسم root@pam باستخدام كلمة مرور root للنظام، لأن PBS يصادق هذا المستخدم عبر PAM (pluggable authentication modules)، أي الحسابات نفسها التي يستخدمها نظام التشغيل. الشهادة موقّعة ذاتياً، وسيُبلغك المتصفح بذلك. بصمة هذه الشهادة هي القيمة التي يثبّتها Proxmox VE لاحقاً، لذلك يُعد التحذير متوقعاً وليس مشكلة يجب إصلاحها.

المنفذ 8007 هو نموذج تسجيل دخول متاح على الإنترنت العام، لذلك لا تتركه مفتوحاً للجميع. يكفي ملف واحد من nftables لتغطيته. تؤدي كتابة /etc/nftables.conf إلى مسح مجموعة القواعد الحالية، لذلك تخطَّ هذه الخطوة إذا كان شيء آخر يدير جدار الحماية على هذا الخادم.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

طبّق القواعد باستخدام sudo systemctl enable --now nftables، وأبقِ جلسة SSH ثانية مفتوحة أثناء ذلك: قد يؤدي policy drop مع خطأ مطبعي واحد في قاعدة SSH إلى منعك من الوصول إلى خادمك. استبدل 203.0.113.7 بالعنوان الذي يتصل منه عنقودك. إذا كان هذا العنوان ديناميكياً، فإما أن توسّع القاعدة لتشمل نطاق مزوّد الخدمة، أو تنهي الاتصال داخل نفق. تذكّر أن معظم لوحات تحكم VPS تحتوي على جدار حماية شبكي منفصل أمام الجهاز، ويجب أن يسمح بالمنفذ نفسه.

ضع مخزن البيانات على وحدة تخزين مستقلة

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

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

استخرج اسم الجهاز من lsblk. يكون الاسم /dev/vdb في معظم صور KVM، و/dev/sdb في الصور الأخرى، ولا يجوز افتراضه بأمان. أضف نقطة الربط إلى /etc/fstab باستخدام label، حتى لا يؤدي تغيير اسم الجهاز بعد إعادة التشغيل إلى توجيه مخزن البيانات إلى القرص الخطأ:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

يجب أن يعرض findmnt الجهاز والمسار والخيارات، بما في ذلك rw,relatime. هناك فشلان مخفيان في ذلك السطر. إذا لم تكن نقطة الربط موجودة وأنشأت مخزن البيانات رغم ذلك، فسيكتب PBS داخل نظام الملفات الجذري تحت نقطة الربط، ثم ستخفي عملية الربط الناجحة التالية تلك البيانات من دون حذفها. عندها سيبدو مخزن البيانات فارغاً، بينما يظل نظام الملفات الجذري ممتلئاً. وإذا كانت الخيارات تتضمن noatime، فسيرفض PBS العمل، لأنّه يجري فحصاً لسلامة أوقات الوصول عند إنشاء مخزن البيانات، ثم يعيد الفحص في كل عملية garbage collection.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

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

تمنع Namespaces تعارض مضيفين

يكون مخزن البيانات مسطحاً افتراضياً. تُسمّى النسخ الاحتياطية vm/100 وct/101 وhost/<name>. إذا كتب عنقودان، لكل منهما ضيف بالمعرّف 100، في المجموعة نفسها، فسوف تتداخل لقطاتهما، وستحسب قاعدة الاحتفاظ المعرّفة لأحدهما لقطات الآخر أيضاً. تمنح Namespaces كل مصدر شجرة خاصة به داخل مخزن بيانات واحد.

أنشئها على مضيف PBS. تكون صيغة الوسيط --repository هي [[auth-id@]server[:port]:]datastore، ولذلك تُكتب القيمة المحلية root@pam@localhost:store1، ويطلب الأمر كلمة مرور root.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

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

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

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

يطبع أمر الرمز السري مرة واحدة بالضبط:

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

انسخه الآن، لأن PBS لا يحتفظ بأي صيغة منه يمكنه عرضها لك مرة أخرى. راجع أمر التحكم في الوصول مرتين. فهو يسمّي الرمز، backup@pbs!pve-home، وليس المستخدم، لأن أذونات الرمز تُحسب فقط من الإدخالات التي تسمّي الرمز نفسه. يترك إدخال backup@pbs وحده الرمز بلا أي وصول على الإطلاق، وعندها تفشل أول نسخة احتياطية بسبب الأذونات، لا بسبب أي شيء ظاهر في الشبكة. المسار مهم بالقدر نفسه: لا يستطيع رمز مقيّد بـ/datastore/store1/pve-home قراءة أي شيء في Namespace الخاصة بالمكتب أو حذفه، ولذلك لا يستطيع عنقود مخترق تدمير سجل موقع آخر.

إضافة VPS كوحدة تخزين للنسخ الاحتياطية في Proxmox VE

اقرأ بصمة الشهادة على مضيف PBS أولاً.

sudo proxmox-backup-manager cert info | grep Fingerprint

ثم نفّذ الأمر على أي عقدة في المجموعة:

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

الصق القيمة cert info المطبوعة مكان العنصر النائب في السطر الثالث. يؤدي تمرير --password من دون قيمة إلى جعل pvesm يطلبها، لذلك يبقى سر الرمز خارج سجل أوامر الصدفة. تُخزَّن القيمة في /etc/pve/priv/storage/pbs-offsite.pw، بينما يُحفظ تعريف وحدة التخزين نفسه في /etc/pve/storage.cfg، ويُنسخ إلى كل عقدة في المجموعة، لذلك تضبطه مرة واحدة للمجموعة بأكملها.

يخبر --prune-backups keep-all=1 Proxmox VE بألا يحذف أي شيء. تُضبط سياسة الاحتفاظ على جانب PBS، كما هو موضح لاحقاً، لسبب واضح: لا يحتاج الرمز حينها إلى صلاحية الحذف، ولذلك لا تستطيع مجموعة تتعرض للتشفير ببرمجية فدية الوصول إلى السجل البعيد وحذف النسخ القديمة التي يفترض أن تنقذها.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

يعرض pvesm status القيمة active في عمود الحالة، مع إجمالي مساحة مخزن البيانات والمساحة المستخدمة بجانبها. تعني inactive أن العقدة لم تتمكن من إكمال جلسة TLS (أمان طبقة النقل) إلى المنفذ 8007، وهذا يشير إلى مشكلة في جدار الحماية أو البصمة، وليس في بيانات الاعتماد.

ترفع أول نسخة احتياطية كل البيانات، لذلك أجرِ الحساب قبل بدء العملية. تساوي سعة 200 GB مقدار 1600 gigabits، وينقل اتصال صاعد بسرعة 100 Mbit مقدار 0.1 gigabit في الثانية، لذلك يستغرق النقل أربع ساعات ونصف تقريباً كحد أدنى، ويستغرق في الواقع مدة أطول. ابدأ العملية عندما لا تحتاج إلى عرض النطاق الترددي. ترسل كل عملية لاحقة الأجزاء الجديدة فقط.

تشفير جهة العميل، ومكان حفظ المفتاح

الـVPS هو جهاز لا تملكه. شفّر البيانات على جهاز العميل، وسيخزّن مخزن البيانات أجزاءً لا يستطيع المزوّد قراءتها.

sudo pvesm set pbs-offsite --encryption-key autogen

يكتب ذلك مفتاحاً جديداً إلى /etc/pve/priv/storage/pbs-offsite.enc، ولا يستطيع قراءته إلا root، ويُنسخ مع بقية /etc/pve. ابتداءً من النسخة الاحتياطية التالية، يشفّر العميل كل جزء قبل إرساله. يظل الخادم قادراً على عرض لقطاتك وأحجامها، لكنه لا يستطيع قراءة محتوياتها.

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

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

يطبع key paperkey المفتاح في مستند مخصص للطباعة على الورق وحفظه في مكان آخر. تعامل مع الملف نفسه باعتباره سراً، لأن أي شخص يحوزه يستطيع فك تشفير كل نسخة احتياطية أُنشئت باستخدامه. في الإعدادات الأكبر، يدعم PBS أيضاً مفتاحاً رئيسياً، وهو زوج مفاتيح RSA (Rivest Shamir Adleman) يُنشأ باستخدام proxmox-backup-client key create-master-key. تخزّن كل نسخة احتياطية مفتاح التشفير الخاص بها مشفراً بالمفتاح العام، بينما يبقى المفتاح الخاص دون اتصال لاستخدامه في الاسترداد.

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

تنظيف العلامات واستعادة المساحة بجمع المهملات

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

اضبط الجدولين. ابدأ بالاحتفاظ، مع مهمة واحدة لكل مساحة أسماء:

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

ثم اضبط جدول جمع المهملات على مخزن البيانات، بعد مهمة التنظيف ببضع ساعات وخارج نافذة النسخ الاحتياطي:

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

تحقق من هذا الفصل بنفسك مرة واحدة على مضيف PBS:

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

شغّل مهمة التنظيف، ثم df، وستلاحظ أن قيمة المساحة المستخدمة لم تتغير. شغّل جمع المهملات، ثم df مرة أخرى، وستتغير.

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

على VPS صغير، هذه أثقل مهمة يشغّلها الخادم، لأنها تفحص حالة كل ملف جزء على وحدة التخزين. ينتهي سجل المهمة بملخص لما أُزيل وما يزال معلقاً بسبب فترة السماح. إذا كان هناك الكثير من العناصر المعلقة، فشغّلها مرة أخرى في اليوم التالي. يوفّر PBS الخيارين gc-atime-safety-check وgc-atime-cutoff لضبط مخزن البيانات، ويجب تركهما دون تغيير. فهما مخصصان لوحدات التخزين التي لا تستطيع تسجيل أوقات الوصول، وتعطيل فحص الأمان على نظام ملفات مُضمّن باستخدام noatime هو الطريقة التي تفقد بها الأجزاء التي لا تزال اللقطات الحية تشير إليها.

يثبت التحقق أن الأجزاء ما زالت قابلة للقراءة

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

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

أبقِ عدد مؤشرات التنفيذ منخفضاً على VPS صغير. يعتمد التحقق على القرص ووحدة المعالجة المركزية، وإلا فسيتنافس مع العمليات الأخرى التي ينفذها الخادم. لتحديد جدول زمني، استخدم علامة Verify Jobs في واجهة الويب الخاصة بـ datastore: يغطي تشغيل أسبوعي يتجاوز snapshots التي جرى التحقق منها مسبقاً، ويعيد التحقق من أي snapshot أقدم من 30 يوماً، مخزن البيانات بالكامل بمرور الوقت من دون تكرار العمل.

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

اختبر عملية الاستعادة، ثم اختبرها من دون العنقود

لن تعرف أن النسخة الاحتياطية تعمل حتى تستعيدها. يختبر الاختباران جانبين مختلفين.

الضيف بالكامل على العنقود:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

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

الاختبار الثاني هو الاختبار الذي لا يجريه أحد تقريباً. افترض أن المبنى الذي يوجد فيه العنقود قد اختفى، ثم استعد النسخة من جهاز لم يكن جزءاً منه قط. على أي جهاز Debian 13، أضف المستودع المخصص للعميل فقط كما يلي /etc/apt/sources.list.d/pbs-client.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs-client
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

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

ما الذي تفعله إزالة التكرارات وما لا تفعله في فاتورة القرص

إزالة التكرارات حقيقية، وتعمل على مستوى مخزن البيانات بالكامل. تشترك عشر ضيوف Debian في نسخة واحدة من النظام الأساسي، لذلك لا يضيف الضيف الثاني المطابق تقريباً أي تكلفة تخزين. كما توفر عرض النطاق الترددي للرفع، لأن العميل يرسل checksum بدلاً من البيانات لأي chunk يحتفظ به الخادم مسبقاً.

من المهم توضيح ما لا تفعله.

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

لا تضف طبقة أخرى لإزالة التكرارات أسفلها. تصل chunks بعد أن يكون العميل قد أزال تكراراتها وضغطها، لذلك تستهلك إزالة التكرارات في ZFS أسفل مخزن البيانات RAM للبحث عن تطابقات أزيلت قبل الكتابة. الخيار الصحيح هنا هو استخدام ext4 أو xfs عادي على volume.

تعرض واجهة الويب معامل إزالة التكرارات لمخزن البيانات. يصف هذا الرقم ضيوفك، وهو الرقم الوحيد المفيد للتخطيط، لأن النسب المنشورة تصف بيانات أشخاص آخرين. إذا احتجت أيضاً إلى نسخ احتياطية على مستوى الملفات لأجهزة ليست ضيوف Proxmox، فشغّلها بالتوازي على VPS نفسه: PBS هو هدف يدرك طبيعة hypervisor للضيوف بالكامل، بينما يتعامل restic وBorgBackup مع الأدلة، وتناسب نسخ restic الاحتياطية إلى VPS أجهزة الكمبيوتر المحمولة والخوادم المستقلة التي لم يُصمم PBS لتغطيتها قط.

أوضاع الفشل وما ستراه

تظهر وحدة التخزين بالحالة غير النشطة. يطبع pvesm status --storage pbs-offsite القيمة inactive عندما تعجز العقدة عن إكمال جلسة TLS إلى المنفذ 8007. افحص جدار الحماية على VPS، ثم جدار الحماية الشبكي المنفصل لدى مزود الخدمة، ثم بصمة الشهادة. تفشل البصمة التي لم تعد تطابق الشهادة بالطريقة الظاهرة نفسها التي يفشل بها المنفذ المحجوب، وتتغير كلما استُبدلت تلك الشهادة.

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

يرفض جمع البيانات المهملة البدء. فشل فحص أمان وقت الوصول، وهذا يعني في معظم الحالات أن نظام ملفات مخزن البيانات مركّب مع noatime. شغّل findmnt -no OPTIONS /mnt/datastore/store1 للتأكد، وأصلح الخيار في /etc/fstab، ثم أعد التركيب. لا تعطل الفحص لتجاوز المشكلة.

لا يتوقف مخزن البيانات عن النمو. تعمل مهام الحذف ولا تُستعاد أي مساحة. إما ألا يكون هناك جدول لجمع البيانات المهملة، أو أن كل عملية جمع تقع ضمن فترة السماح البالغة 24 ساعة لأنها تعمل مباشرة بعد النسخ الاحتياطية. افحص الجدول باستخدام proxmox-backup-manager datastore show store1.

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

FAQ

لماذا يستمر مخزن بيانات Proxmox Backup Server في النمو عند تشغيل مهمة pruning؟

لأن pruning تزيل بيانات التعريف الخاصة باللقطات فقط: manifest وindexes وlog وnotes. تبقى chunks على القرص إلى أن تحذف garbage collection تلك التي لا يشير أي index إليها. اضبط جدولاً زمنياً لمخزن البيانات باستخدام proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'، وأثبت ذلك بتشغيل df -h على مسار مخزن البيانات قبل proxmox-backup-manager garbage-collection start store1 وبعده. توقّع تأخراً لا يقل عن يوم، لأن المرحلة الثانية تزيل فقط chunks التي يزيد عمر وقت الوصول إليها على 24 ساعة و5 دقائق.

ما مقدار مساحة القرص التي تحتاج إليها VPS تعمل بـProxmox Backup Server؟

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

أين يجب تخزين مفتاح تشفير النسخ الاحتياطية؟

في أي مكان، لكن ليس على العنقود الذي يحميه وحده. يحتفظ Proxmox VE بالمفتاح في /etc/pve/priv/storage/<storage>.enc، ويُنسخ ذلك الملف إلى كل عقدة، ولذلك يضيع مع العنقود. انسخه إلى خارج العنقود في اليوم الأول، واطبعه باستخدام proxmox-backup-client key paperkey، واحتفظ بالنسخة في مبنى مختلف. لاحظ أيضاً أن المفتاح يشارك في digest الخاص بـchunk، ولذلك يعني استبداله لاحقاً أن النسخة الاحتياطية التالية سترفع كل شيء من جديد.

هل أحتاج إلى مخزن بيانات واحد لكل مضيف Proxmox، أم إلى namespaces؟

استخدم مخزن بيانات واحداً وnamespace واحداً لكل مضيف مصدر أو عنقود مصدر. تعمل إزالة التكرار عبر مخزن البيانات، لا بين مخازن البيانات، ولذلك يؤدي التقسيم حسب المضيف إلى تخزين الصور الأساسية نفسها عدة مرات. تفصل namespaces مجموعات النسخ الاحتياطية، ولذلك لا يمكن لمضيفين لديهما guest بالمعرّف 100 أن يتعارضا. كما يحد مسار التحكم بالوصول ذي الشكل /datastore/store1/pve-home رمز API المميز لكل مضيف ضمن namespace الخاص به.

هل تستطيع VPS صغيرة مواكبة العمل كخادم Proxmox للنسخ الاحتياطي؟

عادةً نعم، في بيئة homelab، لأن إنشاء chunks وحساب hashing يحدثان على عقدة Proxmox VE، لا على خادم النسخ الاحتياطي. تكتب VPS الـchunks وتشغّل المهمتين الثقيلتين: garbage collection والتحقق. خصص لها 4 GB من RAM، وأبقِ عدد خيوط التحقق منخفضاً. جدْوِل المهمتين خارج نافذة النسخ الاحتياطي. وإذا استمر تشغيلهما مدة أطول بكثير مما ينبغي أن يحتاجه القرص، فقِس steal time قبل شراء خطة أكبر.