2026'da Duplicati Self-Hosting: Şifreli Yedekler, Mount'lar ve Geri Yükleme Testleri

Duplicati'yi daha önce self-host etmeyi denediyseniz, can sıkıcı bu duruma muhtemelen aşinasınızdır: UI açılır, ancak host kaynakları başka bir yere mount edildiği için container boş bir path görür. Container'ı yeniden oluşturmak; URL'ler, state ve bağımlılıklar arasındaki uyuşmazlığı nadiren çözer.

Bu walkthrough'ta tek bir somut tamamlanma kriteri kullanıyoruz: bir test dizinini seçilen hedefe yedeklemek, bir kaynak dosyasını silmek ve dosyayı temiz, alternatif bir path'e geri yüklemek. Her yapılandırma tercihini, yeşil container rozeti yerine bu kritere göre değerlendiriyoruz.

Portlar, process'ler ve private servisler

Kullanışlı bir Duplicati diyagramı public route'u, private 8200 portunu, state sınırını ve tüm destek gereksinimlerini gösterir. Hangi okların credential taşıdığını, hangilerinin ise sıradan user traffic olduğunu işaretleyin. Duplicati'nin network contract'ı, read-only source mount'ları ile erişilebilir backup destination storage'dan oluşur. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Duplicati'ye kapsamı sınırlandırılmış bir service credential verin.

Diyagramı tek bir gerçek işlemle doğrulayın: bir test dizinini seçilen hedefe yedekleyin, bir kaynak dosyasını silin ve dosyayı temiz, alternatif bir path'e geri yükleyin. Olası yükü kaynak dosyası sayısı, compression, encryption, destination latency ve zamanlanmış job'ların çakışması oluşturur; tüm HTTP request'lerini eşit kabul etmek yerine bu path'i izleyin.

Sağlıklı görünen bir Duplicati'yi teşhis etme

Dashboard'ları kaynak dosyası sayısı, compression, encryption, destination latency ve zamanlanmış job'ların çakışması etrafında oluşturun. Bu workload context'i olmadan bir CPU grafiği, Duplicati'nin neden yavaş olduğunu açıklayamaz. Zararsız test verileri kullanarak bir test dizinini seçilen hedefe yedekleyen, bir kaynak dosyasını silen ve dosyayı temiz, alternatif bir path'e geri yükleyen synthetic veya zamanlanmış bir check ekleyin.

Upgrade öncesinde uygulamaya özgü şu riski hesaba katın: Duplicati'nin configuration database'i ve backup format değişiklikleri, tek remote backup set'inin üzerine yazılmadan test edilmelidir. Yakın tarihli bir backup'ı isolated bir deployment'a restore edin, migration'ları orada çalıştırın ve davranışı karşılaştırın. Container boş bir path görüyorsa (host kaynakları başka bir yere mount edildiği için), ilgisiz ayarlara dokunmadan önce ilgili sınırı (public origin, storage veya dependency) inceleyin.

Gerçek Duplicati verileri gelmeden önce geçmesi gerekenler

Duplicati için release kaydı “iyi görünüyor” gibi ifadeler değil, somut bilgiler içermelidir. Seçilen image digest'ini, configuration checksum'ını, public hostname'i ve şu işlem için timestamp içeren sonucu kaydedin: bir test dizinini seçilen hedefe yedeklemek, bir kaynak dosyasını silmek ve dosyayı temiz, alternatif bir path'e geri yüklemek. Check'in her deployment sonrasında çalıştırılabilmesi için production dışı örnek veriler kullanın.

İki lifecycle event'ini ayrı ayrı doğrulayın. Container replacement normal çalışmayı korumalıdır; clean recovery ise fresh bir Duplicati instance'ının configuration'ı import edebildiğini ve seçilen dosyaları doğrulanmış hash'lerle geri yükleyebildiğini göstermelidir. Check'ler çalışırken kaynak dosyası sayısını, compression'ı, encryption'ı, destination latency'yi ve zamanlanmış job'ların çakışmasını ölçün; sonucu bu sürüm için beklenen envelope olarak saklayın.

Ayrıca reddedilmiş veya geçersiz bir durumu da test edin: test identity'sinin read-only source mount'ları ile erişilebilir backup destination storage'a erişimini geçici olarak engelleyin. Duplicati teşhis edilebilir bir şekilde hata vermeli ve sağlıklı state'in üzerine yazmamalıdır. Geçerli duruma dönün, örneği yeniden çalıştırın ve ilgili redacted log'ları ekleyin. Bu artifact'ler, gelecekteki bir rollback kararı için somut kanıt sağlar.

Local command'ı incelenebilir bir servise dönüştürme

Aşağıdaki command, her external service'i provision ediyormuş gibi davranmadan container sınırını görünür kılar.

docker run -d \
  --name duplicati \
  --restart unless-stopped \
  -p 127.0.0.1:8200:8200 \
  -v duplicati-data:/config \
  -v /srv/data:/source:ro \
  -e SETTINGS_ENCRYPTION_KEY=replace-with-a-long-random-value \
  lscr.io/linuxserver/duplicati:latest

Ingress'i açmadan önce çözümlenen environment'ı, mount'ları ve listener'ı inceleyin. Read-only source mount'ları ile erişilebilir backup destination storage için gözden geçirilmiş connection settings'i ekleyin; private servisler için private name'ler kullanın. Başarılı launch, docker ps çıktısında Up görülmesiyle değil, bir test dizinini seçilen hedefe yedekleyip bir kaynak dosyasını sildikten sonra dosyayı temiz, alternatif bir path'e geri yükleyebildiğinizde tamamlanır.

