Immich VPS Yedekleme ve Geri Yükleme Rehberi

Bir Immich yedeğinin içermesi gerekenler

Bir Immich yedeği, aynı anda alınan üç bileşenden oluşur. UPLOAD_LOCATION altındaki orijinal dosyalar, Postgres veritabanının SQL dökümü ve yığın yapısını tanımlayan .env ile docker-compose.yml dosyaları. Geri yükleme işlemi, Immich sunucusu durdurulmuş durumdayken bu dökümün yeni bir veritabanına aktarılmasını ve yığının geri kalanının ancak bu işlemden sonra başlatılmasını gerektirir. Sıralama hatalı yapılırsa, dolu bir disk üzerinde boş bir zaman çizelgesi gösteren çalışan bir Immich ile karşılaşırsınız.

Bu ayrım önemlidir çünkü Immich, durum bilgisini birbirinden habersiz iki farklı yerde tutar. Postgres; tüm albümleri, yüz gruplarını, paylaşılan bağlantıları, kullanıcı hesaplarını, API anahtarlarını ve her bir varlığın kayıtlı dosya yolunu saklar. Dosya sistemi ise pikselleri tutar. Dosyaları veritabanı olmadan geri yüklerseniz Immich size hiçbir şey göstermez. Veritabanını dosyalar olmadan geri yüklerseniz, her varlık bozuk bir görsel olarak açılır.

Buradaki komutlar, Ağustos 2026 başı itibarıyla güncel sürüm olan Immich v3.1.0 baz alınarak yazılmıştır. Proje hızlı güncellenmekte ve belgelenen yedekleme prosedürü birden fazla kez değişmiş durumdadır; bu nedenle herhangi bir komutu kopyalamadan önce kullandığınız sürümü mutlaka kontrol edin. Eğer yığın henüz kurulu değilse, Immich kurulum rehberi ile başlayıp ardından buraya dönün.

Yolların neyi işaret ettiğini bilin

Bu sayfadaki her şeyi iki değişken belirler: .env. UPLOAD_LOCATION, Immich'in tüm medya dosyalarını içine yazdığı üst dizindir. DB_DATA_LOCATION ise Postgres veri dizinidir.

Varsayılan example.env ayarı UPLOAD_LOCATION=./library değerini atar; bu kafa karıştırıcı bir varsayılandır çünkü Immich bunun içinde library adında bir klasör oluşturur. Orijinal dosyalarınız ./library/library konumunda biter. Bunun yerine mutlak bir yol belirleyin; böylece bir yedekleme betiği, onu hangi dizinden çalıştırdığınıza asla bağımlı kalmaz.

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

Immich, UPLOAD_LOCATION içinde çeşitli klasörler oluşturur. Bunlardan üçü, hiçbir işlemin yeniden oluşturamayacağı verileri tutar:

• library: depolama şablonunuza göre düzenlenmiş orijinal dosyalar
• upload: henüz şablon düzenine taşınmamış orijinal dosyalar ve yükleme aşamasındaki veriler
• profile: kullanıcı profil resimleri

library dizinini kaybederseniz fotoğraf da gider. Immich, orijinal dosyanın ikinci bir kopyasını hiçbir yerde tutmaz.

Postgres veri dizinini kopyalamanın neden yedekleme sayılmadığı

DB_DATA_LOCATION kolay bir hedef gibi görünür. Bir dizindir, rsync onu kopyalar ve kopyalama işlemi hatasız tamamlanır. Yine de bu bir yedekleme değildir; bunun başarısızlıkla sonuçlandığını görebileceğiniz iki nedeni vardır.

Birincisi veri tutarsızlığıdır (tearing). Postgres her değişikliği önce write-ahead log (WAL) dosyasına yazar, ardından bir checkpoint sırasında tablo dosyalarına uygular. Bu nedenle diskteki dosyalar herhangi bir anda işlem halindedir ve dört dakika süren bir kopyalama işlemi, ilk dosyayı 02:00'de, sonuncusunu ise 02:04'te okur. Bu iki dosya aynı işleme ait değildir. Postgres'i bu kopya üzerinde başlattığınızda, ya PANIC: could not locate a valid checkpoint record hatasıyla açılışta reddeder ya da başlar ve hasarlı bir sayfayı ilk okuduğunda invalid page in block 1234 of relation base/16384/... hatasıyla çöker. Her iki durumda da bu kopyadan kurtarma yapılamaz.

