Immich backup மற்றும் restore செய்வது எப்படி?

Immich backup-ல் என்னென்ன இருக்க வேண்டும்

ஒரு Immich backup என்பது ஒரே நேரத்தில் எடுக்கப்படும் மூன்று விஷயங்களைக் குறிக்கும். UPLOAD_LOCATION-க்கு கீழ் உள்ள originals கோப்புகள், Postgres database-ன் SQL dump, மற்றும் அந்த stack-ஐ விவரிக்கும் .env மற்றும் docker-compose.yml கோப்புகள். மீட்டெடுக்கும்போது (restoring), Immich server-ஐ நிறுத்திவிட்டு, அந்த dump-ஐ ஒரு புதிய database-ல் பதிவேற்ற வேண்டும்; அதன் பிறகுதான் stack-ன் மற்ற பகுதிகளைத் தொடங்க வேண்டும். இந்த வரிசை மாறினால், வட்டில் கோப்புகள் முழுமையாக இருந்தாலும், Immich-ல் காலவரிசை (timeline) காலியாகவே காட்டும்.

இந்த இரண்டு பகுதிகளும் ஒன்றையொன்று அறியாதவை என்பதால், இந்த பிரிப்பு முக்கியமானது. Postgres-ல் தான் அனைத்து album-கள், face cluster-கள், பகிரப்பட்ட இணைப்புகள், பயனர் கணக்குகள், API key-கள் மற்றும் ஒவ்வொரு asset-ன் சேமிப்புப் பாதை ஆகியவை இருக்கும். கோப்பு முறைமையில் (filesystem) படங்கள் மட்டுமே இருக்கும். database இல்லாமல் கோப்புகளை மட்டும் மீட்டெடுத்தால் Immich எதையும் காட்டாது. கோப்புகள் இல்லாமல் database-ஐ மட்டும் மீட்டெடுத்தால், ஒவ்வொரு asset-ம் உடைந்த படமாகவே (broken image) காட்டும்.

இங்குள்ள கட்டளைகள் ஆகஸ்ட் 2026 தொடக்கத்தில் தற்போதைய வெளியீடாக உள்ள Immich v3.1.0-க்காக எழுதப்பட்டுள்ளன. இந்தத் திட்டம் மிக வேகமாக மேம்படுத்தப்படுவதால், ஆவணப்படுத்தப்பட்ட backup நடைமுறைகள் பலமுறை மாறியுள்ளன. எனவே, எதையும் நகலெடுக்கும் முன் நீங்கள் தற்போது இயக்கும் பதிப்பைச் சரிபார்க்கவும். stack இன்னும் தொடங்கப்படவில்லை என்றால், Immich நிறுவல் வழிகாட்டி-யுடன் தொடங்கிவிட்டு, பிறகு இங்கு வரவும்.

உங்கள் paths எதைக் குறிக்கின்றன என்பதை அறிந்துகொள்ளுங்கள்

இந்தப்பக்கத்தில் உள்ள அனைத்தையும் .env-ல் உள்ள இரண்டு மாறிகள் (variables) தீர்மானிக்கின்றன. UPLOAD_LOCATION என்பது Immich அனைத்து மீடியா கோப்புகளையும் எழுதும் முதன்மை அடைவு (parent directory) ஆகும். DB_DATA_LOCATION என்பது Postgres தரவு அடைவு ஆகும்.

இயல்பான example.env அமைப்பானது UPLOAD_LOCATION=./library-ஐ அமைக்கிறது. இது குழப்பமான ஒரு இயல்புநிலை (default) ஆகும், ஏனெனில் Immich இதற்குள் library என்ற பெயரில் ஒரு கோப்புறையை உருவாக்குகிறது. உங்கள் அசல் கோப்புகள் ./library/library-ல் சேமிக்கப்படுகின்றன. இதற்குப் பதிலாக ஒரு முழுமையான பாதையை (absolute path) அமைக்கவும்; அப்போதுதான் எந்த அடைவிலிருந்து ஸ்கிரிப்டை இயக்கினாலும், பேக்கப் ஸ்கிரிப்ட் சரியாகச் செயல்படும்.

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 பல கோப்புறைகளை உருவாக்குகிறது. அவற்றில் மூன்று கோப்புறைகள் எந்தவொரு வேலையாலும் மீண்டும் உருவாக்க முடியாத தரவுகளைக் கொண்டுள்ளன:

• library: உங்கள் சேமிப்பக வார்ப்புருவின் (storage template) படி அடுக்கப்பட்ட அசல் கோப்புகள்.
• upload: வார்ப்புரு அமைப்பிற்கு இன்னும் மாற்றப்படாத அசல் கோப்புகள் மற்றும் பதிவேற்றத்தில் உள்ள கோப்புகள்.
• profile: பயனர் சுயவிவரப் படங்கள் (user profile pictures).

library-ஐ இழந்தால், அந்தப் புகைப்படம் நிரந்தரமாக அழிந்துவிடும். அசல் கோப்பின் இரண்டாவது நகலை Immich எங்கும் சேமித்து வைப்பதில்லை.

Postgres தரவு அடைவை (data directory) நகலெடுப்பது ஏன் காப்புப்பிரதி (backup) ஆகாது