Duplicati recovery'yi ölçülebilir hâle getirme

İlk gerçek record oluşturulmadan önce state'i listeleyin: Duplicati configuration database'i ve ayrı olarak doğrulanmış backup set'leri. Bootstrap işleminden önce /config'i mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Zararsız veriler yazarak, Duplicati'yi değiştirerek ve verileri yeniden okuyarak mount'ı doğrulayın.

Snapshot'lar hızlı rollback için değerlidir; ancak host veya volume ortadan kalktığında bağımsız bir backup gerekir. Pinned image'ı kullanarak boş bir environment'a restore edin ve fresh bir Duplicati instance'ının configuration'ı import edebildiğini ve seçilen dosyaları doğrulanmış hash'lerle geri yükleyebildiğini doğrulayın. Bu iki recovery mekanizmasını birbirinden ayrı tutmak için persistent volume ve snapshot'lar içeriğini kullanın.

TLS kolaydır; generated URL'ler ise değildir

Duplicati için tek bir HTTPS hostname yayınlayın; raw 8200 portunu private tutun. Management UI'ı private tutun veya HTTPS arkasında güçlü authentication uygulayın. Bu, browser'ların ve API client'larının birbiriyle yarışan iki adres öğrenmesini önler.

Temiz bir client'tan bilinen iyi transaction'ı çalıştırın ve ilk başarısız request'i inceleyin. DNS veya TLS hatalı olduğunda custom-domain rehberini kullanın. “Container, host kaynakları başka bir yere mount edildiği için boş bir path görüyor” durumunu, route doğrulandıktan sonra ayrı bir application diagnosis olarak ele alın.

Bootstrap sonrasında Duplicati'yi sıkılaştırma

Bootstrap credential'ları geçicidir; trust model kalıcıdır. Duplicati ile backup source'larını read-write mount etme veya encryption passphrase'ini kaybetme risklerine dikkat edin; source'ları read-only mount edin, management UI'ı private tutun ve backup passphrase'ini server dışında saklayın.

SETTINGS_ENCRYPTION_KEY'i bir kez oluşturun, Git dışında tutun ve recovery manifest ile birlikte saklayın; çünkü bu anahtarı değiştirmek encrypted veya signed application state'i geçersiz kılabilir. Image'ı gereksiz Linux capability'leri olmadan çalıştırın ve yalnızca public application route'unu yayınlayın. Secret değerleri kaydetmeden administrator activity'sini görünür tutun.

Platform katmanı için Dockup kullanma

Duplicati için Dockup route'u ve TLS certificate'ı oluşturabilir, mount'ları koruyabilir, secret'ları iletebilir ve read-only source mount'ları ile erişilebilir backup destination storage'ı private networking üzerine yerleştirirken deployment'ı ister Dockup'a ister bağlı server'lara yapabilir.

Release gate hâlâ somut Duplicati transaction'ıdır: bir test dizinini seçilen hedefe yedeklemek, bir kaynak dosyasını silmek ve dosyayı temiz, alternatif bir path'e geri yüklemek. Ayrıca recovery koşulunu da doğrulayın: fresh bir Duplicati instance'ı configuration'ı import edebilmeli ve seçilen dosyaları doğrulanmış hash'lerle geri yükleyebilmelidir. Bu iki check, deployment'ın çalışıp çalışmadığını ve kurtarılabilir olup olmadığını gösterir.

Sık sorulan sorular

Production deployment için Duplicati'nin neye ihtiyacı var?

Duplicati container'ını port 8200 üzerinden tek bir HTTPS origin'e route edin. Supporting network requirement, read-only source mount'ları ile erişilebilir backup destination storage'dır. Bir test dizinini seçilen hedefe yedekleyip bir kaynak dosyasını sildikten sonra dosyayı temiz, alternatif bir path'e geri yükleyemediğiniz sürece Duplicati'yi hazır kabul etmeyin.

Hangi Duplicati verileri backup'a dahil edilmelidir?

/config'i kalıcı hâle getirin ve Duplicati configuration database'i ile ayrı olarak doğrulanmış backup set'lerini aynı recovery manifest'e dahil edin. Clean Duplicati restore yalnızca fresh bir Duplicati instance'ı configuration'ı import edebildiğinde ve seçilen dosyaları doğrulanmış hash'lerle geri yükleyebildiğinde başarılı sayılır.

Reverse proxy arkasında Duplicati için HTTPS gerekli mi?

Public Duplicati origin'i için HTTPS kullanın ve 8200 portunu internal route üzerinde tutun. Duplicati ayarını doğru uygulayın: management UI'ı private tutun veya HTTPS arkasında güçlü authentication uygulayın. Duplicati için HTTPS, credential'ları veya user content'i transit sırasında korur ve origin'e duyarlı client davranışını tutarlı hâle getirir.

Bir Duplicati upgrade'i nasıl test edilmelidir?

Mevcut Duplicati state'ini isolated bir deployment'a restore edin, aday sürümü uygulayın ve kabul transaction'ını tekrarlayın. Duplicati'nin configuration database'i ve backup format değişiklikleri, tek remote backup set'inin üzerine yazılmadan test edilmelidir; bu noktaya özellikle dikkat edin. Data migration ve rollback sınırları anlaşılana kadar önceki Duplicati image'ını saklayın.