İkinci neden, her şeyi önceden durdursanız bile geçerliliğini korur. Bir Postgres veri dizini, onu yazan ikili dosyalarla (binaries) doğrudan ilişkilidir. Immich, veritabanı imajını digest değeriyle sabitler, bu değer şu an ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0'dur. Bu, içinde iki adet vektör arama eklentisi derlenmiş Postgres 14 sürümüdür. Bu derleme tarafından yazılan bir veri dizini, farklı bir Postgres ana sürümünde veya farklı eklenti sürümlerine sahip bir derlemede açılmaz. Geri yükleme yapacağınız sunucunun, imajı birebir aynı şekilde yeniden oluşturması gerekir. SQL dump ise bundan etkilenmez: metin tabanlıdır ve uyumlu herhangi bir sunucu tarafından tekrar işlenebilir.

pg_dump, veri tutarsızlığı sorununu tamamen ortadan kaldırır. Veritabanının tamamını tek bir MVCC (multi-version concurrency control) anlık görüntüsü (snapshot) içinde okur; böylece veritabanını, diğer yazma işlemleri devam ederken tam olarak tek bir andaki haliyle görür. Postgres'i dump almak için durdurmamanızın nedeni budur.

Yedekleme kapsamı dışında bırakabilecekleriniz

Bu veriler yeniden oluşturulabildiği için yedeklemeyi atlayabilirsiniz:

• thumbs: önizleme ve küçük resimler (thumbnails)
• encoded-video: dönüştürülmüş (transcoded) videolar
• DB_DATA_LOCATION: veritabanı dökümünden yeniden oluşturulabilir
• model-cache Docker volume: makine öğrenmesi modelleri, ihtiyaç duyulduğunda tekrar indirilir

Bunları yedeklememek bir tercihtir, tamamen ücretsiz bir kazanç değildir. Büyük bir kütüphane için küçük resimleri ve videoları yeniden oluşturmak, küçük bir VPS üzerinde saatlerce CPU kullanımı gerektirir ve bu süre zarfında zaman çizelgesinde gri yer tutucular görünür. Bunları Administration > Jobs menüsünden, "Generate Thumbnails" ve "Transcode Videos" seçeneklerini eksik varlıklar için çalışacak şekilde ayarlayarak yeniden başlatabilirsiniz. Yedekleme hedefinizde yer varsa, bunları dahil edin ve bekleme süresinden kurtulun. Depolama sınırınıza yaklaştıysanız, bunları yedekleme dışı bırakın ve yeniden oluşturma sürecini planlayın. Immich kütüphanesini boyutlandırma bölümü, bu klasörlerin orijinal dosyalara kıyasla ne kadar büyüdüğünü açıklar.

Bilmeniz gereken bir klasör daha var. UPLOAD_LOCATION/backups, Immich'in kendi otomatik veritabanı dökümlerini tutar. Bu dökümler her gün 02:00'de alınır, son 14 tanesi saklanır ve Administration > Settings > Backup altından yapılandırılabilir. Bunların size bir maliyeti yoktur ve oldukça faydalıdırlar. Ayrıca korudukları kütüphane ile aynı diskte bulunurlar; bu nedenle hatalı bir taşıma işleminde işe yararlar ancak sunucu arızasında bir çözüm sunmazlar. Yine de kendi dökümünüzü alın; çünkü manuel olarak tetiklediğiniz bir döküm, ilgili dosya anlık görüntüsüyle (snapshot) aynı ana denk gelir.

Veritabanı dökümünü alma

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

Eğer değiştirdiyseniz immich ve postgres değerlerini kendi DB_DATABASE_NAME ve DB_USERNAME bilgilerinizle değiştirin. --clean --if-exists, her CREATE ifadesinin önüne bir DROP ... IF EXISTS ekler; böylece döküm, halihazırda nesneler içeren bir veritabanına aktarılırken ilk nesnede durmak yerine işlemeye devam eder.

