Docker Compose stack‌ను backup చేసి upgrade చేయడం ఎలా

Docker Compose stack backup లో ఉండాల్సిన అంశాలు

Docker Compose stack backup లో నాలుగు వేర్వేరు అంశాలు ఉండాలి. వీటిలో ఏ ఒక్కటి పోయినా app మళ్లీ ప్రారంభం కాదు: compose file, దాని పక్కనే ఉన్న .env, ప్రతి volume లోని మొత్తం కంటెంట్, అలాగే database యొక్క స్వంత client తో రాసిన database dump. Container నడుస్తున్న సమయంలో database files ను copy చేయడం backup కాదు. Upgrades సమయంలో కూడా ఇదే జాబితా వర్తిస్తుంది. అయితే ఒక నియమం అదనంగా ఉంది: pull చేయడానికి ముందు backup తీసుకోండి. Schema migrations ముందుకు మాత్రమే అమలు కావడానికి రూపొందించబడతాయి. చాలా projects వెనక్కి వెళ్లే మార్గాన్ని అందించవు.

క్రింద ఉన్న ప్రతిదీ stack ఇప్పటికే deployed అయి ఉందని, అలాగే అది running లో ఉందని docker compose ps చూపిస్తుందని భావిస్తుంది. ఉదాహరణల్లో /srv/myapp వద్ద ఉన్న project directory, అలాగే app మరియు db పేర్లతో ఉన్న services ఉపయోగించబడ్డాయి. మీ స్వంత పేర్లను ఉపయోగించండి. Commands ఉద్దేశపూర్వకంగా generic గా ఉంచబడ్డాయి. కారణం, ముఖ్యమైన భాగాలు అయిన volumes మరియు database, app ఏదైనా ఒకే విధంగా పనిచేస్తాయి.

మీ stack వాస్తవంగా ఏమి నిల్వ చేస్తుందో తెలుసుకోండి

cd /srv/myapp
docker compose ps
docker compose config --volumes
docker volume ls --filter label=com.docker.compose.project=myapp

docker compose config --volumes మీ file ప్రకటించిన named volumes యొక్క సంక్షిప్త పేర్లను చూపిస్తుంది. docker volume ls ఆ volumes diskపై వాస్తవంగా కలిగి ఉన్న పేర్లను చూపిస్తుంది. ఈ రెండు జాబితాలు వేర్వేరుగా ఉంటాయి, ఎందుకంటే Compose ముందు project name ను జోడిస్తుంది: fileలో db_data గా రాసిన volume, వాస్తవంగా myapp_db_data గా ఉంటుంది. Project name కు default విలువ directory name. అందువల్ల directory name మార్చితే stack కొత్త, ఖాళీ volumes సమూహాన్ని ఉపయోగిస్తుంది. పాత volumes మాత్రం మీ డేటాతో అక్కడే మిగిలిపోతాయి. దిగువన ఉన్న ప్రతి command కు docker volume ls నుంచి పొందిన వాస్తవ పేరు అవసరం.

Bind mounts ఏ జాబితాలోనూ కనిపించవు. Compose fileలో colon ఎడమవైపు host path ఉన్న entries అవే bind mounts: ./config:/app/config. అవి hostలోని సాధారణ directories కాబట్టి సాధారణ tools వాటిని నేరుగా యాక్సెస్ చేయగలవు. Named volumes /var/lib/docker/volumes/ కింద ఉంటాయి. వాటిలో ఒకదాని ఖచ్చితమైన path ను docker volume inspect --format '{{.Mountpoint}}' myapp_db_data చూపిస్తుంది. మీ stack ఏ రకాన్ని ఉపయోగిస్తుందో బట్టి దాన్ని copy చేసే విధానం మారుతుంది. bind mounts మరియు named volumes మధ్య తేడాలు ఈ trade-off ను పూర్తిగా వివరిస్తుంది.

ఇప్పుడు మీరు కనుగొన్న వాటిని రెండు సమూహాలుగా విభజించండి. కొన్ని volumesలో ఏదీ మళ్లీ సృష్టించలేని state ఉంటుంది: upload చేసిన files, generated keys, database, అలాగే user appలో నమోదు చేసిన ఏదైనా data. మరికొన్నింటిలో thumbnails, search indexes వంటి derived data ఉంటుంది. వీటిని app స్వయంగా మళ్లీ నిర్మిస్తుంది. రెండవ సమూహాన్ని backup చేయడం వల్ల disk space మరియు restore సమయం ఖర్చవుతాయి; దానికి ప్రతిఫలంగా ప్రయోజనం ఉండదు. Redis cache volume దీనికి స్పష్టమైన ఉదాహరణ: దాన్ని కోల్పోతే మొదటి request మాత్రమే నెమ్మదిగా పూర్తవుతుంది.

Compose file మరియు .env file ను backup చేయండి

