Hizmet · Depolama

S3 depolama ve yedekleme

Sunucunuza yük bindirmeden resim, medya ve dosyalarınızı taşıyın; yedeklerinizi yönetin, saklayın, geri yükleyin. S3 API uyumlu nesne deposu, CDN dağıtımı ve şifreli yedek planı tek kurulumda gelir.

S3 API
uyumlu
AES-256
şifreli saklama
Günlük
yedek planı
TR / AB
veri lokasyonu
Kapsam

Hizmete dahil olanlar

Depolama, dağıtım ve yedek aynı kurulumun parçası. Ayrı ayrı satın alıp birbirine bağlamanız gerekmez.

2 dakika · 4 soru

Verileriniz gerçekten yedekli mi?

Dört soruda yedekleme düzeninize bakalım. Sorun görünmüyorsa bunu da açıkça söylüyoruz.

Şirket dosyalarınız ve müşteri kayıtlarınız nerede duruyor?

Soru 1 / 4

Şirket dosyalarınız ve müşteri kayıtlarınız nerede duruyor?

Öncesi / sonrası

Sunucu yükü nasıl değişiyor

Medya dosyaları uygulama sunucusundan çıktığında değişen tek şey depolama yeri değil. Disk, CPU, bant genişliği ve yedek boyutu aynı anda rahatlar.

Disk doluluğu

Öncesi

Kullanıcı yüklemeleri arttıkça sunucu diski öngörülemez biçimde dolar. Kapasite genişletme çoğu zaman gece yarısı, baskı altında yapılır.

Sonrası

Dosyalar nesne deposunda büyür; uygulama sunucusunun diski uygulamanın kendi boyutunda sabit kalır. Kapasite planlaması bir bakım işi olmaktan çıkar.

CPU ve bellek

Öncesi

Görüntü boyutlandırma, thumbnail üretimi ve statik dosya servisi uygulama süreçleriyle aynı çekirdekleri paylaşır. Yoğun saatte istek kuyruğu uzar.

Sonrası

Dosya servisi sunucudan tamamen çıkar; CPU ve bellek yalnız uygulama mantığına çalışır. Aynı donanım belirgin biçimde daha fazla eşzamanlı isteği karşılar.

Bant genişliği

Öncesi

Çıkış trafiğinin büyük bölümünü resim ve video tüketir. Uygulamanın kendi API yanıtları bu trafiğin arkasında sıraya girer.

Sonrası

Medya CDN düğümlerinden iner, sunucunun hattını hiç kullanmaz. Kalan bant genişliği tamamen uygulama trafiğine kalır.

Yedek boyutu

Öncesi

Yedek, medya klasörünü de kapsadığı için sürekli büyür. Alma süresi uzar, geri yükleme saatlere yayılır, saklama maliyeti şişer.

Sonrası

Yedek yalnız uygulama ve veritabanını kapsar. Küçülen yedek daha sık alınabilir ve olay anında çok daha hızlı geri yüklenir.

Kesinti ve kurtarma

Öncesi

Sunucu çöktüğünde uygulama ve medya aynı anda erişilemez olur. Kurtarma, terabaytlarca dosyanın geri kopyalanmasını bekler.

Sonrası

Sunucu sıfırdan kurulsa bile medya yerinde durur. Kurtarma sadece uygulamayı ayağa kaldırmaktır; erişilebilirlik yukarı çıkar.

Sonuç tek cümlede: aynı donanım daha çok kullanıcı taşır, yedek küçüldüğü için daha sık alınır ve olay anında geri dönüş süresi kısalır.

Süreç

Kurulum 5 adımda

Her adımın çıktısı belli. Nerede olduğumuzu sormak zorunda kalmazsınız.

  1. 01

    Envanter ve ölçüm

    Hangi klasör kaç GB, hangi dosya tipi ne sıklıkla okunuyor, aylık çıkış trafiği ne kadar — mevcut durum tahminle değil ölçümle çıkarılır.

  2. 02

    Depo provizyonu ve anahtarlar

    Kova yapısı, klasör şeması, erişim anahtarları ve yetki politikaları kurulur. Veri lokasyonu Türkiye veya AB olarak bu adımda seçilir.

  3. 03

    Migrasyon

    Mevcut dosyalar doğrulamalı olarak taşınır, uygulama S3 endpoint ve CDN adreslerine geçirilir. Eski kopya doğrulama bitene kadar durur.

  4. 04

    Yedek planı ve şifreleme

    Sıklık, saklama süresi ve sürümleme kuralları tanımlanır; yedekler AES-256 ile şifrelenir, aktarım TLS üzerinden yapılır.

  5. 05

    İzleme ve aylık restore testi

    Kapasite, hata ve gecikme uyarıları devreye alınır. Her ay izole ortamda geri yükleme testi çalışır ve sonucu raporlanır.

