Skip to content
VDS · समस्या निवारण

डिस्क स्पेस ख़त्म हो गया

डिस्क क्या खा रहा है यह जल्दी कैसे पता करें, गीगाबाइट्स सुरक्षित तरीके से कैसे खाली करें, और गड़बड़ियाँ समझें: डिलीट की गई खुली फ़ाइलें और ख़त्म हुए inodes।

23 अगस्त 2026 को अपडेट किया गया

डिस्क पूरी भर जाए तो सब कुछ एक साथ बंद हो जाता है: डेटाबेस लिखना बंद कर देता है, साइट एरर देने लगती है, journalctl काम करना मना कर देता है, और कभी-कभी SSH भी अंदर नहीं आने देता, क्योंकि सत्र लॉग में लिखने के लिए कुछ बचा ही नहीं होता। आपको तेज़ी से और सही क्रम में काम करना होगा।

जाँच करें

df -h
df -i

पहला कमांड जगह दिखाता है, दूसरा inodes। inodes भर जाने पर भी वही "No space left on device" एरर आता है, भले ही गीगाबाइट्स खाली हों: ऐसा तब होता है जब किसी डायरेक्टरी में लाखों छोटी फ़ाइलें जमा हो जाती हैं (PHP सत्र, कैश, क्यू)।

आप पैनल में /hosting/vds/m/<id> पर भी इस्तेमाल हुई जगह देख सकते हैं — "Overview" टैब पर बना रिंग। यह qemu-guest-agent की भेजी गई जानकारी से भरता है; अगर एजेंट हटा दिया गया है, तो रिंग खाली रहता है और पैनल इंस्टॉल कमांड दिखाता है।

दोषी ढूँढें

du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -15
du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -15
ncdu -x /                     # apt install ncdu, interactive
find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null

-x फ़्लैग खोज को एक ही फ़ाइलसिस्टम तक सीमित रखता है और उसे /proc तथा माउंट की गई डायरेक्टरियों में भटकने से रोकता है।

आम दोषी: /var/log के लॉग, /var/cache का पैकेज कैश, /var/lib/docker की Docker इमेज और वॉल्यूम, डेटाबेस डंप, /root और /tmp में भूली हुई आर्काइव, पुराने एप्लिकेशन रिलीज़ की फ़ाइलें।

जगह खाली करें

journalctl --vacuum-size=200M
apt clean                                   # Debian, Ubuntu
dnf clean all                               # AlmaLinux, CentOS Stream
docker system prune -af --volumes           # careful: will remove unused volumes
find /tmp -type f -mtime +7 -delete

journal को हमेशा के लिए सीमित करने के लिए /etc/systemd/journald.conf एडिट करें (SystemMaxUse=300M); जानकारी के लिए systemd journals लेख देखें। एप्लिकेशन फ़ाइलों के लिए logrotate सेट करें: रोटेशन के बिना एक अकेला app.log आसानी से दसियों गीगाबाइट तक बढ़ सकता है।

जाल: हटाई गई पर अब भी खुली फ़ाइल

आपने विशाल लॉग हटा दिया, लेकिन df वही आँकड़े दिखाता है। जब तक कोई प्रोसेस फ़ाइल खुली रखता है, जगह वापस नहीं मिलती।

lsof +L1 | head -20

सही हल यह है कि फ़ाइल रखने वाली सेवा को रीस्टार्ट करें (systemctl restart nginx), या फ़ाइल को हटाए बिना खाली कर दें:

: > /var/log/nginx/access.log

जाल: inodes खत्म

df -i
find /var/www -xdev -type d -printf '%h\n' | sort | uniq -c | sort -rn | head

ऐसी डायरेक्टरी ढूँढें जिसमें लाखों फ़ाइलें हों और उसे टुकड़ों में साफ़ करें, ताकि मशीन बंद न पड़ जाए:

find /var/lib/php/sessions -type f -mtime +2 -delete

अगर जगह बिल्कुल भी न हो

जब डिस्क 100% भरी हो और सिस्टम मुश्किल से चल रहा हो, तो पैनल के "Console" टैब से लॉगिन करें, कम से कम सौ मेगाबाइट खाली करें (journalctl --vacuum-size=50M लगभग हमेशा काम करता है), और फिर सामान्य तरीके से समस्या हल करना जारी रखें। बहुत बुरी स्थिति में rescue disk मदद करेगी: मशीन SystemRescue में बूट होती है, आपकी डिस्क /dev/sda के रूप में दिखती है, और आप उसे माउंट करके बाहर से सफ़ाई कर सकते हैं।

दोबारा ऐसा न हो, इसके लिए

  • 85% थ्रेशोल्ड पर अलर्ट — देखें Site downtime alerts।
  • सिर्फ़ सिस्टम के नहीं, सभी एप्लिकेशन लॉग रोटेट करें।
  • डेटाबेस डंप और आर्काइव को /root में रखने के बजाय तुरंत सर्वर से बाहर भेजें।
  • अगर साफ़ करने के लिए कुछ न बचा हो और आपका डेटा बढ़ता जा रहा हो, तो बड़ी डिस्क वाले टियर में जाएँ: 40, 80, 120, 160, 200 और 250 GB। सिर्फ़ अपग्रेड: डिस्क छोटी नहीं की जा सकती, और डाउनग्रेड उपलब्ध नहीं है।

/var/lib और /usr से मनमाने तरीके से फ़ाइलें न हटाएँ: डेटाबेस डेटा और सिस्टम पैकेज वहीं रहते हैं। पहले समझें कि कोई डायरेक्टरी किसकी है, और उसके बाद ही उसे साफ़ करें।