రెండు files host పై పక్కపక్కనే ఉంటాయి. వీటిలో ఏదీ volume లో ఉండదు. .env లో database password, application secret మరియు API tokens ఉంటాయి. అందువల్ల volumes సమూహాన్ని మళ్లీ పనిచేసే app గా మార్చే ముఖ్యమైన file ఇదే. సాధారణంగా ఇది .gitignore లో కూడా పేర్కొనబడుతుంది. అంటే "నా configuration git లో ఉంది" అనే backup ప్రణాళికలో అత్యంత ముఖ్యమైన single file మినహాయించబడుతుంది. Secrets ను env file లో ఉంచడం సరైన పద్ధతి. అందువల్ల దానికి సరిపోయే బాధ్యత మీ backup పై కూడా ఉంటుంది.

sudo install -d -m 700 -o "$USER" -g "$(id -gn)" /srv/backups/myapp
cp -a compose.yaml .env /srv/backups/myapp/
chmod 600 /srv/backups/myapp/.env

Stack ఉపయోగించే ప్రతి compose file ను copy చేయండి. మొదటి file ను మాత్రమే copy చేయవద్దు. -f compose.yaml -f compose.prod.yaml తో ప్రారంభించిన stack ను అదే విధంగా తిరిగి తీసుకురావాలంటే రెండు files అవసరం. ఏ values చివరకు container కు చేరుతాయో multiple compose files ఎలా merge అవుతాయి నిర్ణయిస్తుంది.

.env ను volumes తో కలిపి చూడాల్సిన ఒక ముఖ్యమైన విషయం ఉంది. Official Postgres image ఖాళీ data directory ను initialise చేస్తున్నప్పుడు మాత్రమే POSTGRES_PASSWORD ను చదువుతుంది. తరువాత ఆ value ను మార్చినా database లోని password మారదు. గత నెల volume ను నేటి .env పక్కన restore చేస్తే app FATAL: password authentication failed for user "appuser" తో connect కావడంలో విఫలమవుతుంది. పరిశీలించినప్పుడు రెండు files సరిగ్గా కనిపించినా ఈ సమస్య ఉంటుంది. ఒకే backup లో ఒకే సమయంలో ఉన్న .env మరియు volumes ను కలిపి ఉంచండి.

దాని స్వంత client తో database ను dump చేయండి

Database server తన files కు నిరంతరం రాస్తుంది. Server నడుస్తున్న సమయంలో తీసిన tar of /var/lib/postgresql/data లో కొన్ని pages రాయడానికి ముందు స్థితిలో, మరికొన్ని రాసిన తర్వాత స్థితిలో ఉండవచ్చు. అందువల్ల archive లో ఒకదానితో ఒకటి సరిపోని వేర్వేరు క్షణాల మిశ్రమం ఉంటుంది, దాన్ని తరువాత replay చేయలేకపోవచ్చు. Dump tool ఒకే transaction లోని data ను చదువుతుంది. కాబట్టి file ఒకే consistent moment ను కలిగి ఉంటుంది. Backup ను copy నుంచి వేరు చేసేది ఇదే తేడా.

docker compose exec -T db sh -c \
  'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \
  > /srv/backups/myapp/db-$(date +%F).dump

-T ను అలాగే ఉంచండి. ఇది TTY allocation ను ఆపుతుంది. TTY అనుసంధానమై ఉంటే Docker output stream ను మీ shell కు పంపే సమయంలో మార్చుతుంది. దాంతో binary dump పాడవుతుంది. Restore విఫలమైనప్పుడు మాత్రమే ఈ సమస్య మీకు తెలుస్తుంది. Single quotes కూడా ముఖ్యమే. అవి మీ host shell $POSTGRES_USER ను expand చేయకుండా ఆపుతాయి. అందువల్ల container లోని shell దాన్ని అక్కడే expand చేస్తుంది. Compose file ఇప్పటికే అక్కడ అమర్చిన values ను అది ఉపయోగిస్తుంది. -Fc custom format ను రాస్తుంది. ఇది dump సమయంలోనే compress చేస్తుంది. తరువాత pg_restore ఉపయోగించి అందులోని objects ను ఎంపిక చేసుకోవచ్చు.

Roles మరియు వాటి passwords ఏ ఒక్క database వెలుపల కాకుండా వేరుగా నిల్వ ఉంటాయి. కాబట్టి వాటినీ dump చేయండి:

docker compose exec -T db sh -c 'pg_dumpall -U "$POSTGRES_USER" --globals-only' \
  > /srv/backups/myapp/globals.sql

తర్వాత file dump కాదా, error message కాదా అని తనిఖీ చేయండి:

ls -lh /srv/backups/myapp/
head -c 5 /srv/backups/myapp/db-$(date +%F).dump