Fiyat politikası

Hacim bazlı · tek sayfa teklif

Hacim bazlı

Sakladığınız veri ve kullandığınız trafik kadar ödersiniz. Kullanmayacağınız kapasite için peşin taahhüt istemiyoruz.

Migrasyon tek seferlik

Mevcut sisteminizden taşıma teklifte ayrı bir satır olarak görünür. Aylık ücrete gizlenmiş, sonradan çıkan bir kalem değildir.

Yıllık sözleşme, tek sayfa teklif

Depolama, trafik, yedek planı, izleme ve aylık restore testi aynı teklifte yer alır. Hizmet 12 aylık sözleşmeyle verilir: birim fiyat yıl içinde değişmez, yıl sonunda kapsam ve fiyat birlikte gözden geçirilip yenilenir. Sonradan gelen sürpriz fatura göndermiyoruz.

SSS

Sık sorulanlar

Mevcut kodumu değiştirmem gerekiyor mu?

Depo S3 API ile uyumlu olduğu için AWS SDK, MinIO client, rclone, s3fs ve S3 destekli hazır eklentiler aynı şekilde çalışır. Değişen genelde yalnız endpoint adresi, erişim anahtarı ve dosya bağlantılarının üretildiği yerdir. Kod değişikliği minimumda kalır.

Mevcut dosyalarımı siz mi taşıyorsunuz?

Evet. Taşıma tek seferlik bir kalem olarak planlanır: dosyalar kopyalanır, kontrol toplamlarıyla doğrulanır, ardından uygulama yeni adreslere geçirilir. Yeni yapı doğrulanana kadar eski kopya yerinde bırakılır.

Yanlışlıkla silinen bir dosya geri gelir mi?

Sürümleme açıkken evet. Silinen veya üzerine yazılan nesnenin önceki sürümü saklama süresi boyunca durur ve geri çağrılabilir. Sürümlerin ne kadar tutulacağı proje ihtiyacına göre birlikte belirlenir.

Yedekler ne sıklıkla alınıyor?

Varsayılan plan günlük. İhtiyaca göre saatlik plan kurulabilir veya sürüm yayınlamadan önce talep üzerine yedek alınabilir. Sıklık, göze aldığınız veri kaybı penceresine göre seçilir.

Yedeklerin gerçekten açıldığını nasıl biliyorum?

Her ay izole bir ortamda otomatik geri yükleme testi çalışır; sonucu ve bütünlük kontrolü raporlanır. Test edilmemiş bir yedeği yedek saymıyoruz.

Verilerim nerede tutuluyor?

Türkiye veya Avrupa Birliği lokasyonu arasında siz seçim yaparsınız. Lokasyon kararı KVKK ve GDPR yükümlülüklerinizle birlikte alınır ve sözleşmede yazılı olur.

Kimin hangi dosyaya erişebileceğini nasıl sınırlıyorsunuz?

Her uygulama ve ekip için ayrı erişim anahtarı üretilir; yetkiler klasör ve işlem düzeyinde tanımlanır. Herkese açık olması gerekmeyen dosyalar süreli imzalı bağlantılarla servis edilir, anahtar iptali ve döndürme süreci hazırdır.

Proje talebi

Projenizi anlatın, size ulaşalım

Formu doldurun; seçtiğiniz kanaldan 1 iş günü içinde dönüş yapalım. Bilgileriniz yalnızca bu görüşme için kullanılır ve KVKK kapsamında korunur.

S3 depolama: medya dosyaları sunucuda ne kadara mal oluyor

S3 depolama: medya dosyaları sunucuda ne kadara mal oluyor

