إدارة التخزين والنسخ الاحتياطي على خادم VPS

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

01ما الذي تحت قرصك الافتراضي

خادمك يرى قرصاً افتراضياً، غالباً باسم /dev/vda، يقدمه المشرف الافتراضي عبر virtio. تحته مصفوفة أقراص فيزيائية يديرها المزود، فلا تراها ولا تحتاج إدارتها. لكن نوعها يحدد ما تتوقعه منها:

• NVMe مقابل SATA SSD: أقراص NVMe تتصل بالمعالج عبر ناقل PCIe وتعالج الطلبات في طوابير متوازية كثيرة، فيبقى زمن الانتظار منخفضاً حين تقرأ قاعدة البيانات وتكتب في الوقت نفسه. أما SATA فتمر عبر واجهة صُممت للأقراص الدوارة، بطابور واحد من 32 أمراً.
• RAID 10: تُنسخ البيانات على أزواج من الأقراص ثم تُوزَّع بين الأزواج. تصمد المصفوفة إن تعطّل قرص من كل زوج، وتبقى الكتابة سريعة لأنها لا تحسب بيانات تكافؤ (parity) كما في RAID 5 وRAID 6.
• سقف لكل خادم: يضع المزود عادةً حداً لعمليات القراءة والكتابة في الثانية لكل خادم، كي لا يستهلك خادم واحد المصفوفة كلها. ونشرح قياسه في مقال مستقل عن الفرق بين VPS وVDS.

خوادم CoreVPS مثلاً تعمل على تخزين NVMe بمصفوفة Software RAID 10. وهذا يحميك من تعطّل قرص فيزيائي، ولا يحميك من شيء آخر، كما سترى. ابدأ بمعرفة ما يراه نظامك:

# الأقراص والأقسام وأنظمة ملفاتها ونقاط تركيبهاlsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS# نظام الملفات الجذر وخيارات تركيبهfindmnt /

02نظام الملفات وLVM

على قرص NVMe لن تشعر بفرق كبير في الأداء بين ext4 وXFS في موقع أو متجر عادي. الفرق الحقيقي في الإدارة:

القاعدة العملية: ابقَ على ما يأتي به نظامك. والاستثناء خادم يخزن ملفات ضخمة أو يكتب بالتوازي بكثافة، كأرشيف فيديو، فقد يستفيد من XFS.

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

والأهم عملياً: حين ترقّي مساحة القرص من لوحة التحكم، يكبر القرص الافتراضي، لكن القسم ونظام الملفات يبقيان بحجمهما القديم حتى توسّعهما. بعض القوالب تفعل ذلك تلقائياً عند الإقلاع عبر cloud-init، وإن لم يحدث فهذه الأوامر:

# تأكد من الحجم الجديد للقرص ورقم قسم الجذر (هنا vda1)lsblk# وسّع القسم ليملأ القرص (الأداة من حزمة cloud-guest-utils)sudo growpart /dev/vda 1# ثم وسّع نظام الملفات وهو مركّب: لـ ext4sudo resize2fs /dev/vda1# أو لـ XFS، بنقطة التركيب لا باسم القسمsudo xfs_growfs /# وإن كان الجذر على LVM: وسّع الحجم الفيزيائي، ثم المنطقي مع نظام ملفاته (تحقق من الأسماء بـ lvs)sudo pvresize /dev/vda3sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

03راقب قبل أن يمتلئ

القرص لا يمتلئ فجأة، بل يمتلئ بصمت ثم يتوقف كل شيء في لحظة. وثلاثة مصادر تملأ أقراص الخوادم أكثر من غيرها: السجلات، والنسخ الاحتياطية المحلية المنسية، وملايين الملفات الصغيرة كالجلسات والمخبئ القديم، وهذه تستهلك الـ inodes قبل المساحة. هذه الأوامر تخبرك أين تذهب المساحة:

# المساحة لكل نظام ملفات، ثم الـ inodesdf -hTdf -i# أكبر المجلدات تحت /var دون عبور أنظمة ملفات أخرىsudo du -xh --max-depth=2 /var | sort -h | tail -15# مستكشف تفاعلي للمساحة (ثبّته بالحزمة ncdu)sudo ncdu -x /# ملفات محذوفة ما زالت عملية تفتحها، فلا تتحرر مساحتهاsudo lsof +L1# حجم سجل systemd، ثم قصّه إلى 500 MBjournalctl --disk-usagesudo journalctl --vacuum-size=500M# زمن انتظار القرص ونسبة انشغاله، كل ثانيتين خمس مراتiostat -x 2 5

وقصّ السجل مرة لا يكفي: اضبط الحد الدائم بمفتاح SystemMaxUse في إعدادات journald، وتأكد أن logrotate يدوّر سجلات تطبيقاتك. ثم ضع تنبيهاً عند 80% من المساحة و80% من الـ inodes، من لوحة خادمك أو من أداة مراقبة مثل Prometheus أو Zabbix، فالتنبيه عند 95% يأتي متأخراً.