Custom-format dump మొదటి ఐదు bytes గా PGDMP తో ప్రారంభమవుతుంది. Zero bytes పరిమాణం ఉన్న file లేదా pg_dump: తో ప్రారంభమయ్యే file అంటే command విఫలమైందని అర్థం. Command నడవకముందే shell output file ను సృష్టిస్తుంది. అందువల్ల dump విఫలమైనా సరైనదిగా కనిపించే పేరు మరియు timestamp తో file మిగిలిపోతుంది. ఇది అత్యంత సాధారణమైన silent backup failure.

MariaDB లేదా MySQL కోసం client మారుతుంది. విధానం మాత్రం అదే:

docker compose exec -T db sh -c \
  'mariadb-dump -u root -p"$MARIADB_ROOT_PASSWORD" --single-transaction --databases "$MARIADB_DATABASE"' \
  > /srv/backups/myapp/db-$(date +%F).sql

--single-transaction writers ను block చేయకుండా InnoDB tables కు consistent dump ను ఇస్తుంది. MySQL image లో command mysqldump. Variables MYSQL_ROOT_PASSWORD మరియు MYSQL_DATABASE. ప్రస్తుత MariaDB images లో mysqldump ఇప్పటికీ mariadb-dump కు compatibility name గా పనిచేస్తుంది. Command line లో ఇచ్చిన password dump నడుస్తున్నంతసేపు container యొక్క process list లో కనిపిస్తుందని గుర్తుంచుకోండి.

SQLite కు ప్రత్యేక జాగ్రత్త అవసరం. Database ఒకే file అయినప్పటికీ, ఇటీవలి transactions దాని పక్కన ఉన్న ప్రత్యేక -wal file లో ఉండవచ్చు. కాబట్టి .db ను మాత్రమే copy చేస్తే తాజా writes లేని database లభిస్తుంది. Image లో client అందుబాటులో ఉంటే, app నడుస్తున్నప్పుడే sqlite3 /data/app.db ".backup '/data/app-backup.db'" consistent copy ను రాస్తుంది. Client లేకపోతే container ను ఆపి, .db file ను దాని -wal మరియు -shm companion files తో కలిసి copy చేయండి.

మీ database stack లోపల కాకుండా host పై నడుస్తుంటే, docker compose exec prefix లేకుండా ఇదే commands వర్తిస్తాయి. తదుపరి rebuild కు ముందు Docker లో లేదా host పై database నడపడం గురించి చదవడం ఉపయోగకరం.

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

Named volume కు మీరు చేతితో సవరించాల్సిన host path ఉండదు. కాబట్టి దాన్ని తాత్కాలిక container లో mount చేసి, అక్కడి నుంచే archive చేయండి.

docker run --rm \
  -v myapp_uploads:/data:ro \
  -v /srv/backups/myapp:/backup \
  alpine:3 tar czf /backup/uploads.tar.gz -C /data .

Helper container volume ను read-onlyగా /data వద్ద, మీ backup directoryని /backup వద్ద mount చేసి, తరువాత archive ను host వైపుకు రాస్తుంది. --rm, tar ముగిసిన వెంటనే helper ను తొలగిస్తుంది. :ro ముఖ్యమైనది. తప్పుగా టైప్ చేసిన tar command source ను దెబ్బతీయకుండా ఇది నిరోధిస్తుంది. Restore సరైన స్థానంలోకి వెళ్లేలా చేసేది -C /data .. ఇది ప్రతి path ను volume root కు సంబంధించి store చేస్తుంది. దాని బదులు tar czf /backup/uploads.tar.gz /data రాస్తే ప్రతి path ముందు data/ చేరుతుంది. అప్పుడు restore సమయంలో volume లో /data/data సృష్టించబడుతుంది, కానీ app కు అది ఖాళీ directoryలా కనిపిస్తుంది. Container లో tar root గా నడిచినందున archive root కు చెందుతుంది. అది సమస్య అయితే sudo chown "$USER" /srv/backups/myapp/uploads.tar.gz నడపండి. Restored files app కు చదవలేనివిగా వస్తే, PUID మరియు PGID file ownership ను ఎలా నిర్ణయిస్తాయో చూడండి.

ప్రతి named volume కోసం దీన్ని ఒక్కసారి నడపండి. Bind mounts కు container అవసరం లేదు: host పై tar czf /srv/backups/myapp/config.tar.gz -C /srv/myapp/config . అదే పని చేస్తుంది.

ప్రతి volume కు app ను ఆపాల్సిన అవసరం ఉందో నిర్ణయించండి. App ఒక volume లోని files ను అదే సమయంలో తిరిగి రాస్తుంటే, live tar command write మధ్యలో ఉన్న file ను capture చేయవచ్చు. Files ఒక్కసారి రాసిన తరువాత కేవలం చదివే uploads directoryకి ఈ ప్రమాదం తక్కువ. ఇతర సందర్భాల్లో copy పూర్తయ్యే వరకు ఆ service ను docker compose stop app తో ఆపి, తరువాత docker compose start app నడపండి. stop containers మరియు volumes ను అలాగే ఉంచుతుంది. ఈ సందర్భంలో మీకు కావలసింది అదే. మీరు వీటిలో ఏదైనా command టైప్ చేసే ముందు down మరియు stop మధ్య తేడా స్పష్టంగా తెలుసుకోవాలి.

