Veri Yedekleme Stratejisi: Şirketler İçin 9 Kritik Kural

Veri Yedekleme Stratejisi, şirketlerin siber saldırı, donanım arızası, kullanıcı hatası, yazılım problemi veya doğal afet sonrasında kritik bilgilerini geri kazanabilmesini sağlayan planlı bir süreçtir.

Yalnızca dosyaları başka bir diske kopyalamak gerçek bir yedekleme planı oluşturmaz. Yedeklerin ne sıklıkla alınacağı, nerede saklanacağı, kimlerin erişebileceği, ne kadar süre korunacağı ve gerektiğinde nasıl geri yükleneceği önceden belirlenmelidir.

Etkili bir Veri Yedekleme Stratejisi, şirketin yalnızca verilerini değil; operasyonlarını, müşteri güvenini, gelir akışını ve yasal sorumluluklarını da korur. Kullanılamayan veya hiç test edilmemiş bir yedek, kriz anında şirkete beklenen faydayı sağlamaz.

Bu rehberde şirketlerin uygulayabileceği dokuz kritik yedekleme kuralını, 3-2-1 yaklaşımını, RPO ve RTO kavramlarını, fidye yazılımlarına karşı alınabilecek önlemleri ve kurtarma testlerinin nasıl planlanacağını inceleyeceğiz.

Veri Yedekleme Stratejisi Neden Önemlidir?

Şirket verileri; müşteri kayıtlarını, muhasebe belgelerini, sözleşmeleri, e-posta kutularını, üretim bilgilerini, insan kaynakları dosyalarını ve uygulama veritabanlarını içerebilir. Bu kayıtların kaybolması, iş süreçlerinin tamamen durmasına neden olabilir.

Veri kaybına yol açabilecek başlıca durumlar şunlardır:

• Fidye yazılımı ve kötü amaçlı yazılım saldırıları,
• Disk veya sunucu arızaları,
• Yanlışlıkla dosya silinmesi,
• Yetkisiz kullanıcı işlemleri,
• Yazılım güncelleme hataları,
• Bulut hesabının ele geçirilmesi,
• Yangın, su baskını veya elektrik problemi,
• Cihaz kaybı veya hırsızlık,
• Veritabanı bozulması,
• Hatalı senkronizasyon işlemleri.

ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı CISA, önemli verilerin düzenli biçimde yedeklenmesini ve çevrimdışı ya da ayrı ortamlarda korunan kopyaların kullanılmasını fidye yazılımlarına karşı temel önlemler arasında gösterir.

Şirketlerin veri korumasını daha geniş bir güvenlik yaklaşımıyla ele alması gerekir. Konuyla ilgili olarak Dijital Dönüşüm Sürecinde Proaktif Siber Güvenlik başlıklı içeriğimizi de inceleyebilirsiniz.

Veri Yedekleme Stratejisi İçin 9 Kritik Kural

1. Kritik Verileri ve Sistemleri Belirleyin

Her verinin iş açısından aynı değere sahip olduğu düşünülmemelidir. Yedekleme planı hazırlanırken öncelikle hangi sistemlerin şirket faaliyetleri için kritik olduğu belirlenmelidir.

Envantere alınabilecek veri ve sistemler şunlardır:

• Müşteri ve kullanıcı veritabanları,
• Finans ve muhasebe kayıtları,
• ERP ve CRM sistemleri,
• Kurumsal e-posta kutuları,
• İnsan kaynakları belgeleri,
• Web sitesi ve e-ticaret verileri,
• Kaynak kodları ve proje dosyaları,
• Sözleşmeler ve hukuki belgeler,
• Sistem yapılandırmaları,
• Sanal makineler ve uygulama sunucuları.

Her veri grubu için bir iş sahibi ve teknik sorumlu belirlenmelidir. Böylece hangi verinin neden korunduğu ve kurtarma sırasında kimin karar vereceği açık hale gelir.

