Docker'daki Uygulamamı Nasıl Yedeklerim? Volume, Veritabanı ve Geri Yükleme Provası

Sunucunuza bir Compose dosyasıyla Nextcloud, Vaultwarden ya da bir Ghost blogu kurdunuz. Aylardır sorunsuz çalışıyor, dosyalarınız içinde, veritabanı büyüyor. Sonra bir gün imajı güncellerken bir şey ters gidiyor: konteyner ayağa kalkmıyor, veritabanı şeması yarım kalıyor ya da yanlış bir docker compose down -v komutu volume'ları da siliyor. O anda aklınıza gelen ilk soru şu oluyor: "Ben bunun yedeğini almış mıydım, aldıysam tam olarak neyin yedeğini almıştım?"

Bu soruyu yanıtlamak sanıldığından zor, çünkü Docker'da "uygulama" tek bir yerde durmaz. Kod imajın içindedir ve zaten registry'de bulunur. Veri volume'lardadır. Yapılandırma Compose dosyası ile .env dosyasındadır. Sertifikalar ve alan adı eşlemeleri ise çoğu zaman bambaşka bir dizindeki ters proxy yapılandırmasındadır. Bunlardan birini atlayan bir yedek, felaket anında ya hiç açılmaz ya da açılır gibi görünüp yarım çalışır.

Bu rehberde bir Docker uygulamasının yedeğini uçtan uca ele alacağız: hangi parçaların yedeklenmesi gerektiği, çalışan bir veritabanının neden ham dosya kopyasıyla yedeklenemeyeceği, container içinden dump almanın doğru yolu, volume ve bind mount arşivleme farkı, otomasyon, saklama politikası ve en sonda asıl değeri olan bölüm: geri yükleme provası. Test edilmemiş bir yedek, yedek değildir; yalnızca yedek olduğunu düşündüğünüz bir dosyadır. Volume kavramına yabancıysanız Docker volume ile kalıcı veri yönetimi yazısı buradaki her şeyin altyapısını veriyor.

Container Yedeği Nereye Gider? Yedeklenmesi Gereken Dört Parça#

İlk düzeltmemiz gereken yanlış anlama şu: konteynerin kendisini yedeklemek anlamlı değildir. docker commit ile çalışan bir konteyneri imaja çevirmek teknik olarak mümkündür ama bu bir yedekleme yöntemi değildir; ürettiği imaj tekrarlanabilir değildir, nasıl oluştuğu kayıt altında değildir ve içindeki veri tutarsız bir anın fotoğrafıdır. Aynı şekilde imajları yedeklemek de gereksizdir, çünkü docker compose pull ile her zaman yeniden indirilebilirler.

Gerçekten yedeklenmesi gereken dört parça vardır:

Uygulamanızın hangi volume'ları kullandığını tahmin etmeyin, sorun:

# Compose projesindeki servisleri ve volume'ları listele
docker compose config --volumes
docker volume ls

# Belirli bir konteynerin bağlı olduğu her şeyi gör
docker inspect -f '{{range .Mounts}}{{.Type}} {{.Name}}{{.Source}} -> {{.Destination}}
{{end}}' nextcloud-app

Son komutun çıktısında volume tipindekiler Docker'ın yönettiği hacimler, bind tipindekiler ise host üzerindeki dizinlerdir. İkisinin yedekleme yöntemi farklıdır; ilerideki bölümde ikisini de ayrı ele alacağız.

Küçük ama pahalı bir ayrıntı: Compose, named volume adlarının başına proje adını ekler ve proje adı varsayılan olarak Compose dosyasının bulunduğu dizin adıdır. /srv/nextcloud altında tanımladığınız data volume'u sistemde nextcloud_data olarak görünür. Geri yüklerken projeyi başka isimli bir dizine açarsanız Compose yepyeni ve boş volume'lar oluşturur; siz de "yedek geri gelmedi" sanırsınız. Yedek notlarınıza proje adını da yazın.

En Pahalı Yanlış: Çalışan Veritabanının Ham Volume Dosyalarını Kopyalamak#

En sık yapılan ve en pahalıya patlayan hata şu:

# BU YEDEK GÜVENİLİR DEĞİLDİR
docker run --rm -v nextcloud_db:/veri:ro -v /yedek:/yedek alpine \
  tar czf /yedek/db.tar.gz -C /veri .

Komut çalışır, dosya oluşur, boyutu makul görünür. Sorun şu ki MySQL, MariaDB veya PostgreSQL çalışırken veri dosyaları sürekli değişir. Veritabanı motoru, bir yazma işlemini bellekte, yazma-öncesi günlükte (WAL / redo log) ve tablo dosyalarında farklı anlarda gerçekleştirir. tar komutu bu dosyaları alfabetik sırayla, saniyeler süren bir işlemde tek tek okur. Sonuç: arşivin başındaki dosya sabah 03:00:01'in, sonundaki dosya 03:00:47'nin hâlidir. Bu iki an arasında yapılan her işlem yedeği tutarsız hâle getirir.

Böyle bir yedeği geri yüklediğinizde üç sonuçtan biriyle karşılaşırsınız: motor açılışta kurtarma (crash recovery) yapar ve şanslıysanız çalışır; bazı tablolar bozuk olarak işaretlenir; ya da hiç açılmaz. Kötü haber şu ki bu üç sonuçtan hangisini alacağınızı yalnızca gerçekten ihtiyaç duyduğunuz anda öğrenirsiniz.

Aynı mantık sanallaştırma katmanındaki disk anlık görüntüleri için de kısmen geçerlidir; ikisi arasındaki farkı snapshot mı yedek mi yazısında ayrıntısıyla ele aldık.

Ham dosya kopyası yalnızca veritabanı durdurulduğunda güvenlidir:

docker compose stop db
docker run --rm -v nextcloud_db:/veri:ro -v /yedek:/yedek alpine \
  tar czf /yedek/db-cold.tar.gz -C /veri .
docker compose start db

Bu yönteme "soğuk yedek" denir ve gerçekten tutarlıdır — bedeli, yedek süresince servisin kapalı kalmasıdır. Küçük kişisel kurulumlarda kabul edilebilir; ama tercih edilmesi gereken yöntem bir sonraki bölümdedir.

Veritabanını Doğru Yedekleme: Container İçinden Dump Almak#

Doğru yöntem, veritabanının kendi araçlarına iş yaptırmaktır. Motor, yedeği kendi tutarlı görünümünden üretir; dosyaların o an ne hâlde olduğu önemli değildir.

MySQL ve MariaDB#

docker exec -i nextcloud-db \
  mariadb-dump --single-transaction --quick --default-character-set=utf8mb4 \
  -u root -p"$MYSQL_ROOT_PASSWORD" nextcloud \
  | gzip > /yedek/nextcloud-db-$(date +%F).sql.gz

Üç ayrıntı burada kritik:

• -i kullanın, -t kullanmayın. docker exec -it alışkanlığı bir sözde terminal açar ve çıktıya satır sonu karakterleri ekler. Bu, SQL dosyasını sessizce bozar; sorun ancak geri yüklemede ortaya çıkar. Çıktıyı dosyaya yönlendireceğiniz her komutta -t bayrağını çıkarın.
• --single-transaction InnoDB tablolarında tabloları kilitlemeden tutarlı bir anlık görünüm alır. Yani site açık kalmaya devam eder. MyISAM tablolarınız varsa bu bayrak işe yaramaz; onlar için kilit gerekir.
• Komut adı sürüme göre değişir. MariaDB 11 ve sonrasında araç mariadb-dump, eski sürümlerde ve MySQL imajlarında mysqldump'tır. Emin değilseniz docker exec nextcloud-db sh -c "command -v mariadb-dump mysqldump" ile hangisinin bulunduğuna bakın.

Parolayı komut satırına yazmak yerine Compose'un .env dosyasından okutmak daha temizdir. mysqldump bayraklarının ayrıntısı için mysqldump ile veritabanı yedekleme yazısına bakabilirsiniz; oradaki her şey container içinde de aynen geçerlidir.

PostgreSQL#

