Cara Sandaran dan Pulih Immich di VPS

Perkara yang perlu ada dalam sandaran Immich

Sandaran Immich terdiri daripada tiga elemen yang ditangkap pada masa yang sama. Fail asal di bawah UPLOAD_LOCATION. Dump SQL bagi pangkalan data Postgres. Fail .env dan docker-compose.yml yang menerangkan tindanan (stack) tersebut. Pemulihan bermaksud memainkan semula dump tersebut ke dalam pangkalan data baharu semasa pelayan Immich dihentikan, dan hanya memulakan baki tindanan selepas itu. Jika urutan salah, anda akan mendapati Immich berfungsi tetapi memaparkan garis masa kosong di atas cakera yang penuh.

Pemisahan ini penting kerana Immich menyimpan statusnya di dua tempat yang tidak berhubung antara satu sama lain. Postgres menyimpan setiap album, setiap kluster wajah, setiap pautan yang dikongsi, setiap akaun pengguna dan kunci API, serta laluan storan bagi setiap aset. Sistem fail pula menyimpan piksel gambar. Jika anda memulihkan fail tanpa pangkalan data, Immich tidak akan memaparkan apa-apa. Jika anda memulihkan pangkalan data tanpa fail, setiap aset akan dibuka sebagai imej yang rosak.

Perintah di sini ditulis berdasarkan Immich v3.1.0, iaitu keluaran semasa pada awal Ogos 2026. Projek ini berkembang dengan pantas dan prosedur sandaran yang didokumentasikan telah berubah lebih daripada sekali, jadi semak versi yang anda jalankan sebelum menyalin apa-apa. Jika tindanan belum dimulakan, mulakan dengan panduan pemasangan Immich dan kembali ke sini kemudian.

Fahami hala tuju laluan anda

Dua pemboleh ubah dalam .env menentukan segala-galanya pada halaman ini. UPLOAD_LOCATION ialah direktori induk tempat Immich menulis semua media. DB_DATA_LOCATION ialah direktori data Postgres.

example.env lalai menetapkan UPLOAD_LOCATION=./library, yang merupakan tetapan lalai yang mengelirukan, kerana Immich kemudiannya mencipta folder bernama library di dalam direktori tersebut. Fail asal anda berakhir di ./library/library. Tetapkan laluan mutlak (absolute path) supaya skrip sandaran tidak bergantung pada direktori tempat anda menjalankannya.

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

Di dalam UPLOAD_LOCATION, Immich mencipta beberapa folder. Tiga daripadanya menyimpan data yang tidak boleh dibina semula oleh mana-mana tugasan:

• library: fail asal, disusun mengikut templat storan anda
• upload: fail asal yang belum dipindahkan ke dalam susun atur templat, serta muat naik yang sedang diproses
• profile: gambar profil pengguna

Jika library hilang, maka foto tersebut akan hilang. Immich tidak menyimpan salinan kedua bagi fail asal di mana-mana lokasi.

Mengapa menyalin direktori data Postgres bukan satu sandaran

DB_DATA_LOCATION kelihatan seperti sasaran yang mudah. Ia hanyalah satu direktori, rsync akan menyalinnya, dan proses salinan selesai tanpa ralat. Namun, ia tetap bukan satu sandaran, atas dua sebab yang boleh anda lihat sendiri kegagalannya.

Sebab pertama ialah tearing. Postgres menulis setiap perubahan ke dalam write-ahead log (WAL) terlebih dahulu, kemudian mengaplikasikannya ke fail jadual pada satu checkpoint. Oleh itu, pada bila-bila masa, fail pada cakera berada dalam keadaan pertengahan, dan salinan berterusan yang mengambil masa empat minit akan membaca fail pertama pada 02:00 dan fail terakhir pada 02:04. Kedua-dua fail tersebut tidak tergolong dalam transaksi yang sama. Apabila anda memulakan Postgres pada hasil salinan tersebut, ia sama ada akan menolak semasa permulaan dengan PANIC: could not locate a valid checkpoint record, atau ia bermula dan kemudian terhenti pada bacaan pertama halaman yang rosak dengan invalid page in block 1234 of relation base/16384/.... Kedua-dua keadaan tidak boleh dipulihkan daripada salinan tersebut.

