Paano Mag-backup at Mag-restore ng Immich sa VPS

Mga Dapat Nilalaman ng Immich Backup

Ang Immich backup ay binubuo ng tatlong bagay na nakuhanan sa parehong oras. Ang mga original sa UPLOAD_LOCATION. Isang SQL dump ng Postgres database. Ang .env at docker-compose.yml na naglalarawan sa stack. Ang pag-restore ay nangangahulugang i-replay ang dump sa bagong database habang naka-stop ang Immich server, at saka lamang simulan ang natitirang bahagi ng stack. Kapag mali ang pagkakasunod-sunod, magkakaroon ka ng gumaganang Immich na walang laman ang timeline kahit puno ang disk.

Mahalaga ang paghihiwalay na ito dahil inilalagay ng Immich ang state nito sa dalawang lugar na walang alam sa isa’t isa. Nasa Postgres ang bawat album, bawat face cluster, bawat shared link, bawat user account at API key, pati ang naka-store na path ng bawat asset. Nasa filesystem ang mga pixel. Kapag ni-restore mo ang mga file nang walang database, walang ipapakita ang Immich. Kapag ni-restore mo ang database nang walang mga file, bubukas ang bawat asset bilang broken image.

Ang mga command dito ay para sa Immich v3.1.0, ang release na kasalukuyan noong unang bahagi ng Agosto 2026. Mabilis maglabas ng update ang project, at higit sa isang beses nang nagbago ang documented backup procedure. Kaya tingnan muna ang aktuwal na version na pinapatakbo mo bago ka magkopya ng anuman. Kung hindi pa naka-start ang stack, magsimula sa Immich install guide at bumalik dito.

Alamin kung saan tumuturo ang iyong mga path

Dalawang variable sa .env ang nagtatakda ng lahat sa pahinang ito. Ang UPLOAD_LOCATION ay ang parent directory kung saan isinusulat ng Immich ang lahat ng media. Ang DB_DATA_LOCATION ay ang data directory ng Postgres.

Itinatakda ng stock na example.env ang UPLOAD_LOCATION=./library, na nakalilitong default dahil gumagawa ang Immich ng folder na library sa loob nito. Mapupunta ang iyong mga original sa ./library/library. Sa halip, magtakda ng absolute path upang hindi kailanman umasa ang backup script sa directory kung saan mo ito pinatakbo.

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

Sa loob ng UPLOAD_LOCATION, gumagawa ang Immich ng ilang folder. Tatlo sa mga ito ang naglalaman ng data na hindi kayang buuing muli ng anumang job:

• library: ang mga original, na nakaayos ayon sa iyong storage template
• upload: mga original na hindi pa naililipat sa layout ng template, pati mga upload na kasalukuyang isinasagawa
• profile: mga larawan sa user profile

Kapag nawala ang library, wala na ang larawan. Walang ibang kopya ng original na itinatago ang Immich saanman.

Bakit hindi backup ang pagkopya sa direktoryo ng data ng Postgres

Mukhang madaling kopyahin ang DB_DATA_LOCATION. Direktoryo ito, makokopya ito ng rsync, at matatapos ang pagkopya nang walang error. Hindi pa rin ito backup, dahil may dalawang problemang maaaring mangyari.

Ang una ay tearing. Isinusulat muna ng Postgres sa write-ahead log (WAL) ang bawat pagbabago, at saka lamang ito inilalapat sa mga table file kapag may checkpoint. Kaya sa anumang sandali, maaaring nasa kalagitnaan ng pagbabago ang mga file sa disk. Kung tumatagal nang apat na minuto ang rolling copy, mababasa nito ang unang file sa 02:00 at ang huling file sa 02:04. Hindi kabilang ang dalawang file na ito sa iisang transaction. Kapag sinimulan mo ang Postgres gamit ang resulta, tatanggi itong magsimula at lalabas ang PANIC: could not locate a valid checkpoint record, o magsisimula ito ngunit hihinto sa unang pagbasa ng sirang page at lalabas ang invalid page in block 1234 of relation base/16384/.... Hindi na mare-recover ang alinman sa mga ito mula sa kopyang iyon.

