VPS वर Immich चा बॅकअप आणि restore कसा करावा

Immich बॅकअपमध्ये काय असणे आवश्यक आहे

Immich बॅकअपमध्ये एकाच वेळी घेतलेल्या तीन गोष्टी असतात. UPLOAD_LOCATION अंतर्गत असलेल्या मूळ फाइल्स. Postgres डेटाबेसचा SQL dump. Stack चे वर्णन करणारे .env आणि docker-compose.yml. Restore करताना Immich server बंद असताना हा dump नवीन डेटाबेसमध्ये लागू करा. त्यानंतरच stack मधील उर्वरित सेवा सुरू करा. क्रम चुकीचा ठेवल्यास पूर्ण disk वर कार्यरत Immich दिसेल, पण त्याची timeline रिकामी असेल.

ही विभागणी महत्त्वाची आहे, कारण Immich आपली स्थिती एकमेकांशी संबंधित नसलेल्या दोन ठिकाणी ठेवते. Postgres मध्ये प्रत्येक album, प्रत्येक face cluster, प्रत्येक shared link, प्रत्येक user account आणि API key, तसेच प्रत्येक asset चा stored path असतो. Filesystem मध्ये प्रतिमा असतात. डेटाबेसशिवाय files restore केल्यास Immich मध्ये काहीही दिसत नाही. Files शिवाय डेटाबेस restore केल्यास प्रत्येक asset उघडताना broken image दिसते.

येथील commands Immich v3.1.0 वर आधारित आहेत. ही आवृत्ती August 2026 च्या सुरुवातीला चालू असलेली release होती. Project जलद गतीने releases करते आणि documented backup procedure मध्ये एकापेक्षा जास्त वेळा बदल झाले आहेत. त्यामुळे कोणतीही गोष्ट copy करण्यापूर्वी तुम्ही प्रत्यक्षात चालवत असलेली version तपासा. Stack अद्याप सुरू नसेल, तर Immich install guide पासून सुरुवात करा आणि नंतर येथे परत या.

पथ कोणत्या ठिकाणी निर्देश करतात हे समजून घ्या

.env मधील दोन variables या पृष्ठावरील सर्वकाही ठरवतात. UPLOAD_LOCATION ही parent directory आहे. Immich सर्व media येथे लिहिते. DB_DATA_LOCATION ही Postgres data directory आहे.

मूळ example.env मध्ये UPLOAD_LOCATION=./library सेट केलेले असते. हा default गोंधळात टाकणारा आहे, कारण Immich त्यामध्येच library नावाचे folder तयार करते. तुमचे originals ./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 आणि सध्या सुरू असलेले uploads
• profile: user profile pictures

library गमावल्यास photo नष्ट होतो. Immich कोणत्याही original ची दुसरी प्रत कुठेही ठेवत नाही.

Postgres data directory कॉपी करणे हा backup का नाही

DB_DATA_LOCATION हे सोपे लक्ष्य वाटते. ती एक directory आहे, rsync ती कॉपी करेल आणि कॉपी कोणत्याही त्रुटीशिवाय पूर्ण होईल. तरीही तो backup नाही. याची दोन कारणे प्रत्यक्षात अपयशी ठरू शकतात.

पहिले कारण म्हणजे विसंगत कॉपी. Postgres प्रत्येक बदल आधी write-ahead log (WAL) मध्ये लिहितो आणि नंतर checkpoint वेळी तो table files मध्ये लागू करतो. त्यामुळे कोणत्याही क्षणी disk वरील files लिखाणाच्या प्रक्रियेत असतात. चार मिनिटे चालणारी rolling copy 02:00 वाजता पहिली file आणि 02:04 वाजता शेवटची file वाचते. या दोन files एकाच transaction शी संबंधित नसतात. त्या कॉपीवर Postgres सुरू केल्यास तो एकतर startup वेळी PANIC: could not locate a valid checkpoint record सह सुरू होण्यास नकार देतो, किंवा सुरू झाल्यानंतर damaged page प्रथम वाचताना invalid page in block 1234 of relation base/16384/... मुळे बंद पडतो. या कॉपीवरून दोन्ही स्थिती पुनर्प्राप्त करता येत नाहीत.