Uygulama sunucusunda duran her gigabaytlık medya, size dört ayrı yerden fatura keser. Disk dolar ve genişletme işlemi çoğu zaman gece yarısı, baskı altında yapılır. CPU ile bellek, görsel boyutlandırma ve statik dosya servisi yüzünden uygulama mantığıyla aynı çekirdeği paylaşır. Çıkış trafiğinin büyük bölümünü resim ve video yer, uygulamanın kendi yanıtları o kuyruğun arkasında bekler. Dördüncüsü de en can yakanı: yedek her gün biraz daha şişer, alma süresi uzar, geri yükleme saatlere yayılır. S3 depolama tarafına geçmek bu dört kalemi aynı anda rahatlatır, çünkü dosyalar uygulamanın yaşadığı diskten tamamen çıkar.

Bir kurumsal yazılım şirketi olarak bu geçişi tek başına bir depolama alışverişi gibi görmüyoruz. Nesne deposu, CDN dağıtımı, sürümleme, şifreli yedek planı ve geri yükleme testi aynı kurulumun parçaları. Depolamayı bir sağlayıcıdan, CDN'i başkasından, yedek yazılımını üçüncü bir yerden alıp aralarındaki bağlantıyı kendi ekibinize kurdurduğunuzda, sistem normal günlerde sorunsuz görünür ama bir gece yedek işi sessizce düştüğünde kimin bakacağı belirsiz kalır ve arıza saatler sonra fark edilir. Aşağıda işin teknik tarafını, taşımadan sonra ölçülebilir biçimde neyin değiştiğini, sık yapılan hataları ve hangi senaryolarda hangi kurgunun oturduğunu yazdık.

Geçiş kararı çoğu zaman bir arıza sonrası veriliyor, oysa en ucuz zamanı arızadan önce. İstanbul yazılım ekipleriyle konuşurken sıkça duyduğumuz cümle şu: "sunucu şişti, artık taşımak zorundayız". Taşınacak veri ne kadar büyümüşse migrasyon da o kadar uzuyor. Aynı işi katalog yüz bin görselken yapmakla iki milyon görselken yapmak arasında haftalar fark var. Yeni bir projeye başlıyorsanız medyayı en baştan dışarıda konumlandırmak, sonradan yapılacak her taşımadan ucuza gelir.

S3 API uyumu ve nesne depolama mantığı

S3 uyumluluğu pazarlama cümlesi değil, pratik bir sözleşme. Depo bu API'yi konuştuğu için mevcut araçlarınız aynı şekilde çalışır: AWS SDK, MinIO client, rclone, s3fs ve S3 destekli hazır eklentiler. Kod tarafında değişen şey genelde iki satırdır — endpoint adresi ve erişim anahtarı. Bir de dosya bağlantılarının üretildiği yer.

Nesne depolamanın mantığı klasik dosya sisteminden farklı. Burada gerçek anlamda klasör yok; kova var, anahtar var. "urunler/2024/kapak.webp" dediğinizde aslında iç içe dizinler oluşturmuyorsunuz, tek bir anahtar yazıyorsunuz. Arayüzde klasör gibi görünmesi kolaylık olsun diye. Bu fark neden önemli? Çünkü milyonlarca dosyada dizin taraması diye bir maliyet kalmıyor, listeleme ön ek üzerinden yapılıyor ve kapasite büyüdükçe performans düşmüyor. Her nesnenin yanında ayrıca kendi meta verisi taşınır: içerik tipi, önbellek başlığı, isterseniz kendi tanımladığınız etiketler.

Ölçeklenme tarafında da rahatlama var. Sunucu diski bir gün mutlaka dolar ve büyütmek kesinti ister; nesne deposunda böyle bir tavan yoktur, yer açmak için kimseyi aramazsınız. S3 depolama kurulumunda kova yapısını ve klasör şemasını işin gerçeğine göre tasarlıyoruz: ortam ayrımı, müşteri ayrımı, medya türü ayrımı. Yanlış kurgulanmış bir şema iki yıl sonra taşınmayı zorlaştırır, o yüzden bu adımı baştan konuşuyoruz.

Standart seçimi de bilinçli. S3 API bugün nesne depolamanın ortak dili; birden fazla sağlayıcı aynı arayüzü konuşuyor. Bu ne demek? Sağlayıcı değiştirmeye karar verdiğinizde uygulamanızı baştan yazmıyorsunuz, endpoint'i çeviriyorsunuz. Kapalı bir arayüze bağlanan veri, taşınamayan veridir. Kendi geliştirdiğimiz sistemlerde de aynı ilkeyi uyguluyoruz; hangi katmanı kurduğumuzu Kendi geliştirdiğimiz ürünler sayfasında görebilirsiniz. S3 depolama tercihinin uzun vadeli değeri, aslında bu çıkış kapısının açık kalmasında.

