اسأل أي مزوّد: «هل عندك نسخ احتياطية؟» — سيقول نعم. ثم اسأل: «متى آخر مرّة استرجعت واحدة فعلاً؟» وستجد الصمت.
وهذا هو بيت القصيد كله. تقرير «تمّت النسخة بنجاح» يخبرك أن الملف كُتب، ولا يخبرك أن الجهاز سيقلع منه. والفرق بين الاثنين يظهر في أسوأ يوم ممكن — يوم لا يكون أمامك خيار آخر.
كل رقم في هذه السلسلة مقيس لا مقدَّر. نفّذنا كل أمر على سيرفر Proxmox VE 9.2 حقيقي
بمعالج EPYC وتخزين LVM-thin على NVMe، وأخذنا الأزمنة من مخرجات time نفسها.
وقد استبدلنا العناوين العامة الحقيقية بعناوين التوثيق المخصّصة لهذا الغرض (RFC 5737) حفاظاً على أمان السيرفر.
أولاً: النسخة
vzdump 8801 --storage ext2026 --mode snapshot --compress zstd
النتائج المقيسة على قرص 31.5 غيغابايت:
| حجم القرص | 31.5 GiB |
| منه أصفار (فراغ) | 29.35 GiB — أي 93٪ |
| حجم الأرشيف الناتج | 725 MB |
| سرعة القراءة | 1.5 GiB/s |
| الزمن الكلي | 23 ثانية |
ولهذا لا تخف من حجم الأقراص: النسخة تنسخ ما فيه بيانات فعلاً، لا حجم القرص المعلن.
أوضاع النسخ الثلاثة
| الوضع | ما يفعله | متى تستعمله |
|---|---|---|
| snapshot | لقطة لحظية والجهاز يعمل | الافتراضي — وهو ما تريده غالباً |
| suspend | يجمّد الجهاز أثناء النسخ | حين لا يدعم التخزين اللقطات |
| stop | يطفئ الجهاز ثم ينسخ | أعلى اتّساق — وأكبر انقطاع |
قواعد البيانات حالة خاصة. نسخة على مستوى القرص لقاعدة بيانات نشطة قد تلتقطها في منتصف عملية كتابة. الحلّ ليس تغيير وضع النسخ بل إضافة طبقة: أمر pre-backup يفرّغ القاعدة إلى ملف dump قبل النسخة، فتحصل على الاثنين — صورة القرص وملف قاعدة سليم.
ثانياً: الجدولة
# /etc/pve/jobs.cfg — أو من الواجهة: Datacenter ← Backup
vzdump: daily-all
schedule 02:30
storage ext2026
mode snapshot
compress zstd
all 1
prune-backups keep-daily=7,keep-weekly=4,keep-monthly=6
mailnotification failure
mailto [email protected]
mailnotification failure لا always. رسالة نجاح يومية تُقرأ أسبوعاً ثم تُهمَل إلى الأبد، ورسالة فشل وسط الصمت تُقرأ فوراً. والفرق ليس تفصيلاً: هو ما يجعلك تعرف أن النسخ توقّفت قبل أن تحتاجها بشهر.
ثالثاً — وهو المهمّ: اختبار الاسترجاع
كل ما سبق مجرّد إجراء. وهذه هي اللحظة التي تفصل بين من عنده نسخ ومن يظنّ أن عنده نسخ:
# استرجع إلى رقم جديد — لا فوق الأصل
qmrestore /mnt/pve/ext2026/dump/vzdump-qemu-8801-....vma.zst 8803 --storage thinnvme
qm set 8803 --name web-01-restored
qm start 8803
# ثم السؤال الوحيد الذي يهمّ: هل يعمل؟
qm guest exec 8803 -- /bin/bash -c 'systemctl is-active nginx; curl -s localhost'
في مختبرنا: الاسترجاع استغرق 16 ثانية، والجهاز أقلع، والخدمة تعمل، والمستخدم موجود، والمحتوى كما كان.
استرجع دائماً إلى رقم جديد. الاسترجاع فوق الجهاز الأصلي يمحوه — فإن كانت النسخة معطوبة خسرت الاثنين معاً. والرقم الجديد يكلّفك مساحة مؤقّتة ويشتري لك طريق عودة.
فخّ لاحظناه في الاختبار
الجهاز المُسترجَع أخذ اسم المضيف web-01-restored لا web-01 — لأن cloud-init يعيد كتابة اسم المضيف من اسم الجهاز عند الإقلاع. وهذا لا يهمّ في اختبار، لكنه يهمّ جداً في استرجاع حقيقي لخدمة تعتمد على اسمها: سمِّ الجهاز المُسترجَع بالاسم الأصلي قبل تشغيله إن كنت تستبدل به الأصل فعلاً.
إجراء اختبار شهري — عشرون دقيقة
- اختر جهازاً مختلفاً كل شهر (بالدور، لا الأسهل دائماً).
- استرجعه إلى رقم غير مستعمَل على شبكة معزولة.
- شغّله وتحقّق من ثلاثة أشياء: يقلع · الخدمة تعمل · البيانات حديثة.
- سجّل التاريخ والنتيجة وزمن الاسترجاع في ملف واحد.
- احذف الجهاز المؤقّت.
وزمن الاسترجاع الذي تسجّله ليس رقماً للتوثيق: هو ما ستقوله للزبون حين يسألك «متى يرجع؟».
الطبقة التي تنجو: نسخة خارج السيرفر
نسخة على نفس السيرفر تحميك من الحذف والخطأ. ولا تحميك من حريق، ولا سرقة، ولا تشفير يطال السيرفر كلّه. ولهذا تحتاج نسخة ثالثة في مكان آخر.
وProxmox Backup Server هو الحلّ الطبيعي هنا لسببين عمليين: يخزّن نسخاً تزايدية مع إزالة التكرار — فلا تُنقل إلّا الكتل المتغيّرة — ويستطيع التحقّق الدوري من سلامة النسخ بنفسه، وهو ما لا يفعله ملفّ vzdump ساكن على قرص.
# على السيرفر: أضف التخزين البعيد
pvesm add pbs backup-remote \
--server pbs.example.com \
--datastore store1 \
--username backup@pbs \
--password '********' \
--fingerprint <بصمة الشهادة>
# ثم وجّه المهمّة إليه
vzdump 8801 --storage backup-remote --mode snapshot
وقاعدة 3-2-1 ليست شعاراً: ثلاث نسخ، على وسيطين مختلفين، واحدة منها خارج الموقع. والاختصار الشائع — «عندي نسخة يومية على قرص ثانٍ في نفس السيرفر» — يسقط كلّه أمام حادث واحد.
ما الذي لا تغطّيه النسخة؟
نقطة تُنسى دائماً: نسخ الأجهزة لا تشمل إعداد السيرفر نفسه. أضف هذه إلى مهمّة يومية صغيرة:
tar czf /mnt/backup/pve-config-$(date +%F).tar.gz \
/etc/pve /etc/network/interfaces /etc/hosts \
/etc/vzdump.conf /root/*.sh
لأن استرجاع عشرين جهازاً على سيرفر بلا شبكة ولا جدار ولا مستخدمين يعني أنك ستعيد بناء كل شيء من الذاكرة.
أخطاء شائعة وحلولها
| العَرَض | السبب | الحل |
|---|---|---|
| النسخ توقّفت منذ أسابيع | التخزين امتلأ ولا أحد يقرأ الرسائل | prune-backups + تنبيه عند الفشل |
| الاسترجاع يفشل: مساحة غير كافية | الأرشيف مضغوط والقرص كامل الحجم | وفّر مساحة بحجم القرص لا الأرشيف |
| الجهاز المُسترجَع لا يقلع | ترتيب الإقلاع أو التعريفات | راجع qm config وقارنه بالأصل |
| تعارض عناوين بعد الاسترجاع | الأصل والنسخة يعملان معاً | أطفئ الأصل أو غيّر عنوان النسخة |
| النسخة بطيئة جداً | الضغط على معالج مشغول | zstd وقلّل bwlimit أو غيّر التوقيت |
| قاعدة البيانات مُسترجَعة ناقصة | نسخة على مستوى القرص لقاعدة نشطة | أضف dump قبل النسخة |
| الأرشيف موجود ولا يُقرأ | تلف لم يُكتشف | تحقّق دوري — أو PBS الذي يفعلها بنفسه |
أسئلة شائعة
كم أحتفظ من النسخ؟
نقطة بداية عملية: 7 يومية · 4 أسبوعية · 6 شهرية. وعدّلها بحسب مساحتك وحجم الضرر الذي يسبّبه فقدان يوم عمل.
zstd أم gzip؟
zstd — أسرع بفارق كبير وبنسبة ضغط مقاربة. لا سبب لاستعمال gzip اليوم.
هل أنسخ كل الأجهزة أم المهمّة فقط؟
الكل — بجدولة ليلية. واستثنِ الأجهزة التجريبية صراحةً بـexclude بدل أن تختار يدوياً ما يُنسَخ، لأن الاختيار اليدوي يُنسى مع أول جهاز جديد.
هل أستطيع استرجاع ملف واحد بدل الجهاز كلّه؟
نعم مع PBS (استعراض محتوى النسخة)، ومع vzdump بخطوة إضافية: استرجاع إلى جهاز مؤقّت ثم أخذ الملف منه.
وما أفضل استثمار أوّل إن كانت ميزانيتي محدودة؟
مساحة تخزين خارج السيرفر — قبل أي عتاد آخر. فالسيرفر يمكن استبداله في يوم، والبيانات لا.
خلاصة السلسلة
بنينا في خمسة أجزاء مصنعاً صغيراً: شبكة مرتّبة تحتمل النموّ، وقالباً يولّد سيرفراً في 2.6 ثانية، وتسليماً آلياً بلا كونسول، وطريق عودة من أي خطأ في 49 ثانية، ونسخاً احتياطية مُختبرة تسترجع في 16 ثانية.
وكل هذا يعمل على سيرفر واحد. إن أردت أن تبدأ بواحد مُدار بعنوان ثابت وتوفّر دائم: اطّلع على باقات VPS، أو على السيرفرات المخصّصة إن كنت ستبني عليها أجهزة زبائنك.
هذه المقالة من سلسلة «بروكسموكس كمصنع سيرفرات» — من سيرفر واحد إلى تسليم آليّ لأجهزة زبائنك: ١. الشبكة والجسور والـVLAN · ٢. القوالب · ٣. Cloud-Init · ٤. اللقطات والاستنساخ · ٥. النسخ الاحتياطي واختبار الاسترجاع