सर्व काही आधी थांबवले तरी दुसरे कारण कायम राहते. Postgres data directory ही ती लिहिणाऱ्या अचूक binaries शी बांधलेली असते. Immich त्याची database image digest द्वारे निश्चित करतो; सध्या ती ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0 आहे. ती Postgres 14 असून त्यात vector-search साठी compile केलेली दोन extensions आहेत. त्या build ने लिहिलेली data directory वेगळ्या Postgres major version अंतर्गत उघडणार नाही. वेगळ्या extension versions असलेल्या build अंतर्गतही ती उघडणार नाही. Restore host वर image हुबेहूब पुनरुत्पादित करावी लागते. SQL dump ला याची पर्वा नसते. तो text असतो आणि कोणताही compatible server तो पुन्हा लागू करू शकतो.

pg_dump tearing ची समस्या थेट टाळते. ते संपूर्ण database एका MVCC (multi-version concurrency control) snapshot मध्ये वाचते. त्यामुळे इतर writes सुरू असतानाही database एका विशिष्ट क्षणी जशी होती तशीच दिसते. म्हणून dump घेण्यासाठी Postgres थांबवण्याची गरज नसते.

बॅकअपमध्ये काय वगळू शकता

या गोष्टी पुन्हा तयार करता येतात, त्यामुळे त्या वगळू शकता:

• thumbs: preview आणि thumbnail images
• encoded-video: transcoded video
• DB_DATA_LOCATION: dump मधून पुन्हा तयार केले जाते
• model-cache Docker volume: machine learning models, मागणी केल्यावर पुन्हा download करता येतात

हे वगळणे म्हणजे तडजोड आहे; त्यातून कोणताही अतिरिक्त लाभ विनामूल्य मिळत नाही. मोठ्या library साठी thumbnails आणि transcodes पुन्हा तयार करण्यास लहान VPS वर अनेक तासांचा CPU वेळ लागू शकतो. त्या काळात timeline मध्ये सतत grey placeholders दिसतात. हे पुन्हा चालवण्यासाठी Administration > Jobs मध्ये जाऊन "Generate Thumbnails" आणि "Transcode Videos" या कामांसाठी missing assets वर run होईल असे सेट करा. तुमच्या backup target मध्ये जागा असल्यास, या गोष्टी समाविष्ट करा आणि प्रतीक्षा टाळा. Storage limit जवळ आली असल्यास, त्या वगळा आणि पुन्हा तयार करण्यासाठी नियोजन करा. Immich library चा आकार ठरवणे या पृष्ठावर या folders चा आकार originals च्या तुलनेत किती वाढतो हे स्पष्ट केले आहे.

आणखी एका folder विषयी माहिती असणे उपयुक्त ठरेल. UPLOAD_LOCATION/backups मध्ये Immich चे automatic database dumps साठवले जातात. ते दररोज 02:00 वाजता लिहिले जातात आणि शेवटचे 14 dumps ठेवले जातात. हे Administration > Settings > Backup अंतर्गत configure करता येते. त्यासाठी तुमची कोणतीही अतिरिक्त जागा खर्च होत नाही आणि ते खरोखर उपयुक्त आहेत. मात्र ते ज्या library चे संरक्षण करतात त्याच disk वर साठवले जातात. त्यामुळे ते खराब migration पासून मदत करतात, पण server निकामी झाल्यास मदत करत नाहीत. तरीही स्वतःचा dump घ्या, कारण तुम्ही स्वतः सुरू केलेला 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 ठेवा. --clean --if-exists प्रत्येक CREATE च्या आधी DROP ... IF EXISTS ठेवते. त्यामुळे dump आधीपासून objects असलेल्या डेटाबेसमध्ये पुन्हा लागू होतो आणि पहिल्या object वर थांबत नाही.

आता backup scripts मध्ये शांतपणे समस्या निर्माण करणारा महत्त्वाचा मुद्दा पाहू. ती command pipeline आहे. Shell pipeline मधील शेवटच्या command चा exit status दाखवते. चुकीच्या password मुळे किंवा container चालू नसल्यामुळे pg_dump अयशस्वी झाल्यास, gzip ला रिकामा stream मिळतो, वैध gzip file लिहिली जाते आणि ती 0 status सह समाप्त होते. तुमची script यशस्वी झाल्याची नोंद करते आणि तुमच्याकडे 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 ची पहिली ओळ -- PostgreSQL database dump असते. Script ने काहीही सांगितले तरी काहीशे bytes ची file म्हणजे अयशस्वी dump आहे.

