Docker Compose: Bind mount మరియు Named volume మధ్య తేడాలు

Bind mount లేదా named volume: క్లుప్త సమాధానం

Docker Compose వాల్యూమ్‌లు రెండు రకాలుగా ఉంటాయి. ఫైళ్లను ఎవరు నియంత్రిస్తారనే దానిపై ఎంపిక ఆధారపడి ఉంటుంది. మీరు స్వయంగా రాసే లేదా చదివే ఫైళ్ల కోసం (ఉదాహరణకు: config, templates, static sites) bind mount ఉపయోగించండి. అప్లికేషన్ సొంతంగా నిర్వహించే డేటా కోసం (ఉదాహరణకు: database files, search indexes, uploaded media) named volume ఉపయోగించండి. Bind mount అనేది హోస్ట్ మెషీన్‌లోని ఒక పాత్‌ను సూచిస్తుంది, దీన్ని మీరు ఏదైనా ఎడిటర్‌తో తెరవవచ్చు. Named volume అనేది Docker సృష్టించి, నిర్వహించే నిల్వ (storage), దీన్ని మీరు Docker ద్వారా మాత్రమే యాక్సెస్ చేయగలరు.

రెండూ ఒక సర్వీస్ లోపల volumes: కీ కింద కనిపిస్తాయి, అందుకే వీటి మధ్య గందరగోళం ఏర్పడుతుంది. వీటి మధ్య వ్యత్యాసం కోలన్ (:) కి ఎడమ వైపున ఉంటుంది. ఎడమ వైపు . లేదా / తో మొదలైతే అది హోస్ట్ పాత్, అంటే అది bind mount. మిగిలినవన్నీ ఒక పేరును సూచిస్తాయి, కాబట్టి అది named volume. ఆ పేరును తప్పనిసరిగా టాప్-లెవల్ volumes: బ్లాక్‌లో ప్రకటించాలి.

కంపోజ్ ఫైల్‌లో రెండు సింటాక్స్‌లు

services:
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: changeme
    volumes:
      - pgdata:/var/lib/postgresql/data
  web:
    image: nginx:1.27
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./site:/usr/share/nginx/html:ro

volumes:
  pgdata:

pgdata:/var/lib/postgresql/data అనేది ఒక నేమ్డ్ వాల్యూమ్. ./nginx.conf:/etc/nginx/nginx.conf అనేది బైండ్ మౌంట్, మరియు :ro దీనిని రీడ్-ఓన్లీగా మౌంట్ చేస్తుంది. కంటైనర్ తిరిగి రాయకూడని కాన్ఫిగరేషన్ ఫైళ్లకు ఇదే సరైన డిఫాల్ట్. టాప్-లెవల్ volumes: ఎంట్రీని మర్చిపోతే, కంపోజ్ service "db" refers to undefined volume pgdata తో ఆగిపోతుంది.

దీనిని రన్ చేసి, డాకర్ ఏమి సృష్టించిందో చూడండి:

docker compose up -d
docker volume ls

ఈ వాల్యూమ్ పేరు pgdata కాదు. దీని పేరు <project>_pgdata. ప్రాజెక్ట్ పేరు డిఫాల్ట్‌గా కంపోజ్ ఫైల్ ఉన్న డైరెక్టరీ పేరును తీసుకుంటుంది. myapp అనే డైరెక్టరీ పేరు ఉంటే, అది myapp_pgdata అవుతుంది. ఇది ముఖ్యమైనది, ఎందుకంటే డైరెక్టరీ పేరు మార్చితే మీకు కొత్త ఖాళీ వాల్యూమ్ వస్తుంది, అప్పుడు అప్లికేషన్ తన డేటాను కోల్పోయినట్లు కనిపిస్తుంది. నిజానికి డేటా పోలేదు: పాత వాల్యూమ్ ఇప్పటికీ docker volume ls ద్వారా కనిపిస్తుంది. డైరెక్టరీ మారే అవకాశం ఉంటే, కంపోజ్ ఫైల్‌లో name: తో పేరును స్థిరపరచండి లేదా COMPOSE_PROJECT_NAME ని సెట్ చేయండి. ఇటువంటి సెట్టింగ్‌లు మీ ఇతర కంపోజ్ ఎన్విరాన్మెంట్ ఫైల్స్ మరియు సీక్రెట్స్ తో పాటు ఉండాలి.