Şimdi yedekleme betiklerini sessizce bozan o detaya gelelim. Bu komut bir pipeline yapısıdır ve kabuk (shell), pipeline içindeki son komutun çıkış durumunu raporlar. Eğer pg_dump hatalı bir parola veya çalışmayan bir container nedeniyle başarısız olursa, gzip boş bir akış alır, tamamen geçerli bir gzip dosyası yazar ve 0 çıkış koduyla sonlanır. Betiğiniz başarı raporu verir ancak elinizde 20 baytlık bir yedek dosyası kalır. Her yedekleme betiğinin en üstüne pipefail ekleyin:

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

Ardından çıkış koduna güvenmek yerine sonucu kontrol edin:

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

Sağlıklı bir döküm dosyasının ilk satırı -- PostgreSQL database dump ifadesini içerir. Betiğin ne raporladığından bağımsız olarak, birkaç yüz baytlık bir dosya başarısız bir dökümdür.

Dökümün yanına hangi build tarafından oluşturulduğunu kaydedin:

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

Bunun için .env değerine güvenmeyin. Standart dosya setleri, her 3.x sürümünü takip eden değişken bir etiket olan IMMICH_VERSION=v3 değerini kullanır; bu nedenle dökümü hangi build'in oluşturduğuna dair hiçbir bilgi vermez. .env içindeki etiketi de tam sürüm numarasıyla sabitleyin.

Sunucuyu duraklatın ve restic ile anlık görüntü alın

UPLOAD_LOCATION altındaki dosyalar, Immich çalışırken değişmez değildir. Sunucu yeni yüklemeleri yazar ve depolama şablonu işi dosyaları dizinler arasında taşır. Bir yedekleme aracı bir dosyayı yazma işlemi sırasında okursa, o baytları dosyanın tamamıymış gibi depolar ve hiçbir hata rapor edilmez. Çalışma süresi boyunca sunucu container'ını durdurun:

docker stop immich_server

immich_postgres çalışmaya devam etmelidir, çünkü döküm işlemi buna ihtiyaç duyar. Sunucuyu tekrar başlatana kadar web arayüzü ve mobil uygulama çevrimdışı kalacaktır; ev tipi bir kurulumda saat 03:00'te bu genellikle sorun yaratmaz.

restic, verileri sunucudan çıkmadan önce tekilleştirdiği ve şifrelediği için bu senaryoya uygundur. Aracı, bu sunucuda bulunmayan bir depoya yönlendirin:

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

Nesne depolama (object storage) aynı şekilde çalışır ve kopyayı tamamen kendi donanımınızın dışına çıkarmak istiyorsanız daha iyi bir çözümdür:

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

Bu uç nokta, ikinci bir makinede kendinizin çalıştırdığı bir MinIO bucket'ı veya S3 uyumlu herhangi bir sağlayıcı olabilir. Kütüphane ile aynı disk üzerindeki bir depo, sizi yalnızca yanlışlıkla silme işlemine karşı korur, başka hiçbir şeye karşı korumaz.

Ardından, tam olarak neyin önemli olduğunu belirterek anlık görüntüyü alın:

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 her çalışmada tüm ağacı okur ancak yalnızca daha önce görmediği blokları yükler; bu nedenle ilk anlık görüntü tüm kütüphanenizi taşır, sonraki her anlık görüntü ise yalnızca o günün yeni fotoğraflarını taşır.

Saklama politikası ve başka bir yerde tutulması gereken anahtarlar

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

forget, snapshot'ları dizinden kaldırır. --prune ise bu snapshot'ların son referans olduğu verileri silen kısımdır. forget komutunu --prune bayrağı olmadan çalıştırırsanız depolama maliyetiniz asla düşmez.

Yapı kontrolleri düşük maliyetlidir, bu nedenle haftalık olarak çalıştırın:

restic check

Bu komut, depo meta verilerinin tutarlı olduğunu doğrular. Verilerinizi okumaz. Ayda bir kez, bir örneklem veriyi yeniden okuyun ve kayıtlı hash değerleriyle karşılaştırın:

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

