Jinsi ya kufanya backup na restore ya Immich kwenye VPS

Vitu vinavyopaswa kuwemo kwenye backup ya Immich

Backup ya Immich ni vitu vitatu vinavyonaswa kwa wakati mmoja. Faili asilia zilizo chini ya UPLOAD_LOCATION. SQL dump ya database ya Postgres. Pamoja na .env na docker-compose.yml zinazoelezea stack hiyo. Kurejesha (restore) kunamaanisha kuingiza dump hiyo kwenye database mpya wakati seva ya Immich imesimamishwa, na kuanzisha stack nyingine baada ya hapo pekee. Ukikosea mpangilio, utaishia na Immich inayofanya kazi lakini inayoonyesha timeline tupu juu ya diski iliyojaa data.

Mgawanyo huu ni muhimu kwa sababu Immich huhifadhi hali yake katika sehemu mbili ambazo hazijui chochote kuhusu nyingine. Postgres inashikilia kila albamu, kila kundi la nyuso, kila link iliyoshirikiwa, kila akaunti ya mtumiaji na API key, pamoja na njia (path) iliyohifadhiwa ya kila asset. Mfumo wa faili (filesystem) unashikilia picha zenyewe. Ukirejesha faili bila database, Immich haitaonyesha kitu. Ukirejesha database bila faili, kila asset itafunguka kama picha iliyoharibika.

Amri zilizopo hapa zimeandikwa kwa ajili ya Immich v3.1.0, toleo lililopo sasa mwanzoni mwa Agosti 2026. Mradi huu hutoa matoleo mapya kwa haraka na utaratibu wa backup uliowekwa kwenye nyaraka umebadilika zaidi ya mara moja, kwa hivyo hakikisha toleo unalotumia kabla ya kunakili chochote. Ikiwa stack haijaanza kufanya kazi, anza na mwongozo wa usakinishaji wa Immich kisha urudi hapa.

Elewa njia zako zinaelekeza wapi

Vigezo viwili katika .env huamua kila kitu kwenye ukurasa huu. UPLOAD_LOCATION ni saraka kuu ambayo Immich huandikia vyombo vyote vya habari. DB_DATA_LOCATION ni saraka ya data ya Postgres.

example.env ya kawaida huweka UPLOAD_LOCATION=./library, ambayo ni chaguo-msingi linalochanganya, kwa sababu Immich hutengeneza folda inayoitwa library ndani yake. Faili zako asilia huishia kwenye ./library/library. Badala yake, weka njia kamili (absolute path), ili hati ya kuhifadhi nakala (backup script) isitegemee saraka uliyokuwa ukiitumia wakati wa kuiendesha.

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

Ndani ya UPLOAD_LOCATION, Immich hutengeneza folda kadhaa. Tatu kati ya hizo hushikilia data ambayo hakuna kazi inayoweza kuijenga upya:

• library: faili asilia, zilizopangwa kulingana na kiolezo chako cha hifadhi
• upload: faili asilia ambazo bado hazijahamishiwa kwenye kiolezo, pamoja na faili zinazopakiwa (uploads)
• profile: picha za wasifu wa watumiaji

Ukipoteza library, picha hiyo imepotea. Immich haihifadhi nakala ya pili ya faili asilia popote.

Kwa nini kunakili saraka ya data ya Postgres si chelezo

DB_DATA_LOCATION inaonekana kama lengo rahisi. Ni saraka, na rsync itainakili, na nakala hiyo itakamilika bila hitilafu. Hata hivyo, bado si chelezo, kwa sababu mbili ambazo unaweza kuziona zikifeli.

