حذف فایل های اضافه لینوکس

برای حذف فایل‌های اضافه در لینوکس و آزادسازی فضای دیسک، هیچ‌وقت از حذف کردن شروع نکنید؛ اول با df -h ببینید کدام پارتیشن پر شده و بعد با du یا ncdu دقیقاً پیدا کنید چه چیزی آن فضا را گرفته است. مقصر معمولاً یکی از چند متهم همیشگی است: لاگ‌های رشدکرده، بکاپ‌های قدیمی، کش بسته‌های سیستم‌عامل، محتوای /tmp، ایمیج‌ها و والیوم‌های بلااستفاده داکر، و فایل‌هایی که پاک شده‌اند ولی هنوز یک پروسه آن‌ها را باز نگه داشته است.

چرا «حذف کورکورانه» بدترین کار ممکن است

رایج‌ترین اشتباهی که باعث از کار افتادن سرور می‌شود این است که کاربر با دیدن پیام No space left on device شروع به پاک کردن پوشه‌هایی می‌کند که نامشان آشنا نیست. در لینوکس بسیاری از فایل‌هایی که «اضافه» به نظر می‌رسند در واقع سوکت، فایل موقت پایگاه داده یا کش فعال یک سرویس هستند و حذفشان سرویس را از کار می‌اندازد. تشخیص درست چند دقیقه بیشتر طول نمی‌کشد ولی جلوی ساعت‌ها خرابی را می‌گیرد.

نکته دوم این است که پر شدن دیسک همیشه مشکل «فایل زیادی» نیست. اگر سرویس‌ها خطا می‌دهند اما df -h فضای خالی نشان می‌دهد، احتمالاً inodeها تمام شده‌اند؛ یعنی تعداد فایل‌ها به سقف رسیده، نه حجمشان. هر سروری که انبوه فایل‌های ریز کش، سشن یا صف ایمیل تولید می‌کند در معرض این حالت است، از یک ماشین مجازی داخل ایران گرفته تا یک سرور بزرگ. بررسی‌اش یک دستور است:

df -ih

گام اول: اندازه‌گیری دقیق

ابتدا وضعیت کلی پارتیشن‌ها را ببینید:

df -h

سپس از ریشه شروع کنید و لایه به لایه پایین بروید. سوئیچ -x باعث می‌شود ابزار وارد پارتیشن‌های دیگر نشود و آمار را خراب نکند:

du -xh --max-depth=1 / | sort -h

هر پوشه‌ای که حجم غیرعادی داشت را با همان الگو باز کنید، مثلاً du -xh --max-depth=1 /var | sort -h و همین‌طور جلو بروید تا به پوشه مقصر برسید. اگر ابزار ncdu نصب باشد، همین کار را تعاملی و بسیار سریع‌تر انجام می‌دهد:

ncdu -x /

برای پیدا کردن تک‌فایل‌های بزرگ هم این دستور کافی است:

find / -xdev -type f -size +500M -exec ls -lh {} \;

متهم‌های همیشگی و روش امن پاک‌سازی

ترتیب زیر را رعایت کنید؛ از کم‌ریسک‌ترین به پرریسک‌ترین:

۱. لاگ‌های systemd. اول حجمشان را ببینید، بعد کوتاهشان کنید. این کار فایل‌ها را حذف نمی‌کند بلکه فقط قدیمی‌ها را هرس می‌کند:

journalctl --disk-usage

journalctl --vacuum-time=7d

۲. کش بسته‌ها. این فایل‌ها هر لحظه قابل بازسازی هستند و حذفشان کاملاً بی‌خطر است. روی خانواده رد هت (AlmaLinux، Rocky Linux) از dnf استفاده کنید و روی دبیان و اوبونتو از apt:

dnf clean all

apt clean && apt autoremove

۳. لاگ‌های چرخش‌خورده. فایل‌های فشرده قدیمی در /var/log معمولاً بی‌مصرف‌اند. اول فهرست بگیرید و فقط وقتی خروجی را دیدید حذف کنید:

find /var/log -type f -name "*.gz" -mtime +30

و پس از تأیید فهرست، -delete را به انتهای همان دستور اضافه کنید. هرگز خود پوشه /var/log یا زیرپوشه‌های آن را پاک نکنید؛ سرویس‌ها انتظار دارند آن مسیرها وجود داشته باشند.

۴. فایل لاگ فعال و بزرگ. اگر یک فایل لاگ در حال استفاده چند گیگابایت شده، آن را با rm حذف نکنید. خالی کردنش امن‌تر است چون فایل و دسترسی پروسه دست‌نخورده می‌ماند:

truncate -s 0 /var/log/example.log