Database volume యొక్క tar ను database backup గా పరిగణించవద్దు. Dump నే backup. ఆపివేసిన database యొక్క volume archive వేగంగా rebuild చేయడానికి ఉపయోగపడుతుంది. అంతకుమించి దానికి ఉపయోగం లేదు.

ఆపరేషన్ల క్రమం

1. Compose files మరియు .env ను backup directory కి copy చేయండి.
2. Database ఇంకా నడుస్తున్నప్పుడే దాని dump తీసుకోండి.
3. Volumes ను అదే స్థానంలో మార్చే సందర్భంలో app container ను stop చేయండి.
4. ప్రతి named volume మరియు ప్రతి bind-mount directory ను archive చేయండి.
5. Stop చేసిన వాటిని మళ్లీ start చేసి, తరువాత docker compose ps తో నిర్ధారించండి.
6. Stack నడుపుతున్న image tags మరియు digests ను నమోదు చేయండి.
7. మొత్తం backup directory ను ఈ server వెలుపలికి copy చేయండి.

చాలామంది తరువాత చేస్తామని వదిలేది Step 7 నే.

బ్యాకప్ కాపీని సర్వర్‌ వెలుపల ఉంచండి

Stack ఉన్న అదే diskపై ఉంచిన బ్యాకప్ మీ స్వంత పొరపాట్ల నుంచి మాత్రమే రక్షిస్తుంది. ఇతర సమస్యల నుంచి రక్షించదు. ఒక volume విఫలమైనా, ఒక server తొలగించబడినా లేదా ఒక account పోయినా, రెండు copies ఒకేసారి నష్టపోతాయి. Directoryని ఈ VPSలో లేని storageకు schedule ప్రకారం పంపండి. Retention policyని అమలు చేయండి. VPS నుంచి restic backupsలో repository setup, retention flags మరియు check command వివరించబడ్డాయి. అందువల్ల వాటిని ఇక్కడ మళ్లీ వివరించాల్సిన అవసరం లేదు.

restic dumpను pipe నుంచి నేరుగా చదవగలదు. దీంతో plaintext database diskపై పూర్తిగా రాయకుండా ఉంటుంది:

docker compose exec -T db sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \
  | restic backup --stdin --stdin-filename db.dump

మీరు ఏ tool ఉపయోగించినా, scheduleను systemd timer లేదా cron jobలో ఉంచండి. Job విఫలమైనప్పుడు మీరు గమనించే చోట నివేదిక అందేలా చేయండి. Output ఎక్కడికీ వెళ్లని backup script ఆరు నెలల పాటు పనిచేయకుండా ఉన్నా ఎవరికీ తెలియకపోవచ్చు.

బ్యాకప్‌ను restore drill ద్వారా పనిచేస్తుందని నిరూపించండి

ఎవరూ restore చేయని బ్యాకప్ ఒక ఊహ మాత్రమే. దిగువ drill ను మొదటి stack పక్కనే నడుస్తున్న రెండో stack లో restore చేస్తుంది. అందువల్ల production సేవలను కొనసాగిస్తుంది. మీరు టైప్ చేసే ఏదీ production stack ను చేరదు.

దీనికి project name ఆధారం. Compose దీన్ని directory name నుంచి తీసుకుని, తాను సృష్టించే ప్రతి container మరియు volume పై అమర్చుతుంది. బ్యాకప్‌ను కొత్త directory లోకి copy చేస్తే, restored stack కు స్వయంచాలకంగా ప్రత్యేక volumes లభిస్తాయి.

sudo install -d -m 700 -o "$USER" -g "$(id -gn)" /srv/myapp-restore
cd /srv/myapp-restore
cp /srv/backups/myapp/compose.yaml /srv/backups/myapp/.env .

నడుస్తున్న stack తో published host port ఢీకొనకుండా copied compose file ను సవరించండి. 8080:8080 స్థానంలో 18080:8080 ఉపయోగించండి లేదా copied .env లో ఆ port ను సెట్ చేసే variable ను మార్చండి. తరువాత ఏదీ start చేయకుండా containers మరియు వాటి ఖాళీ volumes ను సృష్టించండి:

docker compose create
docker volume ls --filter label=com.docker.compose.project=myapp-restore

రెండో command ముందు myapp-restore_ తో production లో ఉన్నట్టే volume names ను చూపించాలి. వాటిలో డేటాను నింపి, database ను మాత్రమే ప్రారంభించి, dump ను load చేయండి:

docker run --rm -v myapp-restore_uploads:/data -v /srv/backups/myapp:/backup \
  alpine:3 tar xzf /backup/uploads.tar.gz -C /data