Sebab kedua tetap wujud walaupun anda menghentikan segala-galanya terlebih dahulu. Direktori data Postgres terikat dengan binari tepat yang menulisnya. Immich menetapkan imej pangkalan datanya mengikut digest, yang kini ialah ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0. Itu adalah Postgres 14 dengan dua extension carian vektor yang dikompilasi di dalamnya. Direktori data yang ditulis oleh binaan tersebut tidak akan terbuka di bawah versi utama Postgres yang berbeza, dan ia tidak akan terbuka di bawah binaan yang membawa versi extension yang berlainan. Hos pemulihan anda perlu menghasilkan semula imej tersebut dengan tepat. SQL dump tidak mempunyai masalah ini: ia adalah teks, dan mana-mana pelayan yang serasi boleh memainkannya semula.

pg_dump mengelakkan masalah tearing secara langsung. Ia membaca keseluruhan pangkalan data di dalam satu snapshot MVCC (multi-version concurrency control), jadi ia melihat pangkalan data tepat seperti keadaannya pada satu ketika sementara penulisan lain terus berjalan di sekelilingnya. Itulah sebabnya anda tidak perlu menghentikan Postgres untuk melakukan dump.

Perkara yang boleh dikecualikan daripada sandaran

Fail-fail ini akan dijana semula, jadi anda boleh melangkauinya:

• thumbs: imej pratonton dan imej kecil (thumbnail)
• encoded-video: video yang telah ditranskod
• DB_DATA_LOCATION: dibina semula daripada dump
• volum Docker model-cache: model pembelajaran mesin, dimuat turun semula apabila diperlukan

Melangkau fail-fail ini adalah satu pertukaran, bukan keuntungan percuma. Membina semula imej kecil dan transkod untuk pustaka yang besar memakan masa berjam-jam penggunaan CPU pada VPS kecil, dan garis masa akan memaparkan ruang letak kelabu sepanjang tempoh tersebut. Anda boleh menjalankannya semula daripada Administration > Jobs, dengan "Generate Thumbnails" dan "Transcode Videos" ditetapkan untuk berjalan pada aset yang hilang. Jika sasaran sandaran anda mempunyai ruang, sertakan fail-fail tersebut dan elakkan masa menunggu. Jika anda hampir mencapai had storan, gugurkan fail-fail tersebut dan rancang untuk proses pembinaan semula. Menentukan saiz pustaka Immich merangkumi sejauh mana folder-folder ini membesar berbanding fail asal.

Satu lagi folder yang perlu diketahui ialah UPLOAD_LOCATION/backups yang menyimpan dump pangkalan data automatik Immich sendiri, ditulis setiap hari pada jam 02:00 dengan 14 salinan terakhir disimpan, boleh dikonfigurasikan di bawah Administration > Settings > Backup. Ia tidak memakan ruang anda dan sangat berguna. Fail-fail ini juga berada pada cakera yang sama dengan pustaka yang dilindunginya, jadi ia membantu jika berlaku migrasi yang bermasalah tetapi tidak membantu jika pelayan rosak sepenuhnya. Lakukan dump anda sendiri walau bagaimanapun, kerana dump yang anda cetuskan sendiri akan terhasil pada saat yang sama dengan syot kilat (snapshot) fail yang berkaitan dengannya.

Ambil dump pangkalan data

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

Gantikan immich dan postgres dengan DB_DATABASE_NAME dan DB_USERNAME anda jika anda telah mengubahnya. --clean --if-exists meletakkan DROP ... IF EXISTS di hadapan setiap CREATE, supaya dump tersebut dimainkan semula ke dalam pangkalan data yang sudah mengandungi objek dan bukannya berhenti pada objek pertama.

