Bir işletme için en pahalı sorun çoğu zaman yeni sunucu almak değil, kaybolan veriyi geri getirememektir. Sunucu yedekleme planı oluşturma süreci tam da bu yüzden teknik bir detay değil, iş sürekliliğini koruyan temel bir karardır. Dosyalar, muhasebe kayıtları, müşteri bilgileri, web site verileri ve şirket içi belgeler tek noktada tutuluyorsa, plansız bir yapı bir gün mutlaka sorun çıkarır. Sunucu yedekleme planı neden öncelikli olmalı? Birçok firma yedek aldığını düşünür ama gerçekte yalnızca kopya tutuyordur. Bu iki konu aynı değil. Gerçek bir yedekleme planı, hangi verinin ne sıklıkla yedekleneceğini, nerede saklanacağını, ne kadar süre tutulacağını ve sorun anında nasıl geri yükleneceğini net biçimde belirler. Buradaki kritik nokta şudur: Yedek almak tek başına yeterli değildir, geri yükleme başarısı da garanti altına alınmalıdır. Çünkü bozuk bir yedek dosyası, hiç yedek olmamasından çok farklı sonuç vermez. Özellikle şirket içi dosya sunucuları, muhasebe sistemleri, e-posta verileri, sanal makineler ve web uygulamaları için bu konu doğrudan operasyonel riske dönüşür. Küçük işletmelerde sık görülen hata, tüm veriyi tek disk üstünde tutup harici diske ara sıra manuel kopya almaktır. Bu yöntem kısa vadede ucuz görünür ama insan hatasına çok açıktır. Disk arızası, yanlış silme, zararlı yazılım veya elektrik kaynaklı hasar yaşandığında elinizde güncel ve doğrulanmış bir yedek yoksa iş durur. Sunucu yedekleme planı oluşturma sürecinde ilk adım Doğru plan, cihazdan değil veriden başlar. Önce şu sorulara net cevap vermek gerekir: Hangi veriler kritik? Bir dosya kaybolursa işletme ne kadar süre durur? En fazla ne kadar veri kaybı kabul edilebilir? Bu sorular teknik görünse de aslında tamamen iş odaklıdır. Örneğin bir e-ticaret altyapısında son 24 saatin sipariş verilerini kaybetmek ciddi finansal zarar doğurabilir. Buna karşılık arşiv klasöründeki eski proje dosyaları için daha seyrek yedekleme yeterli olabilir. Yani her veri aynı sıklıkta ve aynı maliyetle korunmak zorunda değildir. Bu noktada iki temel hedef belirlenir. Birincisi ne kadar veri kaybının tolere edilebileceği, ikincisi sistemin ne kadar sürede yeniden ayağa kaldırılması gerektiğidir. Kısaca söylemek gerekirse, bazı firmalar için 1 saatlik veri kaybı bile fazla iken bazı yapılar için günlük yedek yeterlidir. İhtiyaç neyse plan ona göre kurulmalıdır. Kritik verileri sınıflandırın Pratik bir yaklaşım olarak verileri üç gruba ayırmak işe yarar: hayati veriler, operasyonel veriler ve arşiv verileri. Hayati veriler muhasebe kayıtları, müşteri veritabanları, aktif proje dosyaları ve web uygulama verileri gibi günlük işi doğrudan etkileyen alanlardır. Operasyonel veriler düzenli kullanılan ama kısa süreli kayıpta işi tamamen durdurmayan içeriklerdir. Arşiv veriler ise daha uzun saklama süresi isteyen ancak anlık erişim zorunluluğu düşük dosyalardır. Bu sınıflandırma yapılmadan kurulan sistemlerde ya gereksiz depolama maliyeti oluşur ya da kritik veri yeterince korunmaz. İyi plan, maliyet ile güvenlik arasında dengeli bir yapı kurar. Doğru yedekleme modeli nasıl seçilir? Burada tek doğru yöntem yoktur. Sunucunun yapısı, veri hacmi, internet altyapısı ve bütçe belirleyicidir. Yine de çoğu işletme için en güvenli yaklaşım, yerel yedek ile uzak yedek kombinasyonudur. Yerel yedekleme hızlı geri dönüş sağlar. Aynı ofiste veya şirket içi ağda bulunan NAS cihazı, ikinci sunucu ya da yedekleme ünitesi sayesinde dosyalara kısa sürede erişilebilir. Özellikle yanlış silinen dosya veya küçük sistem arızalarında zaman kazandırır. Uzak yedekleme ise farklı bir lokasyonda tutulan kopyadır. Yangın, hırsızlık, ciddi donanım arızası ya da ofis genelini etkileyen bir felakette asıl güvence budur. Sadece ofis içinde yedek tutmak çoğu zaman yeterli değildir. Çünkü ana sunucu ile yedek cihaz aynı olaydan etkilenebilir. En çok kullanılan yapı 3-2-1 mantığıdır. Verinin en az 3 kopyası bulunur, 2 farklı ortamda tutulur, 1 kopya ise farklı lokasyonda saklanır. Her firma için birebir aynı model gerekmese de temel yaklaşım doğru kabul edilir. Özellikle KOBİ ölçeğinde bu yapı, maliyet ve koruma dengesi açısından mantıklıdır. Tam, artımlı ve diferansiyel yedekler Yedekleme türü seçimi de planın performansını etkiler. Tam yedek, tüm verinin baştan sona kopyalanmasıdır. Geri yüklemesi kolaydır ama zaman ve depolama alanı ister. Artımlı yedek, son yedekten sonra değişen dosyaları alır. Daha az alan kullanır fakat geri yükleme zinciri daha dikkatli yönetilmelidir. Diferansiyel yedek ise son tam yedekten sonra değişen her şeyi tutar. Artımlı yapıya göre daha fazla alan kullanır ama geri dönüş süreci daha pratiktir. Hangi modelin doğru olduğu kullanım senaryosuna bağlıdır. Yoğun çalışan dosya sunucularında artımlı yapı avantajlı olabilir. Kritik sistemlerde ise belirli aralıklarla tam yedek alıp araya artımlı yedekler eklemek daha güvenli sonuç verir. Yedekleme sıklığı nasıl belirlenir? Burada yaygın hata, tüm sistem için tek zamanlama belirlemektir. Oysa aktif çalışan bir veritabanı ile ayda bir güncellenen arşiv klasörü aynı düzende yedeklenmemelidir. Muhasebe, sipariş, CRM ve canlı web verileri gibi alanlarda saatlik veya günlük yedekleme gerekebilir. Standart ofis belgelerinde günlük yedek çoğu zaman yeterlidir. Eski arşivler için haftalık ya da aylık plan daha mantıklı olabilir. Bu sayede hem sistem yükü kontrol edilir hem de depolama daha verimli kullanılır. Ayrıca yedeklerin saklama süresi de baştan belirlenmelidir. Son 7 günlük, son 4 haftalık ve son 6 aylık sürümlerin tutulduğu katmanlı yapı birçok işletme için kullanışlıdır. Çünkü bazı sorunlar hemen fark edilmez. Bir dosya bugün bozulmuş olabilir ama kullanıcı bunu 10 gün sonra anlayabilir. Tek sürümlü yedek yapısı bu durumda yetersiz kalır. En kritik konu: Test edilmeyen yedek, yedek değildir Yedekleme sistemlerinin en zayıf noktası, kurulduktan sonra kendi haline bırakılmasıdır. Bildirim geliyor diye her şeyin düzgün çalıştığı sanılır. Oysa bozuk dosyalar, eksik veritabanı kayıtları, hatalı izinler veya çalışmayan sanal makine yedekleri çoğu zaman ancak geri yükleme denemesinde ortaya çıkar. Bu nedenle planın içinde düzenli test şarttır. Belirli periyotlarda örnek dosya geri yükleme, veritabanı açma testi ve gerekiyorsa tam sistem geri dönüş senaryosu uygulanmalıdır. Amaç yalnızca yedek dosyasını görmek değil, gerçekten çalışır durumda olduğunu doğrulamaktır. Özellikle şirket içinde teknik ekip yoksa bu süreç profesyonel destekle yürütülmelidir. Çünkü sorun anında deneme yapma lüksü kalmaz. İşletme için doğru olan yaklaşım, felaket anını beklemeden senaryoyu önceden prova etmektir. Güvenlik tarafını atlamayın Yedekleme sistemi de korunmalıdır. Yetkisiz erişime açık bir yedek sunucusu, asıl sistem kadar risklidir. Yedek dosyalarına erişim sınırlandırılmalı, mümkünse şifreli saklama kullanılmalı ve yönetim paneli temel güvenlik önlemleriyle korunmalıdır. Bir diğer kritik nokta, yedeklerin ana sistemden tamamen bağımsız olabilmesidir. Ağda sürekli bağlı kalan depolama cihazları bazı risklerde birlikte etkilenebilir. Bu yüzden mimari kurulum yapılırken izolasyon seviyesi de değerlendirilmelidir. Ucuz çözüm her zaman pahalı sonuca yol açmaz ama yanlış kurulan ucuz çözüm çoğu zaman ikinci kez maliyet çıkarır. Küçük işletmeler için uygulanabilir bir plan KOBİ ölçeğinde ideal yapı genelde karma modeldir. Günlük otomatik yerel yedek, haftalık tam yedek ve farklı lokasyona düzenli kopya alma sistemi çoğu firma için yeterli bir omurga kurar. Eğer sanal sunucu kullanılıyorsa anlık görüntü alma ile klasik yedekleme birlikte düşünülmelidir. Çünkü anlık görüntü hızlı geri dönüş sağlar, fakat uzun vadeli arşiv için tek başına yeterli değildir. Burada önemli olan en pahalı sistemi kurmak değil, sürdürülebilir sistemi kurmaktır. Personelin takip edemeyeceği kadar karmaşık bir yapı zamanla bozulur. Otomasyon, izleme ve düzenli kontrol bu yüzden kritik hale gelir. Server kurulum, bakım ve yedekleme hizmetlerinde çalışan ekipler olarak sahada en sık gördüğümüz tablo şudur: Yedekleme cihazı vardır ama plan yoktur. Oysa iyi sonuç, cihaz seçiminden çok doğru senaryo ile gelir. Hangi verinin, hangi sıklıkta, hangi yöntemle ve hangi geri yükleme hedefiyle korunacağı net değilse sistem eksiktir. Sunucu tarafında risk almak çoğu zaman sorun çıkmayana kadar fark edilmez. Ama sorun çıktığında karar vermek için geç kalınmış olur. İşinizi ayakta tutan verilerinizse, onları şansa bırakmadan planlı şekilde korumak en mantıklı yatırımdır.