Yedekleme stratejisi kurmak: neyi, nereye, ne sıklıkla?
Beceri rehberi

Yedekleme stratejisi kurmak: neyi, nereye, ne sıklıkla?

Hazırlayan: Mindset Institute EditörlüğüGüncellendi: 5 dk okuma

Kurumsal yedekleme stratejisi: veri envanteri, kritiklik sınıfı, kopya topolojisi, bulut ve SaaS yedekleri, fidye yazılımına dayanıklılık, kurtarma testleri.

Yedekleme stratejisi neden bir kopya almaktan fazlasıdır?

Yedekleme, verinin kaybolması ya da bozulması durumunda geri getirilebilmesi için ayrı bir kopyasının tutulmasıdır. Ancak kurumsal ortamda mesele kopya almak değil, o kopyadan gerektiğinde, yeterli sürede ve kullanılabilir biçimde geri dönebilmektir. Pek çok kurum yedek aldığını sanır; gerçek bir kurtarma gerektiğinde yedeğin eksik, bozuk, eski ya da erişilemez olduğunu fark eder.

Bu nedenle strateji; hangi verinin korunacağı, ne sıklıkla yedekleneceği, kopyaların nerede tutulacağı, ne kadar süre saklanacağı, kimin erişeceği ve kurtarmanın nasıl test edileceğini kapsayan bütün bir çerçevedir. Teknoloji seçimi bu çerçeveden sonra gelir.

Veri envanteri ve kritiklik sınıflandırması

Önce neyin korunacağı bilinmelidir. Veri envanteri; sunucular, veritabanları, dosya paylaşımları, kullanıcı cihazları, bulut hizmetleri, kurumsal uygulamalar ve SaaS hizmetlerindeki verileri listeler. Her varlık için sahip, konum, veri türü ve hukuki saklama yükümlülükleri belirlenir.

Sonra kritiklik sınıflandırması yapılır. İş açısından hangi sistem durursa ne olur? Her sistem için şu hedefler tanımlanır:

  • Kurtarma noktası hedefi: ne kadar veri kaybı kabul edilebilir, yani son yedekten sonraki kayıp ne kadar olabilir
  • Kurtarma süresi hedefi: sistem ne kadar sürede yeniden çalışır hale gelmelidir

Örneğin sipariş veritabanı için kayıp neredeyse sıfır olmalıyken, arşiv dosya paylaşımı için günlük yedek yeterli olabilir. Hedefler sıkılaştıkça maliyet artar; bu yüzden her şeyi en yüksek seviyede korumak yerine iş etkisine göre katmanlı bir yaklaşım tercih edilir.

3-2-1 kuralı ve kopya topolojisi

Yedekleme tasarımının yaygın referansı 3-2-1 kuralıdır: verinin birden fazla kopyası bulunur (üretim verisi ve ayrı yedekler), bu kopyalar farklı depolama türlerinde tutulur ve kopyalardan biri farklı bir konumda, yani sahadan uzakta durur. Fikir basittir: tek bir arıza, yangın, hırsızlık ya da yazılım hatası tüm kopyaları aynı anda yok edememelidir.

Kural günümüzde fidye yazılımı tehdidine karşı genişletilir: kopyalardan en az biri değiştirilemez ya da çevrimdışı olmalıdır. Saldırgan yedekleme sistemine erişip yedekleri silebilirse, kopya sayısı bir şey ifade etmez. Bu nedenle yedek sistemin yönetim hesapları üretim ortamından ayrılır, çok faktörlü doğrulama kullanılır ve silme işlemlerine gecikme ya da çift onay getirilir. Yerel kopya hızlı kurtarma sağlar, uzak kopya felaket durumunda koruma sağlar; ikisi birbirini tamamlar.

Bulut ve SaaS verilerinin yedeklenmesi

Birçok kurum bulut hizmetindeki verinin hizmet sağlayıcı tarafından yedeklendiğini varsayar. Oysa sağlayıcı genellikle altyapının kullanılabilirliğinden sorumludur; kullanıcının yanlışlıkla sildiği, kötü niyetli bir çalışanın bozduğu veya fidye yazılımının şifrelediği veriyi geri getirmek müşterinin sorumluluğundadır. Bu paylaşılan sorumluluk modeli olarak bilinir.

E-posta, ortak çalışma araçları, müşteri ilişkileri sistemleri ve kod depoları gibi SaaS uygulamaları için ayrı yedekleme çözümleri kullanılır. Bulut sanal makineleri ve veritabanları için sağlayıcının yedekleme hizmetleri yönetilen planlar ve kurallarla kullanılabilir. Çapraz hesap ve çapraz bölge kopyaları, bir hesabın ele geçirilmesi ya da bir bölgenin kesintisi durumunda verinin korunmasını sağlar. Maliyet yönetimi de önemlidir: gereksiz uzun saklama ve gereğinden sık yedek bulutta fatura büyütür.

Fidye yazılımına karşı dayanıklılık

Fidye yazılımı saldırıları artık yedekleri de hedef alır. Saldırgan önce ağa sızar, yedekleme sistemini bulur ve yedekleri silmeye ya da şifrelemeye çalışır, sonra üretim verisini şifreler. Korunmak için birkaç katman kullanılır: değiştirilemez depolama ya da zaman kilidi, çevrimdışı ya da ayrılmış ağdaki kopyalar, yedek altyapıya ayrı kimlik ve yetki, anormal değişiklik izleme.

