Month: June 2026

Ev sunucusu (NAS) kullananların en büyük kabuslarından biri, sistem çökmeleri veya disk doluluğu nedeniyle canlıdaki verileri yeni bir sunucuya taşımak zorunda kalmaktır. Hele ki bu veri, içinde binlerce aile anısını, albüm yapılarını ve kullanıcı eşleşmelerini barındıran Immich gibi devasa bir fotoğraf arisviyse süreç daha da stresli bir hal alabilir.

Bu yazıda, eski bir TrueNAS SCALE sunucusunda alanı tamamen dolmuş olan ve web arayüzüne bile erişmekte zorlanan 41.008 adet görsel/videodan (38.923 fotoğraf, 2.085 video) oluşan dev bir Immich arşivini, yeni bir TrueNAS SCALE sunucusuna Docker katmanları ve SSH tünelleri kullanarak nasıl “sıfır veri kaybı” ve “karıştırma riski olmadan” taşıdığımızı, yaşadığımız pratik zorluklarla birlikte adım adım anlatıyoruz.

Senaryo ve Karşılaşılan İlk Zorluklar

Eski sunucumuzun disk alanı %100 dolduğu için sistem kararsızlaşmıştı ve yerel ağda IP adresi sürekli değişiyordu (.195 -> .197 -> .146). Bu durum, sysadmin dünyasının ilk altın kuralını hatırlattı: “Asla varsayımlarla hareket etme, her adımda nerede olduğunu doğrula!”

Verileri taşımak için web arayüzünden sürükle-bırak yapmak 41 bin dosyada tarayıcıyı kilitleyeceği için operasyonu tamamen SSH ve Docker CLI üzerinden yürütmeye karar verdik.

Adım 1: Docker Konteynerinin İçine Sızmak ve Doğru CLI Aracını Bulmak

İlk hedefimiz, eski Immich sunucusuna komut satırından bağlanıp API Key yardımıyla kütüphane durumunu doğrulamaktı.

Eski NAS’a SSH ile bağlandıktan sonra ana Immich konteynerini bulup içine sızdık:

Bash

sudo docker exec -it <konteyner_id> sh

Burada ilk aldığımız hata sh: 1: immich: not found oldu. Immich, mikroservis mimarisiyle çalıştığı için her konteynerin içinde CLI aracı yüklü gelmez. Çözüm olarak Node.js’in npx paket yöneticisinden beslenmek istedik:

Bash

npx immich-cli login http://localhost:3001/api "API_KEY"

Ankara, npm registry dünyasında Immich ekibinin bu aracı @immich/cli ismiyle yayınladığını (E404 hatasıyla) keşfettik. Komutu güncellediğimizde ise karşımıza ECONNREFUSED 127.0.0.1:3001 ağ hatası çıktı.

Alınan Ders (Docker Networking): Konteynerin içindeyken localhost dediğinizde, servis aynı odanın (konteynerin) içinde dinleme yapmıyorsa istek boşa düşer. Docker bridge modunda çalışıyorsa, konteyner içinden dış kapıya dolanmak için sunucunun gerçek yerel IP’sini kullanmak gerekir.

Komutu sunucunun o anki güncel IP’sine yönlendirerek nihayet yeşil ışığı yaktık ve durum raporunu aldık:

Bash

npx @immich/cli login http://192.168.2.146:30041/api "API_KEY"
# Logged in as mkmuratkaya@gmail.com

Adım 2: İki Sunucuyu Dijital İmza (SSH Key) ile Evlendirmek

Eski sunucunun diski tamamen dolu olduğundan, dosyaları kendi içinde sıkıştırıp taşımak diski patlatırdı. Veriyi eski diskte hiç yer kaplamadan doğrudan yeni sunucuya akıtmak için iki sunucu arasında şifresiz, güvenli bir SSH Tüneli inşa etmeliydik.

Eski NAS üzerinde bir dijital imza ürettik:

Bash

ssh-keygen -t ed25519

Ancak bu aşamada sinsi bir hata yaptık ve komutun başına sudo koyduk. Bu yüzden anahtar bizim normal kullanıcımızın (truenas_admin) odasında değil, kök kullanıcının (root) odasında üretildi.