docker exec -i vaultwarden-db \
  pg_dump -U vaultwarden -Fc vaultwarden \
  > /yedek/vaultwarden-db-$(date +%F).dump

-Fc (custom format) çıktıyı sıkıştırılmış ve pg_restore ile seçici geri yüklenebilir bir biçimde üretir; düz SQL isterseniz bayrağı kaldırın. Sunucuda birden fazla veritabanı ve rol varsa pg_dumpall ile hepsini birden almak daha güvenlidir. Ayrıntılar için PostgreSQL yedekleme ve pg_dump yazısı var.

Uygulamayı Bakım Moduna Almak#

Veritabanı ile dosya verisi arasındaki tutarlılık da önemlidir. Dump'ı 03:00'te, dosya arşivini 03:05'te alırsanız, arada yüklenen bir dosya arşive girer ama veritabanı kaydı yedekte yoktur. Küçük kurulumlarda bu tolere edilebilir; ama uygulamanız bakım modu destekliyorsa kullanın:

docker exec -u www-data nextcloud php occ maintenance:mode --on
# ... dump + arşiv adımları ...
docker exec -u www-data nextcloud php occ maintenance:mode --off

Bakım modu olmayan uygulamalarda alternatif, yalnızca uygulama konteynerini durdurup veritabanını açık bırakmaktır: docker compose stop app. Böylece yazma durur, dump yine canlı motordan alınır.

Dosya Volume'larını Arşivleme: Named Volume ve Bind Mount#

Veritabanı dışındaki veri — yüklenen dosyalar, kullanıcı avatarları, üretilmiş küçük resimler — düz dosyadır ve arşivlenerek yedeklenir. Yöntem, mount tipine göre değişir.

Named volume host üzerinde /var/lib/docker/volumes/ altındadır ama oraya elle girmek doğru yaklaşım değildir. Geçici bir yardımcı konteyner kullanın:

docker run --rm \
  -v nextcloud_data:/veri:ro \
  -v /yedek:/yedek \
  alpine tar czf /yedek/nextcloud_data-$(date +%F).tar.gz -C /veri .

Volume'u :ro ile salt okunur bağlamak, yedekleme sırasında kaza eseri yazma ihtimalini ortadan kaldırır.

Bind mount ise host üzerinde bildiğiniz bir dizindir; doğrudan arşivleyebilirsiniz:

sudo tar czf /yedek/appdata-$(date +%F).tar.gz --numeric-owner -C /srv/appdata .

--numeric-owner bayrağı burada önemlidir. Konteyner içindeki kullanıcı (www-data, uid 33 gibi) host üzerinde farklı bir isme karşılık gelebilir veya hiç bulunmayabilir. İsim yerine sayısal uid/gid saklamak, arşivi başka bir sunucuya açtığınızda dosya sahipliklerinin bozulmamasını sağlar. Yanlış sahiplikle geri yüklenen bir Nextcloud data dizini, uygulamanın "izin yok" hatalarıyla açılmamasının en sık nedenidir.

Geri yükleme yönü de simetriktir:

docker volume create nextcloud_data
docker run --rm -v nextcloud_data:/veri -v /yedek:/yedek alpine \
  tar xzf /yedek/nextcloud_data-2026-08-18.tar.gz -C /veri

Unutulan Yarı: compose.yaml, .env ve Ters Proxy#

Yedek dosyalarınız eksiksiz olsa bile, uygulamayı yeniden ayağa kaldıracak tarifi kaybettiyseniz saatlerinizi geri kazanmaya çalışmakla geçirirsiniz. Pratikte en çok unutulan parçalar şunlardır:

1. compose.yaml — Servisler, imaj etiketleri, portlar, ağlar ve volume tanımları. latest yerine sabit sürüm etiketi kullanıyorsanız (kullanmalısınız) bu dosya aynı zamanda "hangi sürümü çalıştırıyordum" sorusunun da tek cevabıdır.
2. .env — Veritabanı parolası, uygulama anahtarları, alan adı. Bu dosya olmadan veritabanı dump'ınızı geri yüklerseniz uygulama kendi veritabanına bağlanamaz. Şifreleme anahtarını kaybettiğiniz durumlarda (Vaultwarden, Paperless gibi) veri matematiksel olarak geri getirilemez hâle gelir.
3. Ters proxy yapılandırması — Nginx veya Caddy site dosyaları, Traefik etiketleri, acme.json sertifika deposu. Yeniden üretmek genellikle mümkündür ama felaket anında kaybedilecek en son şey zamandır.
4. Cron işleri ve systemd birimleri — Uygulamanın dışında kalan zamanlanmış görevler.