docker compose up -d db
docker compose exec -T db sh -c \
  'pg_restore -U "$POSTGRES_USER" -d "$POSTGRES_DB" --clean --if-exists' \
  < /srv/backups/myapp/db-2026-08-16.dump

--clean --if-exists ప్రతి object ను మళ్లీ సృష్టించే ముందు తొలగిస్తుంది. అందువల్ల restore ను మళ్లీ అమలు చేయవచ్చు. ఇప్పటికే ఆ tables ఉన్న database లో రెండోసారి అమలు చేస్తే, ఇది లేకుండా pg_restore: error: could not execute query: ERROR: relation "users" already exists తో ఆగిపోతుంది.

తరువాత మిగిలిన సేవలను ప్రారంభించి, user చేసే విధంగానే తనిఖీ చేయండి:

docker compose up -d --wait
docker compose exec -T db sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "\dt"'
docker compose logs --tail=50

docker compose up -d --wait ప్రతి service running లేదా healthy అని నివేదించే వరకు వేచి ఉంటుంది. ఏదైనా service అలా కాకపోతే non-zero తో నిష్క్రమిస్తుంది. అందువల్ల ఈ దశను script లో అమలు చేయవచ్చు. ఏదైనా service healthy కాకపోతే, docker compose ps దాని స్థితిని చూపిస్తుంది. ఆ column ఏ విలువను చదువుతుందో Compose healthchecks వివరిస్తుంది. తరువాత alternate port పై app ను తెరిచి, నిజమైన account తో log in చేయండి. ఒక record రాయండి. volume లో ఉన్న ఒక file ను తెరవండి. ఈ రెండు చర్యలే రుజువు: dump restore అయింది, volume restore అయింది, రెండూ పరస్పరం సరిపోతున్నాయి. Login page render అవుతుందని మాత్రమే నిరూపించే drill మీ data గురించి ఏమీ నిరూపించదు.

Drill విజయవంతమైన తర్వాత దాన్ని తొలగించండి:

docker compose down -v

-v సరైన flag అయ్యే ఏకైక సందర్భం ఇదే. Production directory లో అదే command మీరు రక్షించాలనుకుంటున్న volumes ను తొలగిస్తుంది.

Compose stack ను ఎలా upgrade చేయాలి

మీరు ప్రస్తుతం నడుపుతున్న version నుంచి కావలసిన version వరకు ఉన్న ప్రతి version కు సంబంధించిన release notes చదవండి. వాటిలో breaking మరియు migration అనే పదాలను search చేయండి. అనేక major versions ను దాటి నేరుగా upgrade చేయడాన్ని support చేయని projects ఈ విషయాన్ని అక్కడే తెలియజేస్తాయి. Migration అమలు కాకపోతే, schema లో కొంత భాగాన్ని మార్చిన తర్వాత మాత్రమే అది మీకు తెలియజేయవచ్చు.

ఏదైనా మార్చే ముందు ప్రస్తుతం నడుస్తున్న వివరాలను నమోదు చేయండి:

docker compose images
docker image inspect --format '{{index .RepoDigests 0}}' postgres:16.4

docker compose images ప్రస్తుతం ప్రతి service ఉపయోగిస్తున్న image మరియు tag ను చూపుతుంది. Image ను ఖచ్చితంగా గుర్తించగల ఏకైక విలువ digest. ఎందుకంటే tag ను ఎప్పుడైనా వేరే image కు మార్చవచ్చు.

పై sections లో తీసుకున్న backup ను box వెలుపల మరో స్థానానికి copy చేయండి. Patch release కు కూడా ఇదే విధంగా చేయండి. ప్రజలు ముందస్తు సిద్ధతను ఆపేసే upgrade లే తక్కువ ఖర్చుతో పూర్తయ్యేవి.

తర్వాత compose file లో version ను pin చేయండి. ఎందుకంటే latest version కాదు:

services:
  db:
    image: postgres:16.4

image: postgres:latest ఉపయోగించినప్పుడు, docker compose pull ప్రస్తుతం ఆ tag సూచిస్తున్నదేదైనా fetch చేస్తుంది. నిన్న మీరు ఏ image నడిపారో ఖచ్చితంగా గుర్తించే మార్గం ఉండదు. Pinned tag తో upgrade ఒకే line edit గా మారుతుంది. ఆ మార్పును git diff లో చదవవచ్చు, మరో edit తో reverse చేయవచ్చు. Application image కు కూడా ఇదే విధంగా pin చేయండి. Project release page నుంచి exact version తీసుకోండి.

Pull చేసి recreate చేయండి:

docker compose pull
docker compose up -d --wait

docker compose up -d file ను ప్రస్తుతం నడుస్తున్న containers తో పోల్చుతుంది. Image లేదా configuration మారిన services ను మాత్రమే recreate చేస్తుంది. Named volumes ను మార్చదు. అందువల్ల కొత్త container ఇప్పటికే ఉన్న data పై ప్రారంభమవుతుంది. ఇదే ఈ ప్రక్రియ యొక్క ఉద్దేశం. ఇదే ప్రమాదం కూడా. ఎందుకంటే కొత్త version మొదటిసారి start అయ్యేటప్పుడే సాధారణంగా schema migration నడుస్తుంది.

