VPSలో Immich బ్యాకప్ తీసుకుని restore చేయడం ఎలా

Immich backupలో తప్పనిసరిగా ఏమి ఉండాలి

Immich backupలో ఒకే సమయంలో తీసుకున్న మూడు అంశాలు ఉండాలి. UPLOAD_LOCATION కింద ఉన్న అసలు ఫైళ్లు. Postgres database యొక్క SQL dump. Stack ను వివరించే .env మరియు docker-compose.yml. Restore చేయడం అంటే Immich server ఆపి ఉన్న సమయంలో ఆ dump ను కొత్త databaseలోకి తిరిగి అమలు చేయడం. ఆ తర్వాత మాత్రమే stackలోని మిగిలిన సేవలను ప్రారంభించాలి. ఈ క్రమాన్ని తప్పితే, పూర్తి diskపై ఖాళీ timeline చూపించే పనిచేస్తున్న Immich మీకు కనిపిస్తుంది.

Immich తన stateను పరస్పరం ఏమీ తెలియని రెండు ప్రదేశాల్లో ఉంచుతుంది కాబట్టి ఈ విభజన ముఖ్యమైనది. Postgresలో ప్రతి album, ప్రతి face cluster, ప్రతి shared link, ప్రతి user account మరియు API key, అలాగే ప్రతి asset యొక్క నిల్వ path ఉంటాయి. Filesystemలో images ఉంటాయి. Database లేకుండా filesను restore చేస్తే Immichలో ఏదీ కనిపించదు. Files లేకుండా databaseను restore చేస్తే ప్రతి asset తెరిచినప్పుడు broken image కనిపిస్తుంది.

ఇక్కడి commands early August 2026లో ప్రస్తుత release అయిన Immich v3.1.0 ఆధారంగా రాశాం. Project వేగంగా releases విడుదల చేస్తుంది. Documented backup procedure ఒకటి కంటే ఎక్కువసార్లు మారింది. అందువల్ల ఏదైనా copy చేయడానికి ముందు మీరు వాస్తవంగా నడుపుతున్న versionను తనిఖీ చేయండి. Stack ఇంకా up కాకపోతే Immich install guideతో ప్రారంభించి, తర్వాత ఇక్కడికి తిరిగి రండి.

మీ paths ఏ స్థానాన్ని సూచిస్తున్నాయో తెలుసుకోండి

.env లోని రెండు variables ఈ పేజీలోని ప్రతిదాన్ని నిర్ణయిస్తాయి. UPLOAD_LOCATION అనేది Immich అన్ని media ఫైళ్లను రాసే parent directory. DB_DATA_LOCATION అనేది Postgres data directory.

ప్రామాణిక example.env, UPLOAD_LOCATION=./library ను సెట్ చేస్తుంది. ఇది గందరగోళానికి కారణమయ్యే default, ఎందుకంటే Immich దాని లోపల library అనే folder ను సృష్టిస్తుంది. మీ original files ./library/library లోకి వెళ్తాయి. బదులుగా absolute path ను సెట్ చేయండి. అప్పుడు backup script మీరు దాన్ని ఏ directory నుంచి నడిపారనే దానిపై ఎప్పుడూ ఆధారపడదు.

UPLOAD_LOCATION=/srv/immich/data
DB_DATA_LOCATION=/srv/immich/postgres
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
IMMICH_VERSION=v3.1.0

UPLOAD_LOCATION లో Immich అనేక folders ను సృష్టిస్తుంది. వాటిలో మూడు folders లో ఏ job కూడా తిరిగి నిర్మించలేని data ఉంటుంది:

• library: మీ storage template ప్రకారం అమర్చిన originals
• upload: template layout లోకి ఇంకా తరలించని originals, అలాగే ప్రస్తుతం upload అవుతున్న files
• profile: user profile pictures

library ను కోల్పోతే photo పోయినట్టే. ఏ original కు కూడా Immich ఎక్కడా రెండో copy ను ఉంచదు.

Postgres డేటా directoryని కాపీ చేయడం backup ఎందుకు కాదు

DB_DATA_LOCATION సులభమైన లక్ష్యంలా కనిపిస్తుంది. అది ఒక directory, rsync దాన్ని కాపీ చేస్తుంది, కాపీ ఎలాంటి error లేకుండా పూర్తవుతుంది. అయినప్పటికీ అది backup కాదు. దీన్ని విఫలమవుతున్నట్లు మీరు గమనించగల రెండు కారణాలు ఉన్నాయి.