Pratik yaklaşım: compose.yaml ve proxy yapılandırmasını bir Git deposunda tutun, .env dosyasını depoya koymayıp yedek arşivine ayrıca ekleyin. Compose dosyası yapısını gözden geçirmek isterseniz Docker Compose ile çok servisli uygulama yazısı iyi bir referans.

# Yapılandırma yedeği — parolalar içerdiği için erişimi kısıtlı tutun
tar czf /yedek/config-$(date +%F).tar.gz \
  /srv/nextcloud/compose.yaml \
  /srv/nextcloud/.env \
  /etc/nginx/sites-available/nextcloud.conf
chmod 600 /yedek/config-$(date +%F).tar.gz

Otomasyon: Betikle mi, Hazır Konteynerle mi?#

Elle alınan yedek, alınmayan yedektir. İki yaygın yol var.

Kendi betiğiniz. Yukarıdaki adımları tek dosyada toplayıp cron'a bağlamak en şeffaf yöntemdir:

#!/usr/bin/env bash
set -euo pipefail
GUN=$(date +%F)
HEDEF=/yedek/nextcloud/$GUN
mkdir -p "$HEDEF"

cd /srv/nextcloud
source .env

docker exec -u www-data nextcloud php occ maintenance:mode --on
docker exec -i nextcloud-db mariadb-dump --single-transaction --quick \
  -u root -p"$MYSQL_ROOT_PASSWORD" nextcloud | gzip > "$HEDEF/db.sql.gz"
docker run --rm -v nextcloud_data:/veri:ro -v "$HEDEF":/cikti alpine \
  tar czf /cikti/data.tar.gz -C /veri .
docker exec -u www-data nextcloud php occ maintenance:mode --off

