Bir senaryo düşünün. Sabah 04:17. Üretimde bir Cosmos DB hesabı garip garip davranıyor — kayıtlar değişmiş, bazıları silinmiş, log’lar da tam yerine oturmuyor. Security ekibi ne olduğunu çözmeye çalışıyor, uygulama sahibi telefonda bekliyor. Ve o anda gelen soru çok net: “Hangi recovery point’lere güvenebiliriz? Birileri backup’lara da dokunmuş olabilir mi?”
📋 İçindekiler
- Neden Şimdi? Backup Konusunda Olgunlaşma Vakti
- Preview Ne Getiriyor? Dört Ana Başlık
- Mevcut Continuous Backup ile Farkı Ne?
- Türkiye Açısından: Bu Neyi Değiştirir?
- Peki Pratikte Nereden Başlamalı?
- Peki Kimler İçin Aşırı, Kimler İçin Şart?
- Eksik Tarafları — Çünkü Her Şey Toz Pembe Değil
- Sıkça Sorulan Sorular
- Kaynaklar ve İleri Okuma
Bence, İşte tam burada backup işi, sıradan bir “checkbox” olmaktan çıkıyor. Operasyonel dayanıklılığın parçası oluyor. Microsoft da açık konuşayım, bu tarafa biraz daha ciddi eğiliyor.
2 Haziran 2026’da duyurulan Azure Backup for Azure Cosmos DB public preview, Cosmos DB’yi merkezî Azure Backup modeline sokuyor. Politika bazlı yönetim, uzun süreli saklama, değiştirilemez (immutable) recovery point’ler ve klasik “yanlışlıkla sildim” senaryosunun baya ötesine geçen restore seçenekleri geliyor. Şimdi detaya girelim — ama önce neden önemli, önü konuşalım.
Neden Şimdi? Backup Konusunda Olgunlaşma Vakti
Tuhaf ama, Cosmos DB’yi kim kullanıyor? Genelde latency’nın milisaniyelerle ölçüldüğü, global ölçek isteyen uygulamalar: ödeme sistemleri, hasta takip platformları, kullanıcıya bakan servisler, operasyonel dashboard’lar. Yani arka tarafta bir şey patlarsa, etkisi hemen hissedilen işler.
Cosmos DB’nın kendi continuous backup özelliği zaten vardı. Point-in-time restore yapabiliyordunuz, fena değil. Ama işin can sıkıcı tarafı şu: o backup’lar Cosmos DB hesabının yaşam döngüsüne bağlıydı. Yani hesabı silen biri (veya kötü niyetli biri) backup tarafını da bozabiliyordu. Operasyonel hata için yeterliydi; düzenleme ve ransomware tarafında işe (kendi tecrübem). eh, pek değil.
Bir banka geçmişteki bir kaydı yeniden kurmak zorunda kalabilir. Bir sağlık kuruluşu soruşturma için veriyi yıllarca saklamak isteyebilir. Bir e-ticaret şirketi de saldırganların önce backup’a sonra üretime yöneldiği bir senaryoya hazırlanmak zorunda kalabilir. Ortak nokta şu: kısa kurtarma penceresi yetmiyor (ki bu çoğu kişinin gözünden kaçıyor)
Sahada gördüğüm şey şu: Kurumsal müşterilerin büyük kısmında “backup stratejisi” aslında bir checkbox gibi duruyor. Dokümanda var, ama tatbikat yok. Immutable backup geldiğinde asıl sınav, bunu DR plan’ına gerçekten koyup koymadığınız olacak.
Preview Ne Getiriyor? Dört Ana Başlık
Bakın, Microsoft’un duyurusunda dört ana yetenek öne çıkıyor. Tek tek bakalım — ama her birini gerçek hayatta ne anlama geldiğiyle birlikte düşünelim.
Bir dakika — bununla bitmedi.
1. Immutable Backups — Asıl Mesele Bu
Immutable backup demek, recovery point’in belirlenen saklama süresi dolana kadar değiştirilememesi ve silinememesi demek. Yani “ben yanlışlıkla sildim” demek bile kurtarmıyor; süre dolmadan eliniz kolunuz bağlı kalıyor. Kulağa kısıtlayıcı geliyor, evet. Ama işin omurgası da burada.
Ransomware senaryolarında saldırganların ilk baktığı yer genelde backup oluyor. Çünkü backup yoksa pazarlık masasında elinizde koz kalmıyor. Immutable yapı da tam olarak bu kozu koruyor. Hatta NIŞ2 ve DORA gibi çerçevelerde de “tamper-proof backup” beklentisi yavaş yavaş normalleşiyor.
2. Long-Term Retention (LTR)
Cosmos DB’nın continuous backup tarafı tipik olarak 7 ila 30 gün arasında geri dönüş sunuyordu. Günlük operasyon için çoğu zaman yeterliydi. Ama “7 yıl saklayacaksın” diyen denetçiyle karşılaşınca bu süre biraz komik kalıyor, nasıl desem… kısa düşüyor işte.
LTR sayesinde Cosmos DB backup’larını Azure Backup vault içinde uzun yıllar tutabiliyorsunuz (inanın bana). Bu da özellikle regülasyonlu sektörlerde rahat nefes aldırıyor.
3. Merkezî Yönetim
Bence en pratik parçalardan biri bu (inanın bana). Azure ortamında VM’ler, SQL, Blob Storage, AKS ve şimdi Cosmos DB… hepsi ayrı ayrı backup ekranlarından yönetiliyordu. Audit zamanı gelince ekipler politikaları toparlamakta zorlanıyordu.
Tek bir Backup Center üzerinden bunları yönetmek kağıt üstünde sade görünüyor olabilir; ama sahada baya iş görüyor. Az önce söyledim ya, bazen küçük görünen şeyler operasyonu rahatlatıyor.
4. Restore Mobility (Subscription ve Region Esnekliği)
Preview’da logical restore farklı subscription’a yapılabiliyor. Physical restore’un cross-region tarafı işe yol haritasında duruyor. En çok da “compromise edilmiş bir subscription’a hiç dokunmadan temiz ortama dönmek istiyorum” diyen ekipler için kritik bir detay bu.
Forensic ekiplerin kâbusu olan “kanıtları bozma” riskini de azaltıyor aslında. Küçük gibi duruyor ama değil.
Mevcut Continuous Backup ile Farkı Ne?
Bunu net söylemek lazım çünkü kafa karışabiliyor: İki yapı birbirinin alternatifi değil, tamamlayıcısı.
| Özellik | Continuous Backup (mevcut) | Azure Backup for Cosmos DB (preview) |
|---|---|---|
| Saklama süresi | 7-30 gün | Yıllarca (LTR) |
| Immutability | Yok | Var |
| Hesap silinirse? | Backup da gider | Vault’ta korunur |
| Cross-subscription restore | Sınırlı | Var (logical) |
| Merkezî yönetim | Cosmos DB blade | Azure Backup Center |
| Kullanım alanı | Operasyonel hatalar | Regülasyon, ransomware, denetim |
Şunu fark ettim: Kısacası benim önerim şu: ikisini birlikte düşünün. Günlük “ay ben bu collection’ı yanlış sildim” senaryoları için continuous backup; hayatı. Regüle iş yükleri için Azure Backup daha mantıklı duruyor.
Türkiye Açısından: Bu Neyi Değiştirir?
Daha açık söyleyeyim, şunu fark ettim: Türkiye’de finans, sigorta ve sağlık sektörünün regülasyon baskısı son yıllarda iyice arttı diyebilirim. BDDK, EPDK, KVKK ve Avrupa kaynaklı DORA’nın lokal etkileri… Bunların hepsi “veri nerede duruyor, nasıl korunuyor, ne kadar süre saklanıyor” sorusunu önünüze koyuyor.
Bence asıl mesele şu: Kanıtlanabilir backup süreci kurmak artık sadece IT’nın konusu değil; doğrudan compliance işi oldu bile diyebiliriz.
Kendi gördüğüm klasik tabloyu söyleyeyim: Cosmos DB üretimde çalışıyor, herkes “backup var” diyor ama saklama süresi 30 gün civarında kalıyor. Sonra denetimde “1 yıl önceki tutarsızlığı göster” denince ortam sessizleşiyor. Bu preview o boşluğu doğal şekilde kapatmaya aday gibi duruyor — üstelik üçüncü parti ürün almadan.
Maliyet tarafı da var tabiî ki işin içinde.
Üçüncü parti çözümler (Veeam, Commvault, Rubrik gibi) Cosmos DB desteğinde lisans olarak ciddi rakamlara çıkabiliyor.
Azure Backup’ın native fiyatlaması işe özellikle TL bazında çoğu senaryoda daha makul kalabilir.
Tabi public preview döneminde GA fiyatlandırması net değil — burada peşin hüküm vermeyeyim.
Ama Azure Backup’ın diğer kaynaklardaki yaklaşımını düşününce çok şaşırmam açıkçası.
Test ortamında deneyin.
Mevcut continuous backup’ınızı paralel tutun.
GA olduğunda geçiş çok daha rahat olur.
Peki Pratikte Nereden Başlamalı?
Eğer Cosmos DB üzerinde regüle bir iş yükü çalıştırıyorsanız ve bu preview ilgimi çekti diyorsanız ben şöyle ilerlerdim:
Bir dakika — bununla bitmedi.
- Elden geçirin: Hangi Cosmos DB hesapları gerçekten kritik? Hepsi LTR istemiyor olabilir; bunu baştan ayırmak hem maliyeti hem karmaşayı azaltır.
- RPO/RTO hedeflerini yenileyin: Backup tasarımına girince zaten bu sayılara tekrar bakmanız gerekecek.
İki üç yıl önce yazılan değerler bugün hâlâ anlamlı mı?
Çoğu zaman değil. (bence en önemlisi) - Pilot açın: Test hesabıyla policy oluşturun, immutable retention’ı deneyin.
Sonra restore tatbikatı yapın — sadece “backup alındı” demek yetmez.
Restore çalışmıyorsa strateji de yarım kalır. - RBAC ve roller:– Kim vault’a erişecek? Kim policy değiştirecek?
Bunları en başta netleştirin.
Backup admin ile production admin ayrı kişiler olmalı; yoksa immutable’in tadı kaçıyor. - Maliyet tahmini:– LTR’de uzun saklama süreleri storage faturasında yer kaplar.
Bunu aylık bütçeye mutlaka yazın.
Sonra sürpriz yaşamayın.
Böyle bir policy iskeleti kabaca şu mantıkla kurulabilir (preview API’leri değişebilir ama fikir aynı):
{
"policyName": "cosmos-prod-ltr",
"backupFrequency": "Daily",
"retentionRules": [
{
"name": "Daily",
"lifecycles": [{"duration": "P30D", "deleteAfter": "Vault"}]
},
{
"name": "Monthly",
"lifecycles": [{"duration": "P12M", "deleteAfter": "Vault"}]
},
{
"name": "Yearly",
"lifecycles": [{"duration": "P7Y", "deleteAfter": "Vault"}],
"immutability": "Enabled"
}
]
}
Dikkat ederseniz günlük backup’lar 30 gün tutuluyor.
Aylık olanlar 1 yıl gidiyor.
Yıllık olanlar işe 7 yıl immutable şekilde saklanıyor.
Compliance ekibi buna bakınca kafası rahat eder.
Operasyon ekibi de günlük işlerde eli kolu bağlı hissetmez.
Peki Kimler İçin Aşırı, Kimler İçin Şart?
Şunu söyleyeyim, Açık konuşayım: Bu özellik herkese şart değil.
Küçük bir SaaS yan ürünü için Cosmos DB kullanıyorsanız ve regülasyon baskınız yoksa continuous backup büyük ihtimalle yeterli.
Üstüne LTR ve immutable katmanı eklemek storage maliyetini artırır; getirisi sınırlı kalabilir.
Ama şu profillerden biriyseniz bence konu değişiyor:
- Banka uygulamaları veya finans servisleri
- Sigorta platformları
- Sektörel düzenlemeye tabi sağlık sistemleri
- Kamu projeleri veya kamuya hizmet veren SaaS çözümleri
- E-ticaret ve B2C tarafında ransomware riski yüksek işler
- `SOX`, `ISO 27001`, `PCI DSS` gibi standartlara hazırlanan kurumlar
Neyse uzatmayayım; Cosmos DB tarafında veri modeliyle sürekli uğraşıyorsanız Azure Cosmos DB’de Partition Key Değiştirmek: Artık Daha Az Acı Veriyor yazısı da işinize yarayabilir.
AI iş yükleri varsa. Vektör araması kullanıyorsanız Azure Cosmos DB’de Vektörler Kendini Güncelliyor: AI Uygulamalarda Yeni Dönem‘e de bakabilirsiniz.
Eksik Tarafları — Çünkü Her Şey Toz Pembe Değil
Burasını atlamayayım; yoksa yazı fazla cilalı olurdu.
Birincisi preview olması.
Yani SLA garantisi sınırlı olabilir,
breaking change ihtimali vardır,
arayüzler de henüz tam oturmamış olabilir.
Production’a gidip “bütün backup buraya bağlı olsun” demek bana göre erken olur.
İkinci nokta physical restore’un cross-region versiyonunun henüz gelmemiş olması.
Disaster recovery planınız bölgeler arası taşımayı içeriyorsa bu özellik tek başına tam çözüm sayılmaz.
Ne yalan söyleyeyim, Üçüncüsü multi-API desteği meselesi.
NoSQL. MongoDB API’leri preview’da var;
Cassandra, Gremlin ve Table API tarafında durum hâlâ net olmayabilir.
Eğer oralardaysanız kontrol edip beklemek lazım yanı.
Dördüncüsü maliyet.
LTR ile 7 yıl veri tutmak storage faturasında yer kaplayabilir.
Sıkıştırma ne kadar etkili olacak,
soğuk katman fiyatlaması nasıl şekillenecek,
bunların GA tarafını izlemek gerekiyor.
Tam da öyle.
İşte böyle.
Tamamdır.
Evet.
Maalesef.
Sıkça Sorulan Sorular
Mevcut continuous backup’ı kapatmam gerekiyor mu?
Hayır, gerek yok. İkisi zaten paralel çalışabiliyor, hatta bence çalışmalı da. Yani şöyle düşünün: continuous backup günlük operasyonel hataları için hızlı kurtarma sağlıyor, Azure Backup işe uzun süreli ve immutable saklama için. Aslında — hayır dur, daha doğrusu birbirini tamamlıyorlar, rakip değiller.
Immutable backup’ı yanlışlıkla yapılandırırsam ne olur?
İşte tam burada dikkatli olmak gerekiyor (bizzat test ettim). Retention süresi dolana kadar o recovery point’i silemiyorsunuz. Mesela “test için 10 yıl tutalım” derseniz, hani şaka gibi geliyor ama gerçekten 10 yıl storage faturası ödüyorsunuz (ki bu çoğu kişinin gözünden kaçıyor). Tecrübeme göre production’a almadan önce mutlaka kısa retention ile test edin, sonra pişman olmazsınız.
Şimdi gelelim işin can alıcı noktasına.
Hangi Cosmos DB API’leri destekleniyor?
Araya gireyim: Public preview’da şu an için Azure Cosmos DB for NoSQL ve Azure Cosmos DB for MongoDB destekleniyor. Diğer API’ler, yani Cassandra, Gremlin, — ki bu tartışılır — Table için Microsoft’un yol haritasını takip etmek gerekiyor. Açıkçası bunlar için net bir tarih yok, resmî dokümantasyonu ara ara kontrol edin derim.
Fiyatlandırması nasıl?
Preview döneminde fiyatlar henüz tam netleşmedi. Azure Backup’ın diğer iş yüklerindeki modeline benzer olması bekleniyor: yani protected instance başına aylık ücret artı saklanan veri miktarı (GB başına). GA’ya yakın net fiyat açıklanacak, o yüzden şimdilik kesin bir şey söylemek zor.
Evet, doğru duydunuz.
Mevcut Cosmos DB hesabımı production’da bu preview’a alabilir mıyım?
Teknik olarak alabiliyorsunuz, ama açıkçası önermem. Preview özellikleri önce non-production ortamda test edin, bir de restore tatbikatı yapın. Sonra GA’yı bekleyin. Hani acele etmeye değmez. Production’da en azından mevcut continuous backup’ı paralel tutmanız şart, bunu sakın atlamamın.
Kaynaklar ve İleri Okuma
Azure Backup Resmî Dokümantasyonu
Azure Cosmos DB Online Backup and Restore (Microsoft Learn)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Ransomware senaryolarında “backup’ım var” demek artık yetmiyordu, backup’ın da ele geçirilmesi çok yaygın bir saldırı vektörü haline gelmişti. Immutable recovery point’ler bu açıdan ciddi bir güvence. Politika bazlı yönetim nasıl çalışıyor, granülerlik seviyesi ne kadar iyi acaba?
Bu arada şu yazınız da aklıma geldi, Microsoft’un son dönemde pek çok şeyi ücretli modele çektiğini görünce insanın aklına hep “bunun sonu nereye gider” sorusu geliyor: https://www.askinkilic.com.tr/github-code-
Ransomware senaryolarında bu özellik gerçekten can kurtarıcı olabilir, özellikle politika bazlı yönetim işleri çok kolaylaştırıyor. Peki immutable backup aktifken bir recovery point’i manuel olarak silmek gerekirse ne oluyor, sistem tamamen engelliyor mu?
Ransomware senaryolarında en büyük sorun zaten yedeğin de şifrelenmesiydi, immutable recovery point bu açıdan ciddi bir güvence sağlıyor. Acaba politika bazlı yönetimde mevcut veritabanlarına retroaktif uygulama yapılabiliyor mu, yoksa sadece yeni oluşturulanlara mı geçerli?
Ransomware senaryolarında bu özellik gerçekten kritik, özellikle production veritabanlarında yanlışlıkla silinen verileri geri almak için epey uğraşmıştım daha önce. Politika bazlı yönetim nasıl çalışıyor, granüler düzeyde mi ayarlanabiliyor merak ettim açıkçası.