Yedekleme Stratejisi Nedir?
Yedekleme stratejisi; hangi veri ve sistemlerin, hangi sıklıkta, kaç kopya halinde, nerede ve ne kadar süre saklanacağını; hata durumunda kimin bilgilendirileceğini ve geri yüklemenin nasıl test edileceğini belirleyen iş sürekliliği planıdır. RAID, senkronizasyon veya tek bir bulut kopyası tek başına yedekleme stratejisi değildir.
Plan, veri ve uygulama envanteriyle başlar
Önce kurumun çalışması için gerekli veri kaynakları çıkarılır: dosya sunucuları, veritabanları, sanal makineler, iş uygulamaları, Microsoft 365 verileri, cihaz konfigürasyonları ve üçüncü taraf sistemler. Verinin sahibi, günlük değişim miktarı, toplam hacmi, hassasiyet seviyesi ve uygulamaya bağımlılığı kaydedilir.
Her sistem aynı sıklıkta yedeklenmek zorunda değildir. Gün içinde sürekli değişen sipariş veritabanı ile ayda birkaç kez güncellenen arşivin veri kaybı toleransı farklıdır. RPO kabul edilebilir veri kaybını, RTO ise hizmetin yeniden çalışması için hedeflenen süreyi tanımlar; yöntem ve bütçe bu hedeflere göre belirlenir.
- İş verisi
- Veritabanı, dosya, e-posta ve uygulama verileri; sahibi ve kritikliğiyle birlikte sınıflandırılır.
- Sistem bileşenleri
- Sanal makine, işletim sistemi, uygulama ayarı, lisans ve cihaz konfigürasyonları belirlenir.
- Bağımlılıklar
- Uygulamanın çalışması için gereken veritabanı, kimlik, DNS, ağ ve üçüncü taraf servisleri kaydedilir.
- RPO ve RTO
- Kabul edilebilir veri kaybı ile hedeflenen geri dönüş süresi iş birimiyle onaylanır.
Kopya ile yedek arasındaki fark geri dönüşte ortaya çıkar
Senkronizasyon, dosyaları iki konumda eşitleyebilir; ancak silinen veya şifrelenen dosya diğer konuma da yansıyabilir. RAID ise disk arızasına karşı erişilebilirlik sağlar fakat yanlış silme, fidye yazılımı, işletim sistemi bozulması veya cihazın fiziksel kaybına karşı geçmiş sürüm sunmaz.
3-2-1 yaklaşımı, verinin üretim kopyasıyla birlikte en az üç kopyasının, iki farklı ortamda ve bir kopyasının farklı konumda tutulmasını hedefler. Risk düzeyi yüksek sistemlerde çevrimdışı veya değiştirilemez kopya eklenerek yedeklerin yönetici hesabı ele geçirilse bile silinmesi ya da şifrelenmesi zorlaştırılır.
- Üretim sisteminden bağımsız en az bir yedek kopya
- Farklı cihaz, ortam veya depolama teknolojisi kullanımı
- Farklı lokasyonda veya güvenilir nesne depolamada ek kopya
- Kritik sistemler için çevrimdışı ya da değiştirilemez saklama
- Yedek yönetim hesaplarında MFA ve en az yetki ilkesi
Saklama, şifreleme ve erişim politikası açık olmalıdır
Saklama süresi yalnızca depolama kotasına göre belirlenmez. Günlük, haftalık, aylık ve gerekiyorsa yıllık geri dönüş noktaları; iş ihtiyacı, mevzuat, sözleşme ve olayın fark edilme süresi dikkate alınarak planlanır. Çok kısa saklama süresi geç fark edilen veri bozulmasını kapsamayabilir; gereksiz uzun saklama ise maliyet ve veri koruma yükü oluşturur.
Yedekler aktarım sırasında ve depolamada şifrelenmeli, erişim ayrı hesaplarla sınırlandırılmalı ve işlem kayıtları tutulmalıdır. Şifreleme anahtarı veya kurtarma parolası yedek sistemden bağımsız ve yetkili kişilerce erişilebilir biçimde saklanmalıdır; aksi halde sağlam yedek geri yüklenemeyebilir.
- Saklama katmanları
- Günlük, haftalık ve aylık noktalar veri değişim hızı ve olayın fark edilme süresine göre belirlenir.
- Şifreleme
- Aktarım ve depolama şifrelemesi kullanılır; anahtar sorumluluğu ve kurtarma yöntemi tanımlanır.
- Erişim
- Yedek yöneticileri, operatörleri ve rapor kullanıcıları için ayrı ve sınırlı yetkiler uygulanır.
- Müşteri sahipliği
- Hizmet kapsamına göre yedeklerin konumu, erişim hakkı ve hizmet sona erdiğinde teslim yöntemi yazılı hale getirilir.
İzlenmeyen ve geri yüklenmeyen yedek doğrulanmış sayılmaz
Başarılı görünen bir görev, hedef depolamaya eksik veri yazmış veya uygulamayla tutarsız bir veritabanı kopyası oluşturmuş olabilir. Görev sonucu, yedek boyutu, son başarılı tarih, değişen veri miktarı ve depolama kapasitesi izlenmeli; hata ve gecikmeler sorumlu kişilere bildirilmelidir.
Geri yükleme testleri önceden belirlenen aralıklarla yalıtılmış bir ortamda yapılır. Dosyanın açılması, veritabanının tutarlı biçimde başlatılması, uygulamanın bağımlılıklarıyla çalışması ve hedef RTO içinde hizmete dönmesi kontrol edilir. Test sonucu ve eksikler raporlanarak yedekleme planı güncellenir.
- Günlük görev sonucu ve son başarılı yedek zamanının izlenmesi
- Beklenmeyen boyut düşüşü ve kapasite doluluğu için alarm kurulması
- Düzenli dosya, veritabanı ve tam sistem geri yükleme testleri
- RPO ve RTO hedefleriyle gerçekleşen sürenin karşılaştırılması
- Test bulgularına göre saklama ve işlem adımlarının güncellenmesi
- Yetkili kişilere anlaşılır durum raporu sunulması
Sık Sorulan Sorular
RAID yedekleme yerine geçer mi?
Hayır. RAID bir veya bazı disk arızalarında sistemin çalışmaya devam etmesine yardımcı olur. Silme, fidye yazılımı, dosya bozulması, cihaz kaybı ve geçmiş bir tarihe dönüş için üretim sisteminden bağımsız yedek kopyalar gerekir.
Buluta senkronize edilen dosyalar yedek sayılır mı?
Sürümleme, saklama ve bağımsız erişim koruması yoksa senkronizasyon tek başına yeterli değildir. Silme veya şifreleme diğer kopyaya yansıyabilir. Kullanılan hizmetin sürüm geçmişi, değiştirilemezlik ve geri yükleme özellikleri doğrulanmalıdır.
Yedekleme ne sıklıkta yapılmalıdır?
Sıklık, iş biriminin kabul ettiği veri kaybı süresine yani RPO’ya göre belirlenir. Kritik veritabanlarında daha sık, az değişen arşivlerde daha seyrek işlem uygun olabilir. Tek bir günlük program tüm sistemlere uygulanmamalıdır.
Geri yükleme testi ne kadar sık yapılmalıdır?
Sıklık sistemin kritikliği, değişiklik hızı ve denetim gereksinimine bağlıdır. Kritik sistemlerde planlı ve düzenli test; büyük uygulama, altyapı veya sürüm değişikliklerinden sonra ise ek test yapılmalıdır. Sonuçlar kayıt altına alınmalıdır.
Değiştirilemez yedek nedir?
Belirlenen saklama süresi boyunca değiştirilemeyen veya silinemeyen yedek kopyadır. Yönetici hesabının ele geçirilmesi ve fidye yazılımı gibi olaylarda yedeğin saldırgan tarafından silinmesini zorlaştırır; yine de erişim, izleme ve geri yükleme testlerinin yerini tutmaz.
Microsoft 365 verileri ayrıca yedeklenmeli midir?
İhtiyaç; silme, saklama, hukuk, geri dönüş süresi ve veri sahipliği beklentilerine göre değerlendirilmelidir. Hizmet sürekliliği ile kurumun istediği geçmiş sürüm ve bağımsız geri yükleme kapsamı aynı şey değildir. Politika iş gereksinimiyle yazılı hale getirilmelidir.
Biga Bilişim teknik ekibi tarafından gözden geçirilmiştir.
Teknik Değerlendirme İçin Bize Ulaşın
Veri kaynaklarınızı, mevcut kopyaları, saklama ihtiyacını ve geri dönüş hedeflerini birlikte inceleyerek denetlenebilir bir yedekleme planı hazırlayalım.