Ana içeriğe geç

SecuraWall.com

E-posta güvenliği ve sürekliliği

Keşfedin
Teknik Rehber · Microsoft 365 & Cloud

Bulut Yedekleme mi Lokal Yedekleme mi?

Bulut ve lokal yedekleme birbirinin mutlak alternatifi değildir; veri hacmi, geri dönüş süresi, bağlantı kapasitesi, maliyet, fiziksel risk ve ransomware dayanıklılığı birlikte değerlendirilmelidir.

SON TEKNİK GÖZDEN GEÇİRME:
Microsoft 365 & Cloud

Bu Konu Neden Önemli?

Bulut ve lokal yedekleme birbirinin mutlak alternatifi değildir; veri hacmi, geri dönüş süresi, bağlantı kapasitesi, maliyet, fiziksel risk ve ransomware dayanıklılığı birlikte değerlendirilmelidir.

Karar Verirken Kontrol Edilecek Noktalar

RPO/RTO hedefini depolama lokasyonundan önce belirleyin.

Büyük geri yüklemelerde ağ bant genişliğini hesaba katın.

Lokal hızlı restore ile offsite dayanıklılığı birlikte tasarlayın.

Şifreleme ve anahtar yönetimini her iki modelde de planlayın.

Mimari ve çalışma modeli

Lokal kopya düşük aktarım gecikmesiyle büyük restore sağlayabilir; bulut kopya farklı lokasyon ve kapasite modeli sunabilir. Her ikisi de kimlik, silme, anahtar ve bağlantı riskleri taşır. Hibrit tasarım yerel hızlı kurtarma ile uzak korumayı birleştirebilir. Depolama fiyatı, veri çıkışı, retrieval gecikmesi ve gerçek restore kapasitesi birlikte hesaplanmalıdır.

Bulut tarafında Google Cloud, Amazon Web Services (AWS) ve Microsoft Azure seçeneklerini aynı veri, kurtarma ve işletim gereksinimleriyle değerlendirin. Platform servisleri benzer amaçlara hizmet etse de backup kapsamı, saklama, IAM, region ve egress koşulları farklıdır. Seçim ürün adına göre değil, restore testinde kanıtlanan sonuç ve toplam işletim maliyetine göre yapılır.

  1. 1İş yükü ve RTO
  2. 2Lokal geri dönüş
  3. 3Bulut/offsite koruma
  4. 4Hibrit kurtarma testi
Lokal ve bulut kopyadan aynı uygulamayı geri getirip süre ve maliyeti karşılaştırın.

Tasarım parametreleri

Toplam kurtarma maliyeti
Depolama yanında okuma, egress, API, geri kazanım ve işletim giderini hesaplayın.
Yerel ve uzak arıza
Hızlı yerel restore ile site kaybı için uzak restore farklı hedeflerdir; tek seçeneğe aynı garantiyi yüklemeyin.
Kurtarma birimi
Dosya, uygulama, veritabanı ve tüm sistem için kurtarma gereksinimlerini ayrı ayrı belirleyin. Her birinin bağımlılığı ve test yöntemi farklıdır.
Kopyanın tutarlılığı
Yedekleme işinin başarıyla tamamlanmasıyla yetinmeyin. Uygulama hazırlığı, günlük zinciri ve gerçek geri yükleme sonucu üzerinden tutarlılığı doğrulayın.
Kapasite ve aktarım
Günlük değişim, saklama, tam kopya yöntemi ve ölçülen net hızla hesap yapın. Sıkıştırma veya deduplication oranını varsaymak yerine pilotta ölçün.
Bağımsız kurtarma
Yedek yönetimi, anahtar, katalog ve hedef altyapının üretim kaybından sonra erişilebilirliğini sınayın.

Platformlardaki uygulama karşılıkları

Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.

KonuGoogle CloudAmazon Web Services (AWS)Microsoft Azure
Nesne kopyasıCloud StorageAmazon S3Azure Blob Storage
Backup işletimiBackup and DR / service-specific backupAWS Backup / service-specific backupAzure Backup / service-specific backup
KontrolBağımsız erişim, retention ve restore testiAccount/region, yetki ve restore testiSubscription/region, yetki ve restore testi

Hesap ve uygulama örneği