DB_DATA_LOCATION ஒரு எளிதான வழியாகத் தோன்றலாம். இது ஒரு அடைவு என்பதால், rsync கட்டளையைப் பயன்படுத்தி அதை நகலெடுக்கலாம், மேலும் எந்தப் பிழையும் இன்றி நகலெடுப்பு முடிந்துவிடும். இருப்பினும், இது காப்புப்பிரதி ஆகாது. இதற்கான இரண்டு காரணங்களை நீங்கள் கீழே காணலாம்.

முதலாவது, தரவு சிதைவு (tearing). Postgres ஒவ்வொரு மாற்றத்தையும் முதலில் write-ahead log (WAL)-ல் எழுதிவிட்டு, பின்னர் ஒரு checkpoint-ன் போது அதை table கோப்புகளில் பதிவேற்றும். எனவே, எந்தவொரு கணத்திலும் வட்டில் உள்ள கோப்புகள் முழுமையற்ற நிலையில் இருக்கலாம். நான்கு நிமிடங்கள் எடுக்கும் ஒரு நகலெடுப்புச் செயல்முறை, முதல் கோப்பை 02:00 மணிக்கும், கடைசி கோப்பை 02:04 மணிக்கும் வாசிக்கும். இந்த இரண்டு கோப்புகளும் ஒரே transaction-க்கு உரியவை அல்ல. இதன் விளைவாகக் கிடைக்கும் தரவை வைத்து நீங்கள் Postgres-ஐத் தொடங்க முயன்றால், அது தொடக்கத்திலேயே PANIC: could not locate a valid checkpoint record பிழையைக் காட்டி மறுக்கலாம், அல்லது தொடங்கும், ஆனால் சேதமடைந்த பக்கத்தை வாசிக்கும்போது invalid page in block 1234 of relation base/16384/... பிழையுடன் நின்றுவிடும். இந்த நகலிலிருந்து தரவை மீட்டெடுக்க முடியாது.

இரண்டாவது காரணம், நீங்கள் அனைத்தையும் நிறுத்திவிட்டு நகலெடுத்தாலும் பொருந்தும். ஒரு Postgres தரவு அடைவு, அதை உருவாக்கிய அதே binaries-உடன் பிணைக்கப்பட்டுள்ளது. Immich அதன் database image-ஐ digest மூலம் உறுதிப்படுத்துகிறது, தற்போது அது ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0 ஆக உள்ளது. இது இரண்டு vector-search extensions உடன் தொகுக்கப்பட்ட Postgres 14 ஆகும். அந்த build-ஆல் உருவாக்கப்பட்ட தரவு அடைவு, வேறொரு Postgres major version-ல் திறக்காது; மேலும், வெவ்வேறு extension பதிப்புகளைக் கொண்ட build-லும் அது திறக்காது. நீங்கள் தரவை மீட்டெடுக்கும் host, அதே image-ஐ அப்படியே கொண்டிருக்க வேண்டும். ஆனால், SQL dump-க்கு இந்தச் சிக்கல் இல்லை: அது உரை வடிவில் (text) இருப்பதால், இணக்கமான எந்தவொரு server-லும் அதை மீண்டும் இயக்க முடியும்.

pg_dump தரவு சிதைவுச் சிக்கலைத் தவிர்க்கிறது. இது முழு தரவுத்தளத்தையும் ஒரே MVCC (multi-version concurrency control) snapshot-க்குள் வாசிக்கிறது. எனவே, மற்ற மாற்றங்கள் நிகழ்ந்துகொண்டிருக்கும்போதே, ஒரு குறிப்பிட்ட கணத்தில் தரவுத்தளம் எப்படி இருந்ததோ, அப்படியே அது பார்க்கிறது. இதனால்தான், dump எடுப்பதற்காக நீங்கள் Postgres-ஐ நிறுத்த வேண்டிய அவசியமில்லை.

காப்புப்பிரதியிலிருந்து (backup) எவற்றைத் தவிர்க்கலாம்

இவை மீண்டும் உருவாக்கப்படக்கூடியவை என்பதால், இவற்றைத் தவிர்க்கலாம்:

• thumbs: முன்னோட்ட (preview) மற்றும் சிறுபடங்கள் (thumbnail)
• encoded-video: மாற்றப்பட்ட (transcoded) காணொளிகள்
• DB_DATA_LOCATION: தரவுத்தளப் பதிவிலிருந்து (dump) மீண்டும் கட்டமைக்கப்படுபவை
• model-cache Docker volume: இயந்திரக் கற்றல் (machine learning) மாதிரிகள், தேவைப்படும்போது மீண்டும் பதிவிறக்கிக்கொள்ளலாம்