Sürümleme, imzalı bağlantı ve anahtar yönetimi

Sürümleme açık olduğunda silinen ya da üzerine yazılan nesnenin önceki hâli saklama süresi boyunca durur. Yanlış komut, felaket olmaktan çıkıp geri alınabilir bir olaya dönüşür. Toplu bir güncelleme betiği bin dosyayı bozduysa, önceki sürümler yerinde olduğu için dönüş birkaç dakikalık iştir.

Erişim tarafında ikili bir ayrım kuruyoruz. Herkese açık olması gereken dosyalar — ürün görselleri, blog kapakları — doğrudan CDN üzerinden servis edilir; ziyaretçiye en yakın düğümden iner, sunucunuzun hattını hiç kullanmaz. Yurt dışından bağlanan kullanıcı da aynı açılış hızını görür. Gizli kalması gereken dosyalar ise imzalı bağlantıyla verilir: bağlantı belirli bir süre için üretilir, süre dolduğunda çalışmaz. Fatura PDF'i, sözleşme, kullanıcıya özel rapor tam olarak buraya girer. Bağlantı paylaşılsa bile ömrü sınırlıdır.

Anahtar yönetimi çoğu kurulumun zayıf halkası. Tek bir yönetici anahtarını bütün uygulamalara dağıtmak kolaydır, sonra o anahtar bir yerde sızdığında her şeye erişim açılır. Biz her uygulama ve her ekip için ayrı anahtar üretiyoruz, yetkileri klasör ve işlem düzeyinde tanımlıyoruz. Yükleme yapan servisin silme yetkisi olmaz. Rapor okuyan servisin yazma yetkisi olmaz. Anahtar iptali ve döndürme süreci de baştan hazır durur, çünkü bir anahtarın sızdığını fark ettiğiniz an aranacak şey, o anahtarın hangi servislerde kullanıldığını gösteren güncel bir liste ile devreye alınacak yazılı bir prosedürdür; o dakikada mimariyi yeniden düşünmeye kimsenin vakti olmaz. Beklemede duran veri AES-256 ile şifrelenir, aktarım TLS üzerinden yapılır. Erişim politikalarının bütünsel denetimini isteyen müşteriler için bu katmanı Siber güvenlik denetimi kapsamında ayrıca ele alıyoruz.

Migrasyon nasıl yürüyor

İş envanterle başlıyor. Hangi klasör kaç gigabayt, hangi dosya tipi ne sıklıkla okunuyor, aylık çıkış trafiği ne kadar — mevcut durum tahminle değil ölçümle çıkarılır. Bu adım atlandığında maliyet tahmini de taşıma planı da havada kalır.

Ardından depo tarafı hazırlanır: kova yapısı, klasör şeması, erişim anahtarları, yetki politikaları. Verinin Türkiye'de mi Avrupa Birliği'nde mi duracağı burada seçilir, çünkü sonradan lokasyon değiştirmek yeni bir taşıma demektir. S3 depolama kurulumunda bu kararı hukuk tarafındaki yükümlülüklerinizle birlikte alıyoruz.

Kopyalama doğrulamalı yapılır. Her dosya taşındıktan sonra kontrol toplamıyla karşılaştırılır; bir bayt kaymışsa o dosya yeniden alınır. Milyonlarca küçük dosyada bu süreç saatler sürebilir, o yüzden çalışma saatleri dışına planlanır. Kritik olan şudur: eski kopya, yeni yapı tamamen doğrulanana kadar yerinde bırakılır. Geri dönüş yolu kapanmadan ileri adım atılmaz.

En çok sürprizin çıktığı yer ise dosya bağlantılarının üretildiği kısım. Çoğu projede eski sunucunun tam adresi veritabanına gömülü hâlde durur — içerik alanlarında, ürün açıklamalarında, e-posta şablonlarında. Bunlar bulunup temizlenmediğinde taşıma bitse bile yarısı kırık bir site kalır. Biz bu adresleri taramayla çıkarıp yapılandırılabilir bir taban adrese bağlıyoruz, böylece bir dahaki sefere değişen tek şey bir ayar satırı oluyor. Alanya yazılım ekibimizin devraldığı eski projelerde en çok zaman alan iş, çoğu zaman taşımanın kendisi değil bu temizlik oluyor.

