वॉल्यूम: कंटेनर डेटा असल में कहाँ रहता है
नेम्ड वॉल्यूम और बाइंड माउंट में क्या फ़र्क़ है, यह सब डिस्क पर कहाँ रहता है, और कंटेनर दोबारा बनाते समय डेटाबेस कैसे न खोएँ।
23 अगस्त 2026 को अपडेट किया गया
कंटेनर डिस्पोज़ेबल होता है। उसके अंदर लिखी हर चीज़ उसके साथ गायब हो जाती है। डेटा बाहर रहना चाहिए, और इसके ठीक दो तरीके हैं: नामित वॉल्यूम और होस्ट डायरेक्टरी बाइंड माउंट।
दो तरीके और कब कौन-सा इस्तेमाल करें
services:
db:
image: postgres:17
volumes:
- db-data:/var/lib/postgresql/data # named volume
app:
image: nginx:1.27
volumes:
- ./site:/usr/share/nginx/html:ro # directory bind mount
- ./nginx.conf:/etc/nginx/nginx.conf:ro
volumes:
db-data:
नामित वॉल्यूम Docker खुद बनाता और सेव करता है, /var/lib/docker/volumes/<name>/_data में। अंदर की परमिशन इमेज अपने आप सेट कर देती है। डेटाबेस और सर्विस की अंदरूनी स्टेट इसी तरह रखी जाती है।
डायरेक्टरी बाइंड माउंट मशीन की डिस्क पर एक सामान्य पाथ होता है। इसी तरह आप कॉन्फ़िगरेशन फ़ाइलें, वेबसाइट की स्टैटिक फ़ाइलें और सर्टिफ़िकेट देते हैं: इन्हें एडिटर में एडिट करना और रिपॉज़िटरी में रखना आसान होता है।
:ro फ़्लैग माउंट को रीड-ओनली बना देता है। जहाँ भी कंटेनर को राइट एक्सेस की ज़रूरत न हो, वहाँ इसे इस्तेमाल करें — यह सस्ती सुरक्षा है।
सब कुछ असल में कहाँ सेव होता है
docker volume ls
docker volume inspect db-data
docker inspect -f '{{json .Mounts}}' <container> | python3 -m json.tool
sudo du -sh /var/lib/docker/volumes/* | sort -h | tail
डिस्क स्पेस खत्म होने पर सबसे पहले यही आख़िरी कमांड चलाएँ। ज़्यादा जानकारी: disk space।
docker compose down -vऔरdocker volume pruneवॉल्यूम हमेशा के लिए डिलीट कर देते हैं। कंटेनर बंद होने पर डेटाबेस वाला वॉल्यूम “बिना इस्तेमाल” दिखता है और क्लीनअप में आ जाता है। साफ़ करने से पहले लिस्ट देखें:docker volume ls -f dangling=true।
कॉपी करना और माइग्रेशन
डिस्पोज़ेबल कंटेनर से नामित वॉल्यूम कॉपी करना:
docker run --rm -v db-data:/from -v $(pwd):/to alpine \
tar czf /to/db-data.tar.gz -C /from .
रीस्टोर करना:
docker volume create db-data
docker run --rm -v db-data:/to -v $(pwd):/from alpine \
tar xzf /from/db-data.tar.gz -C /to
डेटाबेस के लिए यह तरीका सिर्फ़ तब ठीक है जब कंटेनर बंद हो: चलते डेटाबेस की फ़ाइल-लेवल कॉपी इनकंसिस्टेंट हो सकती है। बेहतर है कि डेटाबेस के अपने टूल्स — pg_dump, mysqldump — से डंप लें। देखें what exactly to copy।
परमिशन
बाइंड माउंट में सबसे आम गलती ओनर का मेल न खाना है। कंटेनर के अंदर प्रोसेस अपने UID से चलता है, और होस्ट पर root से बनी फ़ाइल उसके लिए पहुँच से बाहर रहती है।
docker compose exec app id
sudo chown -R 1000:1000 ./data
कई इमेज PUID/PGID वेरिएबल लेती हैं — डायरेक्टरी का ओनर बदलने से यह ज़्यादा सुविधाजनक है।
आम गलतियाँ
- डेटा कंटेनर के अंदर लिखा गया। अपडेट के दौरान आपने कंटेनर फिर से बनाया — डेटा गायब। जाँचें:
docker diff <container>दिखाएगा कि उसके फ़ाइलसिस्टम में क्या बदला; वहाँ ज़्यादा लिखावट एक चेतावनी है। - आपने इमेज के नॉन-एम्प्टी पाथ पर डायरेक्टरी बाइंड-माउंट कर दी। इमेज का कॉन्टेंट छिप जाता है, और सर्विस अपनी फ़ाइलें नहीं ढूँढ पाती।
- बाइंड माउंट में रिलेटिव पाथ। यह उस डायरेक्टरी से रिज़ॉल्व होता है जिसमें
compose.yamlहै, करंट डायरेक्टरी से नहीं। किसी और जगह से चलाने पर नई खाली डायरेक्टरी बन जाएगी। - OS रीइंस्टॉल के दौरान वॉल्यूम भूल गए। रीइंस्टॉल पूरी डिस्क मिटा देता है। कॉपी इस मशीन पर नहीं रखनी चाहिए।