तो dump कोणत्या build ने तयार केला, याची नोंद dump च्या शेजारी करा:

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

यासाठी .env वर अवलंबून राहू नका. Stock file मध्ये IMMICH_VERSION=v3 सेट केलेले असते. हा floating tag प्रत्येक 3.x release सोबत पुढे जातो. त्यामुळे dump प्रत्यक्षात कोणत्या build ने तयार केला हे समजत नाही. .env मध्ये exact tag देखील निश्चित करा.

सर्व्हर थांबवा, त्यानंतर restic ने snapshot घ्या

Immich चालू असताना UPLOAD_LOCATION मधील फाइल्स अपरिवर्तनीय नसतात. सर्व्हर नवीन uploads लिहितो आणि storage template job फाइल्स एका directory मधून दुसऱ्या directory मध्ये हलवतो. Backup tool ने write अर्धवट असताना एखादी फाइल वाचली, तर तो त्या bytes ना पूर्ण फाइल समजून साठवतो. याबाबत कोणतीही त्रुटी कळवली जात नाही. Run पूर्ण होईपर्यंत server container थांबवा:

docker stop immich_server

immich_postgres चालू ठेवा, कारण dump साठी त्याची आवश्यकता आहे. सर्व्हर पुन्हा सुरू करेपर्यंत web interface आणि mobile app offline राहतील. घरगुती instance वर 03:00 वाजता हे सहसा स्वीकार्य असते.

restic येथे योग्य आहे, कारण कोणताही डेटा या मशीनबाहेर जाण्यापूर्वी ते deduplicate आणि encrypt करते. ते या सर्व्हरवर नसलेल्या repository कडे निर्देशित करा:

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

Object storage देखील याच प्रकारे कार्य करते. प्रत पूर्णपणे तुमच्या स्वतःच्या 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 दुसऱ्या मशीनवर स्वतः चालवलेला MinIO bucket किंवा कोणताही S3-compatible provider असू शकतो. Library ज्या disk वर आहे त्याच disk वर repository ठेवल्याने चुकीच्या delete पासून संरक्षण मिळते; इतर कोणत्याही समस्येपासून संरक्षण मिळत नाही.

यानंतर snapshot घ्या आणि महत्त्वाच्या फाइल्सच समाविष्ट आहेत याची खात्री करा:

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 transfer होते. त्यानंतरच्या प्रत्येक snapshot मध्ये त्या दिवसाचे नवीन photos transfer होतात.

Retention आणि इतरत्र ठेवाव्या लागणाऱ्या keys

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

forget index मधून snapshots काढते. --prune हा त्या snapshots साठी शेवटचा reference असलेल्या data ला delete करणारा भाग आहे. --prune शिवाय forget चालवला, तर तुमचा storage bill कधीही कमी होणार नाही.

Structure checks स्वस्त असतात, त्यामुळे ते आठवड्यातून एकदा चालवा:

restic check

यामुळे repository metadata सुसंगत आहे का ते पडताळले जाते. यात तुमचा data वाचला जात नाही. महिन्यातून एकदा sample पुन्हा वाचा आणि तो नोंदवलेल्या hashes शी तपासा:

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

Storage backend वरील silent corruption शोधणारी हीच एकमेव तपासणी आहे, कारण यात प्रत्यक्ष 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 कार्यरत क्रमाने पुनर्संचयित करा

चांगले backups असूनही timeline रिकामी होण्याचे कारण restore चा चुकीचा क्रम असतो. नवीन host वर खालील क्रम पाळा.

सर्वप्रथम configuration परत मिळवा. कोणती 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 ला तोच exact tag द्या. सध्या नवीनतम release वापरू नका. Immich downgrade ला समर्थन देत नाही, अगदी patch releases मधेदेखील नाही. त्यामुळे newer server ने older dump वर सुरू होऊन migrations चालवल्यास परत जाण्याचा कोणताही मार्ग राहत नाही.