2. Veri Yedekleme Stratejisi İçin 3-2-1 Kuralını Uygulayın

3-2-1 yaklaşımı, yedekleme planlamasında sık kullanılan temel bir yöntemdir:

• 3 kopya: Orijinal veriyle birlikte en az üç veri kopyası bulundurun.
• 2 farklı ortam: Kopyaları iki farklı depolama türünde saklayın.
• 1 uzak kopya: En az bir kopyayı ana sistemden fiziksel veya mantıksal olarak ayrı tutun.

Örneğin şirketin canlı verisi ana sunucuda, ikinci kopyası yerel bir yedekleme cihazında ve üçüncü kopyası güvenli bir bulut ortamında saklanabilir.

Aynı sunucu üzerindeki farklı bir klasör yedek sayılmamalıdır. Sunucu bozulduğunda, ele geçirildiğinde veya şifrelendiğinde bu klasör de kullanılamaz hale gelebilir.

3. Çevrimdışı veya Değiştirilemez Bir Kopya Bulundurun

Fidye yazılımları yalnızca canlı sistemleri değil, ağa bağlı yedekleme alanlarını da hedefleyebilir. Bu nedenle en az bir yedek kopyasının saldırıya uğrayan kullanıcı hesabından veya ağdan erişilememesi gerekir.

Kullanılabilecek yöntemler şunlardır:

• İşlem tamamlandıktan sonra bağlantısı kesilen harici depolama,
• Yazma korumalı yedekler,
• Değiştirilemez nesne depolama,
• Ayrı kullanıcı ve yönetici hesapları,
• Farklı bir bulut hesabında tutulan yedekler,
• Ayrı ağ segmentindeki yedekleme sistemi.

CISA, harici yedekleme cihazlarının aktif yedekleme yapılmadığı zamanlarda sürekli bağlı bırakılmamasını önerir. Ağa bağlı kalan bir cihaz, fidye yazılımı tarafından silinebilir veya şifrelenebilir.

4. RPO ve RTO Hedeflerini Belirleyin

Başarılı bir Veri Yedekleme Stratejisi, yalnızca verinin korunup korunmadığını değil, şirketin ne kadar veri kaybını ve ne kadar kesintiyi kabul edebileceğini de belirlemelidir.

RPO nedir?

RPO, yani Kurtarma Noktası Hedefi, kabul edilebilir en fazla veri kaybı süresini ifade eder.

Örneğin RPO iki saat olarak belirlenmişse şirket, bir olay sonrasında en fazla son iki saatlik veriyi kaybetmeyi kabul ediyor demektir. Bu hedef, yedekleme sıklığını doğrudan etkiler.

RTO nedir?

RTO, yani Kurtarma Süresi Hedefi, bir sistemin kesinti sonrasında ne kadar sürede yeniden çalışır hale getirilmesi gerektiğini belirtir.

Örneğin bir e-ticaret sistemi için RTO dört saat olarak belirlenmişse sistemin en geç dört saat içinde tekrar hizmet vermesi hedeflenir.

Tablodaki süreler yalnızca örnektir. Gerçek hedefler şirketin iş modeli, müşteri yükümlülükleri ve teknik kapasitesi dikkate alınarak belirlenmelidir.

5. Yedekleme Sıklığını Veri Değişimine Göre Planlayın

Tüm sistemleri günde bir kez yedeklemek her şirket için yeterli olmayabilir. Yedekleme sıklığı, verinin ne kadar hızlı değiştiğine ve kaybının yaratacağı etkiye göre belirlenmelidir.

Örnek bir plan şöyle olabilir:

• Kritik veritabanları için 15 dakikalık işlem günlüğü yedekleri,
• Uygulama sunucuları için günlük artımlı yedekleme,
• Haftalık tam sistem yedeği,
• Aylık arşiv kopyası,
• Önemli güncellemelerden önce sistem anlık görüntüsü,
• Yıllık uzun süreli saklama kopyası.