మొదటి కారణం tearing. Postgres ప్రతి మార్పును ముందుగా write-ahead log (WAL) లో రాస్తుంది. తరువాత checkpoint సమయంలో దాన్ని table files కు వర్తింపజేస్తుంది. అందువల్ల ఏ క్షణంలోనైనా diskపై ఉన్న files మధ్యలో ఉన్న స్థితిలో ఉంటాయి. నాలుగు నిమిషాలు పట్టే rolling copy మొదటి fileను 02:00కి, చివరి fileను 02:04కి చదువుతుంది. ఆ రెండు files ఒకే transactionకు చెందినవి కావు. ఆ ఫలితంపై Postgresను ప్రారంభిస్తే, అది startup సమయంలో PANIC: could not locate a valid checkpoint record తో ప్రారంభించడాన్ని నిరాకరించవచ్చు. లేదా ప్రారంభమైన తరువాత దెబ్బతిన్న pageను మొదటిసారి చదివినప్పుడు invalid page in block 1234 of relation base/16384/... తో ఆగిపోవచ్చు. ఆ copy నుంచి ఈ రెండు పరిస్థితుల్లో దేనినీ పునరుద్ధరించలేరు.

మీరు ముందుగా అన్నింటినీ ఆపినప్పటికీ రెండవ కారణం అలాగే ఉంటుంది. Postgres data directory దాన్ని రాసిన ఖచ్చితమైన binariesకు అనుసంధానించబడి ఉంటుంది. Immich తన database imageను digest ద్వారా pin చేస్తుంది; ప్రస్తుతం అది ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0. అది రెండు vector-search extensions compile చేయబడిన Postgres 14. ఆ buildతో రాసిన data directory వేరే Postgres major versionలో open కాదు. వేరే extension versions కలిగిన buildలో కూడా open కాదు. మీ restore host ఆ imageను ఖచ్చితంగా పునరుత్పత్తి చేయాలి. SQL dumpకు ఈ పరిమితి లేదు. అది text రూపంలో ఉంటుంది, కాబట్టి compatible server ఏదైనా దాన్ని replay చేయగలదు.

pg_dump tearing సమస్యను పూర్తిగా నివారిస్తుంది. ఇది మొత్తం databaseను ఒకే MVCC (multi-version concurrency control) snapshotలో చదువుతుంది. అందువల్ల ఇతర writes కొనసాగుతున్నప్పటికీ, databaseను ఒకే క్షణంలో ఉన్న ఖచ్చితమైన స్థితిలో చూస్తుంది. అందుకే dump తీసుకోవడానికి Postgresను ఆపాల్సిన అవసరం ఉండదు.

బ్యాకప్‌లో చేర్చనవసరం ఉన్నవి

ఇవి మళ్లీ రూపొందించవచ్చు. కాబట్టి వీటిని వదిలేయవచ్చు:

• thumbs: preview మరియు thumbnail చిత్రాలు
• encoded-video: transcoded video
• DB_DATA_LOCATION: dump నుంచి మళ్లీ రూపొందించబడే డేటా
• model-cache Docker volume: machine learning models; అవసరమైనప్పుడు మళ్లీ download అవుతాయి

వీటిని వదిలేయడం ఒక trade-off; ఇది ఉచిత ప్రయోజనం కాదు. పెద్ద library కోసం thumbnails మరియు transcodes ను మళ్లీ రూపొందించడానికి చిన్న VPS పై గంటల CPU సమయం పట్టవచ్చు. ఆ సమయంలో timeline మొత్తం grey placeholders ను చూపిస్తుంది. వీటిని Administration > Jobs నుంచి మళ్లీ అమలు చేయవచ్చు. అక్కడ "Generate Thumbnails" మరియు "Transcode Videos" ను missing assets పై run అయ్యేలా సెట్ చేయాలి. మీ backup target లో స్థలం ఉంటే, వీటిని చేర్చి వేచి ఉండాల్సిన సమయాన్ని తప్పించండి. Storage limit కు దగ్గరగా ఉంటే, వీటిని వదిలి rebuild కోసం ప్రణాళిక రూపొందించండి. Immich library పరిమాణం నిర్ణయించడం ఈ folders, originals తో పోలిస్తే, ఎంత పెద్దవిగా పెరుగుతాయో వివరిస్తుంది.