Depolama arka ucundaki sessiz bozulmaları yakalayan tek kontrol budur; çünkü gerçek blokları indirir ve sağlama toplamlarını (checksum) yeniden hesaplar. Bir fotoğraf kütüphanesi üzerinde tam bir --read-data işlemi, tüm deponun indirilmesi anlamına gelir. Bu durum, ücretli nesne depolama (object storage) hizmetlerinde gerçek maliyet yaratır; bu nedenle kullanıcılar genellikle dönemsel bir alt küme üzerinde kontrol yapmayı tercih eder.

Şimdi insanların atladığı kısım: Bir restic depo parolası kurtarılamaz. Parola sıfırlama veya destek talebi oluşturma imkanı yoktur. Eğer parolanın tek kopyası, geri yüklemeye çalıştığınız sunucudaki /root/.restic-password içinde bulunuyorsa, yedekleriniz şifreli gürültüden ibarettir. Aynı durum nesne depolama erişim anahtarı ve .env içindeki DB_PASSWORD için de geçerlidir. Bunların hepsini, bu makinenin çalışır durumda olmasına bağlı olmayan bir yerde saklayın: çıktısını alıp bir çekmeceye koyun veya farklı bir donanımda çalışan bir parola yöneticisinde tutun. Eğer bu yönetici de self-hosted ise aynı muameleye ihtiyaç duyar ve Vaultwarden yedekleme işlemi başlı başına ayrı bir görevdir.

Immich uygulamasını doğru sırada geri yükleme

Geri yükleme sırası, iyi yedeklerin boş zaman çizelgelerine dönüştüğü yerdir. Yeni sunucuda bu sırayı takip edin.

Önce yapılandırmayı geri alın. Bu, hangi sürümü çalıştıracağınızı ve yolların nereyi işaret ettiğini size söyler.

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

Başlamadan önce sürümü sabitleyin. immich-version.txt kısmını okuyun, .env içindeki IMMICH_VERSION değerini tam olarak o etikete ayarlayın ve en yeni sürümü şimdilik olduğu gibi bırakın. Immich, yama sürümleri arasında bile olsa sürüm düşürmeyi desteklemez; bu nedenle daha yeni bir sunucu, eski bir döküm üzerinde başlar ve geçişlerini (migrations) çalıştırırsa geri dönüş yolu kalmaz.

Medya dosyalarını geri yükleyin.

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

Ardından library, upload ve profile dizinlerini, bu sunucuda UPLOAD_LOCATION değerinin işaret ettiği yerin içine doğrudan yerleşecek şekilde taşıyın. Sunucu üzerindeki yol değişebilir, çünkü compose dosyası bu dizini container içinde sabit bir yola bağlar. Ancak içindeki dizin yapısı değişemez.

Veritabanını tek başına başlatın. Postgres'in yeni bir küme başlatması için DB_DATA_LOCATION kısmını boş bırakın.

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

pg_isready, ilk kurulum tamamlandığında (bu birkaç saniye sürer) accepting connections çıktısını verir. docker compose create, tüm container'ları başlatmadan oluşturur ve bu adımın tüm amacı budur: Immich sunucusu henüz çalışmamalıdır. Boş bir veritabanına karşı başlayan bir sunucu, geçişlerini uygular, yeni bir şema oluşturur ve sizden yeni bir yönetici hesabı oluşturmanızı ister; bu durumda çalışan bir uygulamanın altına döküm yüklemeye çalışmış olursunuz.

Dökümü geri yükleyin.

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

Bunun iki parçası asıl işi yapar. sed mevcuttur çünkü pg_dump, bir güvenlik önlemi olarak çıktısına boş bir search_path yazar; böylece dökümdeki nitelenmemiş isimler beklenmedik bir şemaya çözümlenemez. Immich'in vektör arama türleri public içinde bulunur, bu nedenle boş bir arama yoluyla geri yükleme, vektör türüyle tanımlanmış ilk sütuna ulaştığında psql ERROR: type "vector" does not exist hatasıyla durur. public değerini yola geri eklemek bunu düzeltir.