బైండ్ మౌంట్‌లకు మాత్రమే అనుమతి లోపాలు ఎందుకు వస్తాయి

ఇది ఆచరణాత్మకంగా అతిపెద్ద వ్యత్యాసం. ఇది ఒక నియమంపై ఆధారపడి ఉంటుంది: మొదటిసారి ఉపయోగించినప్పుడు ఖాళీగా ఉన్న నేమ్డ్ వాల్యూమ్ (named volume) ఇమేజ్ నుండి డేటాను పొందుతుంది, కానీ బైండ్ మౌంట్ (bind mount) ఎప్పటికీ అలా చేయదు.

Docker ఒక ఖాళీ నేమ్డ్ వాల్యూమ్‌ను ఇమేజ్‌లో ఇప్పటికే కంటెంట్ ఉన్న డైరెక్టరీపై మౌంట్ చేసినప్పుడు, అది ఆ కంటెంట్‌ను వాల్యూమ్‌లోకి కాపీ చేస్తుంది. ఇమేజ్ సెట్ చేసిన ఓనర్‌షిప్ మరియు మోడ్‌లను అది కలిగి ఉంటుంది. అధికారిక Postgres ఇమేజ్ /var/lib/postgresql/data తో వస్తుంది, ఇది దాని స్వంత postgres యూజర్ యాజమాన్యంలో ఉంటుంది. కాబట్టి వాల్యూమ్ కూడా అదే సంఖ్యా ఐడి (numeric id) యాజమాన్యంలోకి వస్తుంది మరియు డేటాబేస్ ప్రారంభమవుతుంది.

బైండ్ మౌంట్ దీనికి విరుద్ధంగా పనిచేస్తుంది. హోస్ట్ మెషీన్‌లో ఏది ఉంటే, కంటైనర్ అదే చూస్తుంది (యాజమాన్యంతో సహా). ఆ పాత్ (path) వద్ద ఉన్న ఇమేజ్ కంటెంట్ దాచబడుతుంది. హోస్ట్ డైరెక్టరీ లేకపోతే, Docker డెమన్ (daemon) దానిని సృష్టిస్తుంది. డెమన్ root యూజర్‌గా రన్ అవుతుంది కాబట్టి, మీకు root:root యాజమాన్యంలో ఉన్న డైరెక్టరీ వస్తుంది. అప్పుడు నాన్-రూట్ యూజర్‌గా రన్ అవుతున్న కంటైనర్ ప్రాసెస్ అందులో రాయలేదు:

PermissionError: [Errno 13] Permission denied: '/data/app.db'

దీనికి పరిష్కారం సంఖ్యలను సరిపోల్చడం. బైండ్ మౌంట్ అంతటా యాజమాన్యం అనేది పేరు ద్వారా కాకుండా, సంఖ్యా యూజర్ ఐడి (numeric user id) ద్వారా పోల్చబడుతుంది, ఎందుకంటే కంటైనర్‌కు దాని స్వంత /etc/passwd ఉంటుంది. కంటైనర్ లోపల app అని పిలువబడే యూజర్‌కు హోస్ట్ మెషీన్‌పై ఎటువంటి అర్థం ఉండదు. Uid 1000 అంటే రెండు వైపులా Uid 1000 అని అర్థం.

id -u
mkdir -p ./data
docker compose exec web id
sudo chown -R 1000:1000 ./data