అది జరుగుతున్న విధానాన్ని monitor చేయండి:

docker compose ps
docker compose logs -f --tail=100 app

విఫలమైన container యొక్క docker compose ps లోని STATUS column లో Exited (1) కనిపిస్తుంది. దానికి కారణం log లోని చివరి lines లో ఉంటుంది. Migration errors అక్కడ స్పష్టంగా కనిపిస్తాయి. మిగతా చోట్ల అవి కనిపించకపోవచ్చు. Logs స్థిరపడిన తర్వాత login చేసి app ను ఒక నిమిషం ఉపయోగించండి.

docker compose pull no space left on device తో ఆగిపోతే, సాధారణ కారణం పాత image layers ఉండటమే. ఉపయోగంలో లేని Docker images ను prune చేయడం ద్వారా ఆ స్థలాన్ని తిరిగి పొందవచ్చు. Upgrade విజయవంతమైందని నిర్ధారించిన తర్వాతే pruning చేయండి. ముందుగా చేయవద్దు. వేగంగా rollback చేయడానికి ఆ పాత layers అవసరం.

అప్‌గ్రేడ్ విఫలమైనప్పుడు ఎలా rollback చేయాలి

ఇక్కడ రెండు పరిస్థితులు ఉంటాయి. వాటి కోసం అవసరమైన శ్రమ చాలా భిన్నంగా ఉంటుంది. కొత్త version schema ను మార్చకపోతే rollback ఒకే command తో పూర్తవుతుంది: compose file లో పాత tag ను తిరిగి పెట్టి docker compose up -d ను run చేయండి. Container మళ్లీ సృష్టించబడుతుంది. Volumes తమ స్థానాల్లోనే ఉంటాయి. పాత code అది రాసిన data ను చదవగలదు.

కొత్త version schema ను migrate చేసి ఉంటే పాత code దాన్ని ఇక చదవలేడు. Migrations సాధారణంగా ముందుకు అమలయ్యేలా మాత్రమే రాయబడతాయి. చాలా projects downgrade script ను అసలు విడుదల చేయవు. అందువల్ల పాత version ప్రారంభమైన వెంటనే rename చేసిన లేదా drop చేసిన column పై మొదటి query వద్ద విఫలమవుతుంది. Error సాధారణంగా ERROR: column "avatar_url" does not exist రూపంలో కనిపిస్తుంది. తిరిగి వెళ్లే మార్గం pull చేయడానికి ముందు తీసుకున్న dump మాత్రమే. పాత tag ను తిరిగి పెట్టండి. Database volume ను తొలగించండి. దాన్ని ఖాళీగా మళ్లీ సృష్టించండి. Dump ను అందులో restore చేసి ప్రారంభించండి. ఆ dump లేకపోతే తిరిగి వెళ్లే మార్గం అసలు ఉండదు. అందుకే pull కు ముందు backup తీసుకోవాలి.

Postgres major versions లో ఈ సమస్య అత్యంత తీవ్రంగా ఉంటుంది. Rollback సమయంలో కాకుండా upgrade సమయంలోనే failure సంభవించడం వల్ల ఇది చాలామందిని ఆశ్చర్యపరుస్తుంది. ప్రతి major release తో on-disk format మారుతుంది. postgres:16.4 ను postgres:17.2 గా మార్చి, docker compose up -d ను run చేస్తే కొత్త server ప్రారంభం కావడానికి నిరాకరిస్తుంది:

FATAL:  database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.2.

Image మీ కోసం pg_upgrade ను run చేయదు. Compose stack లో support చేయబడిన విధానం dump, replace, restore. పాత version ఇంకా నడుస్తున్నప్పుడు dump తీసుకోండి. docker compose down ను run చేయండి. Database volume ను తొలగించండి. కొత్త tag ను సెట్ చేయండి. ఖాళీ data directory కోసం docker compose create ను run చేయండి. Database ను ప్రారంభించండి. Dump ను restore చేయండి. తరువాత మిగతా services ను ప్రారంభించండి. కొత్త major version నిజమైన network traffic ను ఒక రోజు సరిగ్గా నిర్వహించే వరకు పాత dump ను ఉంచండి. ఒకే major version లోని minor upgrades, ఉదాహరణకు 16.4 నుంచి 16.9 కు మారడం, వీటిలో ఏదీ అవసరం చేయవు. వాటిలో format స్థిరంగా ఉంటుంది. Container సాధారణంగా ప్రారంభమవుతుంది.

VPS snapshots backup అవుతాయా?

