دیسک پر می‌تواند نوشتن دیتابیس، session، log و فایل موقت را متوقف و سایت را ناگهان Down کند. اولین واکنش نباید حذف فایل‌های ناشناس یا پاک کردن directoryهای Docker و دیتابیس باشد. ابتدا باید معلوم شود کدام filesystem پر است، فضاست یا inode، چه چیزی رشد کرده و آیا process هنوز فایل حذف‌شده‌ای را باز نگه داشته است.
پاسخ سریع: با df -h filesystem پر و با df -i وضعیت inode را پیدا کنید. سپس فقط داخل همان mount، مصرف directoryها را از بالا به پایین بررسی کنید. log، backup، upload، database، Docker و فایل حذف‌شده باز را جدا بسنجید. پیش از حذف، مالک داده، retention و امکان بازیابی را تأیید کنید.
اول مشخص کنید چه چیزی تمام شده است
df -h
df -i
findmnt
lsblk -fاین فرمان‌ها layout filesystem، ظرفیت و inode را بدون تغییر نشان می‌دهند. ممکن است root پر باشد اما volume دیتابیس فضای کافی داشته باشد، یا برعکس. overlay/container و mountهای bind را درست نسبت دهید. نام device به‌تنهایی محل داده را مشخص نمی‌کند.
فضا یا Inode؟
فایل‌های بسیار کوچک می‌توانند inode را تمام کنند در حالی که چند گیگابایت فضا باقی است. در این حالت ساخت فایل تازه شکست می‌خورد و پیام شبیه disk full دیده می‌شود. cache session، mail queue یا directory موقت با میلیون‌ها فایل از سناریوهای قابل بررسی‌اند. افزایش حجم block device مشکل inode طراحی‌نشده را الزاماً رفع نمی‌کند.
مصرف Directory را داخل همان Filesystem بسنجید
sudo du -xhd1 /var
sudo du -xhd1 /srvگزینه -x مانع عبور به filesystemهای دیگر می‌شود. مسیر را متناسب با mount پر انتخاب کنید. اجرای du روی tree بزرگ I/O ایجاد می‌کند؛ در ساعت اوج با priority و دامنه محدود اجرا کنید. از اسکن کور کل سرور شروع نکنید.
چرا جمع du با df برابر نیست؟
df مصرف filesystem را می‌بیند و du فایل‌های قابل پیمایش را. فایل حذف‌شده‌ای که process هنوز باز نگه داشته، در du دیده نمی‌شود اما تا بسته شدن descriptor فضا را نگه می‌دارد. reserved blocks، mount پنهان و permission نیز اختلاف ایجاد می‌کنند.
فایل حذف‌شده اما باز
اگر ابزار lsof نصب است، نمایش فایل‌های link-count صفر می‌تواند process نگه‌دارنده را پیدا کند. خروجی را بر اساس اندازه و PID تحلیل کنید. کشتن process یا truncate کردن descriptor می‌تواند داده را خراب کند؛ روش امن معمولاً rotation/reload یا restart کنترل‌شده همان سرویس پس از بررسی اثر است.
Logهای بدون Rotation
access/error log، application log و debug log ممکن است با خطای تکراری سریع رشد کنند. فقط فایل را خالی نکنید؛ علت flood، سیاست rotation، compression و retention را اصلاح کنید. rotation باید با روش reopen سرویس هماهنگ باشد، وگرنه process به inode قدیمی می‌نویسد.
Systemd Journal
journal نیز سهم disk دارد و policy نگهداری آن باید با نیاز audit و ظرفیت هماهنگ باشد. ابتدا مصرف و بازه زمانی را ببینید. کاهش retention یک تصمیم نگهداری شواهد است؛ در incident امنیتی حذف log می‌تواند بررسی را مختل کند. مشکل سرویس پرخطا را نیز جدا رفع کنید.
Backup روی همان سرور
backupهای روزانه بدون retention یکی از علت‌های رشد پیوسته‌اند. بدتر اینکه backup فقط روی همان disk در خرابی storage قابل بازیابی نیست. فایل‌ها را بر اساس تاریخ، صحت و نسخه خارج از سرور بررسی کنید. هیچ backup را قبل از تأیید نسخه سالم و سیاست retention حذف نکنید.
Docker و Overlay Storage
imageهای قدیمی، layerهای build، container متوقف، volume و log می‌توانند فضا بگیرند. directory داخلی Docker را دستی حذف نکنید؛ metadata آن با storage driver مدیریت می‌شود. ابتدا مصرف را با ابزار خود Docker طبقه‌بندی و مالک volume را مشخص کنید. prune گسترده ممکن است image rollback یا volume داده را از بین ببرد.
برای Docker باید image، volume، build cache و log را جدا گزارش کنید؛ عدد کل به‌تنهایی نشان نمی‌دهد کدام بخش قابل‌بازیابی است. پیش از هر cleanup، وابستگی deployment و rollback به imageهای محلی را نیز ثبت کنید.
دیتابیس و WAL/Binary Log
رشد table/index، temporary file، PostgreSQL WAL یا MySQL binary log باید با ابزار و retention همان دیتابیس مدیریت شود. حذف مستقیم فایل‌های داخل data directory می‌تواند دیتابیس را غیرقابل‌راه‌اندازی کند. replication، backup و point-in-time recovery تعیین می‌کنند چه logی قابل بازیافت است.
Upload و فایل برنامه
رشد media، artifact deploy، export و فایل موقت را بررسی کنید. فایل کاربر ممکن است الزام قانونی یا کسب‌وکاری داشته باشد. extension و نام فایل معیار کافی برای حذف نیست. lifecycle storage، quota و انتقال به object storage باید همراه دسترسی و backup طراحی شود.
Package Cache و Kernelهای قدیمی
package manager می‌تواند cache نگه دارد و نسخه‌های kernel برای rollback لازم باشند. از فرمان رسمی همان توزیع و preview تغییرات استفاده کنید. حذف دستی فایل‌های package database یا boot می‌تواند update و boot بعدی را خراب کند. قبل از cleanup وضعیت kernel در حال اجرا و فضای boot را مشخص کنید.
فایل موقت و Cache برنامه
نام temp یا cache مجوز حذف کور نمی‌دهد. ممکن است job فعال، session یا lock به آن وابسته باشد. owner، زمان آخرین استفاده و روش رسمی پاک‌سازی برنامه را بیابید. پاک کردن cache بزرگ می‌تواند cache stampede و فشار ناگهانی روی دیتابیس ایجاد کند.
آیا حجم Disk واقعاً بزرگ شده است؟
گاهی partition یا volume پس از افزایش دیسک هنوز resize نشده، mount مورد انتظار انجام نشده یا داده زیر mount point اشتباه نوشته شده است. findmnt و lsblk layout را روشن می‌کنند. resize filesystem عملیات حساس است و باید با مستندات نوع filesystem، snapshot و برنامه rollback انجام شود.
وقتی سایت همین حالا قطع است
- filesystem و inode پر را ثبت کنید.
- writeهای غیرضروری و job تولیدکننده را طبق runbook محدود کنید.
- کم‌ریسک‌ترین داده قابل‌بازیابی را با تأیید owner مدیریت کنید.
- سرویس آسیب‌دیده را پس از آزاد شدن headroom کنترل کنید.
- سلامت دیتابیس و queue را پیش از باز کردن کامل ترافیک بسنجید.
- رشد مجدد را دقیقه‌به‌دقیقه مانیتور کنید.
هدف آزاد کردن مقدار کوچکی headroom برای بازیابی کنترل‌شده است، نه حذف سریع بیشترین حجم. در پایگاه داده یا queue ممکن است shutdown ناقص نیازمند recovery باشد.
ترتیب تشخیص پیشنهادی
df -hوdf -iبرای تعیین نوع کمبود- mount و filesystem دقیق با
findmnt du -xمرحله‌ای روی همان mount- بررسی deleted-open files و log
- طبقه‌بندی backup، Docker، database و upload
- تطبیق timeline رشد با deploy، job یا ترافیک
- پاک‌سازی فقط با retention و امکان بازیابی
- تعریف quota، rotation و alert پیشگیرانه
چه چیزهایی را دستی حذف نکنیم؟
- فایل داخل data directory دیتابیس
- directory داخلی Docker یا container runtime
- backup بدون تأیید نسخه سالم دیگر
- فایل log موردنیاز incident بدون archive
- kernel و فایل boot بدون ابزار package manager
- فایل کاربر یا upload بدون policy
- فایل ناشناخته صرفاً به دلیل حجم بالا
چرا حذف فایل گاهی فضا آزاد نمی‌کند؟
اگر process descriptor را باز نگه دارد، inode تا بسته شدن آن باقی است. اگر فایل روی mount دیگری حذف شده باشد، filesystem پر تغییری نمی‌کند. snapshotهای storage نیز ممکن است blockها را نگه دارند. پس از اقدام، همان df و metric را دوباره بررسی کنید و به پیام موفقیت فرمان اکتفا نکنید.
پیشگیری
برای درصد و بایت آزاد، inode، نرخ رشد، log rate، backup age، database growth و Docker storage alert تعریف کنید. هشدار ۱۰۰٪ دیر است؛ زمان تا پر شدن مهم‌تر است. rotation و retention را آزمون کنید و ظرفیت burst هنگام deploy، backup و restore را در نظر بگیرید.
در چک‌لیست کانفیگ اولیه سرور محل log، backup مستقل و monitoring باید پیش از production مشخص شود.
چه زمانی کمک تخصصی لازم است؟
اگر df و du اختلاف زیادی دارند، data directory دیتابیس یا Docker عامل اصلی است، حذف عجولانه ریسک از دست رفتن داده دارد. مدیریت ماهانه سرور می‌تواند منبع رشد را بدون دستکاری کور شناسایی و retention، rotation و alert پایدار طراحی کند.
پرسش‌های متداول
چرا با حذف فایل بزرگ فضا آزاد نشد؟
ممکن است process هنوز فایل حذف‌شده را باز نگه داشته یا فایل روی filesystem دیگری بوده باشد.
آیا می‌توان پوشه Docker را دستی پاک کرد؟
خیر؛ این کار metadata و داده container را خراب می‌کند. از inventory و ابزار رسمی runtime استفاده کنید.
فرق پر شدن فضا و inode چیست؟
اولی کمبود block ذخیره‌سازی و دومی کمبود امکان ساخت فایل تازه است؛ df -h و df -i آن‌ها را جدا نشان می‌دهند.
چقدر فضای خالی نگه داریم؟
عدد ثابت عمومی وجود ندارد؛ نرخ رشد، burst، backup/restore و نیاز دیتابیس تعیین‌کننده‌اند. alert باید پیش از exhaustion فرصت اقدام بدهد.