Son adımda uygulama yeni endpoint ve CDN adreslerine geçirilir, önbellek başlıkları ayarlanır, izleme ve uyarılar devreye alınır. S3 depolama tarafındaki tek seferlik migrasyon bizde ayrı bir kalem olarak planlanır ve teklifte görünür.

Taşıma bittikten sonra ne değişiyor

Değişimin ilk göstergesi disk grafiğinde görünür. Uygulama sunucusunun diski artık kullanıcı yüklemeleriyle değil, yalnız uygulamanın kendi boyutuyla ilgilidir; kapasite planlaması bir bakım işi olmaktan çıkar. İkincisi işlemci: dosya servisi sunucudan çıktığı için CPU ve bellek yalnız uygulama mantığına çalışır, aynı donanım daha fazla eşzamanlı isteği karşılar.

Üçüncüsü açılış hızı. Görseller CDN düğümlerinden indiğinde ilk boyanan içerik erken gelir ve mobilde fark hissedilir olur. Dördüncüsü yedek boyutu — bu bizim en çok önemsediğimiz kalem. Yedek yalnız uygulamayı ve veritabanını kapsadığında küçülür; küçülen yedek daha sık alınabilir, olay anında çok daha hızlı geri yüklenir. Beşincisi erişilebilirlik: sunucu sıfırdan kurulsa bile medya yerinde durduğu için kurtarma, terabaytlarca dosyanın geri kopyalanmasını beklemez. Ayağa kaldırılacak tek şey uygulamadır.

S3 depolama hizmetine geçen ekiplerin en çok şaşırdığı nokta genelde şu oluyor: sunucu maliyetini düşürmek için başlanan iş, asıl kazancını kurtarma süresinde veriyor. Alanya yazılım ekibimizin kurduğu projelerde bunu somut olarak izleyebiliyoruz — medya ayrıldıktan sonra gece yedeğinin süresi belirgin biçimde kısalıyor ve yedek penceresi sabaha taşmıyor.

Talep dalgalanan işlerde bir kazanç daha var: kapasite ayarlamak diye bir iş kalmıyor. Nesne deposu büyüdüğü kadar büyür, önceden yer satın almazsınız. Yoğun döneme hazırlık, sunucu büyütmek yerine önbellek ömürlerini ve görsel boyut politikasını gözden geçirmeye dönüşür. Antalya yazılım tarafındaki sezonluk projelerde bunu her yıl aynı şekilde yaşıyoruz — talep ikiye katlanıyor, sunucu tarafında hiçbir müdahale gerekmiyor. Darboğaz çıkacaksa artık uygulama katmanında çıkar, depolamada değil.

Yedek planı nasıl işliyor

Sıklık tek bir sorunun cevabına bağlı: kaç saatlik veriyi kaybetmeyi göze alıyorsunuz? Günlük plan çoğu kurumsal iş için yeterlidir. İşlem yoğunluğu yüksek sistemlerde saatlik plan kurulur. Sürüm yayınlamadan önce ya da riskli bir veri taşımasına girmeden önce talep üzerine yedek alınır; bu, ekiplerin en çok kullandığı düğmedir.

Kopyalar ana sunucu dışında iki ayrı lokasyonda tutulur. Aynı makinede duran bir yedek, o makine gittiğinde yedek değildir. Verinin Türkiye'de mi yoksa Avrupa Birliği'nde mi duracağına ise siz karar verirsiniz; karar KVKK ve GDPR yükümlülüklerinizle birlikte alınır ve sözleşmeye yazılır. Şifreleme beklemede AES-256, aktarımda TLS.

Yedek planını kurarken iki süreyi de yazılı hâle getiriyoruz: ne kadar veri kaybını kabul ediyorsunuz ve sistemin ayakta olması için ne kadar süreniz var. Bu ikisi netleşmeden sıklık seçmek, tahminle plan yapmaktır. S3 depolama üzerine kurulan yedek akışında saklama süresi, sürüm sayısı ve şifreleme politikası aynı belgede toplanır; ekip değiştiğinde kimse "biz burada nasıl yedek alıyorduk" sorusuyla baş başa kalmaz.