మరో folder గురించి కూడా తెలుసుకోవాలి. UPLOAD_LOCATION/backups లో Immich స్వయంచాలకంగా రూపొందించే database dumps ఉంటాయి. ఇవి ప్రతిరోజూ 02:00 కు వ్రాయబడతాయి. చివరి 14 dumps ఉంచబడతాయి. ఈ విధానాన్ని Administration > Settings > Backup లో configure చేయవచ్చు. వీటికి అదనపు ఖర్చు ఉండదు. ఇవి నిజంగా ఉపయోగకరంగా కూడా ఉంటాయి. అయితే, ఇవి రక్షించే library ఉన్న అదే disk పై ఉంటాయి. అందువల్ల migration లోపం వచ్చినప్పుడు ఇవి సహాయపడతాయి; server పూర్తిగా పనిచేయకుండా పోయినప్పుడు మాత్రం సహాయపడవు. అయినప్పటికీ మీ స్వంత dump ను తీసుకోండి. మీరు స్వయంగా trigger చేసే dump, దానికి సంబంధించిన file snapshot తీసుకునే అదే సమయంలో రూపొందుతుంది.

డేటాబేస్ dump తీసుకోండి

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres \
  | gzip > /srv/immich/backup/immich.sql.gz

మీరు వాటిని మార్చి ఉంటే, immich మరియు postgres స్థానాల్లో మీ DB_DATABASE_NAME మరియు DB_USERNAME విలువలను ఉపయోగించండి. ప్రతి CREATE ముందు DROP ... IF EXISTS ను జోడించడానికి --clean --if-exists ఉపయోగిస్తుంది. అందువల్ల dump ఇప్పటికే objects ఉన్న database లోకి replay అవుతుంది; మొదటి object వద్ద ఆగిపోదు.

ఇప్పుడు backup scripts ను నిశ్శబ్దంగా పాడుచేసే ముఖ్యమైన విషయం. ఆ command ఒక pipeline. Pipeline లోని చివరి command యొక్క exit status ను shell report చేస్తుంది. తప్పు password ఇచ్చినప్పుడు లేదా container నడుస్తూ లేనప్పుడు pg_dump విఫలమైతే, gzip కు ఖాళీ stream అందుతుంది. అది చెల్లుబాటు అయ్యే gzip file ను రాసి, 0 exit code తో ముగుస్తుంది. మీ script విజయాన్ని log చేస్తుంది, కానీ మీ వద్ద 20-byte backup మాత్రమే ఉంటుంది. ప్రతి backup script ప్రారంభంలో pipefail ఉంచండి:

#!/usr/bin/env bash
set -euo pipefail

తరువాత exit code పై ఆధారపడకుండా ఫలితాన్ని తనిఖీ చేయండి:

ls -lh /srv/immich/backup/immich.sql.gz
gunzip -c /srv/immich/backup/immich.sql.gz | head -n 3

సరైన dump లోని మొదటి line -- PostgreSQL database dump తో ప్రారంభమవుతుంది. Script ఏమి చెప్పినా, కొన్ని వందల bytes పరిమాణం ఉన్న file విఫలమైన dump.

దాన్ని రాసిన build ఏదో dump పక్కనే నమోదు చేయండి:

docker inspect --format '{{.Config.Image}}' immich_server > /srv/immich/backup/immich-version.txt

దీని కోసం .env పై ఆధారపడవద్దు. ప్రామాణిక file లో IMMICH_VERSION=v3 ఉంటుంది. ఇది ప్రతి 3.x release ను అనుసరించే మారుతూ ఉండే tag. అందువల్ల dump ను వాస్తవంగా ఏ build రాసిందో అది తెలియజేయదు. .env లో కూడా ఖచ్చితమైన tag ను pin చేయండి.

సర్వర్‌ను ఆపి, తరువాత restic తో snapshot తీసుకోండి

Immich నడుస్తున్నప్పుడు UPLOAD_LOCATION కింద ఉన్న ఫైళ్లు immutable గా ఉండవు. సర్వర్ కొత్త uploads ను రాస్తుంది. Storage template job ఫైళ్లను directories మధ్యకు తరలిస్తుంది. ఒక backup tool రాస్తున్న ఫైల్‌ను మధ్యలో చదివితే, ఆ bytes ను పూర్తి ఫైల్‌గా నిల్వ చేస్తుంది. ఈ సందర్భంలో ఎలాంటి error report కాదు. Run పూర్తయ్యేంత వరకు server container ను ఆపండి:

docker stop immich_server

immich_postgres ను నడుస్తూనే ఉంచండి. Dump కు అది అవసరం. మీరు server ను మళ్లీ start చేసే వరకు web interface మరియు mobile app offline లో ఉంటాయి. Household instance లో 03:00 సమయంలో ఇది సాధారణంగా సమస్య కాదు.