--single-transaction --set ON_ERROR_STOP=on, tüm geri yükleme işlemini ilk hatada iptal edilen tek bir işlem (transaction) içine alır. Ya tam bir veritabanına ya da hiç dokunulmamış bir veritabanına sahip olursunuz. Bu olmadan, yarıda kalan bir hata; başlayan, girişinizi kabul eden ancak kaç tane olduğu bilinmeyen albümlerin eksik olduğu bir veritabanı bırakır ve bunu haftalar sonra fark edersiniz.

Şimdi her şeyi başlatın.

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

Immich Server is listening on gibi bir başlangıç satırı bekleyin, ardından 2283 numaralı portu açın ve eski kimlik bilgilerinizle giriş yapın; çünkü kullanıcı hesapları dökümle birlikte geri gelmiştir. Eğer giriş sayfası bunun yerine ilk yönetici hesabını oluşturmayı teklif ediyorsa, veritabanı geri yüklenmemiştir. Durun ve psql çıktısını tekrar okuyun.

Resmi geri yükleme talimatları hakkında bir uyarı: bu talimatlar docker compose down -v ile başlar. -v komutu, adlandırılmış birimleri (named volumes) siler. Standart compose dosyasında UPLOAD_LOCATION ve DB_DATA_LOCATION bağlama noktalarıdır (bind mounts), bu yüzden bu komuttan etkilenmezler. Eğer bunlardan herhangi birini adlandırılmış birime dönüştürdüyseniz, bu komut fotoğraflarınızı siler. Komutu yazmadan önce compose dosyanızı mutlaka okuyun.

Geri yükleme sonrasında zaman çizelgesi neden boş

Zaman çizelgesi veritabanı satırlarından oluşturulur. Immich, fotoğrafları yeniden keşfetmek için açılışta asla upload/ dizinini taramaz; çünkü veritabanı satırı olmayan bir dosyanın sahibi, tarihi ve albümü yoktur. Bu nedenle en yaygın hatalı geri yükleme senaryosu, dosyaların geri getirilip veritabanının eksik bırakılmasıdır. Immich başlar, boş bir şema oluşturur ve disk fotoğraflarınızla dolu olmasına rağmen size içinde hiçbir şey olmayan çalışan bir örnek sunar. Hiçbir şey kaybolmamıştır ancak hiçbir şey görünür de değildir. Çözüm, sunucu durdurulmuş haldeyken dökümü yukarıda belirtildiği şekilde yeniden yüklemektir.

İkinci senaryo daha sessizdir. Veritabanı geri yüklenir, zaman çizelgesi girdilerle dolar ancak hiçbir varlık (asset) açılmaz. Bu durum, satırların container'ın göremediği dosyalara işaret ettiği anlamına gelir; genellikle restic restore --target /restore komutundan sonra library, upload ve profile dizinlerinin bir seviye daha derinde kalmasından kaynaklanır. Tahmin yürütmek yerine container içinden kontrol edin:

docker exec immich_server ls /data

Standart compose dosyası UPLOAD_LOCATION dizinini /data konumuna bağlar (mount), bu nedenle listeleme işlemi library, upload ve profile dizinlerini göstermelidir. Eğer boş bir dizin veya fazladan bir srv klasörü görünüyorsa, bind mount işleminiz yanlış seviyeyi işaret ediyordur ve veritabanı satırlarınız aslında doğrudur.

Yedek ve geri yükleme arasında sürüm uyumu

Immich sık sık yeni sürümler yayınlar ve veritabanı şeması bu sürümlerle birlikte değişir; bu nedenle bir dump dosyası, onu oluşturan sunucunun şema yapısını taşır.

Eski bir dump dosyasını daha yeni bir sunucuya geri yüklemek genellikle çalışır; çünkü sunucu, başlatma sırasında bekleyen migrasyonları uygular ve şemayı ileriye taşır. Bu yol, sürüm dizisi boyunca test edilmiştir. Sorun, tek adımda birden fazla ana sürüm atlandığında ortaya çıkar; proje, köklü değişiklikleri ana sürümlere saklar ve bunları değişiklik günlüğünde (changelog) belgeler.