Her ay izole bir ortamda otomatik geri yükleme testi çalışır, bütünlük kontrolü yapılır ve sonuç raporlanır. Test edilmemiş bir yedeği yedek saymıyoruz. Bu cümle bize pahalıya mal olan bir dersten kalma: yedek işleri aylarca "başarılı" raporladığı hâlde, arşiv dosyasının içindeki veritabanı dökümünün boş olduğu ancak restore denendiğinde anlaşılır. İzleme tarafında kapasite, hata oranı, gecikme ve başarısız yedek işleri takip edilir; bir yedek çalışmadıysa aylık raporu beklemeden e-posta bildirimi gider. Raporlama panelinde hangi kovanın ne kadar yer kapladığı, hangi yedeğin ne zaman alındığı ve restore testinin ne sonuç verdiği tek ekranda durur.

Maliyet hangi kalemlerden oluşuyor

Depolama faturası tek bir rakamdan ibaret değil, üç ayrı musluğu var.

Birincisi saklanan hacim: ne kadar veri duruyorsa o kadar ödersiniz. İkincisi çıkış trafiği — dosyalarınız ne kadar çok indiriliyorsa o kalem büyür. Üçüncüsü istek sayısı; milyonlarca küçük dosyaya yapılan sürekli okuma, birkaç büyük dosyadan farklı davranır. S3 depolama maliyetini konuşurken bu üçünü ayrı ayrı ölçüyoruz, çünkü aynı hacimdeki iki müşteri tamamen farklı fatura görebilir.

Sessizce büyüyen iki kalem daha var. Sürümleme açıkken her değişiklik yeni bir sürüm bırakır; saklama süresi tanımlanmamışsa depo, kimsenin farkında olmadığı eski sürümlerle şişer. Benzer biçimde yedek sıklığını artırmak da doğrudan hacme yazılır. Bu yüzden sıklık ve saklama süresini birlikte kararlaştırıyoruz — biri olmadan diğeri anlamsız.

Fiyatlama tarafında peşin taahhüt istemiyoruz; kullanmayacağınız kapasite için ödeme yapmanızın bir mantığı yok. Migrasyon tek seferlik satır olarak durur, aylık ücrete gizlenmez. Depolama, trafik, yedek planı, izleme ve aylık restore testi aynı teklifte toplanır. Bir kurumsal yazılım şirketi için asıl kıymetli olan, ay sonunda sürpriz çıkmamasıdır. Antalya yazılım tarafındaki sezonluk işlerde bu esneklik özellikle işe yarıyor: ölü sezonda trafik düşüyor, fatura da düşüyor.

Yedekle ilgili beş klasik hata

Birincisi, yedeği hiç geri yüklemeyi denememek. Yedek almak bir iştir, yedeğin açıldığını doğrulamak bambaşka bir iş. Sıkıştırılmış arşiv bozuk olabilir, şifreleme anahtarı değişmiş olabilir, döküm eksik tabloyla alınmış olabilir. Hiçbiri yedek alma logunda görünmez.

İkincisi, yedeği aynı sunucuda tutmak. Disk arızası, silme komutu ya da fidye yazılımı — üçünde de asıl veriyle yedek aynı anda gider. Fidye yazılımları zaten ilk iş bağlı diskleri ve erişilebilir paylaşımları arar. Yedek başka bir yerde, tercihen ayrı yetkiyle erişilen bir depoda durmalı. Kurduğumuz yapıda kopyalar ana sunucu dışında iki ayrı lokasyonda tutuluyor; S3 depolama tarafındaki kova, uygulama sunucusunun erişim anahtarıyla silinebilecek bir yer olmuyor.

Üçüncüsü, medya ile veritabanını aynı diske koymak. Bu ikisinin büyüme hızı, değişim sıklığı ve yedekleme ihtiyacı taban tabana zıt olduğu hâlde çoğu kurulumda aynı bölümde yan yana dururlar, çünkü ilk günün küçük projesinde bu ayrımı yapmak gereksiz bir titizlik gibi görünür ve kimse sonradan geri dönüp düzeltmez. Veritabanı küçüktür ama sık yedek ister; medya devasadır ama nadiren değişir. Aynı yere konduklarında her gece terabaytlarca değişmemiş görseli tekrar tekrar yedeklersiniz ve saatlik veritabanı yedeği imkânsız hâle gelir.