Sekarang, perincian yang merosakkan skrip sandaran secara senyap. Perintah tersebut ialah satu pipeline, dan shell melaporkan status keluar bagi perintah terakhir dalam pipeline. Jika pg_dump gagal, disebabkan kata laluan yang salah atau container yang tidak berjalan, gzip menerima aliran kosong, menulis fail gzip yang sah sepenuhnya, dan keluar dengan status 0. Skrip anda merekodkan kejayaan dan anda memiliki sandaran bersaiz 20-byte. Letakkan pipefail di bahagian atas setiap skrip sandaran:

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

Kemudian semak hasilnya dan bukannya mempercayai kod keluar:

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

Baris pertama dump yang sihat mengandungi -- PostgreSQL database dump. Fail yang bersaiz beberapa ratus byte adalah dump yang gagal, tidak kira apa yang dinyatakan oleh skrip.

Rekodkan binaan (build) yang menulisnya, bersebelahan dengan dump tersebut:

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

Jangan bergantung pada .env untuk perkara ini. Set fail stok IMMICH_VERSION=v3, iaitu tag terapung yang mengikuti setiap keluaran 3.x, jadi ia tidak memberitahu anda apa-apa tentang binaan mana yang sebenarnya menulis dump tersebut. Tetapkan tag yang tepat dalam .env juga.

Jeda pelayan, kemudian ambil snapshot dengan restic

Fail di bawah UPLOAD_LOCATION tidak bersifat kekal (immutable) semasa Immich berjalan. Pelayan menulis muat naik baharu, dan tugasan templat storan memindahkan fail antara direktori. Jika alat sandaran membaca fail semasa proses penulisan sedang berlangsung, ia akan menyimpan bait tersebut seolah-olah ia adalah fail lengkap, dan tiada ralat akan dilaporkan. Hentikan kontena pelayan sepanjang tempoh sandaran dijalankan:

docker stop immich_server

Biarkan immich_postgres terus berjalan, kerana proses dump memerlukannya. Antara muka web dan aplikasi mudah alih akan berada di luar talian sehingga anda memulakan semula pelayan, yang biasanya tidak menjadi masalah pada jam 03:00 bagi penggunaan isi rumah.

restic sesuai digunakan di sini kerana ia melakukan penyahduplikasian (deduplication) dan penyulitan (encryption) sebelum sebarang data meninggalkan pelayan. Halakan ia ke repositori yang tidak berada pada pelayan ini:

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

Storan objek berfungsi dengan cara yang sama, dan merupakan pilihan yang lebih baik jika anda mahu salinan data berada sepenuhnya di luar perkakasan anda sendiri:

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 tersebut boleh jadi bucket MinIO yang anda kendalikan sendiri pada mesin kedua, atau mana-mana penyedia yang serasi dengan S3. Repositori yang berada pada cakera yang sama dengan pustaka hanya melindungi anda daripada pemadaman tidak sengaja dan tiada ancaman lain.

Kemudian lakukan snapshot, dengan menyenaraikan perkara yang penting sahaja:

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 membaca keseluruhan pepohon direktori pada setiap kali dijalankan tetapi hanya memuat naik blok data yang belum pernah dilihat sebelum ini. Oleh itu, snapshot pertama akan memindahkan keseluruhan pustaka anda dan setiap snapshot selepas itu hanya memindahkan foto baharu bagi hari tersebut.

Pengekalan, dan kunci yang mesti disimpan di tempat lain

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

forget membuang snapshot daripada indeks. --prune ialah bahagian yang memadamkan data yang mana snapshot tersebut merupakan rujukan terakhirnya. Jalankan forget tanpa --prune dan bil storan anda tidak akan berkurangan.