۵. بکاپ‌های قدیمی و فایل‌های دانلودی. بکاپ‌های محلی سریع‌ترین راه پر کردن دیسک‌اند. بکاپ روی همان سروری که از آن بکاپ می‌گیرید عملاً بکاپ نیست؛ نسخه‌ها را بیرون ببرید. اگر کارتان توزیع فایل حجیم است، نگه داشتن آن‌ها روی سرور اصلی اشتباه است و بهتر است روی هاست دانلود جدا نگهداری شوند که برای ذخیره‌سازی و ارائه فایل‌های حجیم طراحی شده است.

۶. داکر. ایمیج‌ها و والیوم‌های بلااستفاده حجم زیادی می‌گیرند. اول گزارش بگیرید:

docker system df

و بعد با احتیاط پاک‌سازی کنید. توجه کنید که docker system prune -a همه ایمیج‌های بدون کانتینر فعال را حذف می‌کند و اگر رجیستری در دسترس نباشد بازسازی‌شان دردسر دارد.

فایل را پاک کردم ولی فضا آزاد نشد

این کلاسیک‌ترین حالت گیج‌کننده است: فایل چند گیگابایتی را حذف کرده‌اید، du کاهش را نشان می‌دهد اما df همچنان دیسک را پر گزارش می‌کند. علت این است که یک پروسه هنوز آن فایل را باز نگه داشته و لینوکس تا بسته شدن آن دسترسی، فضا را آزاد نمی‌کند. برای دیدن این فایل‌ها:

lsof +L1

راه‌حل، ریستارت کردن همان سرویسی است که فایل را باز نگه داشته (مثلاً systemctl restart nginx). ریستارت کل سرور لازم نیست.

دستورهایی که هرگز نباید اجرا کنید

وقتی با کاربر روت روی یک سرور اختصاصی با دسترسی کامل مدیریتی یا هر سرور دیگری کار می‌کنید، هیچ لایه محافظی جلوی اشتباه شما را نمی‌گیرد و سطل بازیافتی هم در کار نیست. این موارد را جدی بگیرید؛ هیچ‌کدام قابل بازگشت نیستند:

• rm -rf / و rm -rf /* — کل سیستم را نابود می‌کنند. همچنین مراقب متغیر خالی باشید: اگر در اسکریپت بنویسید rm -rf $DIR/ و DIR خالی باشد، همان فاجعه رخ می‌دهد. همیشه از rm -rf "${DIR:?}/" استفاده کنید.
• اجرای مستقیم اسکریپت از اینترنت با الگوی curl ... | sh — شما محتوایی را با دسترسی روت اجرا می‌کنید که ندیده‌اید. آموزش‌های قدیمی «پاک‌سازی خودکار» معمولاً همین الگو را پیشنهاد می‌دادند و امروز نه امن است و نه آن آدرس‌ها دیگر بالا می‌آیند. اگر لازم شد، اول فایل را دانلود کنید، بخوانید و بعد اجرا کنید.
• حذف پوشه‌های /var/lib، /etc، /usr و /boot برای آزادسازی فضا — این‌ها فایل اضافه نیستند.
• find با -delete بدون اینکه اول خروجی بدون آن سوئیچ را دیده باشید.
• حذف دستی فایل‌های دیتابیس (مثل فایل‌های ib_logfile یا بایناری‌لاگ‌ها) از مسیر داده — بایناری‌لاگ را باید از داخل خود دیتابیس و با در نظر گرفتن وضعیت replication هرس کرد.

پیشگیری بهتر از پاک‌سازی اضطراری است

پر شدن دیسک تقریباً همیشه قابل پیش‌بینی است. سه کار ساده جلوی تکرارش را می‌گیرد: تنظیم درست logrotate برای لاگ‌های اپلیکیشن، سقف گذاشتن روی حجم ژورنال با SystemMaxUse در فایل /etc/systemd/journald.conf، و مهم‌تر از همه یک هشدار ساده که پیش از پر شدن کامل دیسک به شما خبر بدهد (آستانه‌اش را خودتان انتخاب کنید؛ خیلی‌ها روی هشتاد درصد می‌گذارند تا فرصت واکنش بماند). روی سرورهایی که چند سرویس سنگین کنار هم اجرا می‌کنند، جدا کردن پارتیشن داده از پارتیشن سیستم هم کمک می‌کند تا پر شدن یکی، کل سیستم‌عامل را زمین نزند.

و اگر ترجیح می‌دهید درگیر این نگهداری دوره‌ای نشوید، سراغ گزینه‌های سرور مدیریت‌شده بروید که در آن‌ها نصب و پیکربندی کنترل‌پنل، عیب‌یابی نرم‌افزارها و پشتیبانی فنی بر عهده تیم آنلاین سرور است. در هر صورت، قاعده طلایی را فراموش نکنید: اول اندازه بگیر، بعد پاک کن.