Coolify'da Kalıcı Veri: Yüklenen Dosyaları Kaybetmemek

Kısa cevap: Coolify kalıcı depolama (persistent storage), konteyner her dağıtımda yeniden oluşturulurken silinmemesi gereken verinin bağlandığı yoldur. Kullanıcıların yüklediği dosyalar, üretilen içerik ve uygulama durumu bu tanım olmadan ilk yeniden dağıtımda kaybolur. Tanım, uygulama üretime alınmadan önce doğru kurulmalıdır; sonradan eklemek eski dosyaları geri getirmez.

Neden veri kayboluyor?

Coolify’ın çalışma modeli şudur: kod gönderildiğinde yeni bir imaj derlenir, yeni bir konteyner oluşturulur, eskisi silinir. Bu, hatalı bir şey değil, konteyner modelinin tam olarak amacıdır: her dağıtım temiz bir başlangıçtır.

Sorun, uygulamanın kalıcı olması gereken veriyi konteyner içine yazmasıdır. Şu veri türleri risk altındadır:

• Kullanıcıların yüklediği dosyalar (görsel, belge, medya)
• Uygulamanın ürettiği dosyalar (küçük resimler, raporlar, dışa aktarımlar)
• Yapılandırma dosyaları (uygulama içinden düzenlenenler)
• Önbellek ve oturum dosyaları (kaybı tolere edilebilir ama fark edilir)
• SQLite gibi tek dosyalık veritabanları

Bunların hiçbiri konteyner içinde durmamalıdır. Konteyner geçici, veri kalıcıdır; modelin temeli budur ve ayrıntısı Docker veri kalıcılığı yazısında.

Kalıcı depolama nasıl tanımlanır?

Coolify’da uygulama ayarlarında kalıcı depolama bölümü bulunur. Tanımlarken iki şey belirtirsiniz: konteyner içindeki yol ve bu yolun nasıl saklanacağı (Docker hacmi veya ana sistemdeki bir dizin).

Kritik olan, uygulamanın gerçekte yazdığı yolu tanımlamaktır. En sık yapılan hata, tahmin edilen bir yolu tanımlayıp uygulamanın başka bir yere yazmasıdır: her şey çalışıyor görünür, dosyalar yüklenir ve ilk yeniden dağıtımda kaybolur.

Uygulamanın nereye yazdığını doğrulamanın yolu, dosyayı yükledikten sonra bakmaktır:

# Konteyner içinde dosyanın gerçekten nerede olduğunu bul
docker exec -it KONTEYNER_ADI find / -name "yuklediginiz-dosya.jpg" 2>/dev/null

# Konteynere bağlı yolların listesi
docker inspect --format '{{range .Mounts}}{{.Type}} {{.Source}} -> {{.Destination}}{{"\n"}}{{end}}' KONTEYNER_ADI

İkinci komutun çıktısındaki hedef yollar ile birinci komutun bulduğu yol örtüşmüyorsa, o dosya konteyner katmanındadır ve bir sonraki dağıtımda silinecektir.

Bir uyarı: tanımı sonradan eklemek eski dosyaları geri getirmez. Eski dosyalar silinmiş konteynerin katmanındaydı ve o katman yok edildi. Tanım yalnız bundan sonrasını korur. Bu yüzden kalıcı depolama, uygulama üretime alınmadan önce doğrulanmalıdır.

Panel tanımı ile çalışan konteyner neden farklı olur?

Bu, kümedeki en önemli uyarıdır ve genel bir ders içerir.

Panelde bir ayarı değiştirdiğinizde, çalışan konteyner etkilenmez. Konteyner oluşturulduğu andaki tanımla çalışmaya devam eder; değişiklik ancak yeniden dağıtım veya yeniden başlatma anında devreye girer.

Bunun iki sonucu var:

1. Değişiklik yaptınız ve hiçbir şey olmadı sanıyorsunuz. Aslında değişiklik kaydedildi, sadece henüz uygulanmadı.
2. Daha tehlikelisi: biriken değişiklikler yeniden başlatmada hep birlikte devreye girer. Aylar önce yapılmış, unutulmuş bir düzenleme, bugünkü rutin bir yeniden başlatmada aniden etkinleşir.

