TürkiyeVPS

دستورات کاربردی در مدیریت سرور: htop، df/du، journalctl، ufw، rsync و cron

ابزارهایی که وقتی سرور کند می‌شود، دیسک پر می‌شود یا یک سرویس از کار می‌افتد، اول سراغشان می‌روید. htop، df/du، journalctl، ufw، rsync و cron را با سناریوهای واقعی توضیح می‌دهیم.

9 دقیقه مطالعه

پس از یادگیری دستورات پایه لینوکس، نوبت به سالم نگه داشتن سرور می‌رسد. کارهای روزانه یک مدیر سرور بیشتر به یافتن پاسخ چند پرسش خلاصه می‌شود: چرا سرور کند است؟ چرا دیسک پر شد؟ چرا سرویس بسته شد؟ آیا پشتیبان‌ها به طور منظم گرفته می‌شوند؟ در این مقاله شش ابزاری را که به این پرسش‌ها پاسخ می‌دهند، با سناریوهای واقعی روی Ubuntu 24.04 توضیح می‌دهیم.

htop: چرا سرور کند است؟

top در هر لینوکسی وجود دارد، اما htop بسیار خواناتر است: نوارهای رنگی، انتخاب با ماوس، مرتب‌سازی آسان و نمای درختی فرایندها را ارائه می‌دهد.

sudo apt install -y htop
htop

در بالای صفحه این موارد را می‌بینید:

  • نوارهای CPU: میزان اشغال هر هسته. اگر همه نوارها دائماً پر باشند، ممکن است پردازنده کافی نباشد.
  • Mem و Swp: مصرف RAM و فضای swap. اگر swap دائماً پر است، RAM کافی نیست و سرور با نوشتن روی دیسک کند می‌شود.
  • Load average: میانگین بار در ۱، ۵ و ۱۵ دقیقه گذشته. به طور تقریبی، مقادیری که دائماً از تعداد هسته‌ها بیشتر باشند نشان می‌دهند کارهایی در صف انتظارند.

میان‌برهای کاربردی:

کلید کاربرد
F6 یا > انتخاب معیار مرتب‌سازی (CPU%، MEM% و غیره)
F4 فیلتر بر اساس نام فرایند
F5 نمای درختی (کدام فرایند کدام را اجرا کرده است)
F9 ارسال سیگنال به فرایند انتخاب‌شده (متوقف کردن)
q خروج

نکته: ممکن است در ستون CPU% در htop مقادیر بیش از ۱۰۰٪ ببینید؛ این یعنی فرایند از بیش از یک هسته استفاده می‌کند.

برای نگاهی سریع به وضعیت لحظه‌ای RAM، free -h هم کافی است. ستون available حافظه‌ای را نشان می‌دهد که برنامه‌ها واقعاً می‌توانند استفاده کنند؛ مقدار کم در ستون free به تنهایی مشکلی نیست، زیرا لینوکس از حافظه آزاد به عنوان حافظه نهان (کش) استفاده می‌کند.

df و du: چرا دیسک پر شد؟

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

df -h

اگر پارتیشنی دارید که ستون Use% آن از ۹۰٪ گذشته است، برای یافتن اینکه چه چیزی فضا را اشغال کرده از du استفاده کنید:

sudo du -h --max-depth=1 / 2>/dev/null | sort -h

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

sudo du -h --max-depth=1 /var | sort -h
sudo du -h --max-depth=1 /var/log | sort -h

رایج‌ترین دلایل و راه‌حل‌ها:

sudo journalctl --vacuum-size=200M   # systemd günlüklerini 200 MB'a indirir
sudo apt clean                        # indirilmiş paket önbelleğini siler
docker system df                      # Docker kullanıyorsanız imaj/volume boyutları

دستور اول لاگ‌های systemd را به ۲۰۰ مگابایت کاهش می‌دهد، دومی کش بسته‌های دانلودشده را پاک می‌کند و سومی، اگر از Docker استفاده می‌کنید، اندازه ایمیج‌ها و volumeها را نشان می‌دهد.

گاهی df می‌گوید دیسک پر است، اما du آن‌قدر فایل پیدا نمی‌کند. این معمولاً ناشی از فایلی است که حذف شده اما هنوز یک فرایند آن را باز نگه داشته است. با sudo lsof +L1 می‌توانید این فایل‌ها را ببینید و با راه‌اندازی مجدد سرویس مربوط فضا را پس بگیرید. اگر دیسک پر به نظر نمی‌رسد اما نمی‌توانید فایل بسازید، مصرف inode را با df -i بررسی کنید.

