چرا هارد سرور مجازی پر می‌شود؟ بررسی دیسک، لاگ، Docker و بک‌آپ

مرحلهٔ ۱: مشخص کنید کدام فایل‌سیستم پر است

از SSH این دو فرمان را اجرا کنید:

df -h
df -i

در خروجی اول، ستون‌های Use% و Mounted on را کنار هم بخوانید. ممکن است دیسک اصلی / پر باشد اما دیسک جداگانهٔ /data فضای آزاد داشته باشد. در خروجی دوم، مصرف inode را بررسی کنید؛ تعداد بسیار زیاد فایل‌های کوچک می‌تواند مانع ساخت فایل تازه شود، حتی وقتی چند گیگابایت فضا باقی مانده است. کاربرد گزینه‌ها در راهنمای GNU df آمده است.

افزایش حجم دیسک در پنل هم لزوماً به معنی رشد فوری پارتیشن و فایل‌سیستم داخل ماشین نیست. اگر پنل فضای جدید را نشان می‌دهد ولی df تغییری نکرده، مدیر باید چیدمان دیسک و روش توسعهٔ همان فایل‌سیستم را بررسی کند؛ فرمان یک نسخهٔ عمومی را برای هر سرور اجرا نکنید.

مرحلهٔ ۲: مسیر بزرگ را پیدا کنید

برای بررسی دیسک ریشه، این فرمان اندازهٔ مسیرهای سطح اول را نشان می‌دهد و از فایل‌سیستم‌های جدا عبور نمی‌کند:

sudo du -xhd1 / 2>/dev/null

اگر /var بزرگ بود، همان بررسی را یک سطح پایین‌تر انجام دهید:

sudo du -xhd1 /var 2>/dev/null
sudo du -xhd1 /var/log 2>/dev/null

روی سرور شلوغ، بررسی عمیق همهٔ مسیرها می‌تواند دیسک را درگیر کند؛ از مسیر بزرگ شروع کنید و مرحله‌به‌مرحله جلو بروید. مسیرهای دادهٔ برنامه را از نصب و لاگ جدا کنید. /var/lib می‌تواند پایگاه داده و دادهٔ Docker داشته باشد؛ بزرگ‌بودنش دلیل بی‌اهمیت‌بودن محتوا نیست.

مرحلهٔ ۳: حجم Journal را ببینید

برای لاگ‌های systemd:

sudo journalctl --disk-usage

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

sudo journalctl --vacuum-time=7d

این دستور لاگ‌های قدیمی را حذف می‌کند؛ برای رخدادهای لازم یا بررسی امنیتی، ابتدا نسخهٔ موردنیاز را ذخیره کنید. طبق مستندات journalctl، Vacuum روی فایل‌های آرشیوشده عمل می‌کند و اندازهٔ نمایش‌داده‌شده می‌تواند فایل فعال را هم شامل شود. بنابراین انتظار صفرشدن کل حجم را نداشته باشید. برای جلوگیری از رشد بعدی، سقف اندازه و نگهداری Journal را در تنظیمات میزبان مشخص کنید.

مرحلهٔ ۴: Docker را بدون حذف Volume بررسی کنید

اگر برنامه‌ها داخل Docker هستند:

docker system df
docker ps -a

خروجی نشان می‌دهد تصاویر، Containerها و Volumeها چه وضعیتی دارند. Volume ممکن است تنها محل دادهٔ مشتری باشد. اجرای عمومی docker system prune --volumes بدون بررسی و بک‌آپ می‌تواند اطلاعات لازم را از بین ببرد.

برای محدودکردن لاگ json-file، مدیر می‌تواند تنظیماتی مانند max-size: "10m" و max-file: "3" را با توجه به برنامه اعمال کند. راهنمای رسمی Docker تأکید می‌کند این گزینه‌ها رشته‌اند. تغییر پیش‌فرض روی Containerهای موجود خودکار اعمال نمی‌شود؛ بازسازی باید با حفظ Volume و برنامهٔ توقف انجام شود. فایل داخلی لاگ Docker را با حذف دستی بی‌بررسی مدیریت نکنید.

مرحلهٔ ۵: بک‌آپ تکراری را با نسخهٔ متفاوت اشتباه نگیرید

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

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

ارسال بک‌آپ در ساعات کم‌ترافیک می‌تواند فشار شبکه را کمتر کند، اما شب‌بودن تضمین نمی‌کند ارتباط خارجی برقرار بماند. مقصد باید پس از دریافت از نظر اندازه و هش بررسی شود و تلاش مجدد بدون ساخت بی‌پایان ZIP تازه انجام شود. نسخهٔ روی همان هارد، در خرابی هارد کمکی نمی‌کند.

مرحلهٔ ۶: اگر فضای حذف‌شده برنگشت، فایل باز را بررسی کنید

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

sudo lsof +L1

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

چطور مطمئن شویم مشکل دوباره تکرار نمی‌شود؟

بعد از اقدام، خروجی df و اندازهٔ مسیر مشکل‌دار را ثبت کنید و چند ساعت یا یک روز بعد مقایسه کنید. برای دیسک و inode هشدار بگذارید، مدت نگهداری لاگ را مشخص کنید و موفقیت دریافت بک‌آپ را پایش کنید. اگر اندازه دوباره سریع رشد می‌کند، علت تولید داده هنوز حل نشده است.

همهٔ لاگ‌ها را پاک کنم؟ خیر؛ لاگ تازه برای پیدا‌کردن علت خطا لازم است. ابتدا خطا و سیاست نگهداری را مشخص کنید.

همهٔ بک‌آپ‌های قدیمی را حذف کنم؟ فقط نسخه‌هایی که براساس سیاست و آزمون بازیابی دیگر لازم نیستند. تعداد فایل کم‌تر به‌تنهایی نشان‌دهندهٔ بک‌آپ مناسب نیست.

برای بک‌آپ سرویس صوتی، راهنمای انتقال و بک‌آپ TeamSpeak را ببینید.