restic ఇక్కడ సరిపోతుంది. ఏదీ server నుంచి బయటకు వెళ్లే ముందు ఇది data ను deduplicate చేసి encrypt చేస్తుంది. దాన్ని ఈ server లో లేని repository కి point చేయండి:

export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/immich
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init

Object storage కూడా ఇదే విధంగా పనిచేస్తుంది. Copy పూర్తిగా మీ స్వంత hardware వెలుపల ఉండాలనుకుంటే అది మెరుగైన ఎంపిక:

export RESTIC_REPOSITORY=s3:https://s3.example.com/immich-backup
export AWS_ACCESS_KEY_ID=your-access-key
export AWS_SECRET_ACCESS_KEY=your-secret-key
restic init

ఆ endpoint రెండవ machine పై మీరు స్వయంగా నడిపే MinIO bucket కావచ్చు. లేదా ఏదైనా S3-compatible provider కావచ్చు. Library ఉన్న అదే disk పై repository ఉంచితే పొరపాటున delete చేయడాన్ని మాత్రమే ఎదుర్కోవచ్చు. ఇతర సమస్యల నుంచి రక్షణ ఉండదు.

తరువాత snapshot తీసుకోండి. అవసరమైన వాటినే ఖచ్చితంగా list చేయండి:

restic backup \
  /srv/immich/backup/immich.sql.gz \
  /srv/immich/backup/immich-version.txt \
  /srv/immich/data/library \
  /srv/immich/data/upload \
  /srv/immich/data/profile \
  /srv/immich/.env \
  /srv/immich/docker-compose.yml
docker start immich_server

restic ప్రతి run లో మొత్తం tree ను చదువుతుంది. అయితే ఇంతకుముందు చూడని blocks ను మాత్రమే upload చేస్తుంది. అందువల్ల మొదటి snapshot మీ మొత్తం library ను తరలిస్తుంది. తరువాతి ప్రతి snapshot ఆ రోజు వచ్చిన కొత్త photos ను మాత్రమే తరలిస్తుంది.

Retention, అలాగే వేరే చోట నిల్వ చేయాల్సిన keys

restic forget --prune --keep-daily 7 --keep-weekly 5 --keep-monthly 12

forget index నుంచి snapshots ను తొలగిస్తుంది. --prune, ఆ snapshots చివరి reference గా ఉన్న data ను తొలగిస్తుంది. --prune లేకుండా forget ను అమలు చేస్తే మీ storage ఖర్చు ఎప్పటికీ తగ్గదు.

Structure checks చవకగా ఉంటాయి. కాబట్టి వారానికి ఒకసారి అమలు చేయండి:

restic check

ఇది repository metadata సరిగా ఉందో లేదో నిర్ధారిస్తుంది. ఇది మీ data ను చదవదు. నెలకు ఒకసారి sample ను మళ్లీ చదివి, దాన్ని నమోదు చేసిన hashes తో సరిపోల్చండి:

restic check --read-data-subset=5%

Storage backend లో జరిగిన నిశ్శబ్ద corruption ను గుర్తించే ఏకైక check ఇదే. ఇది నిజమైన blocks ను download చేసి, వాటి checksums ను మళ్లీ లెక్కిస్తుంది. Photo library పై పూర్తి --read-data అమలు చేయడం అంటే మొత్తం repository ను download చేయడం. Metered object storage లో దీనికి వాస్తవ ఖర్చు ఉంటుంది. అందుకే rolling subset నే వాస్తవంగా ఎక్కువ మంది అమలు చేస్తారు.

ఇప్పుడు చాలామంది వదిలేసే ముఖ్యమైన విషయం. A restic repository password is not recoverable. దాన్ని reset చేయడానికి మార్గం లేదు. Support ticket తో కూడా దాన్ని తిరిగి పొందలేరు. మీరు restore చేయడానికి ప్రయత్నిస్తున్న server లోని /root/.restic-password లోనే దాని ఏకైక copy ఉంటే, మీ backups encrypted noise గా మారతాయి. Object storage access key కు, అలాగే .env నుంచి వచ్చే DB_PASSWORD కు కూడా ఇదే వర్తిస్తుంది. ఈ machine పనిచేస్తుండటంపై ఆధారపడని చోట వాటన్నింటినీ ఉంచండి: print చేసి drawer లో పెట్టండి, లేదా వేరే hardware పై నడుస్తున్న password manager లో భద్రపరచండి. ఆ manager కూడా self-hosted అయితే, దానికీ ఇదే విధానం అవసరం. Vaultwarden ను backup చేయడం ప్రత్యేకంగా చేయాల్సిన పని.

పనిచేసే క్రమంలో Immich ను పునరుద్ధరించండి