అవి backup కు ప్రత్యామ్నాయం కాదు; backup కు తోడ్పడతాయి. రెండూ వేర్వేరు విధాలుగా విఫలమవుతాయి. Snapshot మొత్తం disk ను hypervisor స్థాయిలో copy చేస్తుంది. అందువల్ల backup చేయడం మర్చిపోయిన భాగాలతో సహా మొత్తం machine ను కొన్ని నిమిషాల్లో తిరిగి తీసుకురాగలదు. కాబట్టి ఒక నిర్దిష్ట పనికి ఇది సరైన సాధనం: upgrade వల్ల server పనిచేయడం ఆగిపోయినప్పుడు, ఇరవై నిమిషాల క్రితం ఉన్న స్థితికి దాన్ని తిరిగి తీసుకురావడం.

మిగతా పనులకు ఇది సరైన సాధనం కాదు. దీని granularity మొత్తం machine స్థాయిలో ఉంటుంది. కాబట్టి తొలగించిన ఒక table ను తిరిగి పొందాలంటే ముందుగా మొత్తం server ను ఎక్కడో restore చేసి, అందులో నుంచి ఆ table ను వెలికితీయాలి. Retention సాధారణంగా తక్కువగా ఉంటుంది. Copies సాధారణంగా server ఉన్న provider account లోనే ఉంటాయి. కాబట్టి account పోతే server తో పాటు దాని snapshots కూడా ఒకేసారి పోతాయి. అదనంగా, నడుస్తున్న machine యొక్క snapshot database write మధ్యలో ఉన్న స్థితిని capture చేయవచ్చు. అందువల్ల database మొదటిసారి ప్రారంభమైనప్పుడు crash recovery నిర్వహిస్తుంది. అప్పటికి అమలులో ఉన్న transaction ఏదైనా కోల్పోతారు.

రెండింటినీ ఉపయోగించండి. Upgrade window కోసం snapshot ఒక undo button లాంటిది. తొలగించిన account తర్వాత కూడా మిగిలేది dump copy. snapshots మరియు backups ఎలా వేరుగా ఉంటాయి ప్రతి సాధనం వాస్తవంగా ఏ failures ను కవర్ చేస్తుందో వివరిస్తుంది. అదే backup directory, stack ను కొత్త VPS కు తరలించడం ను జ్ఞాపకం ఆధారంగా మళ్లీ నిర్మించే పనిగా కాకుండా సాధారణ job గా మారుస్తుంది.

ఏం తప్పు జరుగుతుంది, మీరు ఏమి చూస్తారు

down పై volumes flag. docker compose down -v ఫైల్‌లో ప్రకటించిన named volumes ను తొలగిస్తుంది. Compose దీనిని Volume myapp_db_data Removed అనే లైన్‌తో నిర్ధారిస్తుంది. దీన్ని తిరిగి రద్దు చేయలేరు. సాధారణ docker compose down వాటిని అలాగే ఉంచుతుంది. దీర్ఘ రూపమైన docker compose down --volumes ను టైప్ చేయండి. అప్పుడు destructive flag ను పూర్తిగా టైప్ చేయాల్సి ఉంటుంది.

magic string లేని dump. pg_restore: error: did not find magic string in file header అంటే ఫైల్ archive కాదని అర్థం. సాధారణ కారణం docker compose exec పై -T లేకపోవడం. TTY అనుసంధానించి ఉంటే stream మీ shell కు వెళ్లే మార్గంలో మార్చబడుతుంది. దాంతో binary dump దెబ్బతింటుంది. -T ఉపయోగించి dump ను మళ్లీ తీసుకోండి. తరువాత మొదటి ఐదు bytes ను head -c 5 తో తనిఖీ చేయండి.

మార్పు కాని password. Restore తర్వాత FATAL: password authentication failed for user "appuser" కనిపిస్తే, .env మరియు data directory వేర్వేరు సమయాలకు చెందినవని అర్థం. ఖాళీ data directory ని సృష్టించినప్పుడు మాత్రమే image ఆ password ను సెట్ చేస్తుంది. అందువల్ల తరువాత .env ను మార్చినా database లో ఎలాంటి మార్పు ఉండదు. సరిపోలే .env ను restore చేయండి. లేదా ALTER USER ఉపయోగించి database లోపల password ను మార్చండి.

రెండవ, ఖాళీ volume. Docker అవసరమైనప్పుడు volume ను సృష్టిస్తుంది. అందువల్ల s లేకుండా docker run -v myapp_upload:/data నడిపితే, కొత్త ఖాళీ volume లోకి వ్రాసి విజయవంతమైనట్లు చూపిస్తుంది. తరువాత docker volume ls రెండు పేర్లను చూపిస్తుంది. వాటిలో ఒకదానిలో ఏ data ఉండదు. పేర్లను జ్ఞాపకం ఆధారంగా టైప్ చేయకుండా docker volume ls నుండి volume పేర్లను కాపీ చేయండి.