docker compose exec web id కంటైనర్ ప్రాసెస్ వాస్తవానికి ఏ uid తో రన్ అవుతుందో చూపిస్తుంది. హోస్ట్ డైరెక్టరీని ఆ సంఖ్యకు సరిపోల్చండి లేదా సర్వీస్‌లో user: "1000:1000" ఉపయోగించి కంటైనర్‌ను మీ సంఖ్యకు పిన్ చేయండి. మీరు స్వయంగా రాసిన అప్లికేషన్ కోసం user: ని పిన్ చేయడం సులభమైన పద్ధతి. మీరు రాయనటువంటి ఇమేజ్ కోసం హోస్ట్ డైరెక్టరీని chown చేయడం సురక్షితం, ఎందుకంటే కొన్ని ఇమేజ్‌లు ఎంట్రీ పాయింట్‌ను root గా ప్రారంభించి, ఆపై ప్రివిలేజ్‌లను తగ్గించుకుంటాయి మరియు నిర్దిష్ట యాజమాన్యాన్ని ఆశిస్తాయి.

తెలుసుకోవలసిన మరో రెండు విషయాలు ఉన్నాయి. Fedora, RHEL మరియు SELinux (security-enhanced Linux) అమలులో ఉన్న ఇతర సిస్టమ్‌లలో, బైండ్ మౌంట్ రీలేబుల్ (relabel) అయ్యే వరకు అనుమతించబడదు. కాబట్టి కంటైనర్ల మధ్య షేర్ చేయబడిన పాత్ కోసం :z ని జోడించండి, లేదా ఒకే కంటైనర్ ఉపయోగించే పాత్ కోసం :Z ని జోడించండి (దీనిని - ./data:/data:Z గా రాయాలి). అలాగే, ఒక డైరెక్టరీకి బదులుగా ఒకే ఫైల్‌ను బైండ్ మౌంట్ చేసినప్పుడు, ఎడిటర్ ఫైల్‌ను నేరుగా ఎడిట్ చేయకుండా రీప్లేస్ చేస్తే మౌంట్ విఫలమవుతుంది, ఎందుకంటే మౌంట్ అసలు ఇనోడ్ (inode) ను అనుసరిస్తుంది. మీరు కంటైనర్‌ను రీస్టార్ట్ చేసే వరకు అది పాత కంటెంట్‌నే చూపిస్తుంది. ఫైల్‌ను తరచుగా ఎడిట్ చేస్తుంటే, దాని పేరెంట్ డైరెక్టరీని మౌంట్ చేయండి.

పనితీరు: వ్యత్యాసం ఎక్కడ ఉంటుంది

Linux సర్వర్‌లో రెండు రకాలు ఒకే కెర్నల్ పాత్ ద్వారా వెళ్తాయి, కాబట్టి త్రూపుట్ (throughput) వ్యత్యాసం చాలా తక్కువగా ఉంటుంది. దీని ఆధారంగా మీరు నిర్ణయం తీసుకోనవసరం లేదు. డిఫాల్ట్ local డ్రైవర్‌ను ఉపయోగించే నేమ్డ్ వాల్యూమ్‌లు (named volumes), Docker మిగిలిన ఫైల్‌సిస్టమ్ ఉన్న చోటే, అంటే /var/lib/docker/volumes/ కింద ఉంటాయి. బైండ్ మౌంట్ (bind mount) మీరు సూచించిన చోట ఉంటుంది.

macOS మరియు Windows కోసం Docker Desktopలో ఈ వ్యత్యాసం కనిపిస్తుంది, ఎందుకంటే అక్కడ కంటైనర్లు వర్చువల్ మెషీన్ లోపల నడుస్తాయి. అక్కడ ఒక బైండ్ మౌంట్ హోస్ట్ ఫైల్‌సిస్టమ్ నుండి ఫైల్ షేరింగ్ లేయర్ ద్వారా వర్చువల్ మెషీన్‌లోకి వెళ్తుంది. Node.js డిపెండెన్సీ ట్రీ లేదా PHP ఫ్రేమ్‌వర్క్ కాష్ వంటి అనేక చిన్న ఫైల్ ఆపరేషన్లు ఉన్న వర్క్‌లోడ్‌లు గణనీయంగా నెమ్మదిస్తాయి. నేమ్డ్ వాల్యూమ్‌లు వర్చువల్ మెషీన్ లోపలే ఉంటాయి కాబట్టి ఈ భారం ఉండదు. అందుకే చాలా డెవలప్‌మెంట్ compose ఫైల్‌లు సోర్స్ డైరెక్టరీని బైండ్-మౌంట్ చేస్తాయి, కానీ node_modules పైన నేమ్డ్ వాల్యూమ్‌ను ప్రకటిస్తాయి.