இவற்றைத் தவிர்ப்பது ஒரு சமரசமே தவிர, முழுமையான லாபமல்ல. ஒரு பெரிய நூலகத்திற்குச் சிறுபடங்களையும், மாற்றப்பட்ட காணொளிகளையும் மீண்டும் உருவாக்குவது ஒரு சிறிய VPS-ல் பல மணிநேர CPU பயன்பாட்டை எடுக்கும்; அந்த நேரம் முழுவதும் காலவரிசையில் (timeline) சாம்பல் நிற இடங்கள் மட்டுமே தெரியும். Administration > Jobs பகுதிக்குச் சென்று, "Generate Thumbnails" மற்றும் "Transcode Videos" ஆகியவற்றைத் தேர்ந்தெடுத்து, விடுபட்ட கோப்புகளுக்கு மட்டும் இயங்குமாறு அமைப்பதன் மூலம் இவற்றை மீண்டும் உருவாக்கலாம். உங்கள் காப்புப்பிரதி சேமிப்பகத்தில் இடம் இருந்தால், இவற்றைச் சேர்த்துக்கொண்டு காத்திருப்பதைத் தவிர்க்கவும். சேமிப்பக வரம்பிற்கு அருகில் இருந்தால், இவற்றை நீக்கிவிட்டு, மீண்டும் உருவாக்குவதற்கான திட்டத்தை வைத்துக்கொள்ளவும். Immich நூலகத்தின் அளவீடு பகுதியில், அசல் கோப்புகளை விட இந்த கோப்புறைகள் எவ்வளவு பெரியதாக வளரும் என்பது விளக்கப்பட்டுள்ளது.

மேலும் ஒரு கோப்புறையைப் பற்றித் தெரிந்துகொள்வது அவசியம். UPLOAD_LOCATION/backups என்பது Immich-ன் தானியங்கி தரவுத்தளப் பதிவுகளைச் சேமிக்கும் இடமாகும். இது தினமும் 02:00 மணிக்கு எழுதப்பட்டு, கடைசி 14 பதிவுகள் பாதுகாக்கப்படும். இதை Administration > Settings > Backup என்பதில் மாற்றியமைக்கலாம். இவை எந்தச் சேமிப்பகச் செலவையும் ஏற்படுத்தாது, அதே சமயம் மிகவும் பயனுள்ளவை. இவை பாதுகாக்கப்படும் நூலகம் இருக்கும் அதே வட்டில் இருப்பதால், தவறான இடமாற்றத்தின்போது (migration) இவை உதவும், ஆனால் server செயலிழந்தால் உதவாது. எனவே, நீங்களாகவே ஒரு தரவுத்தளப் பதிவை (dump) எடுத்துக்கொள்ளுங்கள்; ஏனெனில், நீங்கள் எடுக்கும் பதிவு, அதனுடன் தொடர்புடைய கோப்பு ஸ்னாப்ஷாட் (snapshot) எடுக்கப்படும் அதே தருணத்தில் அமையும்.

Database 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-ஐச் சேர்க்கிறது. இதனால், ஏற்கனவே தரவுகள் உள்ள ஒரு database-ல் dump-ஐ மீண்டும் பதிவேற்றும்போது, முதல் பிழையிலேயே அது நின்றுவிடாமல் தொடர்ந்து செயல்படும்.

இப்போது, backup script-களை அமைதியாகப் பாதிக்கும் ஒரு நுணுக்கத்தைப் பார்ப்போம். அந்த command ஒரு pipeline ஆகும், மேலும் ஒரு shell அந்த pipeline-ல் உள்ள கடைசி command-ன் exit status-ஐ மட்டுமே தெரிவிக்கும். ஒருவேளை தவறான கடவுச்சொல் அல்லது இயங்காத container காரணமாக pg_dump தோல்வியடைந்தால், gzip காலியான stream-ஐப் பெற்று, ஒரு சரியான gzip கோப்பை உருவாக்கிவிட்டு 0 என்ற exit 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 என்று இருக்கும். சில நூறு bytes மட்டுமே உள்ள கோப்பு, script என்ன சொன்னாலும் அது தோல்வியடைந்த dump ஆகும்.

Dump-க்கு அருகில், எந்த build அதை உருவாக்கியது என்பதைப் பதிவு செய்யவும்:

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

இதற்கு .env-ஐ மட்டும் நம்பியிருக்க வேண்டாம். பொதுவான file தொகுப்புகள் IMMICH_VERSION=v3-ஐ அமைக்கும்; இது ஒவ்வொரு 3.x release-க்கும் மாறும் ஒரு floating tag ஆகும். எனவே, எந்த build உண்மையில் dump-ஐ உருவாக்கியது என்பதை இது காட்டாது. .env-ல் சரியான tag-ஐக் குறிப்பிடவும்.

சர்வரை நிறுத்திவிட்டு, restic மூலம் snapshot எடுக்கவும்

Immich இயங்கும்போது UPLOAD_LOCATION-க்குக் கீழே உள்ள கோப்புகள் மாறாதவை அல்ல. சர்வர் புதிய பதிவேற்றங்களை எழுதுகிறது, மேலும் storage template பணி கோப்புகளை கோப்பகங்களுக்கு இடையே நகர்த்துகிறது. ஒரு backup கருவி கோப்பு எழுதப்படும்போதே அதை வாசித்தால், அது முழுமையான கோப்பாகக் கருதி அந்தத் தரவைச் சேமிக்கும், ஆனால் எந்தப் பிழையும் காட்டாது. எனவே, backup எடுக்கும் நேரம் வரை சர்வர் container-ஐ நிறுத்தவும்:

docker stop immich_server