المشكلةأداة df تقول إن القرص ممتلئ، وdu لا تجد إلا نصف المساحة

الحلملف محذوف ما زالت عملية تفتحه، كسجل حذفته يدوياً وخادم الويب يكتب فيه. اعرضه بأداة lsof، ثم أعد تشغيل الخدمة لتتحرر المساحة.

المشكلةرسالة No space left on device والمساحة الحرة 30%

الحلنفدت الـ inodes لا المساحة. انظر إلى عمود IUse% في ناتج df، وابحث عن مجلد فيه ملايين الملفات الصغيرة، كجلسات PHP أو مخبئ قديم.

المشكلةالقرص يمتلئ كل ليلة ثم يفرغ صباحاً

الحلسكربت النسخ الاحتياطي يكتب التفريغ محلياً قبل رفعه. اجعله يضغط التفريغ، أو يرسله مباشرة، أو خصص له مساحة تكفيه.

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

اللقطة (snapshot) صورة لحالة القرص في لحظة، تُؤخذ في ثوانٍ لأنها لا تنسخ البيانات بل تحفظ ما يتغير بعدها. هي ممتازة قبل ترقية النظام أو تحديث خطر، لأن الرجوع منها سريع. لكنها تعيش على نظام التخزين نفسه، فإن ضاع ضاعت معه.

وانتبه إلى قاعدة البيانات: لقطة قرص تُؤخذ وهو يكتب تشبه انقطاع الكهرباء فجأة. InnoDB يتعافى منها عادةً، لكن الأسلم أن تأخذ معها تفريغاً متسقاً بـ mysqldump أو بأداة مثل mariadb-backup. وهذا ما يحميك منه كل خيار:

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

05قاعدة 3-2-1 بالأوامر

قاعدة 3-2-1 بسيطة: ثلاث نسخ من بياناتك، على نوعين مختلفين من التخزين أو نظامين مستقلين، واحدة منها في موقع آخر. وأضافت الممارسة الحديثة رقمين: نسخة لا يمكن تعديلها أو منفصلة عن الشبكة، وصفر أخطاء في اختبار الاستعادة. على خادم أرشيف صور في طرابلس، arshif-tripoli.com، تبدو هكذا:

• النسخة الأولى: البيانات الحية على الخادم.
• النسخة الثانية: نسخة الخادم اليومية في مساحة النسخ الاحتياطي لدى المزود.
• النسخة الثالثة: مستودع restic مشفّر على خادم في مركز بيانات آخر أو لدى مزود آخر، يومياً، مع احتفاظ أسبوعي وشهري.

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

sudo apt install -y restic zstd# ما يلي يعمل بصلاحيات root، مثلاً من مهمة مجدولة: المستودع على خادم آخر عبر SFTPexport RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/arshif-tripoliexport RESTIC_PASSWORD_FILE=/root/.restic-pass# مرة واحدة فقط: إنشاء المستودعrestic init# تفريغ متسق لقاعدة البيانات أولاً، ثم نسخ الملفات والإعدادات والتفريغmysqldump --single-transaction --quick --all-databases | zstd > /var/backups/db.sql.zstrestic backup /var/www /etc /var/backups# احتفظ بسبع نسخ يومية وأربع أسبوعية وست شهرية، واحذف ما زادrestic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# مرآة سريعة لمجلد الصور إلى خادم آخر. انتبه: --delete ينقل الحذف أيضاًrsync -aH --delete /var/www/arshif-tripoli/uploads/ [email protected]:/srv/mirror/uploads/

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

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

06اختبر الاستعادة قبل أن تحتاجها

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

# فحص سلامة المستودع، مع قراءة 5% من بياناته فعلياًrestic check --read-data-subset=5%# النسخ المتاحة وتواريخهاrestic snapshots# استعادة آخر نسخة إلى مجلد مؤقت، لا فوق الإنتاجrestic restore latest --target /tmp/restore-testls -la /tmp/restore-test/var/www# على خادم اختبار فقط: فك التفريغ واستورده، ثم افحص جدولاً مهماًzstd -dc /tmp/restore-test/var/backups/db.sql.zst | mysql

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

07توصية عملية

لخادم VPS نموذجي يكفيك هذا: ابقَ على نظام الملفات الافتراضي، وضع تنبيهاً عند 80% من المساحة والـ inodes، وحدّ سجل systemd. خذ لقطة أو نسخة من لوحة المزود قبل كل تحديث كبير، وشغّل restic يومياً إلى موقع آخر بصلاحيات لا تسمح للخادم بحذف نسخه، واختبر الاستعادة كل شهر.

هذا كله ساعة عمل في يومك الأول، وتمرين بنصف ساعة كل شهر. وهو الفرق بين عطل يكلّفك ساعة وعطل يكلّفك المشروع.