సరైన backup ఉన్నా, restore క్రమం తప్పితే timelines ఖాళీగా మారవచ్చు. కొత్త host లో ఈ క్రమాన్ని అనుసరించండి.

ముందుగా config ను తిరిగి పొందండి. ఏ version ను నడపాలో, paths ఎక్కడికి సూచిస్తున్నాయో అది తెలియజేస్తుంది.

restic restore latest --target /restore \
  --include /srv/immich/.env \
  --include /srv/immich/docker-compose.yml \
  --include /srv/immich/backup

ఏదైనా ప్రారంభమయ్యే ముందు version ను స్థిరపరచండి. immich-version.txt ను చదివి, .env లో IMMICH_VERSION ను అదే tag కు set చేయండి. ప్రస్తుతానికి తాజా release ను ఉపయోగించవద్దు. Immich downgrade కు మద్దతు ఇవ్వదు. Patch releases మధ్య కూడా downgrade చేయలేరు. కొత్త server పాత dump పై ప్రారంభమై migrations అమలు చేస్తే, తిరిగి వెనక్కి వెళ్లే మార్గం ఉండదు.

Media ను పునరుద్ధరించండి.

restic restore latest --target /restore --include /srv/immich/data

తర్వాత library, upload మరియు profile ను ఈ host లో UPLOAD_LOCATION సూచించే directory లో నేరుగా ఉండేలా తరలించండి. Host path మారవచ్చు, ఎందుకంటే compose file ఆ directory ను container లోని స్థిరమైన path కు bind చేస్తుంది. అయితే దాని లోపలి layout మారకూడదు.

Database ను ప్రత్యేకంగా ప్రారంభించండి. DB_DATA_LOCATION ను ఖాళీగా ఉంచండి, తద్వారా Postgres కొత్త cluster ను initialize చేస్తుంది.

cd /srv/immich
docker compose pull
docker compose create
docker start immich_postgres
docker exec immich_postgres pg_isready --username=postgres

మొదటిసారి setup పూర్తయిన తర్వాత pg_isready, accepting connections ను print చేస్తుంది. దీనికి కొన్ని seconds పడతాయి. docker compose create ప్రతి container ను ప్రారంభించకుండా build చేస్తుంది. ఈ దశ ఉద్దేశం అదే: Immich server ఇంకా run కాకూడదు. ఖాళీ database పై ప్రారంభమైన server migrations అమలు చేసి, కొత్త schema సృష్టించి, కొత్త admin account తయారు చేయమని అడుగుతుంది. అప్పుడు running application కింద dump ను తిరిగి అమలు చేయాల్సి వస్తుంది.

Dump ను తిరిగి అమలు చేయండి.

gunzip --stdout /restore/srv/immich/backup/immich.sql.gz \
  | sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" \
  | docker exec -i immich_postgres psql --dbname=immich --username=postgres \
      --single-transaction --set ON_ERROR_STOP=on

ఇందులోని రెండు భాగాలు ముఖ్యమైన పని చేస్తాయి. sed అవసరం, ఎందుకంటే pg_dump భద్రతా చర్యగా output లో ఖాళీ search_path ను రాస్తుంది. అందువల్ల dump లో schema పేరు లేని పేర్లు అనుకోని schema కు resolve కావు. Immich యొక్క vector-search types public లో ఉంటాయి. Search path ఖాళీగా ఉంటే, vector type తో declare చేసిన మొదటి column వద్ద restore ఆగి, psql ERROR: type "vector" does not exist తో విఫలమవుతుంది. public ను path లో తిరిగి చేరిస్తే ఈ సమస్య పరిష్కారమవుతుంది.

--single-transaction --set ON_ERROR_STOP=on మొత్తం restore ను ఒకే transaction లో అమలు చేస్తుంది. మొదటి error వచ్చిన వెంటనే అది abort అవుతుంది. ఫలితంగా మీకు పూర్తి database లేదా మార్పులేని database మాత్రమే లభిస్తుంది. ఇది లేకపోతే, మధ్యలో జరిగిన failure తర్వాత database ప్రారంభమవుతుంది, మీ login ను అంగీకరిస్తుంది, కానీ తెలియని సంఖ్యలో albums లేకుండా ఉంటుంది. ఆ విషయం మీకు వారాల తర్వాత తెలుస్తుంది.

ఇప్పుడు అన్నింటినీ ప్రారంభించండి.

docker compose up -d
docker compose ps
docker logs -f immich_server

