เปิดโปงไฟล์ลับที่กินพื้นที่จนเครื่องร้องขอชีวิต (พร้อมวิธีลบแบบไม่พังระบบ)
“เมื่อคืนทุกอย่างยังปกติ
เช้ามาอีกที Docker ไม่ขึ้น
n8n login ไม่ได้
WordPress 500 error
แล้วdf -hบอกว่า…
/ 100% ”
ถ้าคุณเคยเจอสถานการณ์นี้
ขอต้อนรับสู่โลกของ Server ที่โดนไฟล์ log แดกพื้นที่แบบเงียบ ๆ
บทความนี้จะพาคุณ:
- เข้าใจว่า ไฟล์อะไรคือผู้ร้าย
- ลบได้ไหม ลบแล้วพังหรือเปล่า
- ลบยังไงให้ปลอดภัย
- ตั้งระบบ auto-clean ไม่ต้องมานั่งเช็ดน้ำตาอีกรอบ
จุดเริ่มต้นของหายนะ: “พื้นที่หายไปไหนวะ?”
คำสั่งแรกที่ Dev ทุกคนกดแบบสั่นมือคือ:
df -h
แล้วคุณจะเห็นอะไรประมาณนี้:
Filesystem Size Used Avail Use%
/dev/mmcblk0p2 14G 14G 0 100% /
ข่าวร้าย: ดิสก์เต็ม
ข่าวดี: มัน ไม่ได้เกิดจาก kernel พัง
แต่เกิดจาก ไฟล์ log ที่ไม่มีใครสนใจ
ผู้ร้ายตัวจริง: ไฟล์ log (ที่โตเงียบกว่า Bitcoin)
ลองส่องดูว่าอะไรใหญ่:
sudo du -h /var/log | sort -h
แล้วคุณจะเจอรายชื่อประมาณนี้:
1.3G /var/log/journal
500M /var/log/nginx
300M /var/log/syslog
200M /var/log/kern.log
ข่าวดีมาก
ไฟล์พวกนี้ ไม่ใช่ไฟล์ระบบหลัก
มันคือ “บันทึกเหตุการณ์” เพื่อ debug เท่านั้น
เคลียร์ชัด ๆ: ไฟล์ไหนลบได้บ้าง?
ลบได้ ปลอดภัย 100%
| ไฟล์ | ลบได้ไหม | เหตุผล |
|---|---|---|
/var/log/kern.log* | ✅ | แค่ log kernel |
/var/log/syslog* | ✅ | log ระบบทั่วไป |
*.gz | ✅ | log เก่าที่บีบอัด |
access.log.9.gz | ✅ | nginx log เก่า |
error.log.1 | ✅ | ไม่กระทบเว็บ |
ไม่ควรลบ (แต่เคลียร์ได้)
| ไฟล์ | หมายเหตุ |
|---|---|
utmp | เก็บ user login |
wtmp | history การ login |
btmp | log login fail (ลบได้ถ้าจำเป็นจริง ๆ) |
วิธีลบแบบมืออาชีพ (ไม่มั่ว)
ลบ log ทั้งกองในคำสั่งเดียว
sudo rm -f /var/log/*.gz
sudo rm -f /var/log/*.[0-9]
เคลียร์ไฟล์แต่ไม่ลบ (ปลอดภัยสุด)
sudo truncate -s 0 /var/log/kern.log
sudo truncate -s 0 /var/log/syslog
sudo truncate -s 0 /var/log/nginx/access.log
คำถามยอดฮิต: “ลบ kern.log ไปแล้วเครื่องจะพังไหม?”
ไม่พัง
ไม่ต้อง reboot
ไม่กระทบ kernel
ไม่ต้องขอโทษ server
ระบบจะ:
“อ๋อ log หาย เดี๋ยวสร้างใหม่ให้”
ตัวร้ายเงียบ: systemd journal
นี่แหละตัวดูดพื้นที่เงียบสุด
ดูขนาด:
journalctl --disk-usage
เคลียร์ทันที:
sudo journalctl --vacuum-size=100M
ตั้ง auto-clean (ทำครั้งเดียว จบ!)
จำกัด journal ไม่ให้เกิน 100MB
sudo nano /etc/systemd/journald.conf
ใส่:
SystemMaxUse=100M
RuntimeMaxUse=50M
รีสตาร์ท:
sudo systemctl restart systemd-journald
ให้ logrotate ทำงานแทนคุณ
เช็กไฟล์:
cat /etc/logrotate.conf
ค่าแนะนำ:
rotate 4
weekly
compress
missingok
Docker & n8n: ตัวดูดพื้นที่ยุค AI
ถ้าคุณใช้ Docker:
docker system df
ล้างของไม่ใช้:
docker system prune -af
จำกัด log container (สำคัญมาก):
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
บทสรุป: Server ไม่เคยพังเพราะคุณโง่
มันพังเพราะ log ไม่มีใครดู
ถ้าคุณ:
- ใช้ VPS เล็ก
- ใช้ Raspberry Pi
- รัน Docker / n8n / WordPress
- หรือสาย automation ที่ log วิ่งทั้งวัน
การรู้ว่า ไฟล์ไหนลบได้
การตั้ง auto-clean
คือทักษะเอาตัวรอดของ Dev ยุคนี้