Nalalapat pa rin ang ikalawang dahilan kahit ihinto mo muna ang lahat. Nakatali ang direktoryo ng data ng Postgres sa eksaktong binaries na sumulat dito. Pini-pin ng Immich ang database image gamit ang digest, na kasalukuyang ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0. Postgres 14 ito na may dalawang vector-search extension na naka-compile. Hindi mabubuksan ng ibang Postgres major version ang data directory na ginawa ng build na iyon. Hindi rin ito mabubuksan ng build na may ibang version ng mga extension. Kailangang eksaktong magaya ng restore host mo ang image. Walang ganitong dependency ang SQL dump: text ito, at maaaring i-replay ito ng anumang compatible na server.

Direktang nilulutas ng pg_dump ang problema ng tearing. Binabasa nito ang buong database sa loob ng isang snapshot na MVCC (multi-version concurrency control), kaya nakikita nito ang database sa eksaktong kalagayan nito sa isang sandali habang nagpapatuloy ang ibang writes. Dahil dito, hindi mo kailangang ihinto ang Postgres para gumawa ng dump.

Mga maaaring hindi isama sa backup

Awtomatikong nabubuo muli ang mga ito, kaya maaari mong laktawan:

• thumbs: mga preview at thumbnail image
• encoded-video: transcoded na video
• DB_DATA_LOCATION: muling binubuo mula sa dump
• ang model-cache Docker volume: mga machine learning model na muling dina-download kapag kailangan

May kapalit ang paglaktaw sa mga ito. Ang muling pagbuo ng mga thumbnail at transcode para sa malaking library ay maaaring umubos ng ilang oras na CPU sa maliit na VPS, at puro gray placeholder ang ipinapakita sa timeline habang ginagawa ito. Patakbuhin muli ang mga ito mula sa Administration > Jobs, at itakda ang "Generate Thumbnails" at "Transcode Videos" na tumakbo para sa mga nawawalang asset. Kung may sapat na espasyo ang backup target, isama ang mga ito para hindi na maghintay sa rebuild. Kung malapit ka na sa storage limit, alisin ang mga ito at magplano para sa rebuild. Ipinaliliwanag sa Pagsukat sa laki ng Immich library kung gaano kalaki ang mga folder na ito kumpara sa mga original.

May isa pang folder na dapat mong malaman. Ang UPLOAD_LOCATION/backups ay naglalaman ng sariling automatic database dump ng Immich. Isinusulat ang mga ito araw-araw sa 02:00 at pinananatili ang pinakahuling 14. Maaari itong i-configure sa Administration > Settings > Backup. Wala itong dagdag na gastos at talagang kapaki-pakinabang. Gayunman, nasa parehong disk ang mga ito ng library na pinoprotektahan nila. Nakakatulong ang mga ito sa maling migration, pero hindi sa server na tuluyang nasira. Gumawa pa rin ng sarili mong dump, dahil ang dump na ikaw mismo ang nag-trigger ay nalilikha sa parehong oras ng file snapshot na kasama nito.

Kunin ang database dump

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

Palitan ang immich at postgres ng iyong DB_DATABASE_NAME at DB_USERNAME kung binago mo ang mga ito. Naglalagay ang --clean --if-exists ng DROP ... IF EXISTS sa unahan ng bawat CREATE, kaya nire-replay ang dump sa database na mayroon nang mga object sa halip na huminto sa unang object.

Narito ang detalyeng tahimik na sumisira sa mga backup script. Pipeline ang command na iyon, at ang exit status na iniuulat ng shell ay ang status ng huling command sa pipeline. Kung mabigo ang pg_dump dahil sa maling password o hindi tumatakbong container, tatanggap ang gzip ng walang laman na stream, magsusulat ng ganap na valid na gzip file, at lalabas na may status na 0. Itatala ng iyong script na matagumpay ang operasyon, pero mayroon ka lamang 20-byte na backup. Ilagay ang pipefail sa itaas ng bawat backup script:

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

Pagkatapos, suriin ang resulta sa halip na umasa sa exit code:

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

Ang unang linya ng isang maayos na dump ay -- PostgreSQL database dump. Ang file na ilang daang byte lamang ang laki ay isang bigong dump, anuman ang iniulat ng script.

Itala kung aling build ang sumulat nito, kasabay ng dump:

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

Huwag umasa sa .env para rito. Itinatakda ng stock file ang IMMICH_VERSION=v3, isang floating tag na sumusunod sa bawat 3.x release, kaya wala itong sinasabi tungkol sa aktuwal na build na sumulat ng dump. I-pin din ang eksaktong tag sa .env.