immich_postgres-ஐ இயங்க விடவும், ஏனெனில் dump செய்வதற்கு அது தேவைப்படுகிறது. நீங்கள் சர்வரை மீண்டும் தொடங்கும் வரை web interface மற்றும் mobile app ஆகியவை offline-ல் இருக்கும். வீட்டு உபயோக சர்வர்களில் அதிகாலை 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-ம் இதே முறையில் செயல்படுகிறது. உங்கள் வன்பொருளைத் தாண்டி தரவை முழுமையாகப் பாதுகாக்க இதுவே சிறந்த வழி:

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-ல் repository வைத்திருப்பது, தவறுதலாகக் கோப்புகளை நீக்குவதைத் தவிர மற்ற பாதிப்புகளிலிருந்து உங்களைப் பாதுகாக்காது.

பிறகு, முக்கியமானவற்றை மட்டும் குறிப்பிட்டு 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 ஒவ்வொரு முறையும் முழு கோப்பு மரத்தையும் (tree) வாசிக்கும், ஆனால் அதுவரை கண்டிராத புதிய தரவுத் தொகுப்புகளை (blocks) மட்டுமே upload செய்யும். எனவே, முதல் snapshot உங்கள் முழு library-யையும் நகர்த்தும், அதன் பிறகு எடுக்கப்படும் ஒவ்வொரு snapshot-ம் அந்த நாளில் சேர்க்கப்பட்ட புதிய புகைப்படங்களை மட்டுமே நகர்த்தும்.

Retention, மற்றும் பிற இடங்களில் இருக்க வேண்டிய சாவிகள்

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

forget, snapshots-ஐ index-லிருந்து நீக்குகிறது. --prune என்பது அந்த snapshots-ஆல் மட்டுமே குறிக்கப்பட்ட தரவுகளை நீக்கும் பாதியாகும். --prune இல்லாமல் forget-ஐ இயக்கினால், உங்கள் storage கட்டணம் குறையாது.

Structure சோதனைகள் குறைந்த செலவில் முடிபவை, எனவே அவற்றை வாரத்திற்கு ஒருமுறை இயக்கவும்:

restic check

இது repository metadata சீராக இருப்பதை உறுதி செய்கிறது. இது உங்கள் தரவுகளை வாசிப்பதில்லை. மாதத்திற்கு ஒருமுறை, ஒரு மாதிரியை மீண்டும் வாசித்து, அதன் பதிவு செய்யப்பட்ட hashes-உடன் ஒப்பிட்டுப் பார்க்கவும்:

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

storage backend-ல் ஏற்படும் அமைதியான சிதைவுகளை (silent corruption) கண்டறியும் ஒரே சோதனை இதுதான், ஏனெனில் இது உண்மையான blocks-ஐ தரவிறக்கம் செய்து அவற்றின் checksums-ஐ மீண்டும் கணக்கிடுகிறது. ஒரு photo library-ல் முழுமையான --read-data செய்வது என்பது முழு repository-யையும் தரவிறக்கம் செய்வதாகும்; இது metered object storage-ல் அதிக செலவை ஏற்படுத்தும் என்பதால், மக்கள் வழக்கமாக ஒரு குறிப்பிட்ட பகுதியை மட்டும் (rolling subset) சரிபார்க்கிறார்கள்.

இப்போது மக்கள் தவிர்க்கும் பகுதி. restic repository கடவுச்சொல்லை மீட்க முடியாது. இதற்கு reset வசதியோ அல்லது support ticket வசதியோ இல்லை. நீங்கள் restore செய்ய முயற்சிக்கும் server-லேயே /root/.restic-password-ல் மட்டும் அதன் நகல் இருந்தால், உங்கள் backups வெறும் குறியாக்கம் செய்யப்பட்ட இரைச்சலாகவே (encrypted noise) இருக்கும். இது object storage access key மற்றும் .env-லிருந்து பெறப்படும் DB_PASSWORD-க்கும் பொருந்தும். இவை அனைத்தையும் இந்த machine-ன் செயல்பாட்டைச் சாராத ஓரிடத்தில் வைத்திருக்கவும்: அச்சிட்டு ஒரு அலமாரியில் வைக்கவும், அல்லது வேறு hardware-ல் இயங்கும் password manager-ல் சேமிக்கவும். அந்த manager-ம் self-hosted ஆக இருந்தால், அதற்கும் இதே பாதுகாப்பு முறையைப் பின்பற்ற வேண்டும், மேலும் Vaultwarden-ஐ backup செய்வது ஒரு தனிப்பணியாகும்.

Immich-ஐ சரியான வரிசையில் மீட்டமைத்தல்

மீட்டெடுக்கும் வரிசை சரியாக இல்லையெனில், நல்ல பேக்கப்கள் கூட பயனற்றதாகிவிடும். புதிய host-ல் இந்த வரிசையைப் பின்பற்றவும்.

முதலில் configuration-ஐ மீட்டெடுக்கவும். இது எந்த version-ஐ இயக்க வேண்டும் மற்றும் paths எங்குள்ளன என்பதைத் தெரிவிக்கும்.

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

எதையும் தொடங்கும் முன் version-ஐ pin செய்யவும். immich-version.txt-ஐப் படித்து, .env-ல் உள்ள IMMICH_VERSION-ஐ அந்த குறிப்பிட்ட tag-க்கு அமைக்கவும். தற்போதைக்கு புதிய release-ஐத் தவிர்க்கவும். Immich-ல் patch releases-க்கு இடையில் கூட downgrade செய்ய முடியாது. எனவே, புதிய server பழைய dump-உடன் தொடங்கி migrations-ஐச் செய்துவிட்டால், மீண்டும் பழைய நிலைக்குத் திரும்ப முடியாது.