Yedekleme programı hazırlanırken depolama kapasitesi, ağ kullanımı ve sistem performansı da değerlendirilmelidir.

6. Yedekleri Şifreleyin ve Erişimleri Sınırlandırın

Yedeklerin içinde canlı sistemlerde bulunan kişisel, ticari ve finansal verilerin kopyaları yer alır. Bu nedenle yedekleme alanları en az üretim sistemleri kadar güçlü biçimde korunmalıdır.

Alınabilecek güvenlik önlemleri:

• Aktarım sırasında şifreleme,
• Depolama sırasında şifreleme,
• Çok faktörlü kimlik doğrulama,
• Rol bazlı erişim yetkilendirmesi,
• Ayrı yedekleme yönetici hesapları,
• Erişim kayıtlarının tutulması,
• Şifreleme anahtarlarının güvenli saklanması,
• Düzenli yetki kontrolleri.

Bir çalışanın günlük hesabıyla hem canlı verileri hem de tüm yedekleri silebilmesi ciddi güvenlik riski oluşturur. Yedekleme yönetimi için farklı ve sınırlı hesaplar kullanılmalıdır.

7. Yedeklerin Bütünlüğünü Otomatik Olarak Kontrol Edin

Yedekleme yazılımında işlemin “başarılı” görünmesi, yedeğin gerçekten kullanılabilir olduğu anlamına gelmez. Dosya bozulması, eksik veri, yanlış yapılandırma veya kapasite problemi nedeniyle kurtarma başarısız olabilir.

Kontrol edilmesi gerekenler:

• Yedekleme işinin tamamlanma durumu,
• Kopyalanan veri miktarı,
• Dosya ve veritabanı bütünlüğü,
• Şifre çözme anahtarlarının çalışması,
• Yedekleme alanının kapasitesi,
• Başarısız işlerin oluşturduğu uyarılar,
• Beklenmeyen veri değişiklikleri,
• Kötü amaçlı yazılım belirtileri.

Başarısız yedekleme bildirimleri yalnızca teknik ekibin görmediği bir posta kutusuna gönderilmemelidir. Alarmın sorumlusu ve müdahale süresi önceden belirlenmelidir.

8. Düzenli Kurtarma Testleri Yapın

Veri Yedekleme Stratejisi içindeki en kritik adımlardan biri geri yükleme testidir. Bir yedeğin değeri, ancak veriler başarıyla geri getirilebildiğinde anlaşılır.

Kurtarma testleri şu seviyelerde yapılabilir:

• Tek bir dosyanın geri yüklenmesi,
• Bir kullanıcının posta kutusunun kurtarılması,
• Veritabanının test ortamında açılması,
• Sanal makinenin tamamen geri yüklenmesi,
• Uygulamanın bağımlılıklarıyla birlikte çalıştırılması,
• Felaket kurtarma ortamına tam geçiş yapılması.

NIST, yedeklerin yalnızca oluşturulmasını değil, düzenli olarak test edilmesini ve kurtarma tatbikatları sırasında değerlendirilmesini etkili yedekleme yönetiminin temel unsurları arasında gösterir.

Test sonucunda gerçek kurtarma süresi ölçülmeli ve belirlenen RTO hedefiyle karşılaştırılmalıdır. Başarısızlıklar belgelenmeli ve düzeltici faaliyetler atanmalıdır.

9. Sorumlulukları ve Olay Planını Yazılı Hale Getirin

Kriz sırasında kimin hangi işlemi yapacağı belli değilse teknik olarak sağlam yedekler bile zamanında kullanılamayabilir.

Yedekleme ve kurtarma planında şu bilgiler bulunmalıdır:

• Yedekleme sisteminin sahibi,
• Teknik yönetici ve yedek sorumlusu,
• Kurtarma kararını verecek yönetici,
• Sistemlerin geri yükleme sırası,
• Hizmet sağlayıcı iletişim bilgileri,
• Şifreleme anahtarlarına erişim yöntemi,
• Olay bildirim ve iletişim süreci,
• Test takvimi,
• Yedek saklama ve silme süreleri.

Plan yalnızca dijital sistemde tutulmamalıdır. Ana sistemlere erişilemediği durumlarda kullanılabilecek güvenli bir çevrimdışı kopya da hazırlanmalıdır.

Veri Yedekleme Stratejisi ile Felaket Kurtarma Arasındaki Fark

Yedekleme ve felaket kurtarma birbiriyle bağlantılı olsa da aynı şey değildir.

Bir şirket tüm dosyalarını geri getirebilse bile uygulama sunucuları, kullanıcı hesapları, ağ bağlantıları veya dış hizmetler çalışmıyorsa operasyon başlayamayabilir.

Tam, Artımlı ve Diferansiyel Yedekleme Nedir?

Tam yedekleme

Seçilen tüm verilerin yeniden kopyalanmasıdır. Kurtarma süreci genellikle daha basittir ancak daha fazla depolama alanı ve zaman gerektirir.

Artımlı yedekleme

Son gerçekleştirilen yedeklemeden sonra değişen veriler kopyalanır. Daha hızlıdır ve daha az alan kullanır. Kurtarma sırasında tam yedekle birlikte birden fazla artımlı kopyaya ihtiyaç duyulabilir.

Diferansiyel yedekleme

Son tam yedeklemeden sonra değişen bütün veriler kopyalanır. Artımlı yönteme göre daha fazla alan kullanabilir ancak geri yükleme süreci daha kolay olabilir.

Bulut Yedekleme Tek Başına Yeterli midir?

Bulut yedekleme; ölçeklenebilirlik, uzak konumda saklama ve otomasyon avantajı sunar. Ancak yalnızca bulut kullanmak bütün riskleri ortadan kaldırmaz.

Dikkat edilmesi gereken noktalar:

• Ana bulut hesabı ele geçirilirse yedekler de etkilenebilir.
• Yanlış senkronizasyon silinen dosyaları diğer ortamlardan da kaldırabilir.
• Geri yükleme sırasında internet bağlantısı sınırlayıcı olabilir.
• Veri çıkış ve kurtarma ücretleri oluşabilir.
• Saklama bölgesi ve mevzuat şartları değerlendirilmelidir.
• Hizmet sağlayıcının sorumluluğu ile müşterinin sorumluluğu ayrılmalıdır.

Bulut depolama ile dosya senkronizasyonu aynı hizmet değildir. Bir dosyanın cihazlar arasında otomatik senkronize edilmesi, bağımsız ve güvenli bir yedek bulunduğu anlamına gelmeyebilir.

Şirketlerin bulut altyapısını maliyet açısından da düzenli değerlendirmesi gerekir. Bu konuda Bulut Maliyetlerini Düşürme: 10 Etkili Yöntem rehberimize göz atabilirsiniz.

Yedekler Ne Kadar Süre Saklanmalıdır?

Saklama süresi; verinin türüne, iş ihtiyacına, sözleşmelere ve yasal yükümlülüklere göre belirlenmelidir.

Örnek bir saklama planı:

• Günlük yedekleri 30 gün,
• Haftalık yedekleri 12 hafta,
• Aylık yedekleri 12 ay,
• Yıllık arşivleri ihtiyaç ve mevzuata göre daha uzun süre korumak.

Bu süreler her şirket için doğrudan uygulanmamalıdır. Gereğinden uzun saklama; depolama maliyeti, kişisel veri riski ve yönetim yükü oluşturabilir.

Veri Yedekleme Stratejisinde Sık Yapılan Hatalar

