Sunucu Tarafında Yedekleme Nasıl Olmalı?

Bir e-ticaret sitesinde gece sipariş akarken veritabanının bozulması, bir yazılım ekibinde yanlış deploy sonrası kritik dosyaların silinmesi ya da ransomware nedeniyle tüm erişimin kesilmesi - bu anlarda tek soru şudur: sunucu tarafında yedekleme nasıl olmalı? Cevap, sadece kopya almak değildir. Cevap; neyin, ne sıklıkla, nereye, hangi doğrulamayla ve ne kadar sürede geri döndürüleceğini baştan tasarlamaktır.

Birçok ekip yedeklemeyi disk dolana kadar çalışan bir cron job olarak görür. Bu yaklaşım küçük projelerde bile risklidir, büyüyen iş yüklerinde ise doğrudan operasyonel zafiyete dönüşür. Çünkü gerçek ihtiyaç, dosya kopyası değil iş sürekliliğidir. Yedek stratejiniz RPO ve RTO hedeflerinize uymuyorsa, teknik olarak yedeğiniz vardır ama operasyonel olarak güvende değilsiniz.

Sunucu tarafında yedekleme nasıl olmalı?

İlk kural nettir: üretim ortamındaki veri tek bir kopyaya emanet edilmez. Aynı sunucuda duran ikinci klasör, gerçek bir yedek değildir. Aynı fiziksel disk grubunda tutulan snapshot da tek başına yeterli değildir. Donanım arızası, kullanıcı hatası, saldırı veya yanlış yapılandırma gibi senaryolarda asıl ihtiyaç, izole ve geri döndürülebilir kopyalardır.

Doğru yapı genelde 3-2-1 mantığına yaklaşır. Verinin en az üç kopyası bulunur, iki farklı ortamda tutulur ve bunlardan biri ana sistem dışında konumlanır. Ancak bu modeli körü körüne uygulamak yerine iş yüküne göre uyarlamak gerekir. Yüksek yazma trafiği alan bir veritabanı ile daha çok statik dosya barındıran kurumsal web sitesi aynı planla yönetilmez.

Burada belirleyici olan iki metrik vardır. RPO, ne kadar veri kaybını tolere edebileceğinizi gösterir. RTO ise sistemin ne kadar sürede tekrar ayağa kalkması gerektiğini belirler. Eğer 15 dakikalık veri kaybı bile kabul edilemezse günlük yedek yetmez. Eğer uygulamanın 6 saat kapalı kalması ticari olarak ciddi zarar yaratıyorsa sadece arşiv almak da yeterli olmaz. Yedekleme planı bu iki sınır üzerinden kurulur.

Tam, artımlı ve diferansiyel yedek seçimi

Tam yedek, geri dönüş açısından en basit modeldir ama depolama ve süre maliyeti yüksektir. Artımlı yedek, son yedekten sonra değişen blokları alır ve alan verimliliği sağlar. Diferansiyel model ise son tam yedekten bu yana değişen veriyi tutar. Hangi yöntemin doğru olduğu altyapının büyüklüğüne, değişim hızına ve geri dönüş beklentisine bağlıdır.

Küçük ve orta ölçekli web projelerinde haftalık tam yedek ile günlük artımlı plan sık kullanılan bir dengedir. Veritabanı yoğun sistemlerde ise saatlik dump, binary log replikasyonu veya snapshot temelli koruma daha mantıklı olabilir. Önemli olan, yedek alma sürecinin canlı performansı ezmemesidir. Özellikle NVMe tabanlı hızlı sistemlerde üretim yükünü korurken arka planda kontrollü I/O planlaması yapmak gerekir.

Hangi veriler mutlaka yedeklenmeli?

Burada yapılan en yaygın hata, sadece public_html ya da uygulama klasörünü kopyalamaktır. Oysa sistemin tekrar ayağa kalkması için çoğu zaman daha fazlası gerekir. Veritabanları, uygulama dosyaları, kullanıcı yüklemeleri, SSL sertifikaları, mail kutuları, DNS zone kayıtları, cron yapılandırmaları ve kritik sistem konfigürasyonları birlikte düşünülmelidir.

Container kullanan ekiplerde image değil veri kalıcılığı sağlayan volume yapıları asıl odak olmalıdır. Sanal sunucu tarafında ise sadece guest OS içindeki dosyalar değil, mümkünse hypervisor seviyesinde alınan tutarlı snapshot stratejisi de plana dahil edilmelidir. Fiziksel sunucularda RAID bulunması ise sık karıştırılan bir noktadır. RAID erişilebilirlik sağlar, yedekleme sağlamaz.

Log verileri için ise seçici davranmak gerekir. Her log dosyasını uzun süre saklamak depolamayı gereksiz şişirir. Ama güvenlik olayları, erişim logları ve hata incelemesinde işinize yarayacak kayıtlar kısa saklama politikalarıyla korunmalıdır. Yedekleme planı sadece neyi saklayacağını değil, neyi saklamayacağını da net belirlemelidir.

Offsite yedek neden şart?

Aynı veri merkezinde ikinci bir kopya tutmak faydalıdır ama tek başına yeterli değildir. Ağ seviyesinde büyük bir sorun, yanlışlıkla toplu silme, kötü niyetli erişim ya da fidye yazılımı gibi durumlarda izole kopya hayat kurtarır. Bu yüzden en az bir yedeğin farklı lokasyonda ve mümkünse üretim erişiminden ayrı kimlik bilgileriyle tutulması gerekir.