Daha yeni bir dump dosyasını daha eski bir sunucuya geri yüklemek ise kesinlikle çalışmaz. Dump dosyası, eski kodun tanımadığı tablo ve sütunlar içerir. Immich, yama sürümleri arasında dahi sürüm düşürmenin (downgrade) desteklenmediğini belirtir. Başvurulabilecek bir geri alma (rollback) komutu bulunmamaktadır.

Bu nedenle güvenli geri yükleme yöntemi standart olandır. Dump dosyasını oluşturan sürümün aynısını çalıştırın, veriyi geri yükleyin, giriş yapın, zaman çizelgesinin eksiksiz olduğunu doğrulayın ve ancak bundan sonra yükseltme yapın. Her seferinde tek bir sürüm yükseltin, IMMICH_VERSION değerini güncelleyin ve her yükseltmeden sonra docker compose pull && docker compose up -d komutunu çalıştırın. Bir haftalık dump dosyalarını saklamak bu noktada yardımcı olur: Eğer en yeni dump dosyasının hatalı bir yükseltme sırasında alındığı ortaya çıkarsa, dünkü yedeğiniz hala deponuzda duruyor olacaktır.

Yedekleri her ay doğrulayın

Geri yüklemesini hiç yapmadığınız bir yedek, sadece bir tahmindir. Ayda bir kez yedeği geçici bir sunucuya geri yükleyin ve bir fotoğrafa bakın. Bu tatbikat yaklaşık yirmi dakika sürer ve bu sayfanın geri kalanını bir kurtarma planına dönüştüren tek şey budur.

restic snapshots
restic stats latest

snapshots, dün geceki çalışmayı listelemelidir. stats latest, birkaç megabayt değil, kütüphanenize yakın bir boyut bildirmelidir.

İdeal olarak yedek bir sunucuda, geçici bir dizine geri yükleme yapın:

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

docker-compose.yml ve .env dosyalarını geri yüklenen kümeden kopyalayın, ardından kopyadaki üç şeyi değiştirin. UPLOAD_LOCATION ve DB_DATA_LOCATION değerlerini /tmp/immich-drill altındaki dizinlere yönlendirin. Web portunu başka bir yere, 2283:2283 yerine 12283:2283 olarak yayınlayın. container_name: satırlarını silin; çünkü standart compose dosyası immich_server gibi isimleri sabit kodlar, bu yüzden aynı sunucudaki ikinci bir yığın ilkiyle çakışır ve Docker oluşturmayı reddeder.

Yukarıdaki geri yükleme sırasını çalıştırın: sadece veritabanı, dump dosyasını tekrar oynatın, ardından docker compose up -d komutunu kullanın. Şimdi bir şeylerin çalıştığını kanıtlayan dört kontrolü yapın.

1. Tatbikattan önce kullandığınız şifreyle giriş yapın. Çalışan hesaplar, dump dosyasının başarıyla geri yüklendiği anlamına gelir.
2. Zaman çizelgesini açın ve en eski aya gidin. Tüm tarih aralığındaki varlıklar, sadece son verilerin değil, tüm satırların geri geldiği anlamına gelir.
3. Bir fotoğrafı tam boyutta açın ve orijinalini indirin.
4. sha256sum ile canlı kütüphanenizdeki aynı dosya ile karşılaştırın. Eşleşen hash değerleri, baytların restic üzerinden gidiş-dönüş sürecinde bozulmadan kaldığı anlamına gelir.

Ardından tatbikat dizininde docker compose down -v ile sistemi kapatın ve /tmp/immich-drill dizinini silin. Tarihi görebileceğiniz bir yere not edin, çünkü bunun değeri tamamen önümüzdeki ay tekrar yapılmasına bağlıdır. Hangi fotoğraf sunucusunu kullanacağınıza hala karar veriyorsanız, PhotoPrism ve Immich karşılaştırması bu iki yazılımın tam olarak bu konuda nasıl farklılaştığını ele almaktadır.

FAQ

Yedekleme yapmak için Immich'i durdurmam gerekiyor mu?