I-pause ang server, pagkatapos ay mag-snapshot gamit ang restic

Hindi immutable ang mga file sa ilalim ng UPLOAD_LOCATION habang tumatakbo ang Immich. Nagsusulat ang server ng mga bagong upload, at inililipat ng storage template job ang mga file sa pagitan ng mga directory. Kung magbabasa ang backup tool ng file habang isinusulat pa ito, ise-save nito ang mga byte na nabasa nito na para bang iyon na ang buong file, at walang mag-uulat ng error. Ihinto ang server container sa buong tagal ng run:

docker stop immich_server

Panatilihing tumatakbo ang immich_postgres dahil kailangan ito ng dump. Offline ang web interface at mobile app hanggang sa muli mong simulan ang server. Karaniwan itong ayos sa isang household instance na tumatakbo nang 03:00.

Ang restic ay angkop dito dahil nagde-deduplicate at nag-e-encrypt ito bago may anumang lumabas sa server. Ituro ito sa isang repository na wala sa server na ito:

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

Ganoon din ang object storage, at mas mainam ito kung gusto mong lubusang mailagay ang kopya sa labas ng sarili mong 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

Ang endpoint na iyon ay maaaring isang MinIO bucket na ikaw mismo ang nagpapatakbo sa isang pangalawang machine, o anumang S3-compatible provider. Pinoprotektahan ka ng repository sa parehong disk ng library laban sa maling pag-delete, ngunit wala na itong ibang napoprotektahan.

Pagkatapos, gawin ang snapshot na naglilista ng eksaktong mga kailangan:

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

Binabasa ng restic ang buong tree sa bawat run, ngunit nag-u-upload lamang ito ng mga block na hindi pa nito nakikita. Kaya inililipat ng unang snapshot ang buong library mo, at inililipat naman ng bawat kasunod na snapshot ang mga bagong larawan sa araw na iyon.

Retention at mga key na dapat nakaimbak sa ibang lokasyon

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

Inaalis ng forget ang mga snapshot mula sa index. Ang --prune naman ang bahagi na nagde-delete ng data na huling tinukoy ng mga snapshot na iyon. Kung patatakbuhin mo ang forget nang walang --prune, hindi bababa ang storage bill mo.

Mura lang ang structure checks, kaya magpatakbo nito isang beses bawat linggo:

restic check

Bine-verify nito kung consistent ang repository metadata. Hindi nito binabasa ang data mo. Isang beses bawat buwan, muling basahin ang isang sample at i-check ito laban sa mga hash na naka-record para rito:

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

Ito lang ang check na nakakahuli ng silent corruption sa storage backend, dahil nagda-download ito ng mga totoong block at muling kino-compute ang mga checksum ng mga ito. Ang buong --read-data sa isang photo library ay nangangahulugang ida-download ang buong repository. Sa metered object storage, may aktuwal na gastos ito, kaya ang rolling subset ang bersyong aktuwal na ginagamit ng mga tao.

Ngayon ang bahaging madalas nilalaktawan. Hindi mare-recover ang password ng restic repository. Walang reset at walang support ticket. Kung ang nag-iisang kopya ay nasa /root/.restic-password sa server na sinusubukan mong i-restore, naka-encrypt na noise ang iyong mga backup. Ganoon din ang object storage access key at ang DB_PASSWORD mula sa .env. Itago ang lahat ng ito sa lugar na hindi nakadepende sa pagiging aktibo ng machine na ito: maaaring naka-print at nasa drawer, o nasa password manager na tumatakbo sa ibang hardware. Kung self-hosted din ang manager na iyon, kailangan din nito ng parehong pag-iingat, at hiwalay na gawain ang pagba-back up sa Vaultwarden.

I-restore ang Immich sa tamang pagkakasunod-sunod

Dito nakasalalay kung magiging maayos ang timeline o magiging walang laman ito matapos ang restore. Sundin ang sequence na ito sa bagong host.

Ibalik muna ang config. Tinutukoy nito kung aling version ang patatakbuhin at kung saan nakaturo ang mga path.

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