Sababu ya kwanza ni tearing. Postgres huandika kila mabadiliko kwenye write-ahead log (WAL) kwanza, kisha huyatumia kwenye faili za jedwali baadaye wakati wa checkpoint. Kwa hivyo, wakati wowote faili zilizopo kwenye diski ziko katika hali ya mabadiliko, na nakala inayochukua dakika nne itasoma faili ya kwanza saa 02:00 na ya mwisho saa 02:04. Faili hizo mbili hazihusiani na transaction moja. Unapoanzisha Postgres kwenye matokeo hayo, ama itakataa kuanza na PANIC: could not locate a valid checkpoint record, au itaanza kisha itakufa kwenye usomaji wa kwanza wa ukurasa ulioharibika na invalid page in block 1234 of relation base/16384/.... Hakuna hali yoyote inayoweza kurejeshwa kutoka kwa nakala hiyo.

Sababu ya pili inabaki hata ukisimamisha kila kitu kwanza. Saraka ya data ya Postgres imefungwa kwenye binaries kamili zilizoiandika. Immich hufunga image yake ya database kwa digest, kwa sasa ni ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0. Hiyo ni Postgres 14 yenye extensions mbili za vector-search zilizokusanywa ndani yake. Saraka ya data iliyoandikwa na build hiyo haitafunguka chini ya toleo tofauti la Postgres, na haitafunguka chini ya build yenye matoleo tofauti ya extensions. Seva yako ya kurejeshea data lazima izalishe upya image hiyo kikamilifu. SQL dump haijali hilo: ni maandishi, na seva yoyote inayooana inaweza kuyaendesha upya.

pg_dump inakwepa tatizo la tearing kabisa. Inasoma database nzima ndani ya snapshot moja ya MVCC (multi-version concurrency control), kwa hivyo inaona database kama ilivyokuwa katika wakati mmoja kamili huku maandishi mengine yakiendelea pembeni. Ndiyo maana si lazima usimamishe Postgres ili kuifanyia dump.

Vitu unavyoweza kuacha kwenye backup

Hivi hujitengeneza upya, kwa hivyo unaweza kuviruka:

• thumbs: picha za awali (preview) na vijipicha (thumbnail)
• encoded-video: video zilizobadilishwa mfumo (transcoded)
• DB_DATA_LOCATION: zinazojengwa upya kutoka kwenye dump
• model-cache Docker volume: mifano ya machine learning, inayopakuliwa tena ikihitajika

Kuviruka ni uamuzi wa kibiashara, si faida ya bure. Kujenga upya vijipicha na video zilizobadilishwa mfumo kwa maktaba kubwa huchukua saa nyingi za CPU kwenye VPS ndogo, na timeline huonyesha alama za kijivu muda wote huo. Unaziendesha upya kutoka Administration > Jobs, huku "Generate Thumbnails" na "Transcode Videos" zikiwa zimewekwa ili ziendeshe kwenye assets zinazokosekana. Ikiwa eneo lako la kuhifadhia backup lina nafasi, yaweke na uepuke kusubiri. Ikiwa unakaribia kikomo cha hifadhi yako, yaondoe na upange muda wa kuyajenga upya. Kukadiria ukubwa wa maktaba ya Immich inaelezea jinsi folda hizi zinavyokua kulingana na faili asilia.

Kuna folda nyingine moja unayopaswa kuijua. UPLOAD_LOCATION/backups huhifadhi dump za database za Immich zinazojiendesha zenyewe, zinazoandikwa kila siku saa 02:00 huku 14 za mwisho zikihifadhiwa, ambazo zinaweza kusanidiwa chini ya Administration > Settings > Backup. Hazikugharimu chochote na ni muhimu sana. Pia hukaa kwenye diski ileile ya maktaba inayolindwa, kwa hivyo husaidia wakati wa migration mbaya na si wakati seva imekufa. Tengeneza dump yako mwenyewe hata hivyo, kwa sababu dump unayoianzisha wewe hufika wakati mmoja na snapshot ya faili inayoiambatana nayo.

Chukua dump ya database

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

Badilisha immich na postgres kwa kutumia DB_DATABASE_NAME na DB_USERNAME zako ikiwa umezibadilisha. --clean --if-exists huweka DROP ... IF EXISTS mbele ya kila CREATE, ili dump iweze kuingia kwenye database ambayo tayari ina vitu badala ya kusimama kwenye kitu cha kwanza.