immich_server servisini durdurun ve immich_postgres servisini çalışır durumda bırakın. Veritabanının duraklatılmasına gerek yoktur; çünkü pg_dump tek bir MVCC anlık görüntüsü (snapshot) üzerinden okuma yapar ve başka işlemler yazma yapsa dahi tutarlı bir anı görür. Dosyalar, durdurma işleminin asıl nedenidir: sunucu yeni yüklemeleri yazar ve depolama şablonu işi dosyaları dizinler arasında taşır. Bu sırada bir yedekleme aracı, dosyanın yazılması bitmeden okuma yapabilir ve hatalı, eksik bir kopya oluşturabilir. Anlık görüntüden önce docker stop immich_server ve sonrasında docker start immich_server komutlarını çalıştırmak bu çakışma riskini ortadan kaldırır.

pg_dump çalıştırmak yerine Postgres veri klasörünü kopyalayabilir miyim?

Hayır. Çalışan bir veri dizininin anlık kopyası, farklı dosyaları farklı zamanlarda okur; bu nedenle sonuç tutarlı bir durum oluşturmaz. Postgres, başlangıçta PANIC: could not locate a valid checkpoint record hatası verir veya daha sonra bozuk bir sayfa nedeniyle başarısız olur. Her şey durdurulmuş olsa bile alınan bir kopya, doğrudan veritabanı sürümüne bağlıdır: Immich, belirli vektör arama eklentisi sürümlerine sahip bir Postgres 14 imajı kullanır ve bu dizin başka bir sürümde açılmaz. SQL dökümü ise düz metindir ve uyumlu herhangi bir sunucuya tekrar yüklenebilir.

Geri yükleme sonrasında Immich zaman çizelgem neden boş?

Zaman çizelgesi veritabanı satırlarından oluşturulur ve siz veritabanını dahil etmeden sadece dosyaları geri yüklediniz. Immich, fotoğrafları yeniden keşfetmek için upload/ dizinini taramaz; bu nedenle veritabanında satırı olmayan dosyalar görünmez kalır. Fotoğrafların kendisi bozulmamıştır. Sunucuyu durdurun, dökümü yeni başlatılmış bir Postgres örneğine geri yükleyin ve ardından yığını başlatın. Eğer zaman çizelgesi dolu ancak fotoğraflar açılmıyorsa, sorun tam tersidir: library, upload ve profile yolları, container içine bağlanan dizinin doğrudan içinde değildir. Bunu docker exec immich_server ls /data ile kontrol edin.

Yedeklemede hangi Immich klasörlerini atlayabilirim?

thumbs ve encoded-video klasörleri orijinallerden yeniden oluşturulabilir, DB_DATA_LOCATION ise dökümden tekrar inşa edilebilir; bu nedenle yedekleme setinde bulunmaları zorunlu değildir. Bunları atlamak, yedekleme öncesinde depolama alanından tasarruf sağlar ancak geri yükleme sonrasında işlem süresini artırır. Büyük bir kütüphane için önizlemeleri ve kod dönüştürme işlemlerini yeniden oluşturmak saatlerce CPU gücü gerektirir ve Administration > Jobs menüsü üzerinden eksik varlıklar için çalıştırılır. Asla atlamamanız gerekenler, her orijinalin tek kopyasını barındıran library, upload ve profile dizinleridir.

Immich dökümünü daha yeni bir sürüme geri yükleyebilir miyim?

Genellikle evet; çünkü sunucu başlangıçta bekleyen geçişleri (migrations) uygular ve şemayı günceller. Tersi durum başarısız olur: Immich, yama sürümleri arasında bile olsa sürüm düşürmeyi desteklemez. Bu nedenle daha yeni bir sürümden alınan döküm, daha eski bir sunucuya yüklenemez. Dökümü alan sürümle sabitlenmiş IMMICH_VERSION kullanarak geri yükleme yapın, zaman çizelgesinin tam olduğunu doğrulayın ve ardından yükseltmeyi gerçekleştirin. Her dökümün yanına docker inspect --format '{{.Config.Image}}' immich_server ile sürüm bilgisini not edin; çünkü varsayılan IMMICH_VERSION=v3 etiketi değişken bir değerdir ve sürüm hakkında bilgi vermez.