Yaşadığım vakada ikinci durum gerçekleşti: kullanıcıların yüklediği dosyalar bir yolda duruyordu, aradan geçen sürede kalıcı depolama tanımında bir düzenleme yapılmıştı ve fark edilmemişti. Çalışan konteyner eski tanımla çalışmaya devam ettiği için hiçbir belirti yoktu. Rutin bir yeniden başlatmada yeni tanım devreye girdi ve uygulama artık bambaşka, boş bir dizine bakmaya başladı. Dosyalar diskte duruyordu ama uygulama için yok hükmündeydi.

Buradan çıkardığım kalıcı kural:

Yeniden başlatmadan önce, paneldeki tanım ile çalışan konteynerin gerçek durumunu karşılaştır.

Uygulaması iki komut:

# Çalışan konteynerin gerçekte bağlı olduğu yollar
docker inspect --format '{{range .Mounts}}{{.Type}} {{.Source}} -> {{.Destination}}{{"\n"}}{{end}}' KONTEYNER_ADI

# Ana sistemdeki hedef dizinde gerçekten veri var mı
sudo ls -la /kaynak/yol/

Çıktı, panelde gördüğünüz tanımla örtüşmüyorsa, yeniden başlatma o farkı uygulayacak demektir. Bu tek kontrol, birkaç dakika sürer ve geri getirilemeyen veri kaybını önler.

İkinci kural da buradan çıkar: kullanıcı verisi barındıran servislerde, yeniden başlatma öncesi kalıcı veriyi yedekleyin. Rutin görünen bir yeniden başlatma, biriken tüm değişikliklerin devreye girmesidir.

Bu ders yalnız Coolify’a özgü değildir; yapılandırması diskte duran ve yeniden başlatmada okunan her sistem için geçerlidir.

Veritabanı: panel yedeği yeterli mi?

Coolify, veritabanları için zamanlanmış yedekleme sunar. Başlangıç için uygundur ama iki şeyi doğrulamanız gerekir.

1. Yedek sunucunun dışına gidiyor mu? Aynı sunucuda duran yedek, disk arızasına karşı korur; sunucu kaybına, fidye yazılımına veya sağlayıcı kaynaklı bir olaya karşı korumaz. Yedeklerin uzak bir hedefe (nesne depolama, ağ deposu veya başka bir sunucu) gönderildiğinden emin olun.

2. Geri yüklenebiliyor mu? Alınmış ama hiç geri yüklenmemiş yedek, çalıştığı varsayılan bir dosyadır.

Uygulama seviyesinde döküm almak, hacim kopyalamaya göre daha tutarlı bir yedek üretir:

# PostgreSQL konteynerinden döküm
docker exec -t VERITABANI_KONTEYNERI \
  pg_dump -U kullanici veritabani | gzip > yedek-$(date +%F).sql.gz

# MySQL / MariaDB
docker exec -t VERITABANI_KONTEYNERI \
  mysqldump -u kullanici -pPAROLA veritabani | gzip > yedek-$(date +%F).sql.gz

Parolayı komut satırında yazmak, kabuk geçmişine ve süreç listesine düşmesi anlamına gelir; üretimde bunun yerine ortam değişkeni veya parola dosyası kullanın.

Geri yükleme testi için önerdiğim yordam: yedeği ayrı bir veritabanı örneğine yükleyin, tablo sayısını ve en kritik tablodaki kayıt sayısını üretimle karşılaştırın, sonra test örneğini silin. Üç ayda bir tekrarlayın. Sanallaştırma üzerinde çalışıyorsanız aynı testi makine seviyesinde de yapabilirsiniz; yöntemi Proxmox yedekleme rehberinde.

Coolify’ın kendi verisi neden yedeklenmeli?