మరో ముఖ్యమైన వ్యత్యాసం డేటా ఎక్కడ నిల్వ అవుతుందనేది. /mnt/backup కి బైండ్ మౌంట్ చేస్తే, డేటా ఆ డిస్క్‌లో ఉంటుంది. నేమ్డ్ వాల్యూమ్ /var/lib/docker ఉన్న ఫైల్‌సిస్టమ్‌లో ఉంటుంది, ఇది సాధారణంగా VPSలో రూట్ డిస్క్ అయి ఉంటుంది. నేమ్డ్ వాల్యూమ్ లోపల డేటాబేస్ పెరుగుతుంటే, అది మీ సిస్టమ్ లాగ్‌లు ఉన్న డిస్క్‌నే నింపేస్తుంది. సమస్యగా మారకముందే దీన్ని తనిఖీ చేయండి:

docker system df -v
df -h /var/lib/docker

docker system df -v ప్రతి వాల్యూమ్‌ను దాని పరిమాణంతో సహా జాబితా చేస్తుంది మరియు ఏ కంటైనర్ కూడా ఉపయోగించని వాల్యూమ్‌లను గుర్తిస్తుంది.

నేమ్డ్ వాల్యూమ్‌ను పరిశీలించడం

నేమ్డ్ వాల్యూమ్ అనేది ఒక బ్లాక్ బాక్స్ కాదు. అది ఎక్కడ ఉందో Dockerని అడగండి:

docker volume inspect myapp_pgdata

Mountpoint ఫీల్డ్ ఒక వాస్తవ హోస్ట్ పాత్‌ను ఇస్తుంది, సాధారణంగా ఇది /var/lib/docker/volumes/myapp_pgdata/_data గా ఉంటుంది. మీరు దీన్ని sudo ls తో చదవవచ్చు, ఇది త్వరిత తనిఖీకి ఉపయోగకరంగా ఉంటుంది. ఫైళ్లను సవరించడానికి దీన్ని ఒక ప్రదేశంగా పరిగణించవద్దు. rootగా అక్కడ రాయడం వల్ల పైన వివరించిన ఓనర్‌షిప్ సమస్య మళ్లీ తలెత్తుతుంది, మరియు ఈ పాత్ local డ్రైవర్‌కు సంబంధించిన ఒక వివరము మాత్రమే, ఇతర వాల్యూమ్ డ్రైవర్లలో ఇది ఉండదు.

లోపల చూడటానికి సురక్షితమైన మార్గం ఏమిటంటే, వాల్యూమ్‌ను మౌంట్ చేసే ఒక తాత్కాలిక కంటైనర్‌ను ఉపయోగించడం:

docker run --rm -v myapp_pgdata:/vol alpine ls -la /vol

ఇది ఏ డ్రైవర్‌కైనా పనిచేస్తుంది, అసలు కంటైనర్ చూసే అదే అనుమతులను ఇది చూస్తుంది, మరియు --rm కారణంగా ఇది దేనినీ వెనుక ఉంచదు.

ప్రతి రకాన్ని బ్యాకప్ చేయడం