cp compose.yaml .env "$HEDEF/"
chmod 600 "$HEDEF/.env"
sha256sum "$HEDEF"/* > "$HEDEF/SHA256SUMS"

set -euo pipefail satırı bir estetik tercih değildir: onsuz, dump komutu hata verdiğinde betik devam eder ve boyutu sıfıra yakın bir "yedek" üretir. Bu, insanların aylarca boş dosya biriktirmesinin en yaygın nedenidir.

Hazır konteyner. Named volume'ları düzenli arşivlemek için offen/docker-volume-backup yaygın ve bakımlı bir seçenektir. Stack'e bir servis olarak eklenir:

services:
  backup:
    image: offen/docker-volume-backup:v2
    restart: always
    environment:
      BACKUP_CRON_EXPRESSION: "0 3 * * *"
      BACKUP_FILENAME: "nextcloud-%Y-%m-%dT%H-%M-%S.tar.gz"
      BACKUP_PRUNING_PREFIX: "nextcloud-"
      BACKUP_RETENTION_DAYS: "14"
    volumes:
      - nextcloud_data:/backup/nextcloud_data:ro
      - ./yedekler:/archive
      - /var/run/docker.sock:/var/run/docker.sock:ro

Uygulama servisine docker-volume-backup.stop-during-backup=true etiketi eklerseniz arşiv alınırken o konteyner otomatik durdurulup sonra başlatılır. İki uyarı: bu araç volume arşivler, veritabanı dump'ı almaz — dump adımını yine siz kurgulamalısınız. İkincisi, Docker soketini bir konteynere bağlamak o konteynere pratikte host üzerinde root yetkisi verir; kullandığınız imaja bu düzeyde güveniyor olmanız gerekir.

Saklama Politikası ve Yedeği Sunucudan Çıkarmak#

Aynı sunucuda duran yedek, sunucuyu kaybettiğinizde yedek değildir. Fidye yazılımı senaryosunda ise aynı makinedeki arşivler ilk şifrelenen dosyalar arasındadır. Bu yüzden iki kural:

• En az bir kopya sunucu dışında olmalı. Nesne depolama, ayrı bir VDS veya ofis içi bir disk. Aktarımı restic gibi bir araca devretmek hem şifreleme hem de tekilleştirme (deduplication) kazandırır; restic ile yedekleme yazısı bu tarafı ele alıyor.
• Uzak hedefe yazan hesabın silme yetkisi olmasın. Yalnızca ekleme yapabilen bir anahtar, ele geçirilmiş bir sunucunun uzak yedekleri de silmesini engeller.

Saklama süresi için pratik bir başlangıç: 7 günlük günlük yedek, 4 haftalık haftalık, 6 aylık aylık. Bazı hataların (sessizce bozulan bir tablo, yanlışlıkla silinen bir klasör) fark edilmesi haftalar sürebildiği için yalnızca son üç güne bakan bir politika yetersiz kalır. Sıklık kararını nasıl vereceğinizi ne sıklıkta yedek alınmalı yazısında ayrıca tartıştık.

Arşivlerin sağlam olduğunu her gece ucuz bir kontrolle doğrulayabilirsiniz:

gzip -t /yedek/nextcloud/2026-08-18/db.sql.gz && echo "sql arsivi saglam"
tar tzf /yedek/nextcloud/2026-08-18/data.tar.gz > /dev/null && echo "data arsivi saglam"

Bu kontroller dosyanın okunabilir olduğunu kanıtlar — ama uygulamanın açıldığını kanıtlamaz. Onun için bir adım daha gerekir.

Geri Yükleme Provası: Yedeğin Gerçekten Açıldığını Kanıtlamak#

Bu bölüm, yazının asıl değeri. Bir yedeğin geçerli olduğunun tek kanıtı, o yedekten çalışan bir uygulama ayağa kaldırmış olmanızdır. Boyutu doğru, checksum'ı tutan, cron'u hiç hata vermeyen yedeklerin geri yüklenmediğini yıllardır görüyoruz: eksik olan .env, yanlış proje adı, -t bayrağı yüzünden bozulmuş SQL, uid uyuşmazlığı. Bunların hiçbiri yedeği alırken belli olmaz.

Provayı ayrı bir makinede yapın — geçici bir VDS, ofisteki bir sanal makine, hatta kendi dizüstünüz. Üretim sunucusunda yapılan prova, üretim verisini riske atar.

1. Boş bir hedefte projeyi aynı isimle hazırlayın.

mkdir -p /srv/nextcloud && cd /srv/nextcloud     # dizin adı = proje adı
tar xzf /yedek/config-2026-08-18.tar.gz -C /
docker compose pull

2. Önce yalnızca veritabanını başlatın. Uygulama açılırsa boş bir veritabanı görüp kendi kurulumunu yapabilir; sıralama önemlidir.

docker compose up -d db
docker compose logs -f db     # "ready for connections" satırını bekleyin

3. Dump'ı geri yükleyin.

gunzip -c /yedek/nextcloud/2026-08-18/db.sql.gz | \
  docker exec -i nextcloud-db mariadb -u root -p"$MYSQL_ROOT_PASSWORD" nextcloud

PostgreSQL tarafında karşılığı pg_restore -U kullanici -d veritabani --clean --if-exists biçimindedir.

4. Volume arşivini açın.

docker volume create nextcloud_data
docker run --rm -v nextcloud_data:/veri -v /yedek/nextcloud/2026-08-18:/yedek alpine \
  tar xzf /yedek/data.tar.gz -C /veri

5. Tüm stack'i başlatın ve gerçekten kullanın. Giriş yapın, bir dosya açın, bir kayıt arayın, bir e-posta gönderin. "Konteyner ayakta" yeterli bir kanıt değildir; uygulamanın açıldığını ve verinin göründüğünü kendi gözünüzle doğrulayın.

6. Süreyi ölçün ve yazın. Provanın ikinci çıktısı, gerçek kurtarma sürenizdir. "Yedeğim var" cümlesi ile "bu uygulamayı 35 dakikada geri getirebilirim" cümlesi arasında ciddi bir fark vardır ve ikincisi ancak provayla söylenebilir.

Provayı yılda en az iki kez ve mutlaka şu üç durumdan sonra tekrarlayın: uygulamanın büyük sürüm yükseltmesi, veritabanı motorunun değişmesi, yedekleme betiğinde yapılan her düzenleme. Sonucu tarihiyle birlikte bir yere not edin — bir sonraki provada neyin değiştiğini görebilmenin tek yolu budur.

Sıkça Sorulan Sorular#

Docker konteynerini olduğu gibi yedekleyebilir miyim?#

Teknik olarak docker commit ile konteyneri imaja çevirebilirsiniz, ama bu bir yedekleme yöntemi değildir. Ortaya çıkan imaj nasıl oluştuğu kayıtlı olmayan, tekrarlanamayan bir yığındır ve içindeki veritabanı dosyaları tutarsız bir anın kopyasıdır. Doğru yaklaşım kodu imajdan, veriyi volume'dan, tarifi Compose dosyasından yedeklemektir. İmajları yedeklemeye de gerek yoktur; registry'den tekrar indirilebilirler.

Volume yedeğini alırken uygulamayı durdurmam şart mı?#

Veritabanı için evet ya da dump kullanın; ham dosya kopyası çalışan bir motorda tutarsız çıkar. Düz dosya tutan volume'larda (yüklenen belgeler, medya dosyaları) durdurmadan arşivlemek çoğu senaryoda kabul edilebilir; en kötü ihtimalle arşiv sırasında yazılan birkaç dosya yarım kalır. Tam tutarlılık istiyorsanız uygulamayı bakım moduna alın veya yalnızca uygulama konteynerini durdurup veritabanını açık bırakın.

Docker'ın volume dizinini doğrudan yedeklemek yeterli değil mi?#

Sunucu dizinlerini yedekleyen bir araç /var/lib/docker/volumes yolunu da kapsıyorsa dosyalar arşive girer, ama bu tek başına yeterli değildir. Veritabanı dosyaları çalışırken kopyalandığı için tutarsız olur ve Compose dosyası ile .env bu yolun dışındadır. Ayrıca aynı dizin altındaki imaj katmanları ve konteyner meta verileri yedeği gereksiz yere şişirir. Volume başına arşiv almak daha kontrollü ve küçük bir sonuç üretir.

Geri yüklerken volume adları neden tutmuyor?#

Compose, named volume adlarının başına proje adını ekler ve proje adı varsayılan olarak Compose dosyasının bulunduğu dizinin adıdır. Yedeği farklı isimli bir dizine açarsanız Compose yeni ve boş volume'lar oluşturur, eski arşivinizi de kimse kullanmaz. Ya aynı dizin adını kullanın, ya Compose dosyasında name: alanını sabitleyin, ya da komutu -p projeadi bayrağıyla çalıştırın.

Yedeğimin bozuk olmadığını nasıl anlarım?#

Arşiv bütünlüğü ucuz kontrollerle doğrulanır: sıkıştırılmış dosyaların açılabildiğini test edin ve dosya listelerini alın. Ancak bu, yalnızca dosyanın okunabilir olduğunu gösterir. Yedeğin geçerli olduğunun tek kanıtı, ondan ayrı bir makinede çalışan bir uygulama ayağa kaldırmaktır. Yılda en az iki kez ve yedekleme betiğinde her değişiklikten sonra bu provayı tekrarlayın.

Şifreli uygulamalarda anahtar dosyasını kaybedersem verim kurtulur mu?#

Hayır. Vaultwarden, Paperless-ngx gibi veriyi kendi anahtarıyla şifreleyen uygulamalarda anahtar veya .env içindeki gizli değer kaybolduğunda veritabanı dump'ınız elinizde olsa bile içerik açılamaz. Bu yüzden yapılandırma yedeği, veri yedeği kadar önemlidir. Anahtar içeren arşivleri kısıtlı izinlerle saklayın ve uzak kopyanın da şifreli olduğundan emin olun.