Media கோப்புகளை மீட்டெடுக்கவும்.

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

பின்பு library, upload மற்றும் profile ஆகியவற்றை நகர்த்தவும். அவை இந்த host-ல் UPLOAD_LOCATION எதைக் குறிக்கிறதோ, அதற்குள் நேரடியாக இருக்க வேண்டும். Host path மாறலாம், ஏனெனில் compose file அந்த directory-ஐ container-க்குள் ஒரு நிலையான path-உடன் இணைக்கிறது. ஆனால், அதற்குள் உள்ள அமைப்பு மாறக்கூடாது.

Database-ஐ மட்டும் தனியாகத் தொடங்கவும். Postgres ஒரு புதிய cluster-ஐ உருவாக்க, DB_DATA_LOCATION-ஐ காலியாக விடவும்.

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-ஐக் காட்டும்; இதற்குச் சில நொடிகள் ஆகும். docker compose create அனைத்து container-களையும் தொடங்காமல் build செய்யும். இதுவே இந்த நிலையின் நோக்கம்: Immich server இன்னும் இயங்கக்கூடாது. காலியான database-உடன் தொடங்கும் server, migrations-ஐச் செய்து, புதிய schema-வை உருவாக்கி, புதிய admin account-ஐ உருவாக்கக் கேட்கும். அப்போது நீங்கள் இயங்கிக்கொண்டிருக்கும் application-க்கு அடியில் dump-ஐப் பதிவேற்ற வேண்டியிருக்கும்.

Dump-ஐ மீண்டும் பதிவேற்றவும் (Replay).

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 பாதுகாப்பிற்காக ஒரு காலியான search_path-ஐ அதன் output-ல் எழுதுவதாகும். இதனால் dump-ல் உள்ள பெயர்கள் எதிர்பாராத schema-வில் சேராது. Immich-ன் vector-search வகைகள் public-ல் உள்ளன. எனவே, search path காலியாக இருந்தால், restore செய்யும்போது vector வகையைக் கொண்ட முதல் column-ல் psql ERROR: type "vector" does not exist பிழையுடன் நின்றுவிடும். public-ஐ மீண்டும் path-ல் சேர்ப்பது இதைச் சரிசெய்யும்.

--single-transaction --set ON_ERROR_STOP=on முழு restore செயல்பாட்டையும் ஒரே transaction-ஆக மாற்றும்; ஏதேனும் பிழை ஏற்பட்டால் அது நின்றுவிடும். இதனால் உங்களுக்கு முழுமையான database கிடைக்கும் அல்லது பழையபடியே இருக்கும். இது இல்லையெனில், பாதியில் தோல்வியடைந்தால், database இயங்கும், login-ஐ ஏற்கும், ஆனால் பல albums விடுபட்டிருக்கும். இது பல வாரங்களுக்குப் பிறகுதான் உங்களுக்குத் தெரியவரும்.

இப்போது அனைத்தையும் தொடங்கவும்.

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

Immich Server is listening on போன்ற startup வரியைக் காணும் வரை காத்திருக்கவும். பின் 2283 port-ஐத் திறந்து பழைய credentials மூலம் login செய்யவும், ஏனெனில் user accounts dump மூலம் திரும்ப வந்துவிடும். ஒருவேளை login பக்கம் முதல் admin account-ஐ உருவாக்கக் கேட்டால், database சரியாக மீட்டமைக்கப்படவில்லை என்று அர்த்தம். நிறுத்திவிட்டு psql output-ஐ மீண்டும் சரிபார்க்கவும்.

அதிகாரப்பூர்வ restore வழிமுறைகள் குறித்து ஒரு எச்சரிக்கை: அவை docker compose down -v உடன் தொடங்கும். -v கட்டளை named volumes-ஐ நீக்கிவிடும். பொதுவான compose file-ல் UPLOAD_LOCATION மற்றும் DB_DATA_LOCATION ஆகியவை bind mounts என்பதால் அவை அழியாது. நீங்கள் எதையேனும் named volume-ஆக மாற்றியிருந்தால், அந்தக் கட்டளை உங்கள் புகைப்படங்களை அழித்துவிடும். கட்டளையைத் தட்டச்சு செய்வதற்கு முன் உங்கள் compose file-ஐச் சரிபார்க்கவும்.

மீட்டெடுப்பிற்குப் பிறகு காலக்கோடு (timeline) ஏன் காலியாக உள்ளது

காலக்கோடு தரவுத்தளத்தில் உள்ள வரிசைகளிலிருந்து (rows) உருவாக்கப்படுகிறது. புகைப்படங்களை மீண்டும் கண்டறிய Immich ஒருபோதும் boot செய்யும்போது upload/-ஐ ஸ்கேன் செய்வதில்லை, ஏனெனில் வரிசை இல்லாத கோப்பிற்கு உரிமையாளரோ, தேதியோ அல்லது ஆல்பமோ இருக்காது. எனவே, மிகவும் பொதுவான தவறான மீட்டெடுப்பு என்பது கோப்புகள் திரும்பக் கிடைப்பது, ஆனால் தரவுத்தளம் விடுபடுவது ஆகும். Immich தொடங்கும்போது, ஒரு காலி schema-வை உருவாக்குகிறது, மேலும் உங்கள் வட்டில் புகைப்படங்கள் நிறைந்திருந்தாலும், உள்ளே எதுவுமில்லாத ஒரு இயங்கும் instance-ஐ உங்களுக்கு வழங்குகிறது. எதுவும் இழக்கப்படவில்லை. ஆனால் எதுவும் தெரிவதில்லை. இதற்கான தீர்வு, மேலே குறிப்பிட்டது போல, server-ஐ நிறுத்திவிட்டு dump-ஐ மீண்டும் பதிவேற்றுவது (replay) ஆகும்.

