Bu Konu Neden Önemli?
Offsite yedekleme, üretim sistemiyle aynı fiziksel veya mantıksal hata alanında olmayan ek bir kopya tutarak tesis, donanım veya ransomware kaynaklı ortak kayıp riskini azaltır.
Karar Verirken Kontrol Edilecek Noktalar
Uzak kopyanın aynı kimlik altyapısına bağımlılığını değerlendirin.
Bant genişliği ve ilk kopya süresini planlayın.
Şifreleme anahtarlarını ayrı koruyun.
Offsite kopyadan geri dönüş süresini test edin.
Mimari ve çalışma modeli
Offsite kopya üretim lokasyonunun kaybına karşı koruma sağlayabilir; aynı yönetim hesabıyla silinme veya ele geçirilmiş bağlantı riskini otomatik çözmez. Gecikmeli aktarım, bant genişliği ve uzak hedefin erişim koşulları gerçek RPO/RTO’yu etkiler. Veri çıkışı ve geri alma kapasitesi, günlük yükleme kapasitesinden farklı olabilir.
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.
- 1Kaynak kopya
- 2WAN veya medya aktarımı
- 3Bağımsız uzak hedef
- 4Uzak noktadan restore
Tasarım parametreleri
- Aktarım penceresi
- Değişen veri miktarını gerçek kullanılabilir uplinkle bölün; protokol, kayıp ve yeniden deneme ek süre getirir.
- Geri dönüş yolu
- Bulut indirme, fiziksel taşıma ve yerel restore seçeneklerini ayrı ölçün; dışarıya kopyalama hızı geri dönüşü kanıtlamaz.
- 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.
| Konu | Google Cloud | Amazon Web Services (AWS) | Microsoft Azure |
|---|---|---|---|
| Nesne kopyası | Cloud Storage | Amazon S3 | Azure Blob Storage |
| Backup işletimi | Backup and DR / service-specific backup | AWS Backup / service-specific backup | Azure Backup / service-specific backup |
| Kontrol | Bağımsız erişim, retention ve restore testi | Account/region, yetki ve restore testi | Subscription/region, yetki ve restore testi |
Hesap ve uygulama örneği
500 GB veriyi ölçülen 80 Mbit/s net hızla taşımak ideal sabit hız varsayımında yaklaşık 13 saat 53 dakika sürer. Buna katalog, hazırlık ve uygulama açılışı dahil değildir. Büyük geri dönüşü yalnız günlük değişim aktarımına bakarak planlamayın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Offsite kopya var ama RTO aşılmış | İndirme, egress veya hedef kapasitesi göz ardı edilmiş olabilir. | Temsilî veriyi başka lokasyona geri indirip uygulama açılışını zamanlayın. |
| Yedekleme başarılı ancak geri yüklenen sistem açılamıyor | Zincir, ş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şıyor | Kaynak 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üyor | Değ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
- Ana lokasyonun erişimi olmadan uzak hedefe bağlanıp örnek uygulamayı geri getirin.
- Seçilen kurtarma noktasını temiz bir hedefe geri yükleyin ve iş verilerini doğrulayın.
- Gözlenen veri kaybı penceresini hedef RPO ile karşılaştırın.
- Hazırlık, transfer, açılış ve iş onayını ayrı süreler olarak kaydedin.
- Üretim yönetim hesabı olmadan gerekli kurtarma erişimini test edin.
- Korunan kopyayı kontrollü silme denemesi ve gerçek restore ile sınayın.
İlgili kavramlar
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.
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.
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.
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.
Ş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.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Birincil teknik dokümantasyon
Bu İçerik Nasıl Hazırlandı?
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.
Teknik kriterler + birincil kaynaklar
Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.
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.
İlgili Hizmet ve Rehberler
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