Sasa, maelezo ambayo huharibu script za backup kimyakimya. Amri hiyo ni pipeline, na shell huripoti exit status ya amri ya mwisho kwenye pipeline. Ikiwa pg_dump itafeli, kwa sababu ya nenosiri lisilo sahihi au container ambayo haifanyi kazi, gzip hupokea mtiririko mtupu, huandika faili ya gzip iliyo sahihi kabisa, na kutoka kwa exit code 0. Script yako hurekodi mafanikio na unajikuta na backup ya byte 20. Weka pipefail juu ya kila script ya backup:

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

Kisha kagua matokeo badala ya kuamini exit code:

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

Mstari wa kwanza wa dump iliyo salama husomeka -- PostgreSQL database dump. Faili yenye ukubwa wa byte mia chache ni dump iliyofeli, bila kujali kile script ilichosema.

Rekodi ni build ipi iliyoiandika, kando ya dump hiyo:

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

Usiitegemee .env kwa hili. Faili ya kawaida huweka IMMICH_VERSION=v3, tag inayoelea inayofuata kila toleo la 3.x, kwa hivyo haikupi taarifa yoyote kuhusu ni build ipi iliyoandika dump hiyo. Bandika (pin) tag kamili kwenye .env pia.

Sitisha seva, kisha chukua snapshot kwa kutumia restic

Faili zilizo chini ya UPLOAD_LOCATION si za kudumu (immutable) wakati Immich ikiwa inaendeshwa. Seva huandika faili mpya zilizopakiwa, na kazi ya storage template husogeza faili kati ya saraka. Ikiwa zana ya kuhifadhi nakala (backup tool) itasoma faili wakati bado inaandikwa, itahifadhi baiti hizo kana kwamba ndilo faili zima, na hakuna kitakachotoa taarifa ya hitilafu. Sitisha kontena la seva kwa muda wa operesheni hiyo:

docker stop immich_server

Acha immich_postgres ikiwa inaendelea kufanya kazi, kwa sababu dump inaihitaji. Kiolesura cha wavuti na programu ya simu vitakuwa nje ya mtandao hadi utakapoiwasha seva tena, jambo ambalo saa 03:00 kwenye mfumo wa nyumbani kwa kawaida halina tatizo.

restic inafaa hapa kwa sababu inafuta nakala rudufu (deduplicate) na kusimba data kwa njia fiche (encrypt) kabla ya kitu chochote kutoka kwenye seva. Ielekeze kwenye hifadhi (repository) ambayo haipo kwenye seva hii:

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

Object storage hufanya kazi kwa njia hiyo hiyo, na ndiyo jibu bora zaidi ikiwa unataka nakala hiyo itoke kabisa kwenye vifaa vyako:

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 hiyo inaweza kuwa a MinIO bucket unayoiendesha mwenyewe kwenye mashine ya pili, au mtoa huduma yeyote anayekubaliana na S3. Hifadhi iliyo kwenye diski moja na maktaba yako inakulinda dhidi ya kufuta faili kimakosa tu, na si kitu kingine chochote.

Kisha chukua snapshot, ukiorodhesha hasa kile kinachohitajika:

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 husoma mti mzima wa faili kila inapoendeshwa lakini hupakia tu vizuizi (blocks) ambavyo haijawahi kuviona awali, kwa hivyo snapshot ya kwanza husogeza maktaba yako yote na kila snapshot inayofuata husogeza picha mpya za siku hiyo.

Uhifadhi wa muda mrefu, na funguo zinazopaswa kuhifadhiwa kwingineko

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

forget huondoa snapshots kutoka kwenye index. --prune ndiyo sehemu inayofuta data ambazo snapshots hizo zilikuwa rejeleo la mwisho kwazo. Endesha forget bila --prune na bili yako ya hifadhi haitapungua kamwe.

