RPO, bir arıza anında en fazla ne kadarlık veri kaybını kabul edeceğinizi gösteren bir hedeftir ve gerçek düzenle doğrulanmalıdır. Çoğu kurumda bu hedef bir sunumda ya da bir sözleşme taslağında yazılı kalır, yedekleme ayarlarına hiç inmez. Offsite ve bulut kopya devreye girince fark büyür. Geri yükleyeceğiniz kopya genellikle yerel yedek değil, uzaktaki kopyadır ve o kopya yerel yedekten geç tamamlanır.
Bu yazı yedekleme bulutu ürün sayfasını destekler. Bir hedef rakamı vermez, hedefi nasıl yazılı bir politikaya bağlayacağınızı anlatır. Kopyaların nerede duracağı sorusu için 3-2-1 yedekleme kuralı ve bulut katmanı yazısına bakabilirsiniz.
Hızlı Özet
RPO bir hedef olarak değerlendirilir, bir taahhüt değildir ve gerçek yedekleme düzeniyle doğrulanmalıdır. Hedef, yedekleme sıklığına ve aktarım süresine bağlı olarak tutar ya da tutmaz.
Offsite kopyanın gecikmesi iki parçadan oluşur. Birincisi yedeğin alınma aralığıdır. İkincisi yedeğin uzak konuma aktarılma süresidir. İkisinin toplamı hedefin içinde kalmıyorsa politika kâğıt üzerinde kalır.
Leon-X altyapı sahibi değildir. Veri sınıflarınızı çıkarır, hedefleri iş birimleriyle konuşur ve yedekleme düzenini bu hedeflere göre kurgular.
İçindekiler
- Hedef Neyi Anlatır
- Yerel Kopya ile Offsite Kopya Arasındaki Gecikme
- Veri Sınıfına Göre Hedef Belirleme
- Politikada Bulunması Gerekenler
- Hedefi Nasıl Doğrularsınız
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Pexels, kod ekranları açık çalışma masası.
Hedef Neyi Anlatır
RPO hedefi bir kopya ile arıza anı arasındaki en uzun kabul edilebilir süreyi gösterir ve gerçek düzenle doğrulanmalıdır. Hedef kısaysa yedekler sık alınmalı, uzunsa daha seyrek alınabilir.
Hedefi belirleyen teknik ekip değil, verinin sahibi olan iş birimidir. Muhasebe sistemindeki bir günlük kayıp ile belge arşivindeki bir günlük kayıp aynı sonucu doğurmaz. Teknik ekip bu hedefi yedekleme ayarlarına çevirir ve yapılabilir olup olmadığını söyler.
Hedef bir taahhüt gibi okunmamalıdır. Yedekleme yazılımı başarılı görünse de geri yüklenebilir kopyanın güncelliği ayrıca kontrol edilir. Müşteriye ya da yönetime bir süre sözü vermeden önce bu kontrolün yapılmış olması gerekir.
Yerel Kopya ile Offsite Kopya Arasındaki Gecikme
Yerel yedek tamamlandığında veri henüz uzak konumda değildir. Aktarım arka planda sürer ve bitmesi yedeğin boyutuna, ağ hattına ve diğer işlerin yarattığı yüke bağlıdır.
Bir örnek düşünelim. Yedek gece alınıyor ve yerel kopya sabaha doğru tamamlanıyor. Bulut aktarımı ise gün içinde, hat meşgul olduğu saatlerde yavaşlıyor. Bu durumda uzaktaki kopya, yerel kopyadan yarım gün ya da daha fazla geride kalabilir. Büyük bir arıza yerel kopyayı da yok ederse, elinizdeki en güncel veri bu geride kalan kopyadır.
Bu yüzden hedefi ölçerken şu iki ayrı süreye bakarsınız. Yerel kopyanın güncelliği günlük küçük kayıpları karşılar. Offsite kopyanın güncelliği ise yerel kopyayı da kaybettiğiniz durumu karşılar. İki süre için ayrı hedef yazılması çoğu zaman daha dürüst bir politika verir. Bulut tarafında aktarılan verinin nasıl saklandığı object storage nedir yazısında anlatılıyor.
Aktarım süresini kısaltmanın yolları vardır. Yedeklerin yalnızca değişen kısımlarını göndermek, aktarımı yoğun saatlerin dışına almak ve hat kapasitesini gerçek veri hacmine göre planlamak bunların başında gelir. Kapasite hesabını yedeğin ilk büyük kopyası için değil, günlük değişim için yapmanız gerekir.
Veri Sınıfına Göre Hedef Belirleme
Tüm veriye aynı hedefi vermek hem pahalıdır hem gereksizdir. Veriyi sınıflara ayırıp her sınıf için ayrı hedef yazmak daha sürdürülebilirdir.
Sürekli değişen iş verisi. Sipariş, muhasebe ve müşteri kayıtları gibi veriler en sıkı hedefi ister. Bu sınıfta yedekleme sık alınır ve uzak kopyanın gecikmesi sıkı izlenir.
Paylaşılan belgeler. Dosya sunucularındaki belgeler günlük yedekle çoğu zaman yeterince korunur. İş birimi bir günlük kaybı kabul edebiliyorsa hedef buna göre yazılır.
Arşiv ve referans veri. Nadiren değişen veri için daha geniş hedef yeter. Burada asıl mesele güncellik değil, saklama süresi ve erişilebilirliktir.
Yeniden üretilebilen veri. Kaynağından yeniden oluşturulabilen veri için düşük öncelik verilebilir. Bunu yazılı olarak kabul etmek gerekir.
Her sınıfın yedek yöntemi de farklı olabilir. Sunucunun tamamını mı yoksa yalnızca dosyaları mı yedekleyeceğinizi image backup ile dosya bazlı yedek yazısında karşılaştırdık.
Politikada Bulunması Gerekenler
Hedefi bağlayıcı kılan şey yazılı politikadır. Politika kısa olabilir ama şu başlıkları içermelidir.
Veri sınıfı ve sahibi açıkça yazılır. Her sınıf için hedef süre, onu onaylayan kişiyle birlikte kaydedilir.
Yedekleme sıklığı ve zamanlaması hedefle tutarlı olur. Hedef kısaysa günde bir yedek yetmez.
Offsite aktarım penceresi ve izlenecek gecikme tanımlanır. Aktarım bitmeden yerel kopyanın uzak kopya sayılmadığı net yazılır.
Saklama süresi ve silme yetkisi belirlenir. Kimin hangi kopyayı silebileceği, kopyaların hata alanından ayrılması açısından önemlidir.
Geri yükleme tatbikatının sıklığı ve sonucun kime raporlanacağı yer alır. Politika bir kez yazılıp unutulmaz, tatbikat sonuçlarıyla gözden geçirilir.
Kurumsal standartlar bu politikanın belgelenmesini ister. ISO 27001 çerçevesinde yedekleme politikasının nasıl kurulacağını ISO 27001 yedekleme politikaları yazısında ele aldık.
Hedefi Nasıl Doğrularsınız
Yazılı hedef ancak ölçüldüğünde anlam kazanır. Doğrulama üç adımda yapılır.
Önce yedekleme yazılımının raporlarından her işin tamamlanma zamanını alırsınız. Ardından offsite kopyanın en son tamamlanan noktasını ayrıca görürsünüz. İki zaman arasındaki fark gerçek gecikmenizdir.
Sonra bu gecikmeyi hedefle karşılaştırırsınız. Aşılıyorsa yedek sıklığını artırır, aktarımı yoğun saatlerin dışına alır ya da hat kapasitesini gözden geçirirsiniz.
Son olarak geri yükleme tatbikatı yaparsınız. Uzak kopyadan gerçek bir geri yükleme, gecikmeyi ve süreyi birlikte gösterir. Hizmet olarak yedeklemede bu tatbikatın kimin sorumluluğunda olduğunu BaaS kapsam ve sınırlar yazısında açıkladık.
Yaygın Hatalar
Hedefi iş birimiyle konuşmadan teknik ekibin tek başına belirlemesi ilk hatadır.
Yerel yedeğin güncelliğini uzak kopyanın güncelliği sanmak ikinci ve en sessiz hatadır.
Tüm veriye aynı sıkı hedefi vermek maliyeti gereksiz yükseltir. Hedefsiz bırakmak ise önemli veriyi korumasız bırakır.
Hattın yoğun saatlerde aktarımı yavaşlattığını hesaba katmamak, hedefin sessizce aşılmasına yol açar.
Hedefi yazıp doğrulamamak, politikanın gerçeği yansıtmamasına neden olur.
Kontrol Listesi
- Veriler sınıflandırıldı ve her sınıfın sahibi belirlendi.
- Her sınıf için kabul edilebilir veri kaybı süresi iş birimiyle birlikte yazıldı.
- Yedekleme sıklığı bu sürelerle tutarlı hale getirildi.
- Offsite aktarımın tamamlanma zamanı ayrıca izleniyor.
- Yerel ve uzak kopya için ayrı güncellik hedefi yazıldı.
- Aktarım yoğun saatlerin dışına alındı ve hat kapasitesi günlük değişime göre planlandı.
- Saklama süresi ve silme yetkisi politikaya işlendi.
- Uzak kopyadan geri yükleme tatbikatı yapıldı ve sonuç raporlandı.
- İhtiyaçlar doğrultusunda yedekleme bulutu çözümü incelendi.
Leon-X ile Sonraki Adım
Leon-X veri sınıflarınızı çıkarır, kabul edilebilir veri kaybı sürelerini iş birimleriyle birlikte netleştirir ve bunları yazılı bir yedekleme politikasına çevirir. Ardından yedekleme sıklığını, offsite aktarım düzenini ve izleme raporlarını bu politikaya göre kurgular, geri yükleme tatbikatını planlar. Leon-X altyapı sahibi değildir, doğru bulut teknolojilerini kurumunuz için entegre eder. Başlamak için iletişime geçin.
Sık Sorulan Sorular
Veri kaybı hedefi ile yedekleme sıklığı aynı şey midir?
Aynı değildir. Yedekleme sıklığı bir ayardır, veri kaybı hedefi ise o ayarın sonunda ulaşmak istediğiniz sonuçtur. Sıklık hedefi karşılayacak şekilde seçilir ve hedefin tutup tutmadığı ölçülerek doğrulanmalıdır.
Offsite kopya için ayrı bir hedef yazmak gerekir mi?
Çoğu durumda yazmak doğru olur. Yerel kopya ile uzak kopyanın güncelliği farklıdır. Yerel kopyayı da kaybettiğiniz bir olayda geçerli olan, uzak kopyanın güncelliğidir.
Bulut yedekleme hedefi kendiliğinden karşılar mı?
Karşılamaz. Hedefi yedek sıklığı, aktarım süresi ve hat kapasitesi belirler. Bulut yalnızca kopyanın durduğu yerdir.
Hedefi kim belirlemeli?
Verinin sahibi olan iş birimi kabul edilebilir kaybı söyler. Teknik ekip bunu yedekleme düzenine çevirir ve yapılabilir olup olmadığını bildirir.
Sonuç
Hedef, yazılı bir yedekleme politikasına bağlanmadıkça ve ölçülmedikçe bir dilek olarak kalır. Offsite ve bulut kopyada asıl dikkat edilecek nokta, uzak kopyanın yerel kopyadan geç tamamlandığıdır. Veriyi sınıflara ayırıp her sınıf için hedefi yazın, gecikmeyi izleyin ve geri yüklemeyi deneyin. Ortamınıza uygun düzeni görmek için yedekleme bulutu sayfasına göz atabilirsiniz.