Örnek kararda 5 TB tam geri dönüş ile 50 GB günlük değişimi ayrı iş olarak ölçün. Günlük upload sorunsuzken büyük restore internet hattına takılabilir. Lokal repository kaybında bulut kopyanın erişimi ve anahtarı kullanılabilir olmalıdır.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Bulut job hızlı ama restore yavaşİndirme sınırlaması veya archive retrieval süresi etkili olabilir.Seçilen storage sınıfından temsilî restore ve maliyet ölçümü yapın.
Yedekleme başarılı ancak geri yüklenen sistem açılamıyorZincir, şifreleme anahtarı, katalog veya uygulama tutarlılığı sorunu olabilir.Ayrı hedefe küçük bir gerçek kurtarma yapın; ürün loglarını uygulama doğrulamasıyla birlikte inceleyin.
Aktarım süresi hedefi aşıyorKaynak okuma, ağ, hedef yazma veya çok sayıda küçük nesne sınırlayıcı olabilir.Aynı zaman aralığında üç katmanın hız ve gecikmesini ölçün; yalnız hat hızına bakmayın.
Kapasite tahminden hızlı büyüyorDeğişim oranı, tam kopyalar, kilit süreleri veya temizleme beklemeleri hesap dışı kalmış olabilir.Politika bazında gerçek kullanım ve silinmeye uygun noktaları karşılaştırın.

Kabul ve doğrulama kontrolleri

  1. Lokal ve bulut kopyadan aynı uygulamayı geri getirip süre ve maliyeti karşılaştırın.
  2. Seçilen kurtarma noktasını temiz bir hedefe geri yükleyin ve iş verilerini doğrulayın.
  3. Gözlenen veri kaybı penceresini hedef RPO ile karşılaştırın.
  4. Hazırlık, transfer, açılış ve iş onayını ayrı süreler olarak kaydedin.
  5. Üretim yönetim hesabı olmadan gerekli kurtarma erişimini test edin.
  6. Korunan kopyayı kontrollü silme denemesi ve gerçek restore ile sınayın.

İlgili kavramlar

Bant genişliği ve gerçek aktarım

Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.

RTO ve uçtan uca kurtarma süresi

RTO, bir hizmetin olaydan sonra ne kadar sürede kullanılabilir hale gelmesi gerektiğini ifade eder. Yedek dosyasının indirilmesi veya sanal makinenin açılması bu sürenin yalnız bir bölümüdür. Olayı tanıma, onay, altyapı hazırlığı, veri aktarımı, uygulama açılışı ve iş biriminin doğrulaması ayrı zaman kalemleri olarak kaydedilmelidir. Test süresinin hangi olayla başlayıp hangi olayla sona erdiğini açıkça belirtin. Aynı teknik geri dönüş süresi, bağımlılık veya erişim beklenmesi nedeniyle farklı iş süreçlerinde farklı kesinti süresine dönüşebilir.

RPO ve gerçek veri kaybı penceresi

RPO, olay sonrasında kabul edilebilecek veri kaybı süresidir. Yedek zamanlaması tek başına RPO kanıtı değildir; işin başarısız olması veya kopyanın karşı merkeze geç ulaşması pencereyi büyütebilir. Olay anı ile kullanılabilir son tutarlı kurtarma noktasının zamanını karşılaştırın. Örneğin olay 14.00'te, doğrulanmış kopya 13.20'deyse o testteki veri kaybı penceresi 40 dakikadır. Hedefi uygulama bazında belirleyin: dosya arşivi ile sürekli sipariş alan veritabanının gereksinimleri aynı olmayabilir.

Maliyet ölçümünün sınırı

Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.

Güven sınırı ve hata alanı

Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.

Şifreleme ve anahtarın yaşam döngüsü

Şifreleme, verinin anahtar olmadan okunmasını zorlaştırır; erişim kontrolü, silinme koruması ve yedekleme farklı ihtiyaçları karşılar. Taşınan veri ile disk üzerindeki veri için hangi katmanın şifreleme sağladığını belirtin. Anahtarların oluşturulması, korunması, döndürülmesi ve acil geri kazanımı tasarımın parçasıdır. Yedeği kurtarmak için gereken anahtar yalnız felaket sırasında kaybedilecek sunucuda bulunmamalıdır. Test ortamında ayrı bir yöneticiyle veriyi açma ve anahtar erişimini geri kazanma adımlarını uygulayın; gerçek anahtarları dokümana veya destek mesajına koymayın.

Birincil teknik dokümantasyon

Who · How · Why

Bu İçerik Nasıl Hazırlandı?

Kim?

Doz Teknoloji Teknik Ekibi

İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.

Nasıl?

Teknik kriterler + birincil kaynaklar

Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.

Neden?

Karar kalitesini artırmak

Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.

SON TEKNİK GÖZDEN GEÇİRME

Bu Rehberle İlgili Kurumsal Çözümler

Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.

Teknik İhtiyacınızı Birlikte Değerlendirelim

Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.

Teknik Talep Oluşturun
Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!