I-pin ang version bago magsimula ang anuman. Basahin ang immich-version.txt, itakda ang IMMICH_VERSION sa .env sa eksaktong tag na iyon, at huwag munang gamitin ang pinakabagong release. Hindi sinusuportahan ng Immich ang pag-downgrade, kahit sa pagitan ng patch releases. Kaya kung magsisimula ang mas bagong server gamit ang mas lumang dump at patatakbuhin nito ang migrations, wala nang paraan para bumalik.

I-restore ang media.

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

Pagkatapos, ilipat ang library, upload at profile upang direktang nasa loob ang mga ito ng itinuturo ng UPLOAD_LOCATION sa host na ito. Maaaring magbago ang host path mismo dahil bina-bind ng compose file ang directory na iyon sa fixed path sa loob ng container. Hindi maaaring magbago ang layout sa loob nito.

Simulan nang hiwalay ang database. Iwanang walang laman ang DB_DATA_LOCATION upang mag-initialize ang Postgres ng bagong cluster.

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

Ini-print ng pg_isready ang accepting connections kapag natapos ang first-time setup, na karaniwang tumatagal ng ilang segundo. Binubuo ng docker compose create ang lahat ng container nang hindi sinisimulan ang mga ito. Iyan ang layunin ng hakbang na ito: hindi pa dapat tumakbo ang Immich server. Kapag nagsimula ang server laban sa walang-lamang database, ia-apply nito ang migrations, gagawa ito ng bagong schema, at hihilingin nitong gumawa ka ng bagong admin account. Pagkatapos, ibinabalik mo ang dump sa ilalim ng tumatakbong application.

I-replay ang 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

May dalawang bahagi rito na mahalaga. Ginagamit ang sed dahil nagsusulat ang pg_dump ng walang-lamang search_path sa output nito bilang safety measure. Dahil dito, hindi makakapag-resolve ang mga unqualified name sa dump sa hindi inaasahang schema. Nasa public ang vector-search types ng Immich. Kaya kapag walang laman ang search path, maaabot ng restore ang unang column na may vector type at hihinto ang psql na may ERROR: type "vector" does not exist. Maaayos ito kapag ibinalik sa path ang public.

Binabalot ng --single-transaction --set ON_ERROR_STOP=on ang buong restore sa isang transaction na nag-a-abort sa unang error. Makakakuha ka ng kumpletong database o ng database na hindi nabago. Kung wala ito, ang failure sa kalagitnaan ay mag-iiwan ng database na nagsisimula at tumatanggap ng login mo ngunit may hindi tiyak na bilang ng nawawalang album. Maaaring ilang linggo mo pa ito matuklasan.

Ngayon, simulan ang lahat.

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

Maghintay ng startup line na gaya ng Immich Server is listening on, pagkatapos ay buksan ang port 2283 at mag-log in gamit ang dati mong credentials dahil kasama sa dump ang mga user account. Kung sa halip ay hinihiling ng login page na gumawa ka ng unang admin account, hindi na-restore ang database. Ihinto ang proseso at basahin muli ang psql output.

May isang babala tungkol sa official restore instructions na nagsisimula sa docker compose down -v. Tinatanggal ng -v ang named volumes. Sa stock compose file, bind mounts ang UPLOAD_LOCATION at DB_DATA_LOCATION kaya hindi sila naaapektuhan. Kung pinalitan mo ang alinman sa mga ito ng named volume, tatanggalin ng command na iyon ang iyong mga larawan. Basahin muna ang compose file bago mo ito i-type.

Bakit walang laman ang timeline pagkatapos ng restore

Ang timeline ay binubuo mula sa mga row sa database. Hindi kailanman sine-scan ng Immich ang upload/ sa pag-boot para muling hanapin ang mga photo, dahil ang file na walang row ay walang owner, petsa, o album. Kaya ang pinakakaraniwang maling restore ay naibalik ang mga file pero nawawala ang database. Nagsisimula ang Immich, gumagawa ng walang-lamang schema, at nagbibigay sa iyo ng gumaganang instance na walang laman kahit puno ng mga photo mo ang disk. Walang nawala. Wala rin namang makikita. Ang solusyon ay i-replay ang dump habang nakahinto ang server, gaya mismo ng nasa itaas.

Mas tahimik ang ikalawang bersyon. Nare-restore ang database, napupuno ang timeline ng mga entry, pero hindi mabuksan ang bawat asset. Ibig sabihin, tumuturo ang mga row sa mga file na hindi makita ng container. Karaniwan itong nangyayari dahil ang library, upload at profile ay isang level na mas malalim pagkatapos ng restic restore --target /restore na walang naglipat sa tamang lokasyon. Suriin ito mula sa loob ng container sa halip na manghula:

docker exec immich_server ls /data

Naka-mount ang UPLOAD_LOCATION sa /data sa stock compose file, kaya dapat makita sa listing na iyon ang library, upload at profile. Kung walang laman ang directory o may hiwalay na srv folder, nakaturo ang bind mount sa maling level at maayos ang mga row.

Pagtutugma ng version sa backup at restore

Madalas maglabas ng bagong release ang Immich, at kasabay nito ang paggalaw ng schema. Dahil dito, taglay ng dump ang schema ng server na gumawa nito.

Karaniwang gumagana ang pag-restore ng mas lumang dump sa mas bagong server, dahil inilalapat ng server ang mga nakabinbing migration sa pagsisimula nito at ina-update ang schema nang sunod-sunod. Sinusubukan ang prosesong ito sa release sequence. Nagkakaroon ng problema kapag lumaktaw ng ilang major version sa isang hakbang. Pinapanatili ng project ang mga breaking change sa major release at inililista ang mga ito sa changelog.

Hindi gumagana ang pag-restore ng mas bagong dump sa mas lumang server. May mga table at column ang dump na hindi kilala ng mas lumang code. Sinasabi rin ng Immich na hindi suportado ang pag-downgrade, kahit sa pagitan ng mga patch release. Walang rollback command na maaaring gamitin.

Kaya simple at maingat ang ligtas na restore. Patakbuhin ang eksaktong version na gumawa ng dump, i-restore ito, mag-log in, at tiyaking kumpleto ang timeline. Mag-upgrade lamang pagkatapos nito. Isagawa ang upgrade nang tig-iisang release, i-update ang IMMICH_VERSION, at patakbuhin ang docker compose pull && docker compose up -d pagkatapos ng bawat update. Makakatulong din ang pagpapanatili ng mga dump na saklaw ang isang linggo. Kung lumabas na ginawa ang pinakabagong dump habang bigo ang isang upgrade, nasa repository pa rin ang dump mula kahapon.

I-verify ang backup bawat buwan

Ang backup na hindi mo pa kailanman na-restore ay palagay lamang. Minsan bawat buwan, i-restore ito sa isang throwaway instance at tingnan ang isang larawan. Humigit-kumulang dalawampung minuto ang drill, at ito lamang ang nagiging aktuwal na recovery plan sa buong page na ito.

restic snapshots
restic stats latest

Dapat ilista ng snapshots ang run noong nakaraang gabi. Dapat mag-ulat ang stats latest ng sukat na malapit sa laki ng iyong library, hindi ilang megabytes lamang.

Mag-restore sa isang scratch directory, kung maaari ay sa spare host:

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

Kopyahin ang docker-compose.yml at .env palabas ng na-restore na set, pagkatapos ay baguhin ang tatlong bagay sa kopya. Ituro ang UPLOAD_LOCATION at DB_DATA_LOCATION sa mga directory sa ilalim ng /tmp/immich-drill. Ilathala ang web port sa ibang lugar, 12283:2283 sa halip na 2283:2283. Tanggalin ang mga linyang container_name:, dahil nagha-hard-code ang stock compose file ng mga pangalan gaya ng immich_server. Dahil dito, nagkakaroon ng conflict ang pangalawang stack sa parehong host at tumatanggi ang Docker na likhain ito.

Isagawa ang restore sequence mula sa itaas: database lamang, i-replay ang dump, pagkatapos ay docker compose up -d. Gawin ngayon ang apat na check na magpapatunay na gumagana ito.

1. Mag-log in gamit ang password na ginamit mo bago ang drill. Ibig sabihin ng gumaganang account ay na-restore ang dump.
2. Buksan ang timeline at mag-scroll sa pinakamatandang buwan. Ibig sabihin ng mga asset sa buong saklaw ng petsa ay naibalik ang lahat ng row, hindi lamang ang mga kamakailan.
3. Buksan ang isang larawan sa full size at i-download ang original.
4. Ikumpara ito sa parehong file sa iyong live library gamit ang sha256sum. Ibig sabihin ng magkakatugmang hash ay nakaligtas ang mga byte sa round trip sa pamamagitan ng restic.