Türkiye lokasyonlu hizmet kullanan işletmeler için düşük gecikme ve hızlı erişim avantajı çok değerlidir. Ancak yedek tarafında hız kadar izolasyon da önemlidir. Özellikle kurumsal projelerde ana ortam ile yedekleme ortamı arasında ağ, kullanıcı yetkisi ve erişim politikası bazında ayrım yapılmalıdır. Bu yaklaşım, yedeklerin saldırıyla birlikte şifrelenmesi riskini ciddi biçimde azaltır.

Otomasyon var ama doğrulama yoksa risk devam eder

Başarılı görünen bir backup job, geri yükleme anında bozuk arşiv üretebilir. Bu yüzden rapor alan ama test etmeyen ekipler gerçekte sadece varsayım yönetir. Sağlıklı bir sistemde yedekleme sonrası checksum doğrulaması, başarısız iş uyarıları, kapasite takibi ve düzenli restore testi bulunur.

En azından belirli aralıklarla staging ortamına geri yükleme yapılmalı ve uygulamanın gerçekten çalıştığı doğrulanmalıdır. Veritabanı ayağa kalkıyor mu, servis bağımlılıkları tamam mı, dosya izinleri doğru mu, sertifikalar geçerli mi? Bu sorular backup anında değil restore testinde cevaplanır. İş sürekliliği, yedekleme raporuyla değil başarılı geri yüklemeyle kanıtlanır.

Şifreleme ve erişim kontrolü nasıl ele alınmalı?

Yedek veri, üretim verisinin ikinci hayatıdır. Bu yüzden güvenlik seviyesi daha düşük olamaz. Hem aktarım sırasında hem depolama katmanında şifreleme kullanılmalıdır. Erişim izinleri ise minimum yetki mantığıyla tanımlanmalıdır. Yedekleri okuyabilen, silebilen ve yaşam döngüsü kuralını değiştirebilen hesaplar ayrı düşünülmelidir.

Özellikle müşteri verisi, finansal kayıtlar veya kurumsal e-posta arşivleri söz konusuysa yedeklerin de uyumluluk ve gizlilik yükümlülüklerine tabi olduğu unutulmamalıdır. Şifreleme anahtarlarının aynı sunucuda tutulması ise sık yapılan ama pahalıya mal olabilen bir hatadır. Ayrı anahtar yönetimi, ayrı erişim denetimi ve denetlenebilir log yapısı daha güvenli bir çerçeve sunar.

Yedekleme sıklığı her sistemde aynı olmaz

Kurumsal web sitesi için gece tek sefer yedek almak yeterli olabilir. Ama aktif e-ticaret, ERP, CRM veya yoğun API trafiği olan uygulamalarda saatlik hatta dakikalık veri koruma katmanları gerekebilir. Burada maliyet ile risk arasında net bir hesap yapılmalıdır. Her veriyi aynı sıklıkta yedeklemek gereksiz maliyet üretir, yetersiz sıklık ise doğrudan veri kaybı yaratır.

Doğru yaklaşım veriyi sınıflandırmaktır. Kritik veritabanları daha sık, arşiv niteliğindeki medya dosyaları daha seyrek korunabilir. Bazı veriler için uzun saklama gerekirken bazıları için 7 ila 30 günlük döngü yeterlidir. Yaşam döngüsü politikası olmayan yedekleme sistemi, zamanla pahalı ve yönetilemez hale gelir.

Altyapı performansı neden yedek kalitesini etkiler?

Yedekleme yalnızca yazılım meselesi değildir. Disk I/O, ağ throughput, işlemci yükü ve veri merkezinin erişilebilirliği doğrudan sonucu etkiler. Yoğun saatlerde yanlış planlanan backup job, uygulama gecikmesini artırabilir. Zayıf depolama katmanında alınan uzun süreli snapshot'lar veritabanı performansını düşürebilir.

Bu yüzden performans odaklı altyapı üzerinde çalışan ekipler, yedeklemeyi ayrı bir operasyon katmanı olarak ele alır. Hızlı NVMe depolama, istikrarlı ağ, izole kaynaklar ve düzenli monitöring bu noktada fark yaratır. Vode Host gibi kurumsal sürekliliği merkeze alan altyapılarda asıl avantaj, sadece sunucunun hızlı olması değil, yedekleme ve geri dönüş süreçlerinin de öngörülebilir kalmasıdır.

Pratikte güçlü bir yedekleme standardı

Gerçekçi bir standart şu çerçevede kurulabilir: kritik veriler için sık artımlı koruma, düzenli tam yedek, offsite kopya, şifreleme, erişim ayrımı ve planlı restore testi. Buna ek olarak kapasite alarmı, başarısız görev bildirimi ve yazılı bir geri dönüş prosedürü bulunmalıdır. Acil durumda kimin ne yapacağı belirsizse, teknik olarak güçlü bir yedekleme bile operasyonel stres altında yavaşlar.

En pahalı hata genelde yedek almamak değil, yedeğin işe yarayacağını varsaymaktır. Sunucu tarafında yedekleme, depolama alışkanlığı değil kesinti yönetimi disiplinidir. Sisteminizi büyütürken CPU, RAM ve disk kadar yedek mimarisine de yatırım yapın. Çünkü kriz anında ayakta kalan taraf, daha çok kopyası olan değil, daha hızlı ve doğrulanmış şekilde geri dönebilen taraftır.