Media restore करा.

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

त्यानंतर library, upload आणि profile या files किंवा directories नवीन host वरील UPLOAD_LOCATION ज्या ठिकाणी निर्देशित करते, त्या directory च्या थेट आत ठेवा. Host path बदलू शकतो, कारण compose file त्या directory ला container मधील fixed path वर bind करते. मात्र त्यातील layout बदलता कामा नये.

Database स्वतंत्रपणे सुरू करा. DB_DATA_LOCATION रिकामे ठेवा, म्हणजे Postgres fresh 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 करते. या step चा उद्देश हाच आहे: Immich server अद्याप चालू होता कामा नये. Empty database वर सुरू झालेला server migrations लागू करतो, fresh schema तयार करतो आणि नवीन admin account तयार करण्यास सांगतो. त्यानंतर चालू 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 मधील unqualified names अनपेक्षित schema शी resolve होऊ शकत नाहीत. Immich चे vector-search types public मध्ये असतात. त्यामुळे search path रिकामा असल्यास restore vector type असलेल्या पहिल्या column वर पोहोचते आणि 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 पुन्हा वाचा.

अधिकृत restore instructions बद्दल एक सूचना. त्या docker compose down -v ने सुरू होतात. -v named volumes काढून टाकते. Stock compose file मध्ये UPLOAD_LOCATION आणि DB_DATA_LOCATION हे bind mounts आहेत, त्यामुळे ते या command नंतरही सुरक्षित राहतात. यापैकी कोणताही named volume मध्ये बदलला असल्यास ती command तुमचे photos delete करते. ती type करण्यापूर्वी compose file वाचा.

रीस्टोरनंतर timeline रिकामी का दिसते

timeline database मधील rows वरून तयार होते. फोटो पुन्हा शोधण्यासाठी Immich boot वेळी upload/ वर कधीही फिरत नाही, कारण row नसलेल्या file ला owner, date किंवा album नसतो. त्यामुळे सर्वाधिक आढळणारा चुकीचा restore असा असतो: files परत आल्या, पण database उपलब्ध नाही. Immich सुरू होते, रिकामा schema तयार करते आणि त्यामध्ये काहीही नसलेले कार्यरत instance देते, जरी disk वर तुमचे सर्व photos असले तरी. काहीही हरवलेले नसते. पण काहीही दिसतही नाही. याचे निराकरण म्हणजे server थांबवून, वर दिल्याप्रमाणेच dump पुन्हा लागू करणे.

दुसरी स्थिती अधिक शांतपणे दिसते. Database restore होते, timeline entries ने भरते आणि प्रत्येक asset उघडताना अपयशी ठरतो. याचा अर्थ rows अशा files कडे निर्देश करतात ज्या container ला दिसत नाहीत. सहसा library, upload आणि profile हे कोणीही योग्य ठिकाणी हलवले नसलेल्या restic restore --target /restore नंतर एक स्तर अधिक खोल गेलेले असतात. अंदाज बांधण्याऐवजी container च्या आतून तपासा:

docker exec immich_server ls /data

मूळ compose file मध्ये UPLOAD_LOCATION हे /data येथे mount केलेले असते. त्यामुळे त्या listing मध्ये library, upload आणि profile दिसले पाहिजेत. रिकामी directory किंवा अनावश्यक srv folder दिसत असल्यास, तुमचा bind mount चुकीच्या स्तराकडे निर्देश करतो आणि rows योग्य आहेत.

बॅकअप आणि restore मधील आवृत्ती जुळणी

Immich वारंवार releases प्रकाशित करते आणि schema त्यासोबत बदलतो. त्यामुळे dump मध्ये तो लिहिणाऱ्या server चा schema असतो.

जुन्या dump ला नवीन server वर restore करणे सहसा कार्य करते, कारण server सुरू होताना प्रलंबित migrations लागू करतो आणि schema पुढील स्थितीत नेतो. हा मार्ग release sequence नुसार तपासलेला असतो. एका टप्प्यात अनेक major versions वगळल्यास समस्या निर्माण होतात. प्रकल्प major releases मध्ये breaking changes ठेवतो आणि त्यांचे दस्तऐवजीकरण changelog मध्ये करतो.

