Backup as a Service

Backup as a Service ile Yedekleme Politikalarınızı Yönetin

Backup as a Service, verinin belirlenmiş politika ve saklama kurallarına göre yedeklenmesini sağlayan yönetilen veri koruma modelidir. Başarısı yalnızca yedeğin alınmasına değil, hedeflenen RPO'nun ölçülmesine ve geri yüklemelerin test edilmesine bağlıdır.

RPO politikasıSaklama planıGeri yükleme testiVeri koruma

Teklif Alın Sizi Arayalım

Yedekleme disiplini

Yedek almak ile kurtarılabilir olmak aynı değildir

Yedekleme raporunda başarılı görünmek, uygulamanın olay sonrası çalışacağı anlamına gelmez. Dosya bütünlüğü, uygulama tutarlılığı, erişim ve geri dönüş süresi ayrıca doğrulanmalıdır.

Kritik sistemler ile arşiv niteliğindeki veriler aynı sınıfa konulmamalıdır. Her veri setinin değişim hızı ve iş etkisi farklıdır; tek tip politika ya aşırı maliyet ya da yetersiz koruma üretir.

BaaS'ın başarısı; politika, saklama, erişim ayrımı ve düzenli restore testlerinin birlikte işletilmesine bağlıdır. Araç seçimi bu disiplinin yalnızca bir parçasıdır.

RPO, kabul edilen veri kaybı penceresidir.
RTO, geri dönüşün tamamlanması için hedeflenen süredir.

Politika bileşenleri

BaaS tasarımında karar verilmesi gerekenler

Teknik ayarlar, iş sürekliliği beklentisinin somut ifadesidir.

Çalışma takvimi

Sıklık veri değişim hızı ve yoğun saatlere göre planlanır. Yedekleme penceresi üretimi boğmamalıdır.

Kapsam seçimi

Sanal makine, dosya ve veritabanı ayrı koruma sınıflarına ayrılır. Hepsi aynı iş kuralına bağlanmamalıdır.

Saklama koruması

Silme yetkileri ve saklama kilidi değerlendirilir. Fidye senaryosunda değiştirilebilir yedek zayıf halkadır.

Test senaryosu

Dosya, uygulama ve tam sistem geri yüklemeleri test edilir. Test edilmeyen yedek varsayımdır.

Off-site kopya

Üretimle aynı ortamda kalan tek kopya yerel olay riskini paylaşır.

Erişim ayrımı

Yedek yönetim yetkisi üretim admin yetkisinden ayrılmalıdır.

BaaS ve DRaaS

Yedekleme ile felaket kurtarma arasındaki sınır

İki hizmet birbirini tamamlar; aynı hedefe hizmet etmez.

BaaS: veri kopyası

Geçmişteki geçerli veriyi tutar ve geri yükleme sağlar.

BaaS: anlık devamlılık

Tek başına alternatif ortamda uygulama çalıştırma taahhüdü vermez.

DRaaS: çalışabilir senaryo

Replikasyon ve runbook ile kritik hizmeti yeniden ayağa kaldırmayı hedefler.

DRaaS: yedek yerine geçer

Uzun saklama için DR tasarımı da yedekleme politikasına ihtiyaç duyar.

Politika olgunluğu

BaaS'ı ölçülebilir bir programa dönüştürün

İlk kurulumdan sonra asıl iş, test ve iyileştirme ritmini kurmaktır.

Veriyi sınıflandırın

Kritik, önemli ve arşiv veri setlerini iş etkisiyle ayırın.

RPO/RTO yazın

Her sınıf için kabul edilen kayıp ve dönüş sürelerini onaylatın.

Saklama katmanlayın

Günlük, haftalık ve aylık kopyaları ihtiyaca göre ayırın.

Restore test edin

Dosya ve uygulama geri yüklemelerini takvime bağlayın.

Erişimi gözden geçirin

Yedek konsolu yetkilerini periyodik olarak denetleyin.

SSS

BaaS — Sıkça sorulan sorular

Karar vermeden önce netleştirmeniz gereken başlıklar.

BaaS için RPO nasıl belirlenir?

Kabul edilen veri kaybı süresi ve uygulamanın veri değişim hızı birlikte değerlendirilir. İş birimi onayı olmadan teknik ekibin tek başına verdiği RPO gerçekçi olmayabilir.

Restore testi ne sıklıkla yapılmalıdır?

Kritiklik, değişiklik sıklığı ve regülasyona bağlı düzenli test takvimi oluşturulmalıdır. En kritik sistemlerde daha sık, arşiv sınıfında daha seyrek test planlanabilir.

BaaS fidye yazılımına karşı koruma sağlar mı?

Saklama, erişim ayrımı ve değiştirilemezlik doğru kurgulandığında etkili bir koruma katmanı sağlar. Tek başına antivirüs yerine geçmez.

Snapshot ile BaaS farkı nedir?

Snapshot genelde aynı ortamda hızlı geri dönüş içindir; BaaS politika, saklama ve bağımsız kopya odaklıdır. İkisi tamamlayıcı olabilir, birbirinin yerine geçmez.

Hangi veriler önce korunmalı?

Gelir, müşteri hizmeti, yasal zorunluluk ve geri dönülemez veri kaybı riski yüksek sistemler önceliklidir.

Saklama süresi ne kadar olmalı?

İş ihtiyacı, yasal yükümlülük ve depolama maliyeti dengelenerek belirlenir. Sonsuz saklama çoğu zaman gerekli değildir.

Uygulama tutarlı yedek neden önemli?

Açık dosya ve veritabanı işlemleri sırasında alınan tutarsız kopya geri yüklemede bozulmaya yol açabilir.

Yedekler şifrelenmeli midir?

Hassas veri içeren yedeklerde şifreleme ve anahtar yönetimi önerilir. Anahtarın yedekle aynı risk alanında tutulmaması gerekir.

Başarısız yedek işi nasıl yönetilir?

Alarm, sahiplik ve yeniden çalıştırma prosedürü tanımlanmalıdır. Sessiz başarısızlık en tehlikeli senaryodur.

Bulut ve fiziksel sistemler aynı politikada mı?

Aynı çerçevede yönetilebilir; ancak ajan, tutarlılık ve ağ gereksinimleri platforma göre ayrışır.

BaaS maliyeti nasıl optimize edilir?

Veri sınıflandırma, gereksiz tam kopyaların azaltılması ve saklama katmanlarıyla optimize edilir.

Kimler yedek silebilir?

Üretim yöneticileri ile yedek yöneticileri ayrılmalı; kritik silme işlemleri ek onaya bağlanmalıdır.

DRaaS'a ne zaman geçilir?

Yalnız veri geri yüklemek yetmiyor, kritik uygulamanın alternatif ortamda çalışması gerekiyorsa DRaaS değerlendirilir.

Teklif formu