Pemeriksaan struktur adalah murah, jadi jalankannya setiap minggu:

restic check

Ini mengesahkan bahawa metadata repositori adalah konsisten. Ia tidak membaca data anda. Sekali sebulan, baca semula sampel dan semak ia dengan hash yang direkodkan:

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

Ini adalah satu-satunya pemeriksaan yang mengesan kerosakan senyap (silent corruption) pada backend storan, kerana ia memuat turun blok sebenar dan mengira semula checksumnya. --read-data penuh pada pustaka foto bermakna memuat turun keseluruhan repositori, yang mana pada storan objek bermeter akan melibatkan kos sebenar, jadi subset bergilir adalah versi yang sebenarnya dijalankan oleh pengguna.

Sekarang bahagian yang sering dilangkau oleh orang ramai. Kata laluan repositori restic tidak boleh dipulihkan. Tiada tetapan semula dan tiada tiket sokongan. Jika satu-satunya salinan disimpan dalam /root/.restic-password pada pelayan yang anda cuba pulihkan, sandaran anda hanyalah data disulitkan yang tidak berguna. Perkara yang sama berlaku untuk kunci akses storan objek dan untuk DB_PASSWORD daripada .env. Simpan kesemuanya di tempat yang tidak bergantung pada mesin ini untuk berfungsi: dicetak dan disimpan di dalam laci, atau dalam pengurus kata laluan yang dijalankan pada perkakasan berbeza. Jika pengurus itu juga dihoskan sendiri, ia memerlukan layanan yang sama, dan menyandarkan Vaultwarden adalah tugasnya yang tersendiri.

Memulihkan Immich mengikut urutan yang betul

Urutan pemulihan adalah perkara yang menentukan sama ada sandaran yang baik akan menjadi garis masa yang kosong. Ikuti urutan ini pada hos baharu.

Dapatkan semula konfigurasi terlebih dahulu. Ia memberitahu anda versi yang perlu dijalankan dan ke mana hala tuju laluan (paths).

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

Tetapkan versi (pin) sebelum memulakan apa-apa. Baca immich-version.txt, tetapkan IMMICH_VERSION dalam .env kepada tag yang tepat itu, dan biarkan keluaran (release) terbaharu buat masa ini. Immich tidak menyokong penurunan versi (downgrade), walaupun antara keluaran patch, jadi jika pelayan yang lebih baharu bermula dengan dump yang lebih lama dan menjalankan migrasinya, tiada jalan untuk kembali.

Pulihkan media.

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

Kemudian alihkan library, upload dan profile supaya ia berada terus di dalam apa sahaja yang ditunjuk oleh UPLOAD_LOCATION pada hos ini. Laluan hos itu sendiri boleh berubah, kerana fail compose mengikat direktori tersebut kepada laluan tetap di dalam kontena. Susun atur di dalamnya tidak boleh berubah.

Mulakan pangkalan data secara berasingan. Biarkan DB_DATA_LOCATION kosong supaya Postgres memulakan kluster yang baharu.

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

pg_isready mencetak accepting connections sebaik sahaja persediaan kali pertama selesai, yang mengambil masa beberapa saat. docker compose create membina setiap kontena tanpa memulakannya, dan itulah tujuan utama langkah ini: pelayan Immich tidak boleh berjalan lagi. Pelayan yang bermula dengan pangkalan data kosong akan menggunakan migrasinya, mencipta skema baharu dan meminta anda membuat akaun pentadbir baharu, dan anda kemudiannya akan memainkan semula dump di bawah aplikasi yang sedang berjalan.

Main semula 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

Dua bahagian daripadanya melakukan kerja sebenar. sed wujud kerana pg_dump menulis search_path kosong ke dalam outputnya sebagai langkah keselamatan, supaya nama yang tidak layak (unqualified names) dalam dump tidak boleh diselesaikan kepada skema yang tidak dijangka. Jenis carian vektor Immich berada dalam public, jadi dengan laluan carian kosong, pemulihan mencapai lajur pertama yang diisytiharkan dengan jenis vektor dan psql berhenti dengan ERROR: type "vector" does not exist. Meletakkan public kembali pada laluan tersebut akan membaikinya.