Ukaguzi wa muundo haugharimu sana, kwa hivyo uendeshe kila wiki:

restic check

Hii inathibitisha kuwa metadata ya repository ni thabiti. Haifanyi usomaji wa data yako. Mara moja kwa mwezi, soma upya sampuli ya data na uilinganishe na hashes zake zilizorekodiwa:

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

Huu ndio ukaguzi pekee unaoweza kugundua uharibifu wa kimyakimya (silent corruption) kwenye backend ya hifadhi, kwa sababu unapakua blocks halisi na kuhesabu upya checksum zake. --read-data kamili kwenye maktaba ya picha inamaanisha kupakua repository nzima, jambo ambalo kwenye object storage inayotoza kwa kiasi cha data lina gharama halisi, kwa hivyo subset inayozunguka ndiyo toleo ambalo watu huendesha kwa kawaida.

Sasa sehemu ambayo watu huiruka. Nenosiri la repository ya restic haliwezi kurejeshwa. Hakuna njia ya kuliweka upya na hakuna tiketi ya usaidizi. Ikiwa nakala pekee imehifadhiwa kwenye /root/.restic-password kwenye seva unayojaribu kuirejesha, backups zako ni kelele zilizosimbwa (encrypted noise). Hali kadhalika kwa access key ya object storage na kwa DB_PASSWORD kutoka .env. Hifadhi yote haya mahali ambapo hakutegemei mashine hii kuwa hai: yachapishe na uyaweke kwenye droo, au kwenye password manager inayofanya kazi kwenye vifaa vingine. Ikiwa meneja huyo wa nenosiri pia anajiendesha (self-hosted), anahitaji utaratibu uleule, na kuhifadhi nakala ya Vaultwarden ni kazi ya pekee.

Rejesha Immich kwa mpangilio sahihi

Mpangilio wa urejeshaji ndio mahali ambapo backups nzuri hugeuka kuwa timeline tupu. Fuata mfuatano huu kwenye host mpya.

Rejesha usanidi kwanza. Hii inakuambia toleo gani la kuendesha na mahali ambapo paths zinaelekeza.

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

Funga toleo (pin the version) kabla ya kuanza chochote. Soma immich-version.txt, weka IMMICH_VERSION katika .env kwenye tag hiyo kamili, na uache toleo jipya zaidi kwa sasa. Immich haiauni kushusha toleo (downgrading), hata kati ya patch releases, kwa hivyo seva mpya ikianza dhidi ya dump ya zamani na kuendesha migrations zake, hakuna njia ya kurudi nyuma.

Rejesha media.

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

Kisha hamisha library, upload na profile ili zikae moja kwa moja ndani ya chochote ambacho UPLOAD_LOCATION inaelekeza kwenye host hii. Path ya host yenyewe inaweza kubadilika, kwa sababu compose file hufunga directory hiyo kwenye path isiyobadilika ndani ya container. Mpangilio wa ndani yake hauwezi kubadilika.

Anzisha database peke yake. Acha DB_DATA_LOCATION ikiwa tupu ili Postgres ianzishe cluster mpya.

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

pg_isready huchapisha accepting connections mara tu usanidi wa mara ya kwanza utakapokamilika, jambo ambalo huchukua sekunde chache. docker compose create hujenga kila container bila kuianzisha, na hilo ndilo lengo kuu la hatua hii: seva ya Immich haipaswi kuwaka bado. Seva inayoanza dhidi ya database tupu hutumia migrations zake, hutengeneza schema mpya na kukuomba utengeneze akaunti mpya ya admin, na hapo utakuwa unarejesha dump chini ya programu inayofanya kazi.

Rejesha 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