नवीन dump जुन्या server वर restore करणे अजिबात कार्य करत नाही. dump मध्ये जुन्या code ला माहीत नसलेल्या tables आणि columns असतात. तसेच Immich नुसार patch releases मधील downgrade देखील unsupported आहे. यासाठी वापरता येईल असा rollback command नाही.

म्हणून सुरक्षित restore पद्धत साधी आहे. dump लिहिणारी अचूक version चालवा, dump पुन्हा लागू करा, log in करा आणि timeline पूर्ण असल्याची खात्री करा. त्यानंतरच upgrade करा. प्रत्येक वेळी एकच release upgrade करा. प्रत्येक upgrade नंतर IMMICH_VERSION बदलून docker compose pull && docker compose up -d चालवा. येथे एक आठवड्याचे dumps ठेवणे देखील उपयुक्त ठरते. नवीनतम dump failed upgrade सुरू असताना तयार झालेला आढळल्यास, कालचा dump repository मध्ये उपलब्ध असतो.

दर महिन्याला बॅकअपची पडताळणी करा

ज्या बॅकअपमधून तुम्ही कधीही restore केलेले नाही, तो बॅकअप केवळ अंदाज असतो. महिन्यातून एकदा तो throwaway instance मध्ये restore करा आणि एखादा फोटो पाहा. ही प्रक्रिया सुमारे वीस मिनिटे घेते. या पानावरील उर्वरित माहितीला recovery plan मध्ये रूपांतरित करणारी हीच एकमेव गोष्ट आहे.

restic snapshots
restic stats latest

snapshots मध्ये काल रात्रीची run नोंदलेली असावी. stats latest ने तुमच्या library च्या आकाराच्या जवळपासचा आकार दाखवावा; काही megabytes एवढाच नसावा.

Restore केलेला संच शक्यतो spare host वरील scratch directory मध्ये restore करा:

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

Restore केलेल्या संचातून docker-compose.yml आणि .env बाहेर copy करा, त्यानंतर त्या copy मध्ये तीन बदल करा. UPLOAD_LOCATION आणि DB_DATA_LOCATION यांना /tmp/immich-drill अंतर्गत असलेल्या directories कडे निर्देशित करा. Web port दुसऱ्या ठिकाणी publish करा: 2283:2283 ऐवजी 12283:2283 वापरा. container_name: ओळी delete करा, कारण stock compose file मध्ये immich_server सारखी नावे hard-code केलेली असतात. त्यामुळे त्याच host वर दुसरा stack पहिल्या stack शी collide होतो आणि Docker तो तयार करण्यास नकार देतो.

वर दिलेली restore sequence चालवा: प्रथम database only, त्यानंतर dump replay करा आणि मग docker compose up -d चालवा. आता प्रत्यक्ष पडताळणी करणाऱ्या चार तपासण्या करा.

1. Drill सुरू करण्यापूर्वी वापरलेल्या password ने log in करा. Accounts कार्यरत असल्यास dump restore झाला आहे.
2. Timeline उघडा आणि सर्वात जुन्या month पर्यंत scroll करा. संपूर्ण date range मधील assets दिसत असल्यास केवळ अलीकडील rows नव्हे, तर सर्व rows परत आल्या आहेत.
3. एखादा photo full size मध्ये उघडा आणि original download करा.
4. sha256sum वापरून त्याची live library मधील त्याच file शी तुलना करा. Hash जुळल्यास restic मधून केलेल्या पूर्ण round trip मध्ये bytes सुरक्षित राहिले आहेत.

त्यानंतर drill directory मध्ये docker compose down -v वापरून drill बंद करा आणि /tmp/immich-drill delete करा. ही date तुम्हाला दिसेल अशा ठिकाणी लिहा, कारण याचा संपूर्ण उपयोग पुढील महिन्यात ही प्रक्रिया पुन्हा करण्यामध्ये आहे. तुम्ही कोणत्या photo server वर निश्चितपणे काम करायचे हे अजून ठरवत असाल, तर PhotoPrism आणि Immich ची तुलना या दोन्हीमधील नेमका हा फरक स्पष्ट करते.

FAQ

बॅकअप घेण्यासाठी Immich थांबवणे आवश्यक आहे का?