Güvenlik Paradoksu ve Dosya İzinleri

Yeni NAS’a bu anahtarı ssh-copy-id ile göndermek istediğimizde yeni sunucu Permission denied (publickey) hatası verdi. Çünkü yeni sunucu güvenlik gereği şifreyle girişi kapatmıştı; anahtarı eklemek için şifre istiyor, şifre girmek istediğimizde ise “şifre kabul etmiyoruz” diyerek bizi dışarı atıyordu!

Çözüm: Yeni TrueNAS web arayüzüne gidip truenas_admin kullanıcısında varsayılan olarak kapalı gelen “SSH Access” kutucuğunu işaretledik. Bu kutucuk açılınca altından beliren SSH Public Key alanına, eski sunucuda ürettiğimiz anahtarı yapıştırdık.

Yetmedi; Linux’un katı kuralları gereği, anahtarların saklandığı klasörlerin izinlerini (Permissions) sadece sahibinin okuyabileceği şekilde sıkılaştırdık:

Bash

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Zsh Kabuğu ve Yıldız (*) Engeli

Anahtarları root odasından kendi kullanıcımızın odasına taşırken Eski NAS’ın varsayılan kabuğu olan Zsh araya girdi. sudo cp /root/.ssh/* ~/.ssh/ komutundaki yıldız karakterini Zsh henüz yetkisi yokken taramaya çalıştığı için zsh: no matches found hatası fırlattı. Dosya isimlerini tek tek açıkça yazarak bu engeli de aştık ve nihayet sudosuz olarak yeni sunucunun disk yapısını listelemeyi başardık:

Bash

ssh truenas_admin@192.168.2.89 "ls -la /mnt"

Adım 3: Büyük Veri Aktarımı (rsync) ve “Kullanıcılar Karışır mı?” Endişesi

Docker üzerinde docker inspect <konteyner_id> komutunu çalıştırarak Immich’in fotoğrafları ham olarak sakladığı ambarı bulduk: /mnt/.ix-apps/app_mounts/immich/library/

Transfere başlamadan önce akıllardaki en büyük soru şuydu: “Kürek kürek resimleri yeni sunucuya atınca kullanıcıların fotoğrafları birbirine karışacak mı?”

Kritik Bilgi: Immich, veri tabanında her kullanıcıya benzersiz bir UUID (harf ve sayılardan oluşan karmaşık kimlik) atar. Disk üzerinde de fotoğrafları library/UUID_kodu/ şeklinde klasörler halinde saklar. Yani fotoğraflar zaten diskin içinde birbirine tamamen izole odalardadır.

Ağ üzerinden canlı yayın yapar gibi dosyaları güvenle aktarmak, elektrik kesilse bile kaldığı yerden devam edebilmesini sağlamak için Linux’un en zeki aracı olan rsyncı çalıştırdık:

Bash

sudo rsync -avz --progress /mnt/.ix-apps/app_mounts/immich/library/ truenas_admin@192.168.2.89:/mnt/hdd_data/eski_immich_yedek/

• -a parametresi sayesinde fotoğrafların çekilme ve oluşturulma tarihleri (metadata) hiç bozulmadan korundu.
• -z ile veriler havada sıkıştırılarak ağ trafiği optimize edildi.

Sonuç ve Yeni Sunucuda Aktivasyon

Şu an 41 bin dosya yeni yatağına doğru güvenle akıyor. Transfer tamamlandığında yeni sunucudaki Immich üzerinde süreç şu iki adımla tamamlanacak:

1. Yeni Immich’te, eski sunucudaki e-posta adresleriyle birebir aynı kullanıcı hesapları açılacak.
2. Taşınan bu klasör, Yeni Immich’e “External Library” (Harici Kütüphane) olarak gösterilecek. Immich klasör yapısındaki UUID kodlarını tarayarak veri tabanındaki e-postalarla şak diye eşleştirecek ve herkes sadece kendi anılarını tertemiz bir şekilde görmeye devam edecek.

Sysadminlik; sabır, doğru log okuma ve protokollerin katı kurallarına saygı duyma sanatıdır. Bir sonraki teknik rehberimizde görüşmek üzere!