Dördüncüsü, şifreleme anahtarını yedekle aynı yerde saklamak. Şifreli yedek, anahtarı yanında duruyorsa şifreli değildir. Anahtarın ayrı saklanması, erişiminin ayrı yetkilendirilmesi ve kimin ulaşabildiğinin kayıt altında olması gerekir. Anahtarı tamamen kaybetmek de en az sızdırmak kadar kötüdür; kurtarma prosedürü bu yüzden ayrı yazılır.

Bu beşinin ortak paydası şu: hepsi işler görünen bir sistemde sessizce birikir ve faturayı yalnız felaket anında keser. Yedek, alındığı gün değil geri yüklendiği gün doğrulanır. Alanya yazılım ekibimizin devraldığı sistemlerde ilk yaptığımız iş de bu yüzden yeni yedek kurmak değil, mevcut yedeği açmayı denemek oluyor.

Beşincisi, saklama süresi politikası tanımlamamak. Politikasız bir depo iki yönde de zarar verir: ya her şey sonsuza kadar durur ve maliyet sessizce büyür, ya da temizlik betiği bir gün yanlış eşleşmeyle bilanço dönemine ait dosyaları siler. Hangi veri ne kadar tutulacak, hangisi arşive inecek, hangisi imha edilecek — bunlar teknik değil, kurumsal kararlardır ve yazılı olmaları gerekir. Kurum içi dosya ve doküman düzeni tarafında Nextcloud Kurumsal Çalışma Alanı ile birleşik bir kurgu da mümkün.

Hangi senaryoda ne oturuyor

E-ticarette mesele ürün görselleridir. Katalog büyüdükçe her ürün için birden çok boyut üretilir, arşiv hızla şişer ve kampanya günlerinde aynı görseller aynı anda binlerce kez istenir. Görselleri nesne deposuna taşıyıp CDN'den dağıtmak, sunucuyu kampanya trafiğinde ayakta tutan şeydir. İstanbul yazılım ekipleriyle çalıştığımız e-ticaret projelerinde ilk hamle çoğu zaman burasıdır.

Haber ve blog yayıncılığında sorun arşivin kendisi. Beş yıllık görsel arşivi hiç silinmez, çok az okunur ama her gece yedeğe girer. Sürümleme ile birlikte nesne deposuna alındığında hem yedek küçülür hem eski içerik erişilebilir kalır.

Bir de yayıncılıkta sık atlanan bir kalem var: aynı görselin farklı boyutları. Küçük önizleme, liste görseli, tam boy — üçü de saklanır, üçü de yedeğe girer. Türetilmiş boyutları nesne deposunda ayrı ön ek altında tutmak, gerektiğinde hepsini yeniden üretip silmeyi mümkün kılar. Aslı duruyorsa türevi veri değil, önbellektir.

Kurumsal doküman havuzunda öncelik erişim denetimidir. Kimin hangi klasörü göreceği, dışarıya verilen bağlantının ne kadar yaşayacağı, indirmenin kayda geçip geçmediği — bu üçü kurgunun belkemiği. İmzalı bağlantı ve klasör düzeyinde yetki tam olarak bunun için var. Mobil uygulamalarda ise kullanıcı içeriği söz konusu: profil fotoğrafı, yüklenen belge, ses kaydı. Bunları uygulama sunucusuna yazmak, ilk bin kullanıcıda gayet iyi çalışan ama kullanıcı sayısı on bine yaklaştığında disk dolduğu, yedek penceresi taştığı ve sunucu değiştirmek istendiğinde bütün içerik esir kaldığı için geri dönülmesi pahalıya patlayan bir tercihtir. Yüksek hacimli veri depolama ihtiyacı olan ekipler için kapasite ve maliyet modelini ayrıca kurguluyoruz.

Video barındırma kendi başına bir dünya. Dosyalar büyük, izlenme dalgalı, bant genişliği pahalı. Videoyu uygulama sunucusundan servis etmek en hızlı iflas yollarından biri. Nesne deposu artı CDN kombinasyonu burada tercih değil, zorunluluk. Antalya yazılım ve turizm tarafındaki tanıtım videoları gibi sezonluk yük binen içeriklerde bu ayrım daha da belirginleşiyor: sezon dışında sessiz duran arşiv, sezonda ani talep görüyor ve sunucu tarafında hiçbir şey değişmiyor.