Kurtarma tarafında da hazırlık gerekir. Temiz bir kurtarma ortamı, bulaşmış sistemlerin yeniden etkinleştirilmemesi için izolasyon prosedürü, kurtarma sırası ve iletişim planı baştan hazırlanır. Yedeğin kendisinin zararlı yazılım içermediğinin doğrulanması gerekir; çok geç fark edilen bir bulaşma, tüm eski yedeklerin de bulaşmış olabileceği anlamına gelir. Bu nedenle saklama süresi, bulaşmanın fark edilme gecikmesi dikkate alınarak belirlenir.

Kurtarma testleri ve tatbikatlar

Test edilmemiş yedek, çalıştığı doğrulanmamış bir varsayımdır. Kurtarma testi; yedekten gerçekten geri dönülebildiğini, verinin bütün olduğunu, süre hedeflerinin tutturulduğunu ve ekibin prosedürü bildiğini gösterir. Testler farklı seviyelerde yapılır: tek dosya geri yükleme, bir sunucunun yeniden kurulması, bir uygulamanın bağımlılıklarıyla birlikte ayağa kaldırılması ve tüm bir sistemin felaket senaryosunda kurtarılması.

Tatbikatlar belgelenir: ne denendi, ne kadar sürdü, hangi sorunlar çıktı, hangi düzeltmeler yapıldı? Bulgular prosedürlere ve yapılandırmaya geri beslenir. Kurtarma kılavuzunun yalnızca sistem yöneticisinin kafasında olması, kritik bir risktir; ekip dışından birinin de adım adım izleyebileceği yazılı kılavuzlar tutulur.

Saklama politikaları, imha ve yönetişim

Yedek ne kadar süre saklanacak? Bu soru iş ihtiyacı, hukuki yükümlülükler ve maliyet arasındaki dengeyle yanıtlanır. Bazı veriler mevzuat gereği belirli süre saklanmalıdır, bazı veriler ise kişisel veri kapsamında olduğu için gereğinden uzun tutulmamalıdır. Saklama politikası veri türüne göre yazılır, sürenin sonunda güvenli imha yapılır ve imha kayıt altına alınır.

Yönetişim; roller, sorumluluklar, onay süreçleri ve raporlamayı kapsar. Yedekleme başarısı, geri yükleme testi sonuçları ve politika ihlalleri düzenli olarak yönetime raporlanır. Denetimlerde yedekleme kayıtlarının gösterilebilmesi gerekebilir. Politika yılda en az bir kez ve büyük sistem değişikliklerinde gözden geçirilir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Konunun hem kurumsal politika hem bulut altyapısı tarafı için katalogda ayrı programlar vardır. Kurumsal Veri Yedekleme Stratejisi ve Saklama Politikaları eğitiminin modül başlıkları veri envanteri ve kritiklik sınıflandırması, yedekleme mimarisi ve kopya topolojisi, bulut ve SaaS verilerinin yedeklenmesi, fidye yazılımı dayanıklılığı, kurtarma testleri ve tatbikatlar ile saklama politikaları, imha ve yönetişimdir.

AWS Backup ile Kurumsal Yedekleme Stratejisi eğitimi ise yedekleme stratejisinin temelleri, plan, kural ve kasa tasarımı, çapraz hesap ve bölge dayanıklılığı, kurtarma işlemleri ve tatbikatlar, uyum, denetim ve raporlama ile maliyet yönetimi ve strateji atölyesi başlıklarını içerir.

İlgili Mindset programı

Kurumsal Veri Yedekleme Stratejisi ve Saklama Politikaları

Sık sorulanlar

Sık sorulan sorular

3-2-1 yedekleme kuralı nedir?

Verinin birden fazla kopyasının bulunması, bu kopyaların farklı depolama ortamlarında tutulması ve bir kopyanın farklı bir konumda saklanması ilkesidir. Amaç tek bir arıza ya da olayın tüm kopyaları yok etmesini önlemektir. Fidye yazılımı döneminde bir kopyanın değiştirilemez ya da çevrimdışı olması da eklenir.

Yedekleme ile arşivleme aynı şey midir?

Hayır. Yedekleme, canlı verinin kaybı durumunda geri dönmek için alınan kopyadır ve kısa-orta vadelidir. Arşivleme, artık aktif kullanılmayan ama saklanması gereken verinin uzun süreli, düşük maliyetli depolanmasıdır. Her ikisinin saklama kuralları ve erişim ihtiyaçları farklıdır.

Bulut sağlayıcısı verimi zaten yedekliyor mu?

Sağlayıcı altyapının dayanıklılığını sağlar, ancak yanlışlıkla silme, kötü niyetli değişiklik ya da fidye yazılımı gibi durumlarda verinizi geri getirmeyi sağlamaz. Bu, paylaşılan sorumluluk modelinin gereğidir. Kritik SaaS ve bulut verileri için ayrı yedek planı gerekir.

Yedekler ne sıklıkla test edilmeli?

Sıklık sistemin kritikliğine bağlıdır. Kritik sistemler için düzenli ve planlı kurtarma testleri yapılmalı, daha düşük öneme sahip veriler için örneklem testi yeterli olabilir. Önemli olan testin gerçekleştirilmesi, sonucunun belgelenmesi ve çıkan sorunların giderilmesidir.

Kurtarma noktası ve kurtarma süresi hedefi ne demektir?

Kurtarma noktası hedefi, bir olayda en fazla ne kadar veri kaybının kabul edilebileceğini, yani yedeğin ne kadar eski olabileceğini gösterir. Kurtarma süresi hedefi ise sistemin ne kadar sürede yeniden hizmet vermesi gerektiğini belirtir. Her sistem için iş etkisine göre ayrı belirlenir.

Kurumsal Veri Yedekleme Stratejisi ve 3-2-1 Kuralı