Sık atlanan bir konu: panelin kendi veritabanı da kritik veridir. İçinde uygulama tanımlarınız, ortam değişkenleriniz, alan adı yapılandırmalarınız ve sunucu bağlantılarınız durur.

Bu veri kaybolursa uygulamalarınız çalışmaya devam eder (konteynerler ayaktadır) ama yönetim katmanını sıfırdan kurmanız ve her uygulamayı yeniden tanımlamanız gerekir. Asıl acı veren kısım ortam değişkenleridir: veritabanı parolaları, API anahtarları ve gizli değerler yalnız orada duruyorsa, hepsini yeniden üretip her yere yeniden dağıtmanız gerekir.

İki önlem:

1. Panel verisini yedekleme kapsamına alın. Sunucu seviyesinde yedek alıyorsanız (sanal makine yedeği veya dosya sistemi yedeği) bu kendiliğinden kapsanır.
2. Kritik gizli değerlerin ikinci bir kopyası bulunsun. Panelin veritabanı tek kopya olmamalı; şifreli bir kasada veya güvenli bir not deposunda ayrı kayıt tutun.

Dosya yüklemeleri için hangi depolama seçilmeli?

Uygulamanız çok sayıda dosya yüklüyorsa, kalıcı hacim tek seçenek değildir ve her zaman en iyisi de değildir.

Yaklaşım	Avantaj	Dezavantaj
Kalıcı hacim (sunucuda)	Basit, ek servis yok	Sunucuya bağımlı, taşınması zor, tek nokta
Nesne depolama (S3 uyumlu)	Sunucudan bağımsız, ölçeklenir, yedeklilik sağlayıcıda	Uygulama değişikliği gerekir, ek maliyet
Ağ dosya sistemi	Birden fazla sunucu paylaşabilir	Gecikme, karmaşıklık, tek nokta riski sürer

Kural: veri hacmi büyüyorsa ve sunucu taşımayı düşünüyorsanız, nesne depolamaya geçmeyi erken değerlendirin. Sunucudaki hacimde biriken yüz gigabaytlık kullanıcı dosyası, sunucu değişikliğini basit bir işlem olmaktan çıkarır.

Küçük ve orta ölçekte kalıcı hacim tamamen yeterlidir; önemli olan tanımın doğru olması ve yedeklenmesidir.

Kontrol listesi

• Uygulamanın gerçekte yazdığı yol tespit edildi (tahmin edilmedi)
• Kalıcı depolama tanımı üretime almadan önce yapıldı
• docker inspect ile çalışan konteynerin bağlı yolları doğrulandı
• Dosya yükleme testi yapıldı, dosya ana sistemdeki hedef dizinde görüldü
• Yeniden dağıtım testi yapıldı, dosya hâlâ duruyor
• Yeniden başlatma öncesi panel tanımı ile çalışan durum karşılaştırılıyor
• Kullanıcı verisi barındıran servislerde yeniden başlatma öncesi yedek alınıyor
• Veritabanı yedeği sunucunun dışına gidiyor
• Geri yükleme son üç ay içinde test edildi
• Coolify panelinin kendi verisi yedekleniyor
• Ortam değişkenlerinin ikinci bir güvenli kopyası var
• Disk doluluğu izleniyor (yüklenen dosyalar sessizce büyür)

Bu liste kapandığında Coolify kurulumunuzun en kırılgan tarafı güvenceye alınmış olur. Kurulumun tamamı Coolify kurulum rehberinde, alan adı ve sertifika tarafı Coolify domain ve SSL yazısında, platformun genel çerçevesi Coolify nedir yazısında. Konteyner veri modelinin temelleri Docker veri kalıcılığı yazısında, izleme ve uyarı kurgusu sunucu izleme rehberinde.

Yedekleme ve felaket kurtarma planlamasını kurumsal ölçekte kurmak için yedekleme hizmetleri sayfasına bakabilirsiniz.

Kaynaklar

• Manage data in Docker (hacim ve bind mount modeli)
• Coolify Documentation (kalıcı depolama yapılandırması)
• PostgreSQL: Backup and Restore (tutarlı veritabanı yedeği)