پر شدن هارد سرور و مشکل در IBSng

وقتی هارد سرور پر می‌شود، IBSng معمولاً با پیام Internal Error, Can't connect to IBS Core از کار می‌افتد؛ ولی ریشه‌ی خرابی خودِ IBSng نیست، بلکه PostgreSQL است که بدون فضای خالی نمی‌تواند بنویسد و بالا بیاید. مسیر درست حل مشکل هم همیشه یکی است: با df -h پارتیشن پر را پیدا کنید، با du بگردید فضا کجا رفته، فقط لاگ و کش را خالی کنید و بعد سرویس‌ها را به ترتیب بالا بیاورید.

قدم اول: کدام پارتیشن پر شده است

قبل از هر کاری باید بدانید مشکل روی کدام فایل‌سیستم است. خیلی وقت‌ها ریشه (/) هنوز جا دارد ولی /var که جداگانه مانت شده پر شده است:

df -h

اگر ستون Use% برای پارتیشنی صددرصد بود، متهم پیدا شده. اما یک حالت گمراه‌کننده هم هست: گاهی فضا خالی است و سیستم باز هم می‌گوید No space left on device. در این حالت اینودها تمام شده‌اند، نه بایت‌ها:

df -i

اینودِ تمام‌شده یعنی تعداد فایل‌ها زیاد است نه حجمشان؛ معمولاً انبوهی فایل ریز در یک پوشه‌ی کش.

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

قدم دوم: فضا دقیقاً کجا رفته است

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

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

بعد وارد سنگین‌ترین پوشه شوید و همین کار را تکرار کنید تا به منبع اصلی برسید. داخل هر پوشه هم شکل ساده‌تر کافی است:

du -sh *

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

• لاگ‌های IBSng در مسیر /var/log/IBSng؛ فایل ibs_error.log روی سرورهای پرترافیک خیلی زود بزرگ می‌شود.
• لاگ‌های سیستم و وب‌سرور در /var/log؛ روی سیستم‌های systemd ژورنال هم جای قابل‌توجهی می‌گیرد.
• دایرکتوری داده‌ی دیتابیس، معمولاً /var/lib/pgsql. این یکی را دست نزنید؛ پایین‌تر دلیلش را می‌گویم.
• بک‌آپ‌های قدیمی که کسی برای پاک شدنشان قاعده‌ای نگذاشته و در /backup یا /home تلنبار شده‌اند.
• قاعده درست این است که بک‌آپ‌ها از همین سرور بیرون بروند؛ روش‌ها در بکاپ گیری در سیستم عامل سرور و انتقال اطلاعات با rsync آمده است.
• کش بسته‌ها در /var/cache/yum یا /var/cache/dnf.
• فایل‌های موقت در /tmp و /var/tmp.

پاک‌سازی امن: لاگ را خالی کنید، حذف نکنید

دستوری که در آموزش‌های قدیمی زیاد می‌بینید این است:

rm -rf /var/log/IBSng/ibs_error.log

این کار دو ایراد دارد. اول اینکه rm -rf برای یک فایل معمولی زیادی خطرناک است و یک اشتباه تایپی می‌تواند کل پوشه را ببرد. دوم و مهم‌تر: تا وقتی پروسه‌ای آن فایل را باز نگه داشته باشد، حذفش اصلاً فضایی آزاد نمی‌کند. روش درست، خالی کردن محتوای فایل بدون حذف خودش است:

truncate -s 0 /var/log/IBSng/ibs_error.log

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

برای لاگ‌های چرخانده‌شده‌ی قدیمی اول فهرست بگیرید، بعد پاک کنید. هیچ‌وقت مستقیم با پاک‌کننده شروع نکنید:

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

اگر خروجی همانی بود که انتظار داشتید، همان دستور را با -delete در انتها دوباره اجرا کنید.

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

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

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

lsof +L1

یا:

lsof -nP | grep deleted

ستون PID را ببینید و همان سرویس را ری‌استارت کنید؛ فضا در همان لحظه برمی‌گردد. جمله‌ی «پاک کردم ولی درست نشد» تقریباً همیشه یعنی سرویس ری‌استارت نشده است. روی سروری که دیسکش محدود است، همین چند گیگابایت گیرافتاده می‌تواند تفاوت بین بالا آمدن و نیامدن سرویس باشد.

هشدار جدی: به فایل‌های دیتابیس دست نزنید