இரண்டாவது வகை அமைதியானது. தரவுத்தளம் மீட்டமைக்கப்படுகிறது, காலக்கோடு பதிவுகளால் நிரப்பப்படுகிறது, ஆனால் ஒவ்வொரு asset-ஐயும் திறக்க முடியவில்லை. இதன் பொருள், container-ஆல் பார்க்க முடியாத கோப்புகளை வரிசைகள் சுட்டிக்காட்டுகின்றன என்று அர்த்தம். பொதுவாக, restic restore --target /restore-க்கு பிறகு library, upload மற்றும் profile ஆகியவை ஒரு நிலை ஆழமாக (one level too deep) இருப்பதால் இது நிகழ்கிறது, அவற்றை யாரும் சரியான இடத்திற்கு மாற்றியிருக்க மாட்டார்கள். ஊகிப்பதற்குப் பதிலாக container-க்குள் இருந்து சரிபார்க்கவும்:

docker exec immich_server ls /data

Stock compose கோப்பு UPLOAD_LOCATION-ஐ /data-ல் mount செய்கிறது, எனவே அந்தப் பட்டியலிடல் library, upload மற்றும் profile ஆகியவற்றைக் காட்ட வேண்டும். அது ஒரு காலி directory-யையோ அல்லது தேவையற்ற srv கோப்புறையையோ காட்டினால், உங்கள் bind mount தவறான நிலையைச் சுட்டிக்காட்டுகிறது என்று அர்த்தம், தரவுத்தள வரிசைகள் சரியாகவே உள்ளன.

Backup மற்றும் restore பதிப்புகளுக்கு இடையிலான பொருத்தம்

Immich அடிக்கடி புதிய பதிப்புகளை வெளியிடுகிறது, அதனுடன் database schema-வும் மாறுகிறது. எனவே, ஒரு dump கோப்பு எந்த server-ல் உருவாக்கப்பட்டதோ, அந்த server-ன் schema-வை அது கொண்டிருக்கும்.

பழைய dump கோப்பை புதிய server-ல் restore செய்வது பொதுவாகச் சரியாகச் செயல்படும். ஏனெனில், server தொடங்கும்போதே நிலுவையில் உள்ள migrations-ஐச் செயல்படுத்தி, schema-வை மேம்படுத்திவிடும். இந்த வழிமுறை ஒவ்வொரு வெளியீட்டு வரிசையிலும் சோதிக்கப்படுகிறது. ஆனால், பல major பதிப்புகளை ஒரே அடியில் தாண்டிச் செல்லும்போது சிக்கல்கள் ஏற்படலாம். Immich திட்டமானது, major வெளியீடுகளில் மாற்றங்களைச் செய்து, அவற்றை அதன் changelog-ல் ஆவணப்படுத்துகிறது.

புதிய dump கோப்பை பழைய server-ல் restore செய்வது இயலாது. அந்த dump கோப்பில் பழைய code-க்குத் தெரியாத tables மற்றும் columns இருக்கும். Immich-ன் படி, patch பதிப்புகளுக்கு இடையே கூட downgrade செய்வது ஆதரிக்கப்படுவதில்லை. இதற்குத் திரும்பப் பெறுவதற்கான (rollback) கட்டளை எதுவும் இல்லை.

எனவே, பாதுகாப்பான restore முறை என்பது எளிமையானது. dump கோப்பை உருவாக்கிய அதே பதிப்பை இயக்கி, அதை restore செய்யவும். பின் login செய்து, timeline முழுமையாக உள்ளதா என்பதை உறுதிப்படுத்தவும். அதன் பிறகே upgrade செய்யவும். ஒவ்வொரு வெளியீடாகப் படிப்படியாக upgrade செய்யவும்; ஒவ்வொரு முறை பதிப்பை உயர்த்தும்போதும் IMMICH_VERSION-ஐ மாற்றி, docker compose pull && docker compose up -d கட்டளையை இயக்கவும். ஒரு வாரத்திற்கான dump கோப்புகளைச் சேமித்து வைப்பது இங்கு உதவும்: ஒருவேளை சமீபத்திய dump கோப்பு, தோல்வியுற்ற upgrade-ன் போது எடுக்கப்பட்டிருந்தால், முந்தைய நாள் dump கோப்பு repository-ல் பாதுகாப்பாக இருக்கும்.

ஒவ்வொரு மாதமும் backup-ஐ சரிபார்க்கவும்

நீங்கள் ஒருமுறை கூட restore செய்யாத backup என்பது வெறும் ஊகம் மட்டுமே. மாதத்திற்கு ஒருமுறை, அதை ஒரு தற்காலிக instance-ல் restore செய்து ஒரு புகைப்படத்தைப் பார்க்கவும். இந்தச் செயல்முறைக்கு சுமார் இருபது நிமிடங்கள் ஆகும்; இந்தப் பக்கத்தில் உள்ள மற்ற அனைத்தையும் ஒரு மீட்புத் திட்டமாக (recovery plan) மாற்றுவது இது மட்டுமே.