journalctl: چرا سرویس از کار افتاد؟

در اوبونتو بیشتر سرویس‌ها لاگ‌های خود را در سیستم لاگ systemd می‌نویسند. journalctl این رکوردها را می‌خواند:

journalctl -u nginx                 # yalnızca nginx servisinin kayıtları
journalctl -u nginx -n 100 --no-pager   # son 100 satır
journalctl -u myapp -f              # canlı izleme (tail -f gibi)
journalctl --since "1 hour ago"     # son bir saatteki tüm kayıtlar
journalctl -p err -b                # bu açılıştan beri yalnızca hatalar
journalctl -b -1                    # bir önceki açılışın kayıtları

این دستورات به ترتیب: فقط لاگ‌های سرویس nginx، ۱۰۰ سطر آخر، پایش زنده (مانند tail -f)، همه رکوردهای یک ساعت گذشته، فقط خطاها از زمان این بوت و لاگ‌های بوت قبلی را نشان می‌دهند.

اگر سرویسی کار نمی‌کند، به ترتیب این کارها را انجام دهید: با systemctl status servis-adi وضعیتش را ببینید، سپس با journalctl -u servis-adi -n 50 آخرین پیام‌های خطا را بخوانید. سطر اول پیام خطا اغلب مشکل را مستقیماً می‌گوید: فایل گم‌شده، پورت اشغال‌شده، سطر تنظیمات نادرست و مانند آن.

Nginx و برخی پایگاه‌های داده در فایل‌های خودشان هم می‌نویسند؛ این فایل‌ها در پوشه‌هایی مانند /var/log/nginx/ قرار دارند و با tail -f دنبال می‌شوند.

اگر می‌خواهید فضایی را که لاگ‌ها اشغال می‌کنند به طور دائمی محدود کنید، سطر SystemMaxUse=500M را در فایل /etc/systemd/journald.conf اضافه کنید و sudo systemctl restart systemd-journald را اجرا کنید.

ufw: کدام پورت‌ها باز هستند؟

UFW (Uncomplicated Firewall) به شما امکان می‌دهد فایروال اوبونتو را با دستورات ساده مدیریت کنید.

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

sudo ufw allow OpenSSH          # SSH (22) portuna izin
sudo ufw allow 80,443/tcp       # web trafiği
sudo ufw enable
sudo ufw status numbered        # kuralları numaralı listeler

این دستورات به پورت SSH (۲۲) و ترافیک وب اجازه می‌دهند، فایروال را فعال می‌کنند و قوانین را با شماره فهرست می‌کنند.

سایر قوانین پرکاربرد:

sudo ufw allow from 203.0.113.10 to any port 5432   # PostgreSQL'e yalnızca bir IP erişsin
sudo ufw deny 3306/tcp                               # MySQL portunu dışarıya kapat
sudo ufw delete 3                                    # 3 numaralı kuralı sil
sudo ufw limit OpenSSH                               # çok sık bağlantı denemelerini sınırla

به ترتیب: فقط یک IP به PostgreSQL دسترسی داشته باشد، پورت MySQL به روی بیرون بسته شود، قانون شماره ۳ حذف شود و تلاش‌های اتصال بیش از حد مکرر به SSH محدود شود.

اگر پورت SSH را تغییر داده‌اید، به جای OpenSSH شماره پورت جدید را بنویسید (sudo ufw allow 2222/tcp). برای مراحل جامع‌تر مقاوم‌سازی، راهنمای امنیت سرور لینوکس ما را ببینید.

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

rsync فایل‌ها را به صورت محلی یا از طریق SSH به دستگاه دیگری کپی می‌کند. بزرگ‌ترین مزیت آن این است که فقط بخش‌های تغییرکرده را منتقل می‌کند؛ کپی دوم بسیار سریع تمام می‌شود.

rsync -avh /var/www/ /yedek/www/                        # yerel kopya
rsync -avh /var/www/ [email protected]:/yedek/www/ # başka sunucuya
rsync -avh --delete /var/www/ /yedek/www/              # kaynakta silineni hedefte de sil
rsync -avh --dry-run --delete /var/www/ /yedek/www/    # önce ne yapacağını göster

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

پارامترها: -a مجوزها، مالکیت‌ها و تاریخ‌ها را حفظ می‌کند؛ -v جزئیات را نشان می‌دهد؛ -h اندازه‌ها را خوانا می‌نویسد. با --exclude می‌توانید پوشه‌هایی را که نمی‌خواهید کنار بگذارید:

rsync -avh --exclude 'node_modules' --exclude '.cache' /srv/proje/ /yedek/proje/

به اسلش انتهایی دقت کنید: /var/www/ محتوای پوشه و /var/www خود پوشه را کپی می‌کند. هنگام استفاده از --delete این تفاوت مهم است؛ اگر مطمئن نیستید، ابتدا با --dry-run امتحان کنید.

کپی مستقیم فایل‌های پایگاه داده در حالی که سرویس در حال اجراست، ممکن است پشتیبان ناسازگار تولید کند. ابتدا با mysqldump یا pg_dump خروجی بگیرید و سپس آن فایل را با rsync منتقل کنید.

cron: زمان‌بندی کارها

cron دستورات را در فواصل مشخص به طور خودکار اجرا می‌کند. برای ویرایش فهرست کارهای کاربر خودتان:

crontab -e

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

# Her gece 03:00'te web dosyalarını yedekle
0 3 * * * rsync -a --delete /var/www/ /yedek/www/ >> /var/log/yedek.log 2>&1

# Her 15 dakikada bir betik çalıştır
*/15 * * * * /usr/local/bin/kontrol.sh

# Her pazartesi 09:30'da
30 9 * * 1 /usr/local/bin/haftalik-rapor.sh

این مثال‌ها به ترتیب: هر شب ساعت ۰۳:۰۰ از فایل‌های وب پشتیبان می‌گیرند، هر ۱۵ دقیقه یک اسکریپت را اجرا می‌کنند و هر دوشنبه ساعت ۰۹:۳۰ کاری را انجام می‌دهند.

عادت‌های خوب:

  • در دستورات از مسیر کامل استفاده کنید؛ متغیر PATH در cron کوتاه‌تر از نشست شماست.
  • خروجی را به یک فایل هدایت کنید (>> dosya.log 2>&1)، وگرنه خطاها بی‌صدا گم می‌شوند.
  • پیش از نوشتن زمان‌بندی، آن را با ابزاری مانند crontab.guru بررسی کنید.
  • کارهای موجود را با crontab -l فهرست کنید. می‌توانید با journalctl -u cron ببینید cron کار می‌کند یا نه.

به عنوان جایگزینی مدرن، می‌توان از زمان‌سنج‌های systemd (timers) هم استفاده کرد؛ لاگ‌هایشان با journalctl دیده می‌شود و می‌توانند کارهای ازدست‌رفته را جبران کنند. با این حال، برای کارهای ساده cron همچنان کاربردی‌ترین راه است.

چک‌لیست کوتاه

وقتی در سرور مشکلی پیش می‌آید، دنبال کردن این ترتیب اغلب کافی است:

  1. htop و free -h: وضعیت پردازنده و RAM
  2. df -h: میزان پر بودن دیسک
  3. systemctl status servis و journalctl -u servis: وضعیت سرویس و پیام خطا
  4. sudo ufw status: اگر مشکل دسترسی وجود دارد، قوانین فایروال

در پنل مشتری TürkiyeVPS می‌توانید مصرف منابع و ترافیک ماهانه سرور VPS خود را هم دنبال کنید؛ استفاده از آن در کنار این ابزارهای خط فرمان، یافتن منشأ مشکلات را آسان‌تر می‌کند.

سوالات متداول

تفاوت htop و top چیست؟

هر دو فرایندهای در حال اجرا و مصرف منابع را نشان می‌دهند. htop رنگی و تعاملی است: انتخاب با ماوس، مرتب‌سازی آسان، فیلتر و نمای درختی دارد. اما top در هر سیستمی از پیش نصب است.

چرا df و du نتایج متفاوتی می‌دهند؟

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

تفاوت rsync و scp چیست؟

scp فایل‌ها را هر بار از ابتدا کپی می‌کند. اما rsync فقط بخش‌های تغییرکرده را منتقل می‌کند، می‌تواند انتقال نیمه‌تمام را ادامه دهد و گزینه‌های همگام‌سازی مانند حذف و مستثنا کردن را ارائه می‌دهد. برای پشتیبان‌گیری منظم، rsync مناسب‌تر است.

کار cron من اجرا نمی‌شود؛ چگونه بررسی کنم؟

ابتدا با crontab -l مطمئن شوید کار ثبت شده است. سپس با journalctl -u cron ببینید آیا cron کار را اجرا کرده است یا نه. بیشتر مشکلات از استفاده نکردن از مسیر کامل در دستور یا نداشتن مجوز اجرا برای اسکریپت ناشی می‌شوند.