Vipengele viwili vya hapo vinafanya kazi ya msingi. sed ipo kwa sababu pg_dump huandika search_path tupu kwenye output yake kama hatua ya usalama, ili majina yasiyofafanuliwa kwenye dump yasitatuliwe kwenye schema isiyotarajiwa. Aina za vector-search za Immich huishi kwenye public, kwa hivyo kwa search path tupu, urejeshaji hufika kwenye safu ya kwanza iliyotangazwa na aina ya vector na psql husimama na ERROR: type "vector" does not exist. Kurudisha public kwenye path kunarekebisha hilo.

--single-transaction --set ON_ERROR_STOP=on hufunga urejeshaji mzima katika transaction moja inayositishwa kwenye kosa la kwanza. Unapata database kamili au ile ambayo haijaguswa. Bila hiyo, kufeli katikati huacha database inayowaka, inayokubali login yako, lakini ikiwa imepoteza idadi isiyojulikana ya albamu, jambo ambalo utaligundua wiki kadhaa baadaye.

Sasa anzisha kila kitu.

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

Subiri mstari wa kuanza kama Immich Server is listening on, kisha fungua port 2283 na uingie na credentials zako za zamani, kwa sababu akaunti za watumiaji zilirudi na dump. Ikiwa ukurasa wa login badala yake unatoa ofa ya kutengeneza akaunti ya kwanza ya admin, database haikurejea. Simama na usome output ya psql tena.

Onyo moja kuhusu maelekezo rasmi ya urejeshaji, ambayo huanza na docker compose down -v. -v hufuta named volumes. Katika compose file ya kawaida, UPLOAD_LOCATION na DB_DATA_LOCATION ni bind mounts, kwa hivyo zitanusurika. Ikiwa ulibadilisha mojawapo kuwa named volume, amri hiyo itafuta picha zako. Soma compose file yako kabla ya kuiandika.

Kwa nini timeline haina kitu baada ya restore

Timeline hutokana na safu za hifadhidata (database rows). Immich haichanganui upload/ wakati wa boot ili kugundua picha upya, kwa sababu faili lisilo na safu kwenye hifadhidata halina mmiliki, tarehe, wala albamu. Kwa hiyo, kosa la kawaida la restore ni kurudisha faili pekee huku hifadhidata ikiwa haipo. Immich huanza, hutengeneza schema tupu, na kukupa mfumo unaofanya kazi lakini bila data, wakati diski imejaa picha zako. Hakuna kilichopotea. Hakuna kinachoonekana pia. Suluhisho ni kuingiza dump wakati seva imesimamishwa, kama ilivyoelezwa hapo juu.

Toleo la pili ni la kimya zaidi. Hifadhidata inarudi, timeline inajaa, lakini kila asset inashindwa kufunguka. Hii inamaanisha safu hizo zinaelekeza kwenye faili ambazo container haiwezi kuziona, kwa kawaida kwa sababu library, upload na profile ziko ndani zaidi kwa ngazi moja baada ya restic restore --target /restore ambayo haikuhamishwa mahali pake. Kagua ukiwa ndani ya container badala ya kukisia:

docker exec immich_server ls /data

Faili la kawaida la compose huweka mount ya UPLOAD_LOCATION kwenye /data, kwa hivyo orodha hiyo inapaswa kuonyesha library, upload na profile. Ikiwa inaonyesha saraka tupu au folda ya srv iliyopotea, basi bind mount yako inaelekeza kwenye ngazi isiyo sahihi na safu za hifadhidata ziko sawa.

Kulinganisha toleo kati ya backup na restore

Immich hutoa releases mara kwa mara na schema hubadilika kulingana na toleo hilo, kwa hivyo dump hubeba schema ya seva iliyoiunda.

Kurejesha dump ya toleo la zamani kwenye seva mpya kwa kawaida hufanya kazi, kwa sababu seva hutekeleza migrations zake zinazosubiri wakati wa kuanza na kusasisha schema. Njia hiyo hujaribiwa katika mfululizo wa releases. Kuruka matoleo makuu (major versions) kadhaa kwa hatua moja ndipo mambo yanapoharibika, na mradi huu huweka mabadiliko yanayovunja utangamano (breaking changes) kwenye releases kuu na kuyaandika kwenye changelog yake.