restic snapshots
restic stats latest

snapshots கட்டளை நேற்று இரவு நடந்த backup-ஐக் காட்ட வேண்டும். stats latest கட்டளை உங்கள் library-ன் அளவிற்கு நெருக்கமான அளவைக் காட்ட வேண்டும், சில megabytes-ஐ மட்டும் காட்டக்கூடாது.

ஒரு தற்காலிக directory-ல் restore செய்யவும், முடிந்தால் ஒரு spare host-ஐப் பயன்படுத்தவும்:

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

restore செய்யப்பட்ட தொகுப்பிலிருந்து docker-compose.yml மற்றும் .env ஆகியவற்றை நகலெடுத்து, அந்த நகலில் மூன்று மாற்றங்களைச் செய்யவும். UPLOAD_LOCATION மற்றும் DB_DATA_LOCATION ஆகியவற்றை /tmp/immich-drill-க்குக் கீழே உள்ள directory-களுக்குச் சுட்டிக்காட்டவும். Web port-ஐ வேறொரு இடத்திற்கு மாற்றவும், 2283:2283-க்கு பதிலாக 12283:2283-ஐப் பயன்படுத்தவும். container_name: வரிகளை நீக்கவும், ஏனெனில் stock compose file-ல் immich_server போன்ற பெயர்கள் hard-code செய்யப்பட்டிருக்கும். இதனால் ஒரே host-ல் இரண்டாவது stack-ஐ உருவாக்கும்போது மோதல் ஏற்பட்டு, Docker அதை உருவாக்க மறுக்கும்.

மேலே உள்ள restore வரிசையை இயக்கவும்: database-ஐ மட்டும் எடுத்து, dump-ஐ replay செய்யவும், பிறகு docker compose up -d-ஐ இயக்கவும். இப்போது உறுதிப்படுத்தும் நான்கு சோதனைகளைச் செய்யவும்.

1. இந்தச் சோதனைக்கு முன்பு நீங்கள் பயன்படுத்திய அதே கடவுச்சொல்லைக் கொண்டு login செய்யவும். கணக்குகள் வேலை செய்தால், dump சரியாக restore செய்யப்பட்டுள்ளது என்று அர்த்தம்.
2. Timeline-ஐத் திறந்து, மிகப்பழைய மாதத்திற்குச் செல்லவும். அனைத்துத் தேதிகளிலும் புகைப்படங்கள் இருந்தால், சமீபத்திய தரவுகள் மட்டுமல்லாமல் அனைத்து வரிசைகளும் (rows) மீட்கப்பட்டுள்ளன என்று அர்த்தம்.
3. ஒரு புகைப்படத்தை முழு அளவில் திறந்து, அதன் அசல் கோப்பை (original) தரவிறக்கம் செய்யவும்.
4. உங்கள் நேரடி library-ல் உள்ள அதே கோப்புடன் sha256sum மூலம் அதை ஒப்பிடவும். Hash மதிப்புகள் ஒன்றாக இருந்தால், restic வழியாகத் தரவுகள் சிதையாமல் வந்துள்ளன என்று அர்த்தம்.

பிறகு, சோதனை செய்த directory-ல் docker compose down -v கட்டளையைப் பயன்படுத்தி அந்தச் சோதனையை முடிவுக்குக் கொண்டுவரவும், மேலும் /tmp/immich-drill-ஐ நீக்கவும். இந்தத் தேதியை நீங்கள் பார்க்கும் இடத்தில் குறித்து வைக்கவும், ஏனெனில் இதன் மதிப்பு அடுத்த மாதம் மீண்டும் இதைச் செய்வதிலேயே உள்ளது. நீங்கள் எந்த photo server-ஐத் தேர்ந்தெடுக்கலாம் என்று இன்னும் முடிவு செய்யவில்லை என்றால், PhotoPrism மற்றும் Immich ஒப்பீடு இந்த விஷயத்தில் அவை எவ்வாறு வேறுபடுகின்றன என்பதை விளக்குகிறது.

FAQ

Immich-ஐ backup எடுக்கும்போது அதை நிறுத்த வேண்டுமா?

immich_server-ஐ நிறுத்திவிட்டு, immich_postgres-ஐ இயங்க விடவும். Database-ஐ இடைநிறுத்தம் செய்ய வேண்டிய அவசியமில்லை, ஏனெனில் pg_dump ஒரு MVCC snapshot-க்குள் வாசிப்பதால், மற்றவை எதை எழுதினாலும் அது ஒரு சீரான நிலையை மட்டுமே பார்க்கும். கோப்புகளைப் பொறுத்தவரை, அவற்றை நிறுத்துவது அவசியம்: server புதிய பதிவேற்றங்களை எழுதும்போதும், storage template job கோப்புகளை directory-களுக்கு இடையே நகர்த்தும்போதும், backup கருவி ஒரு கோப்பை பாதியிலேயே வாசித்து, பிழையின்றி முழுமையற்ற நகலைச் சேமிக்கக்கூடும். Snapshot-க்கு முன் docker stop immich_server மற்றும் அதற்குப் பின் docker start immich_server செய்வதன் மூலம் இந்த சிக்கலைத் தவிர்க்கலாம்.