--single-transaction --set ON_ERROR_STOP=on membungkus keseluruhan pemulihan dalam satu transaksi yang akan terbatal pada ralat pertama. Anda akan mendapat sama ada pangkalan data yang lengkap atau pangkalan data yang tidak disentuh. Tanpanya, kegagalan di pertengahan jalan akan meninggalkan pangkalan data yang boleh bermula, menerima log masuk anda, tetapi kehilangan bilangan album yang tidak diketahui, yang mungkin anda sedari beberapa minggu kemudian.

Sekarang mulakan semuanya.

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

Tunggu baris permulaan seperti Immich Server is listening on, kemudian buka port 2283 dan log masuk dengan kelayakan lama anda, kerana akaun pengguna telah kembali bersama dump tersebut. Jika halaman log masuk sebaliknya menawarkan untuk mencipta akaun pentadbir pertama, pangkalan data tidak berjaya dipulihkan. Berhenti dan baca semula output psql.

Satu amaran mengenai arahan pemulihan rasmi, yang bermula dengan docker compose down -v. -v akan memadamkan volum bernama (named volumes). Dalam fail compose standard, UPLOAD_LOCATION dan DB_DATA_LOCATION adalah bind mounts, jadi ia akan terselamat. Jika anda menukar mana-mana daripadanya kepada volum bernama, arahan itu akan memadamkan foto anda. Baca fail compose anda sebelum anda menaipnya.

Mengapa garis masa kosong selepas pemulihan

Garis masa dijana daripada baris pangkalan data. Immich tidak pernah melakukan upload/ semasa but untuk menemui semula foto, kerana fail tanpa baris tidak mempunyai pemilik, tarikh atau album. Oleh itu, kesilapan pemulihan yang paling biasa ialah fail berjaya dikembalikan, tetapi pangkalan data hilang. Immich bermula, mencipta skema kosong, dan memberikan anda instans yang berfungsi tanpa kandungan walaupun cakera penuh dengan foto anda. Tiada apa-apa yang hilang. Tiada apa-apa yang kelihatan juga. Penyelesaiannya adalah dengan memainkan semula dump semasa pelayan dihentikan, tepat seperti di atas.

Versi kedua lebih senyap. Pangkalan data dipulihkan, garis masa diisi dengan entri, tetapi setiap aset gagal dibuka. Ini bermakna baris tersebut merujuk kepada fail yang tidak dapat dilihat oleh kontena, biasanya kerana library, upload dan profile berada satu tahap terlalu dalam selepas restic restore --target /restore yang tidak dialihkan ke tempatnya. Periksa dari dalam kontena dan bukannya meneka:

docker exec immich_server ls /data

Fail compose standard melekapkan UPLOAD_LOCATION pada /data, jadi penyenaraian tersebut sepatutnya menunjukkan library, upload dan profile. Jika ia menunjukkan direktori kosong atau folder srv yang terasing, bind mount anda menghala ke tahap yang salah dan baris pangkalan data sebenarnya adalah betul.

Padanan versi antara sandaran dan pemulihan

Immich kerap mengeluarkan versi baharu dan skema datanya turut berubah, jadi fail dump membawa skema daripada pelayan yang menghasilkannya.

Memulihkan dump versi lama ke pelayan versi baharu biasanya berjaya, kerana pelayan akan melaksanakan migrasi yang tertangguh semasa permulaan dan mengemas kini skema tersebut. Laluan ini diuji sepanjang urutan keluaran. Melompat beberapa versi utama dalam satu langkah adalah punca kegagalan, dan projek ini mengekalkan perubahan yang memecahkan keserasian (breaking changes) pada keluaran utama serta mendokumentasikannya dalam changelog.