Kurejesha dump ya toleo jipya kwenye seva ya zamani hakufanyi kazi kabisa. Dump hiyo huwa na majedwali na safu wima ambazo code ya zamani haizitambui, na Immich inasisitiza kuwa kushusha toleo (downgrading) hakutumiki hata kati ya patch releases. Hakuna amri ya rollback unayoweza kutumia.

Kwa hivyo, urejeshaji salama ni ule wa kawaida. Endesha toleo lilelile lililounda dump, iweke, ingia kwenye mfumo, thibitisha kuwa timeline imekamilika, na ufanye upgrade baada ya hapo tu. Fanya upgrade release moja kwa moja, ukibadilisha IMMICH_VERSION na kuendesha docker compose pull && docker compose up -d baada ya kila hatua. Kutunza dumps za wiki moja husaidia hapa pia: kama dump mpya zaidi itagundulika kuwa ilichukuliwa wakati wa upgrade iliyofeli, ile ya jana bado itakuwa kwenye repository.

Thibitisha nakala rudufu kila mwezi

Nakala rudufu ambayo hujawahi kuirejesha ni kubahatisha tu. Mara moja kwa mwezi, irejeshe kwenye mfumo wa majaribio na utazame picha. Zoezi hili huchukua takriban dakika ishirini na ndilo jambo pekee linalobadilisha maelekezo haya kuwa mpango wa kurejesha data.

restic snapshots
restic stats latest

snapshots inapaswa kuonyesha utekelezaji wa jana usiku. stats latest inapaswa kuripoti ukubwa unaokaribiana na maktaba yako, si megabytes chache tu.

Rejesha kwenye saraka ya muda, ikiwezekana kwenye seva nyingine:

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

Nakili docker-compose.yml na .env kutoka kwenye seti iliyorejeshwa, kisha ubadili mambo matatu kwenye nakala hiyo. Elekeza UPLOAD_LOCATION na DB_DATA_LOCATION kwenye saraka zilizo chini ya /tmp/immich-drill. Chapisha port ya wavuti mahali pengine, 12283:2283 badala ya 2283:2283. Futa mistari ya container_name:, kwa sababu faili ya kawaida ya compose ina majina yaliyowekwa kama immich_server, kwa hivyo stack ya pili kwenye seva hiyo hiyo itagongana na ya kwanza na Docker itakataa kuiumba.

Tekeleza mchakato wa kurejesha kama ilivyo hapo juu: database pekee, rudisha dump, kisha docker compose up -d. Sasa fanya ukaguzi huu manne ili kuthibitisha usahihi.

1. Ingia na nenosiri ulilotumia kabla ya zoezi. Akaunti kufanya kazi inamaanisha dump imerejeshwa.
2. Fungua timeline na usogeze hadi mwezi wa zamani zaidi. Mali katika kipindi chote cha tarehe inamaanisha safu zote zimerudi, si zile za hivi karibuni pekee.
3. Fungua picha moja kwa ukubwa kamili na upakue ile ya asili.
4. Ilinganishe na faili hiyo hiyo katika maktaba yako hai kwa kutumia sha256sum. Hash zinazolingana inamaanisha data imesalia baada ya mzunguko wa restic.

Kisha maliza zoezi kwa docker compose down -v katika saraka ya zoezi na ufute /tmp/immich-drill. Andika tarehe mahali ambapo utaiona, kwa sababu thamani ya zoezi hili inapatikana kwa kulirudia mwezi ujao. Ikiwa bado unaamua ni seva ipi ya picha ya kutumia, ulinganisho wa PhotoPrism na Immich unaelezea jinsi hizo mbili zinavyotofautiana katika msingi huu.

FAQ

Je, ni lazima kusimamisha Immich ili kuifanyia backup?