Pagkatapos, i-tear down ang drill gamit ang docker compose down -v sa drill directory at i-delete ang /tmp/immich-drill. Isulat ang petsa sa lugar na makikita mo, dahil nakasalalay nang buo ang halaga nito sa pag-uulit nito sa susunod na buwan. Kung nagpapasya ka pa kung aling photo server ang gagamitin, tinatalakay sa paghahambing ng PhotoPrism at Immich kung paano nagkakaiba ang dalawa partikular sa aspetong ito.

FAQ

Kailangan ko bang ihinto ang Immich para ma-back up ito?

Ihinto ang immich_server at hayaang tumatakbo ang immich_postgres. Hindi kailangang i-pause ang database dahil nagbabasa ang pg_dump sa loob ng isang MVCC snapshot at nakakakita ng iisang consistent na sandali, anuman ang iba pang nagsusulat. Ang mga file ang kailangang ihinto: nagsusulat ang server ng mga bagong upload, at inililipat ng storage template job ang mga file sa pagitan ng mga directory. Dahil dito, maaaring mabasa ng backup tool ang file habang isinusulat pa ito at makapag-save ng truncated copy nang walang error. Inaalis ng docker stop immich_server bago ang snapshot at docker start immich_server pagkatapos nito ang race na iyon.

Maaari ko bang kopyahin ang Postgres data folder sa halip na patakbuhin ang pg_dump?

Hindi. Ang rolling copy ng live data directory ay nagbabasa ng magkakaibang file sa magkakaibang sandali, kaya hindi iisang consistent state ang resulta. Tinatanggihan ito ng Postgres sa startup gamit ang PANIC: could not locate a valid checkpoint record, o nabibigo ito kalaunan dahil sa damaged page. Kahit ang kopyang ginawa habang nakahinto ang lahat ay nakatali sa eksaktong database build: nagpi-pin ang Immich ng Postgres 14 image na may partikular na vector-search extension versions, at hindi mabubuksan ang directory sa ibang setup. Plain text ang SQL dump at maaari itong i-replay sa anumang compatible server.

Bakit walang laman ang timeline ng Immich pagkatapos ng restore?

Dahil binubuo ang timeline mula sa mga database row, pero ni-restore mo ang mga file nang walang database. Hindi kailanman ini-scan ng Immich ang upload/ upang muling hanapin ang mga photo, kaya nananatiling invisible ang mga file na walang row. Hindi nagalaw ang mismong mga photo. Ihinto ang server, i-replay ang dump sa bagong initialised na Postgres, at pagkatapos ay simulan ang stack. Kung puno naman ang timeline pero hindi mabuksan ang bawat photo, kabaligtaran ang problema: ang library, upload at profile ay wala mismo sa directory na naka-bind sa container. Suriin ito gamit ang docker exec immich_server ls /data.

Aling mga folder ng Immich ang maaari kong laktawan sa backup?

Ang thumbs at encoded-video ay nire-regenerate mula sa originals, at ang DB_DATA_LOCATION ay nire-rebuild mula sa dump, kaya hindi kailangang isama ang alinman sa mga ito sa backup set. Kapag nilaktawan ang mga ito, oras ang ginugugol pagkatapos ng restore sa halip na storage bago ang restore, dahil inaabot ng ilang oras ng CPU ang pag-rebuild ng previews at transcodes para sa malaking library. Isinasagawa ito mula sa Administration > Jobs laban sa missing assets. Hindi maaaring laktawan kailanman ang library, upload at profile dahil nasa mga ito ang tanging kopya ng bawat original.

Maaari ba akong mag-restore ng Immich dump sa mas bagong version?

Karaniwan, oo, dahil inilalapat ng server ang mga pending migration nito sa startup at ina-update ang schema nang sunod-sunod. Kabaligtaran ang nabibigo: hindi sinusuportahan ng Immich ang downgrade, kahit sa pagitan ng patch release, kaya hindi mai-load sa mas lumang server ang dump mula sa mas bagong release. Mag-restore gamit ang IMMICH_VERSION na naka-pin sa release na sumulat ng dump, tiyaking kumpleto ang timeline, at saka mag-upgrade. Itala ang version sa tabi ng bawat dump gamit ang docker inspect --format '{{.Config.Image}}' immich_server dahil floating tag ang default na IMMICH_VERSION=v3 at wala itong ibinibigay na kapaki-pakinabang na impormasyon.