Memulihkan dump versi baharu ke pelayan versi lama tidak akan berfungsi sama sekali. Dump tersebut mengandungi jadual dan lajur yang tidak dikenali oleh kod lama, dan Immich menyatakan bahawa penurunan taraf (downgrade) tidak disokong walaupun antara keluaran patch. Tiada arahan rollback yang boleh digunakan.

Oleh itu, pemulihan yang selamat adalah proses yang rutin. Jalankan versi yang tepat yang menghasilkan dump tersebut, muatkan semula data, log masuk, sahkan garis masa (timeline) adalah lengkap, dan lakukan naik taraf hanya selepas itu. Naik taraf satu keluaran pada satu masa, kemas kini IMMICH_VERSION dan jalankan docker compose pull && docker compose up -d selepas setiap kenaikan versi. Menyimpan sandaran selama seminggu juga membantu dalam situasi ini: jika sandaran terkini didapati diambil semasa naik taraf yang gagal, sandaran semalam masih tersedia dalam repositori.

Sahkan sandaran setiap bulan

Sandaran yang tidak pernah dipulihkan hanyalah satu andaian. Sekali sebulan, pulihkan sandaran tersebut ke dalam instans sementara dan lihat satu foto. Latihan ini mengambil masa kira-kira dua puluh minit dan ia merupakan satu-satunya perkara yang mengubah kandungan halaman ini menjadi pelan pemulihan.

restic snapshots
restic stats latest

snapshots sepatutnya menyenaraikan pelaksanaan malam tadi. stats latest sepatutnya melaporkan saiz yang hampir dengan pustaka anda, bukan sekadar beberapa megabait.

Pulihkan ke dalam direktori sementara, sebaik-baiknya pada hos ganti:

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

Salin docker-compose.yml dan .env keluar daripada set yang dipulihkan, kemudian ubah tiga perkara dalam salinan tersebut. Halakan UPLOAD_LOCATION dan DB_DATA_LOCATION ke direktori di bawah /tmp/immich-drill. Terbitkan port web di tempat lain, 12283:2283 dan bukannya 2283:2283. Padamkan baris container_name:, kerana fail compose asal mengekod nama secara tetap seperti immich_server, jadi tindanan kedua pada hos yang sama akan bertembung dengan yang pertama dan Docker akan menolak untuk menciptanya.

Jalankan urutan pemulihan daripada bahagian di atas: pangkalan data sahaja, main semula dump, kemudian docker compose up -d. Sekarang, lakukan empat pemeriksaan yang membuktikan keberkesanannya.

1. Log masuk dengan kata laluan yang anda gunakan sebelum latihan. Akaun yang berfungsi bermakna dump telah berjaya dipulihkan.
2. Buka garis masa dan tatal ke bulan yang paling lama. Aset merentasi keseluruhan julat tarikh bermakna semua baris telah kembali, bukan sekadar yang terkini.
3. Buka satu foto pada saiz penuh dan muat turun fail asal.
4. Bandingkan ia dengan fail yang sama dalam pustaka langsung anda menggunakan sha256sum. Hash yang sepadan bermakna bait data terselamat melalui proses pusingan restic.

Kemudian, tamatkan latihan dengan docker compose down -v dalam direktori latihan dan padamkan /tmp/immich-drill. Tulis tarikh tersebut di tempat yang anda akan lihat, kerana nilai sebenar proses ini terletak pada melakukannya semula bulan depan. Jika anda masih membuat keputusan pelayan foto mana yang ingin digunakan, perbandingan PhotoPrism dan Immich merangkumi perbezaan antara kedua-duanya berdasarkan aspek ini.

FAQ

Adakah saya perlu menghentikan Immich untuk membuat sandaran?