• Yedekleri canlı sistemle aynı cihazda tutmak,
• Harici diski sürekli bilgisayara bağlı bırakmak,
• Yalnızca dosya senkronizasyonuna güvenmek,
• Geri yükleme testi yapmamak,
• Başarısız yedekleme bildirimlerini kontrol etmemek,
• Yedek hesaplarında çok faktörlü doğrulama kullanmamak,
• Şifreleme anahtarlarını yedeklememek,
• Eski ve gereksiz verileri süresiz saklamak,
• RPO ve RTO hedeflerini belirlememek,
• Kurtarma sırasını dokümante etmemek.

Veri Yedekleme Stratejisi Kontrol Listesi

Güvenilir Veri Yedekleme Kaynakları

• CISA StopRansomware Rehberi
• NIST Yedekleri Koruma ve Test Etme Rehberi
• NIST Veri Bütünlüğü ve Fidye Yazılımı Rehberi

Sık Sorulan Sorular

Veri Yedekleme Stratejisi nedir?

Veri Yedekleme Stratejisi, kritik verilerin hangi sıklıkta, hangi yöntemle, nerede ve ne kadar süreyle korunacağını; gerektiğinde nasıl geri yükleneceğini belirleyen plandır.

3-2-1 yedekleme kuralı nedir?

Verinin toplam üç kopyasının, iki farklı depolama ortamında tutulmasını ve bir kopyanın ana sistemden ayrı bir yerde saklanmasını ifade eder.

Harici disk yedekleme için yeterli midir?

Tek başına yeterli değildir. Disk bozulabilir, kaybolabilir veya sürekli bağlıysa fidye yazılımından etkilenebilir. Başka bir uzak veya çevrimdışı kopya da bulunmalıdır.

Bulut depolama yedek sayılır mı?

Bağımsız sürüm geçmişi, saklama politikası ve geri yükleme özelliği sunuyorsa yedekleme çözümünün bir parçası olabilir. Yalnızca dosya senkronizasyonu kullanmak yeterli olmayabilir.

Yedekleme ne sıklıkla yapılmalıdır?

Sıklık, kabul edilebilir veri kaybı süresine göre belirlenir. Kritik veritabanları birkaç dakikada bir, daha az değişen dosyalar günlük veya haftalık yedeklenebilir.

Yedekler ne sıklıkla test edilmelidir?

Kritik sistemler düzenli aralıklarla ve önemli altyapı değişikliklerinden sonra test edilmelidir. Yılda bir kez yapılan test, yüksek öneme sahip sistemler için yetersiz kalabilir.

Yedekleme fidye yazılımını engeller mi?

Yedekleme saldırının gerçekleşmesini engellemez ancak güvenli, izole ve test edilmiş kopyalar şirketin verilerini geri kazanmasına yardımcı olur.

RPO ile RTO arasındaki fark nedir?

RPO kabul edilebilir veri kaybı süresini, RTO ise sistemin yeniden çalıştırılması için hedeflenen en uzun süreyi ifade eder.

Veri Yedekleme Stratejisi: Sonuç

Veri Yedekleme Stratejisi, şirketlerin yalnızca dosyalarını değil, iş sürekliliğini ve kurumsal itibarını da korur. Kritik verileri belirlemek, 3-2-1 yaklaşımını uygulamak ve çevrimdışı bir kopya bulundurmak güçlü bir başlangıç sağlar.

Ancak yedek almak tek başına yeterli değildir. Yedeklerin şifrelenmesi, erişimlerin sınırlandırılması, bütünlük kontrollerinin yapılması ve düzenli geri yükleme testlerinin gerçekleştirilmesi gerekir.

Başarılı bir Veri Yedekleme Stratejisi, şirketin gerçek RPO ve RTO ihtiyaçlarına dayanmalı; sorumlular, saklama süreleri ve kurtarma sırası yazılı olarak belirlenmelidir. Kriz yaşanmadan önce test edilen bir plan, veri kaybı sonrasında hızlı ve kontrollü hareket edilmesini sağlar.