బైండ్ మౌంట్ (bind mount) అనేది ఒక సాధారణ డైరెక్టరీ, కాబట్టి ఏదైనా ఫైల్-స్థాయి బ్యాకప్ సాధనం దీనిని ఇప్పటికే నిర్వహిస్తుంది. బ్యాకప్‌ను హోస్ట్ పాత్ (host path) వైపు మళ్లించండి, అంతే సరిపోతుంది. నేమ్డ్ వాల్యూమ్ (named volume) కోసం అదనంగా ఒక దశ అవసరం, ఎందుకంటే సాధనం దాని లోపలికి వెళ్లాల్సి ఉంటుంది. వాల్యూమ్‌ను మరియు ఒక హోస్ట్ డైరెక్టరీని ఒకే స్వల్పకాలిక కంటైనర్‌లోకి మౌంట్ చేయండి, ఆపై ఒక ఆర్కైవ్‌ను రాయండి:

docker run --rm \
  -v myapp_pgdata:/data:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/pgdata.tar.gz -C /data .

దీనిని రివర్స్ చేయడం ద్వారా, అంటే ఒక కొత్త వాల్యూమ్‌లోకి మార్చడం ద్వారా పునరుద్ధరించండి (restore):

docker volume create myapp_pgdata_restored
docker run --rm \
  -v myapp_pgdata_restored:/data \
  -v "$PWD":/backup \
  alpine tar xzf /backup/pgdata.tar.gz -C /data

tar కంటైనర్ లోపల rootగా రన్ అయినప్పుడు సంఖ్యాపరమైన యాజమాన్యాన్ని (numeric ownership) అలాగే ఉంచుతుంది, దీనివల్ల పునరుద్ధరించబడిన వాల్యూమ్ అప్లికేషన్ ద్వారా ఉపయోగించడానికి వీలుగా ఉంటుంది.

రెండు రకాలకు ఒక హెచ్చరిక వర్తిస్తుంది. డేటాబేస్ రన్ అవుతున్నప్పుడు దాని ఫైళ్లను కాపీ చేయడం వల్ల మారుతున్న డేటా యొక్క ఆర్కైవ్ వస్తుంది, ఇది పునరుద్ధరించినప్పుడు పాడైపోయే (corrupt) అవకాశం ఉంది. ముందుగా సర్వీస్‌ను ఆపండి, లేదా docker compose exec -T db pg_dump -U postgres appdb > appdb.sqlలో ఉన్నట్లుగా డేటాబేస్ యొక్క స్వంత సాధనం ద్వారా డంప్ చేయండి. ఇది ఒక సాధారణ ఫైల్‌ను సృష్టిస్తుంది, దీనిని మీరు మీ కంపోజ్ ఫైళ్లతో పాటు సాధారణ ఎన్‌క్రిప్టెడ్ restic బ్యాకప్ రొటీన్లో చేర్చుకోవచ్చు.

బైండ్ మౌంట్‌ను నేమ్డ్ వాల్యూమ్‌కు మార్చడం

ఈ ప్రక్రియ ఒక కాపీ మాత్రమే, పేరు మార్చడం కాదు, దీనికి సుమారు ఒక నిమిషం పడుతుంది.

docker compose down
docker volume create myapp_pgdata
docker run --rm \
  -v "$PWD/data":/from \
  -v myapp_pgdata:/to \
  alpine sh -c 'cp -a /from/. /to/'

cp -a యాజమాన్య హక్కులు (ownership), మోడ్‌లు మరియు టైమ్‌స్టాంపులను అలాగే ఉంచుతుంది, కాబట్టి పాత డైరెక్టరీని చదవగలిగే కంటైనర్ యూజర్ కొత్త వాల్యూమ్‌ను కూడా చదవగలరు. ఆ తర్వాత pgdata:/var/lib/postgresql/dataని ఉపయోగించేలా సర్వీస్‌ను మార్చండి, టాప్-లెవల్ volumes: బ్లాక్‌కు pgdataని జోడించండి, docker compose up -dని రన్ చేయండి, మరియు పాత డైరెక్టరీని తొలగించే ముందు అప్లికేషన్ లాగ్‌లను పరిశీలించండి. దీనికి విరుద్ధంగా చేయడానికి, /from మరియు /toలను మార్చి అదే కమాండ్‌ను ఉపయోగించండి.