Immich Server is listening on వంటి startup line కనిపించే వరకు వేచి ఉండండి. తర్వాత port 2283 ను తెరిచి, మీ పాత credentials తో login చేయండి, ఎందుకంటే user accounts dump తో తిరిగి వచ్చాయి. Login page బదులుగా మొదటి admin account ను సృష్టించమని అడిగితే, database restore కాలేదు. ఆపి, psql output ను మళ్లీ చదవండి.

docker compose down -v తో ప్రారంభమయ్యే అధికారిక restore సూచనల గురించి ఒక హెచ్చరిక. -v named volumes ను తొలగిస్తుంది. ప్రామాణిక compose file లో UPLOAD_LOCATION మరియు DB_DATA_LOCATION bind mounts కాబట్టి అవి దాని వల్ల తొలగిపోవు. వాటిలో ఏదైనా named volume గా మార్చి ఉంటే, ఆ command మీ photos ను తొలగిస్తుంది. దాన్ని type చేయడానికి ముందు మీ compose file ను చదవండి.

restore తర్వాత timeline ఎందుకు ఖాళీగా ఉంది

timeline database rows ఆధారంగా రూపొందుతుంది. Photos ను మళ్లీ కనుగొనడానికి Immich boot సమయంలో upload/ ను ఎప్పుడూ పరిశీలించదు. ఎందుకంటే row లేని file కు owner, date, album ఏవీ ఉండవు. అందువల్ల files తిరిగి వచ్చినా database లేకపోవడం అత్యంత సాధారణమైన తప్పు restore. Immich ప్రారంభమై ఖాళీ schema ను సృష్టిస్తుంది. Disk మీ photos తో నిండిపోయి ఉన్నప్పటికీ, లోపల ఏమీ లేని working instance ను మీకు అందిస్తుంది. ఏదీ పోయలేదు. కానీ ఏదీ కనిపించదు కూడా. దీనికి పరిష్కారం server ఆపి, పైన చూపిన విధంగానే dump ను మళ్లీ restore చేయడం.

రెండవ పరిస్థితి అంత స్పష్టంగా కనిపించదు. Database restore అవుతుంది, timeline entries తో నిండుతుంది, కానీ ప్రతి asset open కావడంలో విఫలమవుతుంది. అంటే rows సూచిస్తున్న files ను container చూడలేకపోతోందని అర్థం. సాధారణంగా library, upload మరియు profile, ఎవరూ సరైన స్థానానికి తరలించని restic restore --target /restore తర్వాత ఒక directory level లోపలికి వెళ్లి ఉంటాయి. ఊహించకుండా container లోపల నుంచి పరిశీలించండి:

docker exec immich_server ls /data

ప్రామాణిక compose file UPLOAD_LOCATION ను /data వద్ద mount చేస్తుంది. అందువల్ల ఆ listing లో library, upload మరియు profile కనిపించాలి. ఖాళీ directory లేదా అదనంగా ఉన్న srv folder కనిపిస్తే, మీ bind mount తప్పు level ను సూచిస్తోంది. Rows మాత్రం సరైనవే.

బ్యాకప్ మరియు restore మధ్య version సరిపోలిక

Immich తరచుగా releases విడుదల చేస్తుంది. Schema కూడా వాటితో పాటు మారుతుంది. అందువల్ల dump ను సృష్టించిన server లో ఉన్న schema నే dump కలిగి ఉంటుంది.

పాత dump ను కొత్త server లో restore చేయడం సాధారణంగా పనిచేస్తుంది. ఎందుకంటే server ప్రారంభమైనప్పుడు పెండింగ్ migrations ను అమలు చేసి, schema ను తదుపరి స్థితికి తీసుకెళ్తుంది. ఈ మార్గాన్ని release sequence అంతటా పరీక్షిస్తారు. ఒకేసారి అనేక major versions దాటితే సమస్యలు వస్తాయి. Project major releases కు breaking changes ను పరిమితం చేసి, వాటిని changelog లో నమోదు చేస్తుంది.

కొత్త dump ను పాత server లో restore చేయడం అసలు పనిచేయదు. Dump లో పాత code కు తెలియని tables మరియు columns ఉంటాయి. Patch releases మధ్య కూడా downgrading కు మద్దతు లేదని Immich పేర్కొంటుంది. దీనికి ఉపయోగించగల rollback command ఏదీ లేదు.