Peki hangi senaryoda bu işe hiç girmemek mantıklı? Toplam medyanız birkaç yüz megabaytta kalıyorsa ve büyüme eğriniz düz gidiyorsa, taşımanın getirisi emeğini karşılamayabilir. Dürüst cevap bu. S3 depolama kurulumu, verinin büyüdüğü ya da erişimin yayıldığı yerlerde anlam kazanır. İstanbul yazılım ekipleriyle yürüttüğümüz projelerde eşiği genelde iki şey belirliyor: yedek penceresinin sabaha taşması ve kullanıcı sayısının sunucu diskini öngörülemez hâle getirmesi. İkisinden biri olduysa erteleme yapmıyoruz. Geciken her ay, taşınacak veriyi biraz daha büyütüyor. Eşik geçildiyse tartışılacak konu taşınıp taşınmayacağı değil, sırasının ne zaman geleceğidir. Beklemenin faturası sessizdir. Ama vardır.

Sıkça sorulan sorular

Mevcut klasör yapımız kaybolur mu?
Kaybolmaz. Nesne deposunda klasör kavramı ön ek olarak yaşar; mevcut dizin ağacınız anahtar yapısına birebir yansıtılabilir. Arayüzde de aynı hiyerarşiyi görürsünüz. Taşıma sırasında yolları toparlamak isterseniz bunu birlikte planlıyoruz, ama zorunlu değil — çoğu projede yapı olduğu gibi korunur.
İmzalı bağlantının süresi dolunca dosya erişilemez mi oluyor?
Dosya yerinde durur, erişilemez olan yalnız o bağlantıdır. Süre dolduğunda uygulama yeni bir imza üretir ve kullanıcı hiçbir şey fark etmez. Süreyi işin doğasına göre seçiyoruz: bir fatura bağlantısı için kısa, video oynatımı için oturum boyunca yeterli olacak kadar.
Veritabanı yedeği de aynı depoda mı duruyor?
Aynı depoda ama ayrı kovada, ayrı erişim politikasıyla ve ayrı saklama süresiyle. Medya nadiren değişir, veritabanı sürekli. İkisini aynı kural setine sokmak her ikisine de zarar verir. Veritabanı dökümleri şifrelenerek yazılır ve aylık restore testinde birlikte doğrulanır.
Erişim anahtarı sızarsa ne yapıyoruz?
Anahtar iptal edilir, yenisi üretilir, ilgili servise dağıtılır. İşlem dakikalar sürer çünkü her servis kendi anahtarını kullanır — tek anahtarla çalışan bir kurulumda aynı işlem tüm sistemi durdurur. Sızıntı sonrası erişim kayıtları taranır, anahtarın hangi işlemlerde kullanıldığı çıkarılır. Sunucu ve uç nokta tarafındaki takip için Dış kaynak BT desteği kapsamındaki izleme akışını da devreye alıyoruz.
Taşıma sırasında site kapanacak mı?
Hayır. Dosyalar önce kopyalanır ve kontrol toplamlarıyla doğrulanır, ardından uygulama yeni adreslere geçirilir. Eski kopya, yeni yapı doğrulanana kadar yerinde bırakılır. Kesinti pratikte yalnız yapılandırma değişikliğinin uygulandığı kısa ana iner. Migrasyon tek seferlik bir kalem olarak teklifte ayrı satırda görünür, aylık ücrete gizlenmez.
Saklama süresi politikasını neye göre belirliyoruz?
Üç girdiye bakıyoruz: yasal yükümlülük, işin operasyonel ihtiyacı ve maliyet. Muhasebe belgelerinin süresi mevzuatla bellidir. Kullanıcı içeriğinde hesap kapandıktan sonra ne kadar tutulacağı KVKK tarafında açıkça tanımlanmalıdır. Geri kalanı için soru şu olur: bu dosyayı iki yıl sonra gerçekten açacak mısınız? Cevap net değilse arşiv katmanına indirmek, silmekten daha akıllıca olur. Bir kurumsal yazılım şirketi olarak bu tabloyu teknik ekiple değil, hukuk ve muhasebe tarafıyla birlikte çıkarmayı öneriyoruz.