Hentikan immich_server dan biarkan immich_postgres terus berjalan. Pangkalan data tidak perlu dihentikan kerana pg_dump membaca di dalam satu snapshot MVCC dan melihat satu keadaan konsisten yang tunggal, tidak kira apa yang sedang ditulis. Fail-fail adalah sebab utama untuk berhenti: pelayan menulis muat naik baharu dan tugasan templat storan mengalihkan fail antara direktori, jadi alat sandaran boleh membaca fail separuh jalan semasa proses penulisan dan menyimpan salinan yang terpotong tanpa sebarang ralat. docker stop immich_server sebelum snapshot dan docker start immich_server selepasnya menghapuskan risiko perlumbaan (race condition) tersebut.

Bolehkah saya menyalin folder data Postgres dan bukannya menjalankan pg_dump?

Tidak. Salinan direktori data yang sedang berjalan membaca fail yang berbeza pada waktu yang berbeza, jadi hasilnya bukanlah satu keadaan yang konsisten, dan Postgres akan menolaknya semasa permulaan dengan PANIC: could not locate a valid checkpoint record atau gagal kemudiannya disebabkan halaman yang rosak. Malah salinan yang diambil semasa semuanya dihentikan tetap terikat dengan binaan pangkalan data yang tepat: Immich menetapkan imej Postgres 14 dengan versi sambungan carian vektor yang khusus, dan direktori tersebut tidak akan dibuka di bawah perisian lain. SQL dump adalah teks biasa dan boleh dimainkan semula ke dalam mana-mana pelayan yang serasi.

Mengapa garis masa (timeline) Immich saya kosong selepas pemulihan?

Kerana garis masa dibina daripada baris pangkalan data dan anda memulihkan fail tanpa pangkalan data. Immich tidak pernah mengimbas upload/ untuk menemui semula foto, jadi fail yang tiada baris pangkalan data akan kekal tidak kelihatan. Foto itu sendiri tidak disentuh. Hentikan pelayan, mainkan semula dump ke dalam Postgres yang baru dimulakan, kemudian mulakan stack tersebut. Jika sebaliknya garis masa penuh tetapi setiap foto gagal dibuka, masalahnya adalah sebaliknya: library, upload dan profile tidak berada secara terus di dalam direktori yang diikat (bind) ke dalam kontena. Semak perkara ini dengan docker exec immich_server ls /data.

Folder Immich yang manakah boleh saya abaikan dalam sandaran?

thumbs dan encoded-video akan dijana semula daripada fail asal, dan DB_DATA_LOCATION dibina semula daripada dump, jadi tiada satu pun daripadanya perlu berada dalam set sandaran. Mengabaikannya bermakna anda meluangkan masa selepas pemulihan dan bukannya ruang storan sebelum itu, kerana membina semula pratonton dan transkod untuk pustaka yang besar mengambil masa berjam-jam penggunaan CPU, yang dijalankan daripada Administration > Jobs terhadap aset yang hilang. Apa yang anda tidak boleh abaikan ialah library, upload dan profile, yang menyimpan satu-satunya salinan bagi setiap fail asal.

Bolehkah saya memulihkan dump Immich ke dalam versi yang lebih baharu?

Biasanya ya, kerana pelayan menggunakan migrasi yang belum selesai semasa permulaan dan mengemas kini skema tersebut. Perkara sebaliknya akan gagal: Immich tidak menyokong penurunan versi (downgrade), walaupun antara keluaran patch, jadi dump daripada keluaran yang lebih baharu tidak boleh dimuatkan ke dalam pelayan yang lebih lama. Pulihkan dengan IMMICH_VERSION yang ditetapkan kepada keluaran yang menghasilkan dump tersebut, sahkan garis masa lengkap, dan naik taraf selepas itu. Rekodkan versi di sebelah setiap dump dengan docker inspect --format '{{.Config.Image}}' immich_server, kerana IMMICH_VERSION=v3 lalai adalah tag terapung yang tidak memberikan sebarang maklumat.