అందువల్ల సురక్షితమైన restore విధానం సరళంగా ఉంటుంది. Dump ను సృష్టించిన exact version ను నడపండి. Dump ను తిరిగి అమలు చేయండి. Login చేసి timeline పూర్తిగా ఉందో నిర్ధారించండి. ఆ తర్వాత మాత్రమే upgrade చేయండి. ఒక్కసారి ఒక release చొప్పున upgrade చేయండి. ప్రతి upgrade తర్వాత IMMICH_VERSION ను పెంచి, docker compose pull && docker compose up -d ను అమలు చేయండి. ఇక్కడ కూడా ఒక వారం కాలం నాటి dumps ఉంచడం ఉపయోగకరం. తాజా dump విఫలమైన upgrade సమయంలో తీసుకున్నదిగా తేలితే, నిన్నటి dump repository లో ఇంకా ఉంటుంది.

ప్రతి నెల బ్యాకప్‌ను ధృవీకరించండి

మీరు ఎప్పుడూ పునరుద్ధరించని బ్యాకప్ కేవలం ఒక అంచనా మాత్రమే. నెలకు ఒకసారి దాన్ని తాత్కాలికంగా ఉపయోగించే instance లో restore చేసి, ఒక ఫోటోను పరిశీలించండి. ఈ పరీక్షకు సుమారు ఇరవై నిమిషాలు పడుతుంది. ఈ పేజీలోని మిగతా విషయాలను నిజమైన recovery plan గా మార్చేది ఇదొక్కటే.

restic snapshots
restic stats latest

snapshots లో గత రాత్రి జరిగిన run కనిపించాలి. stats latest మీ library పరిమాణానికి దగ్గరగా ఉన్న size ను చూపాలి; కొన్ని megabytes మాత్రమే ఉండకూడదు.

సాధ్యమైనంతవరకు spare host పై, scratch directory లోకి restore చేయండి:

restic restore latest --target /tmp/immich-drill

Restored set నుంచి docker-compose.yml మరియు .env ను బయటకు copy చేసి, ఆ copy లో మూడు విషయాలను మార్చండి. UPLOAD_LOCATION మరియు DB_DATA_LOCATION ను /tmp/immich-drill కింద ఉన్న directories కు point చేయండి. Web port కోసం వేరే port ను publish చేయండి: 2283:2283 బదులు 12283:2283 ఉపయోగించండి. container_name: lines ను తొలగించండి. Stock compose file లో immich_server వంటి పేర్లు hard-code అయి ఉంటాయి. అందువల్ల అదే host పై రెండో stack మొదటిదానితో conflict అవుతుంది, Docker దాన్ని create చేయడానికి నిరాకరిస్తుంది.

పైన ఇచ్చిన restore క్రమాన్ని అమలు చేయండి: ముందుగా database మాత్రమే, తరువాత dump ను replay చేయండి, ఆపై docker compose up -d. ఇప్పుడు restore సరిగ్గా జరిగిందని నిర్ధారించే నాలుగు checks చేయండి.

1. పరీక్షకు ముందు మీరు ఉపయోగించిన password తో login చేయండి. Accounts పనిచేస్తే dump restore అయిందని అర్థం.
2. Timeline తెరిచి, అత్యంత పాత నెల వరకు scroll చేయండి. మొత్తం date range లో assets కనిపిస్తే, ఇటీవలి rows మాత్రమే కాకుండా అన్ని rows తిరిగి వచ్చాయని అర్థం.
3. ఒక ఫోటోను full size లో తెరిచి, original ను download చేయండి.
4. దాన్ని మీ live library లోని అదే file తో sha256sum ఉపయోగించి compare చేయండి. Hashes సరిపోతే, restic ద్వారా జరిగిన మొత్తం round trip లో bytes సురక్షితంగా నిలిచాయని అర్థం.

తర్వాత drill directory లో docker compose down -v ఉపయోగించి ఈ పరీక్షను తొలగించి, /tmp/immich-drill ను delete చేయండి. Date ను మీరు చూసే ప్రదేశంలో నమోదు చేయండి. దీని విలువ మొత్తం వచ్చే నెల మళ్లీ ఇదే పని చేయడంలోనే ఉంది. ఏ photo server ను ఎంచుకోవాలో ఇంకా నిర్ణయించుకుంటుంటే, PhotoPrism మరియు Immich పోలిక ఈ విషయంలో రెండింటి మధ్య ఉన్న తేడాలను వివరిస్తుంది.

FAQ

Immich ను backup చేయడానికి తప్పనిసరిగా ఆపాలా?