immich_server थांबवा आणि immich_postgres सुरू ठेवा. Database ला थांबवण्याची गरज नाही, कारण pg_dump एका MVCC snapshot मधून read करते आणि इतर कोणतीही प्रक्रिया write करत असली तरी एकाच सुसंगत क्षणाची स्थिती पाहते. थांबवण्याचे कारण files आहेत: server नवीन uploads लिहितो आणि storage template job files एका directory मधून दुसऱ्या directory मध्ये हलवते. त्यामुळे backup tool एखादी file write सुरू असतानाच read करू शकते आणि कोणतीही error न दाखवता truncated copy साठवू शकते. Snapshot घेण्यापूर्वी docker stop immich_server आणि त्यानंतर docker start immich_server केल्यास ही race condition टाळता येते.

pg_dump चालवण्याऐवजी मी Postgres data folder copy करू शकतो का?

नाही. Live data directory ची rolling copy वेगवेगळ्या files वेगवेगळ्या क्षणी read करते. त्यामुळे तयार झालेली copy एकसंध state दर्शवत नाही. Startup वेळी Postgres ती PANIC: could not locate a valid checkpoint record मुळे नाकारते किंवा नंतर damaged page मुळे fail होते. सर्व काही थांबवून घेतलेली copy देखील database च्या अचूक build शी बांधलेली असते. Immich विशिष्ट vector-search extension versions असलेली Postgres 14 image वापरतो आणि ही directory इतर कोणत्याही build अंतर्गत उघडत नाही. SQL dump plain text असतो आणि तो कोणत्याही compatible server मध्ये पुन्हा लागू करता येतो.

Restore केल्यानंतर माझी Immich timeline रिकामी का आहे?

कारण timeline database rows मधून तयार होते आणि तुम्ही database शिवाय files restore केल्या आहेत. Photos पुन्हा शोधण्यासाठी Immich upload/ scan करत नाही. त्यामुळे rows नसलेल्या files अदृश्य राहतात. Photos स्वतः बदललेल्या नसतात. Server थांबवा, freshly initialised Postgres मध्ये dump पुन्हा लागू करा आणि त्यानंतर stack सुरू करा. याउलट timeline पूर्ण दिसत असेल, पण प्रत्येक photo उघडताना fail होत असेल, तर समस्या उलटी आहे: library, upload आणि profile container मध्ये bind केलेल्या directory च्या थेट आत नाहीत. docker exec immich_server ls /data ने ते तपासा.

बॅकअपमध्ये कोणते Immich folders वगळता येतात?

thumbs आणि encoded-video originals मधून पुन्हा तयार होतात, तर DB_DATA_LOCATION dump मधून पुन्हा तयार होते. त्यामुळे यापैकी कोणतेही folder backup set मध्ये ठेवण्याची गरज नाही. त्यांना वगळल्यास restore नंतर storage वाचते, पण rebuilding साठी वेळ लागतो. मोठ्या library साठी previews आणि transcodes पुन्हा तयार करण्यास अनेक तास CPU time लागू शकतो. हे missing assets साठी Administration > Jobs मधून चालवले जाते. तुम्ही कधीही library, upload आणि profile वगळू शकत नाही, कारण प्रत्येक original ची एकमेव copy यांच्यात असते.

Immich dump नवीन version मध्ये restore करता येतो का?

सहसा होय, कारण server सुरू होताना pending migrations लागू करतो आणि schema पुढे अद्ययावत करतो. उलट प्रक्रिया fail होते. Immich downgrading ला support करत नाही, अगदी patch releases मधेसुद्धा नाही. त्यामुळे नवीन release मधून घेतलेला dump जुन्या server मध्ये load करता येत नाही. IMMICH_VERSION ला dump लिहिणाऱ्या release वर pinned ठेवून restore करा. Timeline पूर्ण आहे याची खात्री करा आणि त्यानंतर upgrade करा. प्रत्येक dump च्या बाजूला docker inspect --format '{{.Config.Image}}' immich_server वापरून version नोंदवा, कारण default IMMICH_VERSION=v3 हा floating tag आहे आणि त्यावरून कोणतीही उपयुक्त माहिती मिळत नाही.