Bir klasörü NAS’a kopyalamak, bulut senkronizasyonunu açmak veya sunucuda RAID kullanmak sıkça “yedek aldık” diye yorumlanır. Oysa aynı kullanıcı hesabının erişebildiği, aynı fidye yazılımının şifreleyebildiği ya da aynı yangında kaybolabilecek kopyalar gerçek bir kurtarma planı oluşturmaz. Yedeklemenin başarısı, dosyanın bir yerde görünmesiyle değil; ihtiyaç anında doğru sürümün kabul edilebilir sürede geri getirilebilmesiyle ölçülür.
Tekirdağ’daki bir ofis, üretim şirketi ya da mağaza için planın ölçeği değişebilir; temel sorular aynıdır: Hangi veri kritik? Ne kadar veri kaybı kabul edilebilir? Sistem kaç saat durabilir? Kopyalar nerede tutulacak? Geri yüklemeyi kim, ne zaman test etti?
Önce yedeklenecek veriyi bulun
“Her şeyi yedekleyelim” kulağa güvenli gelir fakat kaynak ve saklama maliyetini gereksiz büyütebilir. Önce veri envanteri çıkarın: muhasebe ve ERP veritabanları, ortak klasörler, proje dosyaları, kullanıcı bilgisayarlarındaki yerel belgeler, e-posta, web uygulamaları, sanal makineler, cihaz yapılandırmaları ve lisans bilgileri.
Sonra veriyi önem ve değişim hızına göre sınıflandırın. Her gün yüzlerce işlem gören veritabanı ile yılda bir kez açılan arşivin aynı sıklıkta yedeklenmesi gerekmez. Kişisel veri ve ticari sır içeren kopyaların şifreleme, erişim ve saklama koşulları ayrıca ele alınmalıdır.
RPO ve RTO’yu teknik terim olmaktan çıkarın
RPO, geri dönüldüğünde kabul edilebilecek veri kaybını; RTO ise hizmetin ne kadar sürede yeniden çalışması gerektiğini ifade eder. Bu değerler teknik ekip tarafından tek başına belirlenmemelidir. İş birimi, “Son dört saatin siparişlerini kaybetsek ne olur?” ve “Muhasebe sistemi bir gün kapalı kalabilir mi?” sorularını yanıtlamalıdır.
RPO ne kadar kısa, RTO ne kadar hızlı istenirse altyapı ve işletim maliyeti genellikle artar. Her sistem için sıfır veri kaybı ve anında dönüş talep etmek bütçeyi gerçekçi olmayan bir tasarıma zorlayabilir. Kritik sistemleri önceliklendirin; geri kalanlar için daha uzun hedefler belirleyin.
3-2-1 yaklaşımı nasıl uygulanır?
Yaygın 3-2-1 yaklaşımı, verinin üretim kopyasıyla birlikte üç kopyasını, iki farklı ortam türünde ve bunlardan en az birini farklı konumda tutmayı hedefler. Güncel ihtiyaçlarda çevrimdışı veya değiştirilemez kopya da plana eklenebilir. Sayıyı ezberlemekten çok ortak hata noktasını azaltma mantığını anlamak önemlidir.
Örneğin dosyalar bir iş sunucusunda bulunabilir; yerel NAS üzerinde hızlı geri dönüş kopyası ve farklı lokasyonda şifreli bir bulut/harici ortam kopyası tutulabilir. Yerel NAS ile sunucu aynı elektrik, aynı kullanıcı hesabı ve aynı fiziksel ortamı paylaşıyorsa tek başına felaket koruması sayılmaz.
CISA’nın fidye yazılımı rehberi, kritik verilerin çevrimdışı ve şifreli yedeklerinin tutulmasını; bu yedeklerin kullanılabilirlik ve bütünlüğünün düzenli olarak test edilmesini önerir. Bunun nedeni, pek çok fidye yazılımının erişebildiği yedekleri de silmeye veya şifrelemeye çalışmasıdır.
NAS, bulut ve harici disk hangi role sahiptir?
NAS
NAS, merkezi dosya paylaşımı ve hızlı yerel yedek hedefi olarak kullanışlıdır. Kullanıcı yetkileri, depolama kapasitesi, disk sağlığı ve ağ erişimi yönetilebilir. Fakat RAID disk arızasına karşı süreklilik sağlar; yanlış silme, cihaz arızası, fidye yazılımı, hırsızlık veya bina kaynaklı felaketlere karşı tek başına yedek değildir.
Bulut yedekleme
Bulut, farklı lokasyonda kopya ve ölçeklenebilir kapasite sağlayabilir. Ancak veri yükleme süresi, geri indirme süresi, saklama ve çıkış ücretleri, hesap güvenliği, sürüm politikası ve sağlayıcının sorumlulukları incelenmelidir. Senkronizasyon ile yedekleme aynı değildir; yanlış silme senkronize oluyorsa geçmiş sürümler yoksa dosya her yerde kaybolabilir.
Harici disk veya çıkarılabilir ortam
Küçük veri setlerinde uygun maliyetli çevrimdışı kopya sağlayabilir. Diski sürekli sunucuya bağlı bırakmak çevrimdışı avantajını ortadan kaldırır. Döngü, taşıma, şifreleme, fiziksel saklama ve kimin değiştireceği yazılı olmalıdır; unutulan manuel işlemler güvenilir plan oluşturmaz.
Yedekleme hesabını üretim hesabından ayırın
Yedek deposuna yazma yetkisi olan hesaplar sınırlı tutulmalıdır. Kullanıcı bilgisayarının ele geçirilmesi hâlinde aynı kimlik bilgileriyle bütün yedeklerin silinmesi engellenmeye çalışılır. Yedek yönetim arayüzü internete gereksiz açılmamalı, çok faktörlü kimlik doğrulama destekleniyorsa kullanılmalı ve yönetici işlemleri kaydedilmelidir.
Depolama ve yedek ağını gerektiğinde ayrı VLAN veya firewall kurallarıyla sınırlandırmak faydalıdır. Ancak ağ ayrımı kötü parola ya da güncellenmeyen cihaz sorununu çözmez; firewall ve ağ güvenliği ile kimlik/yama yönetimi birlikte düşünülmelidir.
Saklama süresi ve sürüm planı
Yalnızca en son kopyayı tutmak, bozuk veya şifrelenmiş dosyanın sağlam sürümün üzerine yazılmasına yol açabilir. Günlük, haftalık, aylık ve uzun dönem arşiv ihtiyacı verinin türüne göre belirlenir. Çok sık ve uzun saklama kapasiteyi artırır; çok kısa saklama ise geç fark edilen hatada geri dönüş noktasını yok eder.
Yasal ve sözleşmesel saklama süreleri ilgili uzmanlarla doğrulanmalıdır. “Sonsuza kadar sakla” yaklaşımı maliyet, kişisel veri ve güvenlik yükü oluşturur. Süresi dolan kopyaların güvenli silme süreci de politikanın parçasıdır.
Geri yükleme testi nasıl yapılır?
Her gün “başarılı” e-postası gelmesi yedeğin kullanılabilir olduğunu kesin göstermez. Rastgele seçilmiş bir dosyanın farklı klasöre geri yüklenmesi temel kontroldür. Veritabanı ve sanal makinelerde uygulamanın gerçekten açıldığı, bağımlı servislerin çalıştığı ve kullanıcı erişimlerinin doğru olduğu daha kapsamlı test gerekir.
Test üretim sistemini riske atmayan izole bir ortamda yapılmalı; süre, hata ve eksik bağımlılıklar kaydedilmelidir. Geri yükleme parolası, şifreleme anahtarı veya lisans dosyası bulunamıyorsa yedek teknik olarak sağlam olsa bile sistem çalışmayabilir. NIST’in olağanüstü durum planlama rehberi de iş etki analizi, kurtarma stratejisi, test/eğitim ve plan bakımını bir bütün olarak ele alır.
Yedekleme planı için kısa kontrol listesi
- Kritik veri ve sistemlerin sahibi belli mi?
- Her sistem için RPO ve RTO iş birimiyle kararlaştırıldı mı?
- Yerel hızlı dönüş ve farklı lokasyon kopyası var mı?
- En az bir kopya üretim hesaplarından ayrılmış, çevrimdışı veya değiştirilemez mi?
- Yedekler şifreleniyor ve anahtarlar güvenli saklanıyor mu?
- Başarısız işler bir kişiye alarm üretiyor mu?
- Kapasite büyümesi ve saklama süresi izleniyor mu?
- Dosya, veritabanı ve tam sistem geri yükleme testleri kayıtlı mı?
- Personel ayrılığında hesap ve fiziksel ortam teslim süreci var mı?
Tekirdağ’da veri yedekleme altyapısı planlama
Yedekleme yazılımı veya NAS satın almadan önce veri hacmi, değişim hızı, kritik sistemler ve hedef geri dönüş süresi belirlenmelidir. DAISHO’nun veri depolama sistemleri kapsamında NAS, merkezi depolama, yetkilendirme ve yedekleme ihtiyacınızı mevcut sunucu/bulut yapınızla birlikte değerlendirebiliriz.
WhatsApp’tan yaklaşık veri hacminizi ve sistemlerinizi paylaşın.
İlgili BT rehberleri ve destek
Altyapı kararını sunucu mu bulut mu rehberi ile karşılaştırabilir; düzenli kontrol ve geri yükleme planı için kurumsal IT destek ve bakım hizmetimizi inceleyebilirsiniz.
Sık sorulan sorular
RAID yedekleme sayılır mı?
Hayır. RAID bazı disk arızalarında hizmetin devamına yardımcı olur; yanlış silme, fidye yazılımı, cihaz kaybı veya bina felaketi için bağımsız kopya sağlamaz.
Bulut senkronizasyonu yedek yerine geçer mi?
Sürüm geçmişi ve bağımsız geri dönüş özellikleri yoksa senkronizasyon hatayı da çoğaltabilir. Hizmetin saklama, sürüm ve kurtarma özellikleri doğrulanmalıdır.
Yedekler ne sıklıkta test edilmeli?
Risk ve değişim hızına göre planlanır. Kritik sistemlerde daha sık örnek geri yükleme ve periyodik tam kurtarma provası gerekir; her test kayıt altına alınmalıdır.
Yedekleme için ne kadar kapasite gerekir?
Aktif veri miktarı tek başına yetmez. Değişim oranı, sıkıştırma, saklama süresi, sürüm sayısı ve büyüme payı hesaba katılmalıdır.
Yedekler şifrelenmeli mi?
Hassas veriler taşıma ve saklama sırasında korunmalıdır. Şifreleme anahtarlarının kaybolması geri yüklemeyi imkânsız kılabileceği için anahtar yönetimi ayrıca planlanmalıdır.