immich_server ను ఆపి, immich_postgres ను నడుస్తూనే ఉంచండి. Database కు విరామం అవసరం లేదు, ఎందుకంటే pg_dump ఒకే MVCC snapshot లోని డేటాను చదివి, ఇతర ప్రక్రియలు ఏదైనా రాస్తున్నా ఒకే consistent instant ను చూస్తుంది. Files కారణంగానే ఆపాలి: server కొత్త uploads ను రాస్తుంది, అలాగే storage template job files ను directories మధ్య తరలిస్తుంది. అందువల్ల backup tool ఒక file write మధ్యలో చదివి, ఎలాంటి error లేకుండానే truncated copy ని నిల్వ చేయవచ్చు. Snapshot కు ముందు docker stop immich_server ను, snapshot పూర్తయిన తర్వాత docker start immich_server ను అమలు చేస్తే ఈ race తొలగిపోతుంది.

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

లేదు. Live data directory ను కొనసాగుతున్న సమయంలో copy చేస్తే వేర్వేరు files ను వేర్వేరు క్షణాల్లో చదువుతుంది. అందువల్ల ఫలితం ఒకే consistent state గా ఉండదు. Startup సమయంలో Postgres దాన్ని PANIC: could not locate a valid checkpoint record తో తిరస్కరించవచ్చు లేదా తరువాత damaged page కారణంగా విఫలమవచ్చు. అన్నీ ఆపిన తర్వాత తీసుకున్న copy కూడా నిర్దిష్ట database build కు మాత్రమే అనుకూలంగా ఉంటుంది: Immich నిర్దిష్ట vector-search extension versions కలిగిన Postgres 14 image ను pin చేస్తుంది. ఆ directory మరే ఇతరదానితోనూ open కాదు. SQL dump plain text గా ఉంటుంది, కాబట్టి ఏదైనా compatible server లోకి మళ్లీ replay చేయవచ్చు.

Restore తర్వాత నా Immich timeline ఖాళీగా ఎందుకు ఉంది?

Timeline database rows ఆధారంగా నిర్మించబడుతుంది, కానీ మీరు database లేకుండా files ను restore చేశారు. Photos ను మళ్లీ గుర్తించడానికి Immich ఎప్పుడూ upload/ ను scan చేయదు. అందువల్ల rows లేని files కనిపించవు. Photos స్వయంగా మారలేదు. Server ను ఆపి, కొత్తగా initialise చేసిన Postgres లోకి dump ను replay చేసి, ఆ తర్వాత stack ను ప్రారంభించండి. Timeline పూర్తిగా కనిపిస్తున్నా ప్రతి photo open కాకపోతే సమస్య వ్యతిరేకంగా ఉంది: library, upload మరియు profile container లోకి bind చేసిన directory లో నేరుగా లేవు. docker exec immich_server ls /data తో దాన్ని తనిఖీ చేయండి.

Backup లో ఏ Immich folders ను వదిలేయవచ్చు?

thumbs మరియు encoded-video originals నుంచి మళ్లీ రూపొందించవచ్చు. DB_DATA_LOCATION dump నుంచి మళ్లీ నిర్మించబడుతుంది. కాబట్టి వీటిలో ఏదీ backup set లో ఉండాల్సిన అవసరం లేదు. వీటిని skip చేస్తే restore తర్వాత storage ఆదా కాకుండా సమయం ఖర్చవుతుంది, ఎందుకంటే పెద్ద library కోసం previews మరియు transcodes ను మళ్లీ నిర్మించడానికి CPU పై గంటలు పడతాయి. ఈ పని missing assets పై Administration > Jobs నుంచి అమలు చేయబడుతుంది. ఎప్పుడూ skip చేయకూడనివి library, upload మరియు profile. ప్రతి original కు ఉన్న ఏకైక copy వీటిలోనే ఉంటుంది.

Immich dump ను కొత్త version లోకి restore చేయవచ్చా?

సాధారణంగా అవును, ఎందుకంటే server ప్రారంభ సమయంలో pending migrations ను అమలు చేసి schema ను ముందుకు తీసుకెళ్తుంది. వ్యతిరేక దిశలో restore విఫలమవుతుంది: patch releases మధ్య కూడా Immich downgrading కు మద్దతు ఇవ్వదు. అందువల్ల కొత్త release నుంచి తీసుకున్న dump ను పాత server లోకి load చేయలేరు. Dump ను రాసిన release కు IMMICH_VERSION ను pin చేసి restore చేయండి. Timeline పూర్తిగా ఉందని నిర్ధారించుకుని, ఆ తర్వాత upgrade చేయండి. ప్రతి dump పక్కన docker inspect --format '{{.Config.Image}}' immich_server తో version ను నమోదు చేయండి, ఎందుకంటే default IMMICH_VERSION=v3 ఒక floating tag మాత్రమే; అది మీకు ఉపయోగకరమైన version సమాచారాన్ని ఇవ్వదు.