pg_dump-ஐ இயக்குவதற்குப் பதிலாக Postgres data folder-ஐ நகலெடுக்கலாமா?

கூடாது. இயங்கிக்கொண்டிருக்கும் data directory-ஐ நகலெடுக்கும்போது, வெவ்வேறு நேரங்களில் வெவ்வேறு கோப்புகள் வாசிக்கப்படும். இதனால் ஒரு சீரான நிலை கிடைக்காது; Postgres அதைத் தொடங்கும்போது PANIC: could not locate a valid checkpoint record பிழையைக் காட்டும் அல்லது பிற்காலத்தில் சேதமடைந்த பக்கங்களால் தோல்வியடையும். அனைத்தையும் நிறுத்திவிட்டு நகலெடுத்தாலும், அது அந்த குறிப்பிட்ட database build-உடன் பிணைக்கப்பட்டிருக்கும்: Immich ஒரு குறிப்பிட்ட vector-search extension பதிப்புகளுடன் கூடிய Postgres 14 image-ஐப் பயன்படுத்துகிறது, அந்த directory வேறு எந்த பதிப்பிலும் திறக்காது. SQL dump என்பது plain text வடிவில் இருப்பதால், அதை எந்த இணக்கமான server-லும் மீண்டும் ஏற்ற முடியும்.

restore செய்த பிறகு எனது Immich timeline ஏன் காலியாக உள்ளது?

Timeline என்பது database வரிசைகளிலிருந்து உருவாக்கப்படுகிறது, நீங்கள் database இல்லாமல் கோப்புகளை மட்டும் restore செய்துள்ளீர்கள். Immich ஒருபோதும் upload/-ஐ ஸ்கேன் செய்து புகைப்படங்களை மீண்டும் கண்டறியாது, எனவே database வரிசைகள் இல்லாத கோப்புகள் கண்ணுக்குத் தெரியாது. புகைப்படங்கள் அப்படியேதான் இருக்கும். Server-ஐ நிறுத்திவிட்டு, புதிதாக initialize செய்யப்பட்ட Postgres-ல் dump-ஐ மீண்டும் ஏற்றி, பிறகு stack-ஐத் தொடங்கவும். ஒருவேளை timeline முழுமையாக இருந்து, ஆனால் எந்தப் புகைப்படமும் திறக்கவில்லை என்றால், சிக்கல் தலைகீழாக உள்ளது: library, upload மற்றும் profile ஆகியவை container-க்குள் இணைக்கப்பட்ட directory-க்குள் நேரடியாக இல்லை என்று அர்த்தம். அதை docker exec immich_server ls /data மூலம் சரிபார்க்கவும்.

Immich-ல் எந்தெந்த folder-களை backup-லிருந்து தவிர்க்கலாம்?

thumbs மற்றும் encoded-video ஆகியவை அசல் கோப்புகளிலிருந்து மீண்டும் உருவாக்கப்படக்கூடியவை, மேலும் DB_DATA_LOCATION dump-லிருந்து மீண்டும் கட்டமைக்கப்படும், எனவே இவற்றை backup-ல் சேர்க்க வேண்டிய அவசியமில்லை. இவற்றைத் தவிர்ப்பது backup சேமிப்பகத்தைச் சேமிக்கும், ஆனால் restore செய்த பிறகு அவற்றை மீண்டும் உருவாக்க அதிக CPU நேரம் தேவைப்படும். பெரிய library-க்கு previews மற்றும் transcodes உருவாக்குவது பல மணிநேரம் எடுக்கும், இதை Administration > Jobs பகுதிக்குச் சென்று விடுபட்ட assets-க்கு இயக்கலாம். நீங்கள் ஒருபோதும் தவிர்க்கக்கூடாதவை library, upload மற்றும் profile ஆகும், ஏனெனில் இவைதான் ஒவ்வொரு அசல் கோப்பின் ஒரே நகலைக் கொண்டுள்ளன.

Immich dump-ஐ புதிய பதிப்பில் restore செய்யலாமா?

பொதுவாக முடியும், ஏனெனில் server தொடங்கும்போது நிலுவையில் உள்ள migrations-ஐச் செயல்படுத்தி schema-வை மேம்படுத்தும். ஆனால் இதற்கு நேர்மாறானது தோல்வியடையும்: Immich downgrade-ஐ ஆதரிக்காது, patch releases-க்கு இடையிலும் இது பொருந்தும். எனவே புதிய பதிப்பில் எடுக்கப்பட்ட dump-ஐ பழைய server-ல் ஏற்ற முடியாது. Dump-ஐ உருவாக்கிய அதே பதிப்பில் IMMICH_VERSION-ஐப் பயன்படுத்தி restore செய்யவும், timeline முழுமையாக உள்ளதா என்பதை உறுதிப்படுத்தவும், அதன் பிறகு upgrade செய்யவும். ஒவ்வொரு dump-உடன் அதன் பதிப்பை docker inspect --format '{{.Config.Image}}' immich_server மூலம் குறித்து வைக்கவும், ஏனெனில் இயல்பான IMMICH_VERSION=v3 என்பது எந்தத் தகவலையும் தராத ஒரு floating tag ஆகும்.