పరీక్షించేటప్పుడు ఒక విషయాన్ని గుర్తుంచుకోండి. docker compose down నేమ్డ్ వాల్యూమ్‌లను ఏమీ చేయదు, కానీ docker compose down -v ప్రాజెక్ట్‌లో పేర్కొన్న ప్రతి నేమ్డ్ వాల్యూమ్‌ను తొలగిస్తుంది, దీనిని తిరిగి పొందడం సాధ్యం కాదు. బైండ్ మౌంట్ రెండింటి నుండి సురక్షితంగా ఉంటుంది, ఎందుకంటే ఆ డైరెక్టరీపై Dockerకు ఎటువంటి యాజమాన్యం ఉండదు. లైఫ్‌సైకిల్ కమాండ్‌లు మీకు కొత్తగా ఉంటే, VPS కోసం Docker Compose ప్రాథమిక మార్గదర్శిని వాటి గురించి వివరిస్తుంది.

సర్వీసుల వారీగా ఎంపిక

ఫైల్‌ను ఎవరు రాస్తారో అడగండి. మీరు టెక్స్ట్ ఎడిటర్‌లో ఎడిట్ చేసి gitకి కమిట్ చేసే కాన్ఫిగరేషన్, bind mountలో ఉండాలి, దీన్ని :ro వద్ద మౌంట్ చేయాలి, ఎందుకంటే అది మీకు కనిపించాలి మరియు వెర్షన్ కంట్రోల్‌లో ఉండాలి. మీరు ఎప్పుడూ మాన్యువల్‌గా తెరవని అప్లికేషన్ స్టేట్, named volumeలో ఉండాలి, ఎందుకంటే Docker అనుమతులను సరిగ్గా సెట్ చేస్తుంది మరియు డేటా హోస్ట్ పాత్‌పై ఆధారపడి ఉండదు.

మిశ్రమ సందర్భం మీడియాకు సంబంధించినది. ఫోటో లైబ్రరీని అప్లికేషన్ రాస్తుంది, కానీ మీరు కూడా నిర్వహిస్తారు, మరియు దీనికి తరచుగా ప్రత్యేక డిస్క్ అవసరమయ్యేంత పరిమాణం ఉంటుంది. దీన్ని ఆ డిస్క్‌లోని ఒక పాత్‌కు bind mount చేయండి మరియు యాజమాన్య హక్కులను (ownership) ఒకసారి ఉద్దేశపూర్వకంగా సెట్ చేయండి. చాలా సెల్ఫ్-హోస్టెడ్ స్టాక్‌లు అనుసరించే పద్ధతి ఇదే: డేటాబేస్‌లు మరియు కాష్‌ల కోసం named volumes, కాన్ఫిగరేషన్ మరియు మీరు శ్రద్ధ వహించే పెద్ద డైరెక్టరీల కోసం bind mounts వాడటం.

FAQ

బైండ్ మౌంట్ (bind mount) మరియు నేమ్డ్ వాల్యూమ్ (named volume) మధ్య తేడా ఏమిటి?

బైండ్ మౌంట్ అనేది హోస్ట్ మెషీన్‌లోని ఒక పాత్‌ను కంటైనర్‌లోకి మ్యాప్ చేస్తుంది. దీనివల్ల రెండు వైపులా ఒకే డైరెక్టరీ కనిపిస్తుంది మరియు మీరు సాధారణ టూల్స్‌తో దానిని ఎడిట్ చేయవచ్చు. నేమ్డ్ వాల్యూమ్ అనేది Docker సృష్టించి నిర్వహించే నిల్వ (storage). దీనిని పేరుతో పిలుస్తారు మరియు టాప్-లెవల్ volumes: బ్లాక్‌లో డిక్లేర్ చేస్తారు. ఆచరణాత్మకంగా చెప్పాలంటే, యాజమాన్యం (ownership) ఆధారంగా వీటిని విభజించవచ్చు: మీరు నిర్వహించే కాన్ఫిగరేషన్ కోసం బైండ్ మౌంట్స్, అప్లికేషన్ నిర్వహించే డేటా కోసం నేమ్డ్ వాల్యూమ్స్ వాడాలి.

