Paylaşımlı dosya sistemi kullanılmadığında yüklenen dosyalar farklı sunucularda görünmeyebilir. Nedenlerini, riskleri ve doğru çözüm seçeneklerini öğrenin.
Bir web uygulamasına yüklenen görsel, PDF, video ya da kullanıcı dosyasının bir süre sonra görünmemesi çoğu zaman uygulama hatası gibi algılanır. Oysa özellikle birden fazla sunucu ile çalışan yapılarda sorun, dosyanın kaydedildiği yerin tüm sunucular tarafından ortak kullanılmamasından kaynaklanır. Paylaşımlı dosya sistemi yoksa dosya yalnızca isteği karşılayan tek sunucunun yerel diskine yazılır; sonraki istek farklı bir sunucuya yönlenirse uygulama o dosyayı bulamaz.
Paylaşımlı dosya sistemi, birden fazla sunucunun aynı dosya alanını ortak kullanmasını sağlar. Böylece kullanıcı A sunucusu üzerinden dosya yüklese bile, B veya C sunucusu aynı dosyaya erişebilir. Bu yapı özellikle ölçeklenebilir web uygulamaları, e-ticaret siteleri, medya portalları ve kurumsal paneller için kritik öneme sahiptir.
Tek sunuculu basit bir yapıda yerel diske dosya yazmak kısa vadede yeterli görünebilir. Ancak trafik arttığında yük dengeleyici, otomatik ölçekleme veya konteyner mimarisi devreye girerse yerel disk yaklaşımı hızlıca sorun üretmeye başlar. Bu nedenle hosting altyapısı seçilirken yalnızca işlemci ve RAM değil, dosya saklama mimarisi de değerlendirilmelidir.
Aslında dosya çoğu zaman tamamen silinmez; yanlış sunucuda aranır. Kullanıcı bir profil fotoğrafı yüklediğinde istek örneğin Sunucu-1 tarafından karşılanır ve dosya Sunucu-1’in diskine kaydedilir. Daha sonra kullanıcı profili görüntülemek istediğinde yük dengeleyici isteği Sunucu-2’ye gönderebilir. Sunucu-2 kendi yerel diskinde dosyayı bulamadığı için 404 hatası, kırık görsel ya da boş dosya alanı oluşur.
Load balancer, gelen trafiği sunucular arasında dağıtarak performansı ve erişilebilirliği artırır. Ancak dosyalar ortak bir alanda tutulmuyorsa dağıtım mantığı veri tutarlılığını bozabilir. “Sticky session” bazı durumlarda geçici çözüm gibi görünse de kalıcı ve güvenilir bir dosya mimarisi yerine kullanılmamalıdır.
Konteyner tabanlı yapılarda dosyalar konteynerin geçici alanına yazılmış olabilir. Konteyner yeniden başlatıldığında, taşındığında veya ölçekleme sırasında kapatıldığında bu alan sıfırlanabilir. Bu durumda dosya yalnızca görünmez hale gelmez, gerçekten kaybolabilir. Üretim ortamında kalıcı volume veya harici depolama kullanılmaması ciddi veri kaybı riskidir.
Bu problem en çok yatay ölçeklenen uygulamalarda ortaya çıkar. Birden fazla web sunucusu, Kubernetes ortamı, Docker tabanlı dağıtım, CDN arkasındaki dinamik uygulamalar ve otomatik dağıtım süreçleri riskli alanlardır. Ayrıca geliştirici ortamında çalışan bir yapı canlıya taşındığında, dosya yolları ve yazma izinleri farklılaştığı için benzer hatalar görülebilir.
WordPress, Laravel, özel PHP panelleri veya kurumsal intranet uygulamalarında kullanıcı yüklemeleri genellikle belirli bir klasöre yazılır. Bu klasör tüm sunucularda ortak değilse, sistemin geri kalanı doğru çalışsa bile medya dosyaları tutarsız davranır. Bu nedenle uygulama mimarisi planlanırken “dosya nereye yazılıyor, kimler okuyabiliyor, yedekleniyor mu?” soruları net cevaplanmalıdır.
İlk seçenek NFS, GlusterFS veya benzeri bir paylaşımlı dosya sistemi kullanmaktır. Bu yaklaşım mevcut uygulama yapısını çok değiştirmeden ortak dosya erişimi sağlar. Ancak performans, kilitleme davranışı, ağ gecikmesi ve yedeklilik ayarları dikkatle yapılandırılmalıdır.
İkinci seçenek nesne depolama servisleridir. Kullanıcı yüklemelerinin yerel diske değil, S3 uyumlu bir alana aktarılması modern uygulamalarda sık tercih edilir. Böylece dosyalar uygulama sunucularından bağımsız saklanır, ölçekleme kolaylaşır ve yedekleme stratejisi daha net yönetilir.
Üçüncü seçenek dağıtım sürecinde kalıcı volume kullanmaktır. Özellikle konteyner ortamlarında volume tanımları doğru yapılmazsa her yeni dağıtım dosya kaybına yol açabilir. Bu noktada sunucu yapılandırması ile uygulama kodunun birlikte ele alınması gerekir.
Öncelikle yüklenen dosyaların uygulama kodu ile aynı dizinde tutulmaması önerilir. Kod dağıtımı sırasında eski klasörlerin silinmesi veya yeni sürümün temiz dizine kurulması, kullanıcı dosyalarını yanlışlıkla kaldırabilir. Dosya yükleme alanı ayrı, kalıcı ve yedeklenen bir alanda konumlandırılmalıdır.
İzinler de sık yapılan hatalardan biridir. Web sunucusu dosyayı yazabiliyor ancak başka bir işlem okuyamıyorsa uygulama tutarsız davranabilir. Klasör sahibi, okuma-yazma izinleri ve güvenlik politikaları canlı ortamda test edilmelidir. Ayrıca dosya adlarında Türkçe karakter, boşluk ve özel sembol kullanımı bazı sistemlerde erişim sorunlarına neden olabilir.
Bir diğer önemli konu yedeklemedir. Veritabanı yedeği almak tek başına yeterli değildir; kullanıcı tarafından yüklenen dosyalar da aynı stratejiye dahil edilmelidir. Veritabanında yalnızca dosya yolu kayıtlıysa, fiziksel dosya yedeği olmadan geri dönüş mümkün olmayabilir.
Önce dosyanın gerçekten hangi makinede oluştuğunu kontrol edin. Aynı dosya yolunu tüm sunucularda arayın. Dosya yalnızca birinde varsa ortak depolama yoktur veya doğru bağlanmamıştır. Ardından yük dengeleyicinin isteği farklı sunuculara yönlendirip yönlendirmediğini inceleyin.
Uygulama loglarında yükleme anındaki hedef yol, hata kodları ve izin hataları kontrol edilmelidir. Dağıtım sonrası dosyalar kayboluyorsa CI/CD süreci veya container image yapısı incelenmelidir. Özellikle hosting ortamı yönetilen bir servis ise, sağlayıcının kalıcı depolama, paylaşımlı alan ve yedekleme politikaları açıkça öğrenilmelidir.
Kalıcı ve güvenilir bir yapı için dosya saklama katmanı, uygulama mimarisinin ayrı bir bileşeni olarak tasarlanmalıdır. Yerel diske geçici kayıt almak yalnızca test veya düşük riskli senaryolarda kabul edilebilir; canlı sistemlerde ortak erişim, yedekleme ve izleme mekanizmaları baştan planlandığında kullanıcıların yüklediği dosyalar tutarlı biçimde erişilebilir kalır.