Hot site, warm site ve cold site ifadeleri felaket kurtarma toplantılarında sık geçer, ancak ekipler bazen bunları depolama katmanındaki sıcak ve soğuk veri diline karıştırır. DR bağlamında site tipi, ikincil konumda iş yükünün ne kadar hazır beklediğini ve yedek ortama geçişte hangi adımların önceden tamamlanmış olduğunu anlatır. Kısa cevap şudur. Cold site çoğunlukla boş kabuk veya minimal altyapı sunar, warm site kısmi hazırlık ve gecikmeli başlatma içerir, hot site ise replike edilmiş iş yükünün kesinti anında veya çok kısa sürede devreye alınmasını hedefler. DRaaS seçeneğini değerlendirirken paket adındaki site etiketi tek başına toparlanma süresi vaadi değildir. Sözleşmede compute, ağ, kimlik ve uygulama sırası ayrı satırlarda yazılmalıdır.
Bu metin DRaaS nedir yazısındaki ürün sınırlarını tamamlar. Yedekleme ile DRaaS ayrımı için DRaaS ile yedekleme farkı rehberine bakın.
Hızlı Özet
Site tipi, ikincil DR konumunda donanım, sanallaştırma kabuğu, replikasyon ve ağ hazırlığının hangi seviyede tutulduğunu tanımlar. Cold modelde kapasite rezerve edilir ancak VM genelde kapalıdır veya hiç oluşturulmamıştır. Warm modelde kopyalar periyodik güncellenir, yedek ortama geçiş sırasında boot ve ağ adımları çalışır. Hot modelde replikasyon sık veya sürekli tutulur, geçiş süresi iş sürekliliği hedefleriyle hizalanır.
Veri kaybı penceresi ve toparlanma süresi hedefleri proje ve sağlayıcı dokümantasyonu ile hedef olarak değerlendirilir. Bu yazıda kesin dakika veya yüzde taahhüdü verilmez. Leon-X altyapı sahibi değildir. Site tipi seçimini iş önceliği, bütçe ve tatbikat disipliniyle birlikte koordine eder.
İçindekiler
- Site Tipi DR Tasarımında Ne Anlama Gelir
- Cold Site Modeli
- Warm Site Modeli
- Hot Site Modeli
- DRaaS Paket Adı ile Gerçek Hazırlık Arasındaki Boşluk
- Site Seçiminde Karar Soruları
- Tatbikat ve Runbook Bağlantısı
- Yaygın Yanlış Okumalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Pexels, veri merkezi sunucu rafları.
Site Tipi DR Tasarımında Ne Anlama Gelir
Felaket kurtarma literatüründe site, fiziksel veri merkezi veya bulut bölgesi gibi ikincil bir konumu ifade eder. Tip ise o konumda iş yükünün ne kadar önceden hazırlandığını tarif eder. Üretim ortamı kullanılamaz hale geldiğinde ekip yedek ortama geçiş kararı verir. Site tipi bu geçişte bekleyeceğiniz manuel adım sayısını ve replikasyon gecikmesini çerçeveler.
Depolama ürünlerinde hot ve cold terimleri veri erişim sıklığı için kullanılır. DR site tipi ile karıştırıldığında yanlış paket seçilir veya bütçe yanlış katmana gider. DR tartışmasında site tipini her zaman ikincil ortam hazırlığı olarak okuyun.
Veri kaybı penceresi hedefi site tipinden bağımsız ölçülmez. Replikasyon sıklığı cold ve warm modellerde daha uzun pencere üretir. Hot modelde pencere daralır ancak uygulama tutarlılığı ve ağ adımları yine ayrı doğrulanır.
Cold Site Modeli
Cold site yaklaşımında ikincil konumda iş yükü çalışır durumda bekletilmez. Genelde boş rack alanı, temel güç ve soğutma veya rezerve edilmiş bulut kotası vardır. Felaket ilan edildiğinde donanım tedariki, sanal makine oluşturma, yedekten geri yükleme veya replika başlatma süreci sıfırdan veya neredeyse sıfırdan başlar.
Bu model en düşük sürekli maliyeti sunar. Toparlanma süresi en uzun seçenekler arasındadır. Regülasyon veya iş sürekliliği planı çok sıkı kesinti toleransı istemiyorsa ve kritik sistem sayısı sınırlıysa cold site mantıklı kalabilir.
Cold site DRaaS paketinde yalnızca depolama replikasyonu aktif, compute kapalı olabilir. Sözleşmede her geçiş tetiklemesinde compute açılış süresi ve ek ücret maddesi net değilse maliyet sürprizi çıkar. 3-2-1 yedekleme kuralı ile uzak kopya katmanını planlarken cold DR kabuğunu ayrı bir satırda tutun.
Warm Site Modeli
Warm site ikincil konumda kısmi hazırlık taşır. Sanal makine şablonları, boyutlandırılmış compute veya periyodik senkronize edilmiş kopyalar bulunur. Üretim ile ikincil site arasında bilinçli gecikme vardır. Geçiş sırasında VM açılır, ağ VLAN ve firewall kuralları uygulanır, veritabanı tutarlılık kontrolü yapılır.
Maliyet cold ile hot arasında dengelenir. Tatbikat sıklığı yılda bir veya iki kez planlanabilir. Warm modelde DNS TTL, TLS kimlik belgesi geçerliliği ve kimlik replikasyon gecikmesi sık sorun kaynağıdır. Toparlanma süresi hedefi ve yedek ortama geçiş tatbikatı warm site için özellikle ölçülebilir adımlar içermelidir.
Kapsam listesi güncel değilse warm site yine de kapsam dışı uygulamaları ayağa kaldıramaz. Paket adı warm yazıyor olsa bile sözleşmedeki VM listesi esas alınır.
Hot Site Modeli
Hot site modelinde ikincil konum üretime yakın hazırlıkta tutulur. Replikasyon sık veya sürekli çalışır. Bazı tasarımlarda aktif pasif çift site, bazılarında aktif aktif okuma trafiği görülür. Geçiş anında başlatma süresi dakika veya saat yerine daha kısa pencerelerle konuşulur.
Sürekli hazırlık maliyeti yükselir. Lisans, compute ve replikasyon kanalı sürekli tüketilir. Kritik gelir üreten sistemler ve sıkı iş sürekliliği hedefleri hot site gündemine getirir. Hot etiketi otomatik olarak tüm uygulama portföyünü kapsamaz. ERP ve kimlik servisi hot listede, raporlama sunucusu cold listede kalabilir.
Hot site tatbikatı üretim trafiğini etkileme riski taşır. Bakım penceresi ve geri alma planı onaylanmadan tam geçiş denemesi yapılmamalıdır. Teknik DR katmanı iş sürekliliği planından ayrı belgelenmelidir.
DRaaS Paket Adı ile Gerçek Hazırlık Arasındaki Boşluk
Hizmet kataloglarında hot DRaaS ifadesi görürsünüz. Katalog dili ile sözleşme ekleri her zaman örtüşmez. Şu maddeler paket adından bağımsız sorulmalıdır.
Replikasyon sıklığı ve tutarlılık penceresi nasıl tanımlanıyor. Yedek ortama geçiş tetikleme yetkisi kimde. İkincil ortamda ağ ve kimlik katmanı pakete dahil mi. Üretime geri dönüş adımları yazılı mı. Yıllık tatbikat hakkı ve kapsamı sözleşmede var mı.
Leon-X Bulutistan altyapısının sahibi değildir. DRaaS seçeneğini gereksinimlere göre değerlendirir ve site tipi ile iş yükü listesini hizalar. Kesin hizmet düzeyi taahhüdü veya çalışma süresi yüzdesi bu yazıda iddia edilmez.
Site Seçiminde Karar Soruları
Karar tablosu yerine sahada işe yarayan soru seti şöyle ilerler.
Kesinti süresi iş için ne kadar tolere edilir. Kritik sistem sayısı ve bağımlılık derinliği nedir. Bütçe sürekli replikasyonu kaldırıyor mu. Tatbikat için operasyon kapasitesi var mı. Veri yerleşimi ve uyumluluk gereksinimleri ikincil konumu nasıl sınırlıyor.
Tek cevap her uygulama için geçerli değildir. Müşteri portalı hot, iç raporlama warm, arşiv cold olabilir. Karışık model sözleşmede açık yazılmazsa destek talepleri karışır.
Tatbikat ve Runbook Bağlantısı
Site tipi ne olursa olsun yazılı runbook şarttır. Cold modelde runbook donanım ve geri yükleme sırasını detaylandırır. Warm modelde boot sırası ve ağ adımları kritiktir. Hot modelde bile DNS ve uygulama smoke testi atlanmamalıdır.
Tatbikat raporunda site tipi, başlangıç ve bitiş zamanı, kapsanan sistem listesi ve bulunan eksikler kayıt altına alınır. Bir sonraki sözleşme yenilemesinde site tipi yükseltme veya düşürme kararı bu kayıtlara dayanmalıdır.
Yaygın Yanlış Okumalar
Hot DRaaS alındığında yedekleme ihtiyacının bittiği düşüncesi yanlıştır. Uzun süreli arşiv ve dosya düzeyi geri dönüş için yedek katmanı ayrı kalır.
Warm site etiketinin otomatik olarak dakika düzeyinde toparlanma süresi vaadi verdiği varsayımı da hatalıdır. Hedefler sözleşme ve sağlayıcı dokümantasyonu ile netleşir.
Cold site seçildiğinde replikasyonun hiç gerekmediği kanısı tehlikelidir. Cold kabukta bile güncel kopya veya yedekten restore süresi planlanmalıdır.
Depolama tier makalesindeki hot veri tanımını DR hot site ile eşleştirmek karışıklık üretir. İki kavram farklı disiplinlerde yaşar.
Kontrol Listesi
- Kritik uygulama listesi site tipi ile eşleştirildi
- Her site tipi için replikasyon veya yedek kaynağı tanımlı
- Sözleşmede yedek ortama geçiş ve üretime dönüş sorumlulukları ayrıldı
- Ağ, DNS ve kimlik adımları runbookta yazılı
- Yıllık tatbikat takvimi onaylı
- DRaaS paket kapsamı site etiketiyle karşılaştırıldı
Leon-X ile Sonraki Adım
Leon-X hot, warm ve cold site seçeneklerini iş önceliğinize ve mevcut yedekleme katmanınıza göre yan yana çizer. Hangi uygulamanın hangi hazırlık seviyesini hak ettiğini netleştirir. Tatbikat ve runbook adımlarını operasyon ekibinizle koordine eder. Keşif için iletişime geçin.
Sık Sorulan Sorular
Tek bir site tipi tüm şirket için yeterli olur mu?
Çoğu kurumda hayır. Gelir üreten sistemler daha sıcak hazırlık ister, arşiv ve geliştirme ortamları soğuk modelde kalabilir. Liste ve sözleşme karışık modeli yansıtmalıdır.
Warm site ile hot site arasındaki pratik fark nedir?
Warm modelde ikincil kopya vardır ancak geçiş sırasında belirgin boot ve ağ adımları çalışır. Hot modelde hazırlık sürekli tutulur ve geçiş penceresi daha dar hedeflenir. Kesin süreler sözleşmeye bağlıdır.
Cold site DRaaS yedekleme yerine geçer mi?
Geçmez. Cold DR kabuğu felaket anında kapasite sağlar. Günlük dosya geri dönüşü ve tutarlılık testleri için yedekleme katmanı ayrı planlanır.
Site tipi yükseltmek her zaman doğru hamle mi?
Maliyet ve operasyon yükü artar. Tatbikat disiplini olmayan ekipte hot site etiketi yeşil panel illüzyonu yaratabilir. Önce warm modelde runbook ve tatbikat oturtulması sık görülür.
Sonuç
Hot, warm ve cold site terimleri DRaaS seçiminde ikincil konumun hazırlık seviyesini anlatır. Cold maliyeti düşürür, süreyi uzatır. Warm dengeli bir orta yol sunar. Hot kesinti penceresini daraltmayı hedefler ancak sürekli maliyet ve disiplin ister. Paket adındaki etiket tek başına yeterli değildir. Replikasyon, ağ, kimlik, tatbikat ve sözleşme maddeleri birlikte okunmalıdır. Leon-X altyapı sahibi değildir, site tipi kararını ve DRaaS kapsamını gereksinimlerle hizalar.
Kaynaklar
- Leon-X iç claim ledger,
docs/research/leonx-seo-claim-evidence.md - DRaaS ürün sayfası,
/solutions/bulutistan/draas
