ERETEK
BİLGİ SİSTEMLERİ
VERİ KORUMA VE SÜREKLİLİK

Yedekleme ve Felaket Kurtarma

Yedekleme işi başarılı görünse bile veri ve sistemlerin geri döndürülebileceği kanıtlanmamış olabilir. Kurtarma noktası, geri dönüş süresi, saklama politikası ve izole kopyalar birlikte tasarlanmalıdır.

HİZMET ODAĞI
Yedek almak kadar geri dönebilmek de önemlidir
Veeam
RPO / RTO
3-2-1-1-0
Kurtarma testi

Somut hedefler · Belgeli çalışma · Kontrollü uygulama

NE ZAMAN GEREKLİ?

Yedek alınıyor ama geri dönüş hiç denenmediyse.

Aşağıdaki durumlar, yedekleme yapısının RPO ve RTO hedeflerine göre yeniden değerlendirilmesi gerektiğini gösterir.

01 / DURUM

Tek kopya riski

Yedeklerin tamamı aynı sistemde veya aynı erişim alanındaysa.

02 / DURUM

Test edilmemiş kurtarma

Düzenli geri yükleme testi ve sorumluluk planı yoksa.

03 / DURUM

Belirsiz saklama

Saklama süreleri ve kritik veri öncelikleri iş gereksinimleriyle eşleşmiyorsa.

HİZMET KAPSAMI

Veri korumada ele aldığımız dört alan.

Kapsamı yazılıma göre değil; her sistemin kabul edilebilir veri kaybı (RPO), geri dönüş süresi (RTO) ve fidye yazılımı riskine göre belirleriz.

01

Koruma kapsamı

VM, dosya, veritabanı, yapılandırma ve bulut iş yüklerinin sınıflandırılması.

02

Yedek mimarisi

Bağımsız kopya, çevrimdışı/immutable seçenekleri, ağ ayrımı ve erişim kontrolü.

03

Kurtarma planlaması

Servis bağımlılık sırası, kurtarma hedefleri ve alternatif çalışma senaryoları.

04

Doğrulama

Dosya, VM ve uygulama seviyesinde kontrollü geri yükleme testleri.

MÜHENDİSLİK YAKLAŞIMI

Yedekleme başarı oranı, kurtarma garantisi değildir.

RPO ve RTO hedefleri uygulamanın iş etkisine göre belirlenir. Dosya, sanal makine, veritabanı ve bulut servisleri farklı kurtarma yöntemleri gerektirebilir.

KARAR NOKTASI
Önce RPO ve RTO. Sonra mimari. Ardından test edilmiş geri dönüş.

Yatırım ve değişiklik kararları mümkün olduğunda ölçüm, bağımlılık analizi ve geri dönüş senaryosu ile desteklenmelidir.

RPO VE RTO

Her sistem aynı korumayı gerektirmez.

Muhasebe veritabanında bir saatlik veri kaybı ciddi bir sorunken, arşiv klasöründe bir günlük kayıp çoğu zaman kabul edilebilir. Hedefleri sistem bazında belirlemek maliyeti ve yedekleme penceresini doğru kurmayı sağlar.

Sistem
Örnek RPO
Örnek RTO
Yöntem
ERP / muhasebe veritabanı
Örnek RPO

15 dk – 1 saat

Örnek RTO

Birkaç saat

Yöntem

Sık aralıklı yedek, işlem günlüğü yedekleri; gerekirse replikasyon

Dosya sunucusu
Örnek RPO

24 saat

Örnek RTO

1 iş günü

Yöntem

Gecelik yedek ve gün içi gölge kopyalar (VSS)

Etki alanı denetleyicisi
Örnek RPO

24 saat

Örnek RTO

Birkaç saat

Yöntem

Gecelik sistem durumu yedeği ve ikinci denetleyiciyle yedeklilik

Microsoft 365 posta ve dosyalar
Örnek RPO

24 saat

Örnek RTO

Öğe bazında kısa

Yöntem

Saklama ilkeleri ve ayrı bir bulut yedeği

Tablodaki değerler örnektir. Gerçek hedefler, sistemin durmasının işe maliyeti konuşularak iş birimleriyle birlikte belirlenir.

ÇALIŞMA MODELİ

Yedekten kurtarma planına uzanan sıralı süreç.

Her aşama bir sonraki adımın kapsamını netleştirir. Planlanan değişiklikler kabul ve doğrulama kriterleriyle ilerler.

01 / AŞAMA

Kritiklik

Sistemlerin iş etkisi ve veri kaybı toleransını sınıflandırırız.

02 / AŞAMA

Tasarım

Kopya yerleşimi, saklama ve güvenlik politikalarını belirleriz.

03 / AŞAMA

Uygulama

İş yüklerine uygun yedekleme işlerini yapılandırırız.

04 / AŞAMA

Test

Seçilmiş senaryolarda kurtarma süresini ve veri bütünlüğünü doğrularız.

SOMUT ÇIKTILAR

Veri koruma çalışmasının sonunda neler hazır olur?

Yedekleme politikası, saklama süreleri, değiştirilemez kopya yapısı ve geri yükleme test kayıtları, felaket anında kimin ne yapacağını netleştirir.

01
RPO/RTO ve kritiklik matrisi
02
Yedekleme kapsamı ve saklama politikası
03
Kurtarma sırası ve runbook
04
Test kaydı ve iyileştirme bulguları
SIK SORULANLAR

Yedekleme ve felaket kurtarma hakkında sık sorulanlar.

Birden fazla kopya, farklı medya, ayrı konum, en az bir izole/immutable kopya ve doğrulanmış hata kontrolü yaklaşımını tarif eder.

Hayır. Ağ, kimlik, uygulama bağımlılıkları, sorumlular ve test edilmiş kurtarma prosedürleri ayrıca gerekir.

Tek başına sayılmaz. Etki alanı hesabıyla erişilebilen ve sürekli bağlı duran bir NAS, fidye yazılımı için kolay bir hedeftir. NAS yedek deposu olarak kullanılabilir; ancak ayrı kimlik bilgileri, anlık görüntü koruması ve bina dışındaki ek bir kopyayla birlikte.

Microsoft altyapının çalışmasından sorumludur; verinin uzun süreli geri getirilebilirliği büyük ölçüde müşterinin yapılandırmasına kalır. İhtiyaç duyduğunuz geri dönüş süresi saklama ilkelerinin karşılayabileceğinden uzunsa ayrı bir Microsoft 365 yedeği öneriyoruz.

İkisi birbirinin alternatifi değil, tamamlayıcısıdır. Hızlı geri dönüş için yerel kopya, bina dışı koruma için bulut ya da ikinci lokasyon kullanılır. Bulut deposundaki verinin internet hattından ne kadar sürede geri indirilebileceği de RTO hesabına girmelidir.

BİRLİKTE PLANLAYALIM

Yedeklerinizin gerçekten geri dönüp dönmediğini birlikte test edelim.

Kritik sistemlerinizi, kabul edilebilir kesinti sürelerini ve mevcut yedek yapınızı konuşarak test edilebilir bir kurtarma planı oluşturalım.