production వైపు restore. /srv/myapp-restore బదులుగా /srv/myapp లో restore commands నడిపితే, backup ద్వారా live data overwrite అవుతుంది. రెండు చోట్ల commands ఒకేలా కనిపిస్తాయి. ప్రతి restore command కు ముందు pwd ను తనిఖీ చేయండి. Drill ను దాని స్వంత directory లో ఉంచండి.

FAQ

docker compose down నా డేటాను తొలగిస్తుందా?

లేదు. docker compose down containers మరియు default network ను తొలగిస్తుంది. Named volumes మరియు bind mounts ను అలాగే ఉంచుతుంది. docker compose down -v మీ file లో ప్రకటించిన named volumes ను తొలగిస్తుంది. ఆ తొలగింపు శాశ్వతం. Bind mounts host directories కాబట్టి Compose వాటిని ఎప్పుడూ తొలగించదు. మిగతావన్నీ అలాగే ఉంచి, backup సమయంలో services ను మాత్రమే ఆపాలంటే docker compose stop ఉపయోగించండి.

pg_dump అమలు చేయడానికి బదులుగా Postgres data directory ని కాపీ చేయవచ్చా?

Container ఆపి ఉన్నప్పుడు మాత్రమే చేయవచ్చు. Server నడుస్తున్నప్పుడు దాని files మారుతూనే ఉంటాయి. అందువల్ల copy లో పరస్పరం సరిపోని వేర్వేరు సమయాల డేటా కలిసిపోవచ్చు. అలాంటి copy ను తర్వాత సరిగ్గా పునరుద్ధరించలేరు. File-level copy ఒక Postgres major version కు కూడా పరిమితం అవుతుంది. కాబట్టి అది వేరే version కింద ప్రారంభం కాదు. Container ను ఆపి, volume ను archive చేసి, మళ్లీ ప్రారంభించండి. అయితే ఆ ఫలితాన్ని మీ ఏకైక backup గా కాకుండా, వేగంగా rebuild చేయడానికి ఉపయోగించే మార్గంగా పరిగణించండి. Dump అనేది వేర్వేరు వాతావరణాల్లో ఉపయోగించగల copy. మీరు restore చేసేది అదే.

Compose లో Postgres ను కొత్త major version కు ఎలా upgrade చేయాలి?

Tag మార్చడం మాత్రమే సరిపోదు. కొత్త server పాత data directory పై ప్రారంభం కావడానికి నిరాకరిస్తుంది. Logs లో The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.2 కనిపిస్తుంది. పాత version ఇంకా నడుస్తున్నప్పుడు pg_dump అమలు చేయండి. తరువాత docker compose down అమలు చేయండి. Database volume ను తొలగించి, కొత్త tag ను సెట్ చేయండి. కొత్తగా ఖాళీ volume కోసం docker compose create అమలు చేయండి. Database ను ప్రారంభించి, dump ను దానిలోకి restore చేయండి. కొత్త version వాస్తవ network traffic ను నిర్వహించే వరకు పాత dump ను భద్రంగా ఉంచండి.

Backups ఎంత తరచుగా అమలు చేయాలి? వాటిని ఎంతకాలం ఉంచాలి?

మీరు మళ్లీ చేయడానికి సిద్ధంగా ఉన్న పనిమొత్తాన్ని ఆధారంగా interval నిర్ణయించండి. Personal లేదా చిన్న బృందం stack కు nightly backup సరిపోతుంది. ప్రతి upgrade కు వెంటనే ముందు ఒక అదనపు manual backup కూడా తీసుకోండి. Retention కోసం, మీరు వెంటనే గుర్తించని నష్టాన్ని కవర్ చేసేంత చరిత్రను ఉంచండి. ఉదాహరణకు, శుక్రవారం గుర్తించిన corrupted table కు గురువారం రాత్రి తీసిన copy ఉపయోగపడకపోవచ్చు. restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune ఒక సముచిత ప్రారంభ విధానం. Schedule ఏదైనా, ప్రతి quarter కు ఒకసారి దాని నుంచి restore చేయండి. మీరు అలా చేసి నిర్ధారించే వరకు, మీ వద్ద backups లేవు; files మాత్రమే ఉన్నాయి.

Backup తీసుకోవడానికి మొత్తం stack ను ఆపాలా?

సాధారణంగా అవసరం లేదు. Server నడుస్తున్నప్పుడే database dump consistent గా ఉంటుంది. కాబట్టి database కు downtime అవసరం లేదు. అసలు ప్రశ్న volumes గురించి. App files ను మాత్రమే జోడిస్తే, ఉదాహరణకు uploads directory ను, live archive సాధారణంగా సురక్షితం. App files ను అదే స్థానంలో తిరిగి రాస్తే, copy పూర్తయ్యేంతకాలం ఆ ఒక్క service ను docker compose stop app తో ఆపి, తరువాత మళ్లీ ప్రారంభించండి. Database నడుస్తూనే app ను ఆపడం సాధారణంగా ఏర్పాటు చేయగల అత్యల్ప సురక్షిత window.