.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
رسالة No space left on device، أو قاعدة بيانات توقفت فجأة، أو موقع لا يحفظ الملفات المرفوعة — كلها علامات أن القرص ممتلئ. حين يكون القرص ممتلئ تتوقف الخدمات وقد تتعطّل قاعدة البيانات، فالحل عاجل. في هذا الدليل الشامل نجد أولًا أين ذهبت المساحة، ثم ننظّفها بأمان، وإن لم يكفِ ذلك نوسّع القرص بعد الترقية — وكل الأوامر مجرّبة على سيرفر حقيقي في مرام هوست، ومنها توسيع فعلي لقرصه من 250 إلى 251GB.
⚡ الإجابة المختصرة
اعرف: df -h ثم sudo du -xh --max-depth=1 / | sort -rh | head. نظّف: sudo apt-get clean وsudo journalctl --vacuum-size=200M وsudo docker system prune. وسّع: بعد ترقية الخطة أعد التشغيل (يتوسع تلقائيًا) أو sudo growpart /dev/sda 1 && sudo resize2fs /dev/sda1.
محتويات الدليل
ماذا يحدث عندما يكون القرص ممتلئ؟
قبل الحل، لماذا مشكلة القرص ممتلئ عاجلة إلى هذا الحدّ؟ لأن نفاد المساحة يشلّ السيرفر:
- الخدمات تتوقف: قاعدة البيانات تفشل في الكتابة فيسقط الموقع.
- لا حفظ للملفات: الرفع والسجلات والجلسات تفشل بصمت.
- قد يتعطّل النظام: بعض الخدمات لا تُقلع إن لم تجد مساحة كافية.
- خطر فقدان البيانات: كتابة نصفية قد تُفسد ملفات قاعدة البيانات.
لذلك عند أول علامة على أن القرص ممتلئ، شخّص السبب ونظّف فورًا. والأدوات الأساسية مثل df وdu تكشف بسرعة أين ذهبت المساحة.
الخطوة 1: أين ذهبت المساحة؟
ابدأ بـdf -h لترى الصورة العامة، ثم du لتنزل مجلدًا مجلدًا نحو السبب. هذه مخرجات سيرفرنا:
مخرجات حقيقية
كرّر du على المجلد الأكبر (مثل sudo du -xh --max-depth=1 /var | sort -rh | head) حتى تصل إلى المجلد الذي تضخّم. ولمعرفة أكبر الملفات مباشرة:
مخرجات حقيقية
الخطوة 2: نظّف بأمان
هذه الأماكن الأشهر لتراكم الملفات، والأوامر آمنة لا تمسّ بياناتك. في سيرفرنا حرّر apt-get clean وحده 290MB:
مخرجات حقيقية: 290MB من apt clean
sudo apt-get cleanآمن تمامًاsudo apt autoremove --purgeراجع القائمة قبل الموافقةsudo journalctl --vacuum-size=200Mيُبقي آخر 200MBsudo find /var/log -name "*.gz" -deleteأرشيف السجلات القديمsudo docker system pruneيحذف الحاويات المتوقفة والصور غير المستعملة. -a أقوى — انتبه.sudo truncate -s 0 /path/app.logيفرغ الملف دون حذفه (أسلم من rm لملف مفتوح)لا تحذف: /swapfile، أو أي شيء داخل /usr و/boot، أو ملفات قاعدة البيانات في /var/lib/mysql مباشرة. وقبل حذف شيء لا تعرفه خذ لقطة Snapshot.
حالة خاصة — inodes: إن كان df -h يعرض مساحة متاحة والرسالة ما زالت تظهر، فافحص df -i: ربما امتلأ عدد الملفات (ملايين الملفات الصغيرة، غالبًا جلسات PHP أو كاش).
الخطوة 3: لم يكفِ التنظيف؟ رقِّ ووسّع القرص
زيادة المساحة تبدأ بترقية الخطة. بعدها يجب أن تكبر ثلاث طبقات: القرص (sda) ثم القسم (sda1) ثم نظام الملفات (ما يعرضه df). افتح صفحة Disks في لوحة سيرفرك وتأكد من الحجم؛ ولاحظ تنبيه اللوحة بأن أي تعديل على القرص يحتاج إعادة تشغيل:
لقطة حقيقية
زر القلم يعدّل الحجم ضمن حدود خطتك فقط — جرّبنا 251 على خطة 250GB فرفضته اللوحة:
لقطة حقيقية من تجربتنا
بعد توسيع قرص سيرفرنا التجريبي فعلًا، هذا ما ظهر داخله: القرص صار 251G، لكن القسم ونظام الملفات بقيا على الحجم القديم:
مخرجات حقيقية بعد توسيع القرص
الطريقة الأولى — إعادة تشغيل واحدة: قوالب لينكس في مرام تستعمل cloud-init، ووحدة growpart فيه تعمل مع كل إقلاع فتمدّ القسم ونظام الملفات تلقائيًا. هذا سجلّ حقيقي من السيرفر نفسه عند أول تشغيل، حين وسّع نفسه من حجم القالب (نحو 30GB) إلى حجم الخطة:
سجل حقيقي من السيرفر
الطريقة الثانية — بدون إعادة تشغيل: أمران (resize2fs وgrowpart) والسيرفر يعمل. هذه المخرجات الحقيقية:
مخرجات حقيقية
lsblk # اسم القرص ورقم القسم (هنا sda و1)
sudo growpart /dev/sda 1 # لاحظ المسافة بين sda و1
df -T / # نوع نظام الملفات
sudo resize2fs /dev/sda1 # ext4 (Ubuntu وDebian)
sudo xfs_growfs / # xfs
df -h / # تحقّقNOCHANGE: partition 1 ... cannot be grownالقسم يملأ القرص أصلًا: التوسيع تمّ، أو القرص نفسه لم يكبر بعد (تحقق من lsblk وصفحة Disks).growpart: command not foundsudo apt install cloud-guest-utilslsblkأعد التشغيل من Reboot ثم افحص من جديد.لكي لا يمتلئ مجددًا
- حدّد حجم سجلات النظام دائمًا: أضف
SystemMaxUse=200Mفي/etc/systemd/journald.confثمsudo systemctl restart systemd-journald. - نظّف Docker دوريًا، وحدّد حجم سجلات الحاويات (
max-sizeفي/etc/docker/daemon.json). - لا تحتفظ بنسخ احتياطية داخل السيرفر نفسه — استعمل النسخ الاحتياطي في لوحة مرام.
- اعرف الامتلاء قبل أن يحدث: ألقِ نظرة أسبوعية على
df -h، أو على عدّاد «المساحة المستهلكة» في صفحة الخدمة.
أسئلة شائعة عن مشكلة القرص ممتلئ
ابدأ بـdf -h للصورة العامة، ثم انزل مجلدًا مجلدًا بـsudo du -xh --max-depth=1 / | sort -rh | head حتى تصل إلى المجلد المتضخّم، واستعمل find لأكبر الملفات مباشرة.
كاش apt (apt-get clean)، سجلات النظام (journalctl --vacuum-size)، صور Docker غير المستعملة (docker system prune)، والسجلات المضغوطة القديمة في /var/log. لا تحذف /swapfile أو محتويات /usr و/boot أو ملفات قاعدة البيانات مباشرة.
غالبًا امتلأ عدد الملفات (inodes) لا المساحة. افحص بـdf -i؛ السبب عادةً ملايين الملفات الصغيرة مثل جلسات PHP أو الكاش.
بعد الترقية إما تعيد التشغيل مرة واحدة (cloud-init يوسّع القسم ونظام الملفات تلقائيًا)، أو تنفّذ sudo growpart /dev/sda 1 ثم sudo resize2fs /dev/sda1 دون إعادة تشغيل.
لأن القرص كبر لكن القسم ونظام الملفات بقيا على الحجم القديم. يجب أن تكبر الطبقات الثلاث: القرص ثم القسم (growpart) ثم نظام الملفات (resize2fs لـext4 أو xfs_growfs لـxfs).
كيف أمنع امتلاء القرص مجددًا؟حدّد حجم سجلات النظام بـSystemMaxUse، ونظّف Docker دوريًا وحدّد حجم سجلات الحاويات، ولا تحتفظ بالنسخ الاحتياطية داخل السيرفر، وراقب df -h أسبوعيًا أو عبر عدّاد المساحة في صفحة الخدمة.