బైండ్ మౌంట్‌తో "permission denied" అని ఎందుకు వస్తుంది, కానీ నేమ్డ్ వాల్యూమ్‌తో ఎందుకు రాదు?

ఖాళీగా ఉన్న నేమ్డ్ వాల్యూమ్ ఇమేజ్ నుండి డేటాను పొందుతుంది, కాబట్టి అది ఇమేజ్ సెట్ చేసిన యాజమాన్య హక్కులను కలిగి ఉంటుంది మరియు కంటైనర్ యూజర్ దానిలో రాయగలరు. బైండ్ మౌంట్ హోస్ట్ డైరెక్టరీని ఉన్నది ఉన్నట్లుగా చూపిస్తుంది. ఒకవేళ ఆ డైరెక్టరీని Docker సృష్టించాల్సి వస్తే, అది root యాజమాన్యంలో ఉంటుంది. కంటైనర్ ఉపయోగిస్తున్న న్యూమరిక్ ఐడిని చూడటానికి docker compose exec <service> id రన్ చేయండి, ఆపై హోస్ట్ డైరెక్టరీకి sudo chown -R <uid>:<gid> చేయండి, లేదా సర్వీస్‌పై user: "1000:1000" సెట్ చేయండి.

డిస్క్‌పై Docker నేమ్డ్ వాల్యూమ్‌లను ఎక్కడ నిల్వ చేస్తుంది?

డిఫాల్ట్ local డ్రైవర్‌తో అవి /var/lib/docker/volumes/<volume>/_data కింద ఉంటాయి, మరియు docker volume inspect <volume> కమాండ్ ఖచ్చితమైన Mountpoint ను ప్రింట్ చేస్తుంది. ఏదైనా తనిఖీ చేయాలంటే దానిని చదవండి, కానీ కంటైనర్ ద్వారా మాత్రమే రాయండి. ఎందుకంటే హోస్ట్‌లో root యూజర్‌గా ఎడిట్ చేయడం వల్ల యాజమాన్య హక్కులు మారుతాయి, దీనిని కంటైనర్ గుర్తించలేదు.

నేమ్డ్ వాల్యూమ్‌ను బ్యాకప్ చేయడం ఎలా?

వాల్యూమ్ మరియు హోస్ట్ డైరెక్టరీ రెండింటినీ మౌంట్ చేసి, తక్కువ సమయం ఉండే ఒక కంటైనర్‌ను రన్ చేయండి. ఆపై docker run --rm -v myvol:/data:ro -v "$PWD":/backup alpine tar czf /backup/myvol.tar.gz -C /data . ఉపయోగించి ఒక దాని నుండి మరొక దానికి ఆర్కైవ్ చేయండి. డేటాబేస్ కోసం అయితే, లైవ్ ఫైళ్లను కాపీ చేసే బదులు డేటాబేస్ సొంత టూల్‌తో డంప్ చేయండి. ఎందుకంటే రైట్స్ జరుగుతున్నప్పుడు ఫైల్ కాపీ చేస్తే, అది పాడైపోయిన (corrupt) స్థితిలో రీస్టోర్ అయ్యే అవకాశం ఉంది.

docker compose down నా వాల్యూమ్‌లను తొలగిస్తుందా?

docker compose down కంటైనర్‌లను మరియు నెట్‌వర్క్‌లను తొలగిస్తుంది, కానీ నేమ్డ్ వాల్యూమ్‌లను అలాగే ఉంచుతుంది. docker compose down -v ప్రాజెక్ట్‌లో డిక్లేర్ చేసిన ప్రతి నేమ్డ్ వాల్యూమ్‌ను శాశ్వతంగా తొలగిస్తుంది. బైండ్ మౌంట్‌లను ఏ కమాండ్ కూడా తొలగించదు, ఎందుకంటే ఆ డైరెక్టరీ హోస్ట్‌కు చెందినది, Docker కు కాదు.