Simamisha immich_server na uache immich_postgres ikiendelea kufanya kazi. Database haihitaji kusitishwa, kwa sababu pg_dump husoma ndani ya snapshot moja ya MVCC na kuona hali moja thabiti bila kujali nini kingine kinaandikwa. Faili ndizo sababu ya kusimamisha: seva huandika uploads mpya na kazi ya storage template huhamisha faili kati ya saraka, kwa hivyo zana ya backup inaweza kusoma faili katikati ya uandishi na kuhifadhi nakala iliyokatika bila kutoa error yoyote. docker stop immich_server kabla ya snapshot na docker start immich_server baada yake huondoa tatizo hilo la ushindani wa rasilimali.

Je, ninaweza kunakili folda ya data ya Postgres badala ya kuendesha pg_dump?

Hapana. Unapokopi folda ya data inayotumika, unasoma faili tofauti kwa nyakati tofauti, kwa hivyo matokeo si hali moja thabiti, na Postgres huikataa wakati wa kuanza kwa PANIC: could not locate a valid checkpoint record au hushindwa baadaye kwa sababu ya ukurasa ulioharibika. Hata nakala iliyochukuliwa wakati kila kitu kimesimamishwa inafungwa kwenye toleo kamili la database: Immich hutumia image ya Postgres 14 yenye matoleo maalum ya extension ya vector-search, na saraka hiyo haitafunguka kwenye kitu kingine chochote. SQL dump ni maandishi ya kawaida na inaweza kuingizwa kwenye seva yoyote inayooana.

Kwa nini timeline yangu ya Immich haina kitu baada ya restore?

Kwa sababu timeline hujengwa kutoka kwa safu za database na wewe umerudisha faili bila database. Immich haichanganui upload/ ili kugundua upya picha, kwa hivyo faili zisizo na safu husika hubaki hazionekani. Picha zenyewe hazijaguswa. Simamisha seva, ingiza dump kwenye Postgres iliyoanzishwa upya, kisha anza stack. Ikiwa badala yake timeline imejaa lakini kila picha inashindwa kufunguka, tatizo ni kinyume chake: library, upload na profile hazipo moja kwa moja ndani ya saraka iliyounganishwa kwenye container. Iangalie kwa kutumia docker exec immich_server ls /data.

Ni folda zipi za Immich ninaweza kuruka kwenye backup?

thumbs na encoded-video hujitengeneza upya kutoka kwa asilia, na DB_DATA_LOCATION hujijenga upya kutoka kwa dump, kwa hivyo hakuna hata moja inayopaswa kuwa kwenye seti ya backup. Kuruka folda hizi kunatumia muda baada ya restore badala ya kuhifadhi nafasi kabla yake, kwa sababu kujenga upya previews na transcodes kwa maktaba kubwa ni masaa ya CPU, yanayoendeshwa kutoka Administration > Jobs dhidi ya assets zilizokosekana. Unachoweza kuruka kamwe ni library, upload na profile, ambazo zina nakala pekee ya kila faili asilia.

Je, ninaweza kurudisha dump ya Immich kwenye toleo jipya zaidi?

Kwa kawaida ndiyo, kwa sababu seva hutumia migrations zake zinazosubiri wakati wa kuanza na kusogeza schema mbele. Kinyume chake hakifanyi kazi: Immich haiauni kushusha toleo (downgrading), hata kati ya matoleo ya patch, kwa hivyo dump kutoka kwa toleo jipya zaidi haiwezi kupakiwa kwenye seva ya zamani. Rudisha kwa kutumia IMMICH_VERSION iliyofungwa kwenye toleo lililoandika dump hiyo, thibitisha kuwa timeline imekamilika, na uboreshe baada ya hapo. Rekodi toleo kando ya kila dump kwa kutumia docker inspect --format '{{.Config.Image}}' immich_server, kwa sababu IMMICH_VERSION=v3 ya kawaida ni tag inayobadilika ambayo haikupi taarifa yoyote.