RPO, kabul etmeye hazır olduğunuz veri kaybı penceresini tanımlar; RTO ise içinde kalmayı hedeflediğiniz kesintiyi tanımlar. Her ikisini de faydalı bir iş fonksiyonu için tanımlayın, ardından kurtarma sırasını bir tatbikatta kanıtlayın. Tek başına bir yedekleme programı veya bir sunucu özelliği bu hedeflerin hiçbirini oluşturmaz.
İnsanların kullanabileceği bir hizmetle başlayın
Kurtarma hedefleri, izole bir makine yerine bir iş fonksiyonunu tanımladığında faydalı hale gelir. Bir sunucu açılabilirken müşteriler hâlâ oturum açamıyor, dosya alamıyor veya bir isteği tamamlayamıyor olabilir. Bitiş koşulunu sade bir dille yazın: yetkili kullanıcılar uygulamaya erişebilir ve gerekli veriler tutarlıdır. Bu, hedefi altyapı ekibi dışındaki biri tarafından test edilebilir kılar.
Uygulamanın sahibine bir kesintinin neyi engelleyeceğini ve eksik verinin neye mal olacağını sorun. Haftalık bir yayın ile işlem işleyen bir uygulamanın yanıtları farklı olabilir. Ortaya çıkan hedefleri donanım kataloğundan uydurulmuş vaatler değil, planlama hedefleri olarak ele alın. Bunları kimin onayladığını ve planın hangi arıza senaryolarını kapsadığını kaydedin.
İki saati ayırın
RPO, kurtarılan verilerin kesintiye göre ne kadar geriye gidebileceğiyle ilgilidir. RTO ise fonksiyonun ne kadar süre kullanılamaz kalabileceğiyle ilgilidir. Yeni bir yedek veri kaybı penceresini iyileştirebilirken yavaş bir geri yükleme yine de kurtarma süresi hedefini kaçırabilir. Tersine, hızlı bir yeniden başlatma, en yeni verisi hayatta kalmamış bir uygulamaya erişimi geri getirebilir.
Referans noktalarını belirtin. Olay saatinin ne zaman başladığına, neyin geri yüklenmiş işlem sayıldığına ve kullanılabilir veri noktasının nasıl tanımlanacağına karar verin. Hedefleri ölçülen sonuçlardan ayrı tutun: hedef, aradığınız şeydir; bir tatbikat mevcut sürecin neyi başardığını gösterir. Uygulama veya veri kümesi değiştiğinde her ikisini de yeniden gözden geçirin.
Kurtarmanın her adımını bütçeleyin
Pratik bir RTO bütçesi; tespit, değerlendirme, yetkilendirme, kurtarma ortamına erişim, geri yükleme, uygulama doğrulama ve yeniden açmayı içerir. Dosya kopyalama süresi bunun yalnızca bir bileşenidir. Kurtarma anahtarını elinde tutan kişi müsait değilse, teorik olarak hızlı bir yedek yine de kullanılamaz olabilir. Bağımlılıkları listeleyin ve kurtarma ekibinin söz konusu arıza sırasında bunlara erişebildiğinden emin olun.
Her adıma geçici bir süre atayın, ardından tahminleri gözlemlerle değiştirin. Bu örnek iki saatlik bütçede, geri yükleme en büyük payı alır ancak doğrulama için yine de korunan bir süre vardır. Sayılar bir planlama örneğini tanımlar, SwissOctet hizmet sunumunu değil. Toplamda hiç pay yoksa, hedef inandırıcı olmadan önce tasarımın iyileştirilmesi gerekir.
| Kurtarma adımı | Örnek pay | Toplanacak kanıt |
|---|---|---|
| Tespit et ve değerlendir | 15 dakika | Uyarı gelişi ve olay kararı |
| Kurtarma ortamını hazırla | 20 dakika | Erişim ve yapılandırma mevcut |
| Veriyi ve hizmeti geri yükle | 50 dakika | Tutarlı veriyle tamamlanmış geri yükleme |
| Doğrula ve yeniden aç | 25 dakika | Kullanıcı yolculuğu başarılı |
| Beklenmeyen durum payı | 10 dakika | Beklenmeyen iş kaydedildi |
Gerçek veri kaybı penceresini kontrol edin
Her saat başı planlanan bir iş, otomatik olarak bir saatlik RPO sağlamaz. Başarısız bir iş, gecikmiş bir yükleme veya kullanılamaz bir kopya, en son kurtarılabilir noktayı çok daha eski hale getirebilir. Başarılı tamamlanmayı ve gerçekte geri yüklenebilecek durumu gözlemleyin. Birkaç veri deposu olan bir uygulama için, her zaman damgasını tek başına okumak yerine kurtarma noktalarının uyumlu olduğunu doğrulayın.
Bir tatbikat sırasında, bilinen bir zamanda oluşturulmuş yetkili bir test kaydı gibi bir referans olay seçin. Geri yüklemeden sonra en yeni geçerli kaydı belirleyin ve farkı ölçün. Zararsız test verileri kullanın. Bu, pratik bir sonuç verir ve yalnızca iş başarısını gösteren bir kontrol panelinin gizli bırakabileceği varsayımları ortaya çıkarır.
Bütçe dahilinde bir strateji seçin
Yedekle-ve-geri-yükle, hazır bekleme ortamları ve çoğaltılmış uygulama tasarımları, maliyet ve karmaşıklığı kurtarma hızıyla değiş tokuş eder. Çoğaltma bazı gecikmeleri azaltabilir ancak kazara bir silmeyi veya uygulama hatasını da çoğaltabilir. Çalışan yapılandırmadan sapmış bir bekleme ortamı kendi riskini oluşturur. Belgelediğiniz arıza senaryolarına ve hedeflere karşı bir strateji seçin.
Dört saatlik hedefi olan küçük bir hizmeti ve bir tatbikatta tek başına geri yüklemesi altı saat süren daha büyük bir veri kümesini düşünün. Daha hızlı bir ağ bağlantı noktası satın almak yalnızca bir hipotezdir: depolama okumaları, alınan yazmalar ve uygulama kurtarma baskın olabilir. Ölçülen sınırlayıcı adımı iyileştirin, kurtarma kümesini azaltın veya stratejiyi değiştirin, ardından tekrar tatbikat yapın.
Üretimi tehlikeye atmadan prova yapın
İzole bir kurtarma ortamı ve tanımlı bir tatbikat penceresi kullanın. Geri yüklenen işlerin gerçek bildirimler gönderemeyeceğinden, genel ödemeleri kabul edemeyeceğinden veya üretim entegrasyonlarına yazamayacağından emin olun. Tatbikatı tamamlanmış saymadan önce erişimi, veri bütünlüğünü ve temsili kullanıcı yolculuklarını test edin. Eksik talimatları ortaya çıkarmak için orijinal prosedürü yazmamış bir kişiyi dahil edin.
Tatbikatın bir zaman çizelgesini, elde edilen kurtarma noktasını ve kullanılamayan bilgilerin neden olduğu her kesintiyi tutun. Faydalı bir rapor ölçülen sonucu, hedefe olan farkı ve belirli bir düzeltici eylemi belirtir. Anlamlı değişikliklerden sonra ve projenin önemine uygun bir aralıkta tekrarlayın.
Planı bir arıza sırasında kullanılabilir tutun
Kurtarma prosedürünü, ekibin yalnızca başarısız uygulamaya güvenmeden erişebileceği bir yerde saklayın. Kimlik bilgilerini ve şifreleme anahtarlarını, test edilmiş bir erişim süreciyle korunan bir konumda tutun. Proje geliştikçe kişileri, veri kümesi boyutlarını ve bağımlılıkları güncelleyin. Kullanımdan kalkmış bir plan, geri yükleme başlamadan önce zaman payını tüketebilir.
SwissOctet yapılandırmalarını karşılaştırırken, kurtarma mimarinizi kataloğun isteğe bağlı yedekleme seçeneklerinden ayırın. Bir seçeneğin neyi kapsadığını, kurtarma verilerinin nerede tutulduğunu ve geri yüklemeyi kimin yaptığını doğrulayın. Katalog bir uygulama RPO'su veya RTO'su oluşturmaz. Ölçülen süreciniz ve gerçek hizmet koşulları bu kararın temelini sağlar.
Pratik kontrol listeniz.
- Geri yüklenen iş fonksiyonunu tanımlayın.
- Ayrı RPO ve RTO hedeflerini onaylayın.
- Tespit, erişim, geri yükleme ve doğrulamayı bütçeleyin.
- En son kullanılabilir veri noktasını ölçün.
- İzole bir ortamda prova yapın.
- Farkları kaydedin ve ilgili değişikliklerden sonra tekrarlayın.
Önemli olan ayrıntılar.
RTO, çalışma süresiyle aynı mıdır?+
Hayır. RTO, bir kesinti senaryosu için kurtarma hedefidir. Çalışma süresi bir dönem boyunca kullanılabilirliği ölçer; biri diğerini oluşturmaz.
Saatlik yedekleme bir saatlik RPO'yu garanti eder mi?+
Hayır. Tamamlanmış, kullanılabilir kopyaları ve uygulamanın tutarlılık gereksinimlerini kontrol edin. Başarısız işler ve gecikmiş transferler kurtarılabilir veri farkını genişletebilir.
Her proje bir bekleme sunucusu kullanmalı mı?+
Projenin kurtarma hedeflerine ve ölçülen geri yükleme sürecine karşı bir strateji seçin. Bir bekleme ortamı maliyet ve operasyonel karmaşıklık ekler ve otomatik olarak gerekli değildir.
Kaynağa gidin.
Bu kaynaklar, bu kılavuzdaki teknik kavramları destekler. Bir üretim sistemini değiştirmeden önce güncel belgeleri izleyin.
- NIST SP 800-34 Rev. 1: Beklenmedik Durum Planlama Kılavuzu nvlpubs.nist.gov
- AWS Well-Architected: Kurtarma hedeflerini tanımlayın docs.aws.amazon.com
- Microsoft Learn: İş sürekliliği, yüksek kullanılabilirlik ve olağanüstü durum kurtarma learn.microsoft.com
SwissOctet tarafından editoryal rehberlik. Örnekler açıklayıcıdır. Hizmet spesifikasyonları, mevcut seçenekler ve sözleşme koşulları ayrıca doğrulanmalıdır.