وسوسه‌انگیزترین پوشه وقتی دنبال فضا می‌گردید همان دایرکتوری داده‌ی PostgreSQL است، چون معمولاً بزرگ‌ترین است. حذف دستی فایل از داخل آن، به‌خصوص فایل‌های WAL در pg_wal (در نسخه‌های قدیمی pg_xlog)، دیتابیس را به‌شکل غیرقابل‌بازگشت خراب می‌کند؛ یعنی از دست رفتن اطلاعات کاربران و صورت‌حساب‌ها. کوچک کردن دیتابیس کار خود PostgreSQL است، نه کار rm؛ اول با pg_dump بک‌آپ بگیرید و بعد سراغ ابزارهای خودش بروید. روال اختصاصی بکاپ و ریستور دیتابیس IBSng را در بک آپ و ریستور دیتابیس IBSng نوشته‌ایم. اگر دیتابیس آسیب دیده یا مطمئن نیستید، همان‌جا متوقف شوید؛ خدمات پشتیبانی و مدیریت سرور نصب، تیونینگ، بک‌آپ و ریکاوری دیتابیس‌هایی مثل PostgreSQL را هم پوشش می‌دهد.

بالا آوردن دوباره سرویس‌ها

بعد از آزاد شدن فضا، به‌جای ری‌استارت کل سرور دو سرویس را به ترتیب بالا بیاورید؛ اول دیتابیس، بعد IBSng:

systemctl start postgresql

systemctl start IBSng

و وضعیتشان را واقعاً بررسی کنید، نه اینکه فرض کنید بالا آمده‌اند:

systemctl status postgresql

دستور قدیمی service postgresql start فقط روی سیستم‌های بدون systemd مثل CentOS 6 معنای مستقل داشت؛ روی توزیع‌های امروزی در بهترین حالت به systemd فوروارد می‌شود. اگر سرویس بالا نیامد، به‌جای حدس زدن لاگ راه‌اندازی را بخوانید:

journalctl -u postgresql -n 50

یک واقعیت که بهتر است بدانید

IBSng سال‌هاست نسخه‌ی تازه‌ای نگرفته و بر پایه‌ی Python 2 نوشته شده است. به همین دلیل بیشتر نصب‌های باقی‌مانده هنوز روی نسخه‌های قدیمی CentOS اجرا می‌شوند و CentOS 6، CentOS 8 و از میانه‌ی ۲۰۲۴ حتی CentOS 7 هم دیگر به‌روزرسانی امنیتی دریافت نمی‌کنند. یعنی سروری که امروز فقط «پر شدن هارد» را نشان می‌دهد، به‌احتمال زیاد ریسک بازتری هم دارد. اگر هنوز به این سامانه وابسته‌اید، دست‌کم دسترسی شبکه‌ای‌اش را محدود کنید و بک‌آپ منظم و آزموده‌شده داشته باشید.

کاری کنید دوباره تکرار نشود

• چرخش لاگ را تنظیم کنید. برای هر لاگی که مدیریت نمی‌شود یک فایل در /etc/logrotate.d/ بسازید و پیکربندی را بدون اعمال تغییر تست کنید: logrotate -d /etc/logrotate.conf
• ژورنال systemd را محدود کنید. حجمش را با journalctl --disk-usage ببینید و در /etc/systemd/journald.conf مقدار SystemMaxUse را مشخص کنید.
• هشدار بگذارید، نه گزارش. مانیتورینگی که پیش از پر شدن کامل دیسک به شما پیام بدهد، از داشبوردی که کسی نگاهش نمی‌کند خیلی مفیدتر است.
• بک‌آپ را روی همان دیسک نگه ندارید. بک‌آپی که با پر شدن همان دیسک از دست می‌رود، بک‌آپ نیست.
• پارتیشن‌بندی و سهمیه. جدا بودن /var یا /home از ریشه باعث می‌شود پر شدن یکی، کل سیستم‌عامل را زمین نزند.

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

جمع‌بندی

شش قدم را به یاد بسپارید: df -h برای پیدا کردن پارتیشن پر، df -i برای اینود، du -x برای رسیدن به پوشه‌ی مقصر، truncate به‌جای rm برای لاگ، lsof +L1 برای فایل‌های حذف‌شده‌ی هنوز باز، و دست نزدن به دایرکتوری دیتابیس. همین ترتیب تقریباً هر «هارد پر شده»‌ای را حل می‌کند، چه IBSng روی سرور باشد چه هر سرویس دیگری. اگر بعد از پاک‌سازی باز هم جا کم آوردید، افزایش فضای دیسک در سیستم‌عامل‌های مختلف گام بعدی است.