Fiziksel yedekleme sunucusu, yedekleri üretim sisteminden ayrı bir fiziksel makinede tutarak tek disk, tek kasa, tek hesap ve tek lokasyon riskini azaltan en güvenli başlangıç düzenlerinden biridir. Bu yapı, yedeği sadece depolamaz; saklama süresini yönetir, erişimi sınırlar, şifrelemeyi uygular ve geri yükleme testini mümkün kılar. Doğru kurulumda ilk karar, yedeğin nerede duracağı, kimlerin yazıp silebileceği, ne kadar süre saklanacağı ve hangi aralıkla restore edileceğidir. RAID, kapasite ve dayanıklılık sağlar ama yedek yerine geçmez; offsite kopya ise yerel felaketlere karşı ikinci güvenlik katmanını oluşturur. En sağlıklı başlangıç, kapasitenin bir kısmını boş bırakmak, ayrı bir backup hesabı kullanmak, en az bir uzak kopya tanımlamak ve küçük bir dosya restore testiyle düzeni doğrulamaktır. Bu rehber, hangi ayarın ne işe yaradığını, nerede risk doğurduğunu ve hangi noktada geri dönmeniz gerektiğini uygulamalı biçimde gösterir.
Mevcut durum: Yedekler şu an nereye bağımlı?
İlk bakılması gereken yer, yedeğin nerede durduğudur. Aynı makinede tutulan kopya ile aynı odadaki ikinci disk, aynı riski paylaşır; çünkü elektrik kesintisi, donanım arızası, yangın veya kötü niyetli silme durumunda ikisi de aynı anda etkilenebilir. Eğer yedekleriniz tek bir NAS üzerinde, tek bir RAID grubunda ya da tek bir yönetici hesabında toplanıyorsa, bu düzen kapasite sağlasa bile gerçek anlamda koruma sağlamayabilir. Fiziksel yedekleme sunucusu burada devreye girer: yedeği üretimden ayırır, erişimi sınırlar ve geri yükleme için kontrollü bir hedef sunar. Bu nedenle ilk soru şudur: elinizde yedek var mı, yoksa yalnızca başka bir yere taşınmış kopya mı var?
Hedef durum: Ayrı, doğrulanabilir bir geri dönüş katmanı
Sağlam hedef, üretim sisteminden bağımsız bir makinede, düzenli artımlı kopyaları ve aralıklı tam kopyaları tutmak, bunları bir saklama politikasıyla yönetmek ve en az bir kopyayı fiziksel ya da mantıksal olarak uzak tutmaktır. Bu makine, gerektiğinde üretimi ayakta tutan sistemlerden daha yavaş olabilir; fakat geri dönüş güveni, ham hızdan daha değerlidir. Özellikle tek sunuculu yapılarda amaç, her şeyi sonsuza kadar saklamak değil, gerekli döneme dönmeyi mümkün kılmaktır. Bu yüzden kurulumu planlarken kapasiteyi yalnız bugünkü veriye göre değil, beklenen büyüme ve saklama penceresine göre düşünmek gerekir. Kapasite doldukça silme kuralları agresifleşirse, elinizde görünürde çalışan ama pratikte geri dönemeyen bir yedek havuzu kalır.
Fiziksel yedekleme sunucusu için ayar grupları
İlk kurulumda ayarları tek tek değil, işlev grupları halinde ele almak daha güvenlidir. Aşağıdaki başlangıç değerleri evrensel doğru değil; ilk referans noktası olarak düşünülmeli ve veri hacmi, restore ihtiyacı ve saklama zorunluluğuna göre uyarlanmalıdır.
| Ayar grubu | Güvenli başlangıç değeri | Etki | Risk |
|---|---|---|---|
| Depolama alanı | Kapasitenin tamamını doldurmadan, en az %20-30 boşluk bırakın | Yeni yedeklerin yazılabilmesini ve yeniden düzenlemeyi kolaylaştırır | Aşırı doluluk performansı düşürür, silme ve genişleme sorunları yaratır |
| Saklama süresi | Günlük 7, haftalık 4, aylık 3 gibi bir başlangıç seti | Geri dönüş noktalarını dengeler | Çok kısa saklama, hatayı kalıcı hale getirir; çok uzun saklama kapasiteyi tüketir |
| Şifreleme | Aktarımda ve diskte şifreleme açık olsun | Yetkisiz erişim riskini düşürür | Anahtar yönetimi kötü kurulursa geri yükleme de kilitlenir |
| Yetki modeli | Ayrı backup hesabı, sınırlı yazma ve silme yetkisi | Fidye yazılımının yayılım alanını daraltır | Aşırı yetkili hesaplar tüm geçmişi tek oturumda silebilir |
| Offsite kopya | En az bir uzak kopya | Yerel felaketlere karşı ikinci güvenlik katmanı oluşturur | Tek lokasyon her zaman kırılgandır |
Depolama katmanı
Disk düzeyi seçimi, yedekleme mantığını belirler ama yedeğin kendisini tanımlamaz. RAID1 ya da RAID10, disk arızasına karşı dayanıklılık sağlar; buna rağmen RAID, yedek yerine geçmez. Çünkü yanlış silinen dosya, bozulmuş veritabanı ya da fidye yazılımı RAID içinde de bozulmadan kalabilir. Bu nedenle depolama katmanını kurarken amaç, hizmetin ayakta kalması ile geçmişin korunmasını birbirine karıştırmamak olmalı. Uygulamada en azından önyükleme, veri ve yedek alanlarını ayırmak, bakım sırasında sürprizleri azaltır. Eğer dosya sistemi snapshot özelliği varsa, bu özellik geri dönüş hızını artırabilir; ancak snapshot da tek başına offsite kopyanın yerini tutmaz.
Saklama süresi ve kopya sayısı
Saklama politikası, ne kadar veriyi ne kadar süre geri alabileceğinizi belirler. Çok kısa politika, sorunun birkaç gün sonra fark edilmesi halinde geri dönüşü imkansız hale getirir. Çok uzun politika ise kullanılmayan kopyaları taşımak anlamına gelir. Güvenli başlangıç yaklaşımı, günlük artımlıları kısa süre, haftalık tam kopyaları orta süre ve aylık kopyaları daha uzun süre tutmaktır. Burada karar, işletmenin veri değişim hızına ve geri dönme ihtiyacına bağlıdır. Önemli ayrıntı şudur: silme kuralı ilk gün otomatik ve agresif çalışmamalı; önce bir restore testiyle bu politikayı taşıyabilecek kapasiteniz olduğunu görmelisiniz.
Erişim, şifreleme ve yetki sınırı
Yedekleme sunucusunu koruyan en güçlü unsur yalnızca disk yapısı değildir; yetki modelidir. Yedeği alan hesap ile yedeği yöneten hesap aynı olmamalı, günlük işlemler için kullanılan kimlikler silme ayrıcalığı taşımamalıdır. Mümkünse yönetim erişimini ayrı bir yönetici hesabı üzerinden yürütün ve backup servisine yalnız gerekli klasörlere yazma hakkı verin. Şifreleme, disk çalınsa bile içerikte doğrudan okuma yapılmasını engeller; ancak anahtar kaybolursa geri dönüş de kaybolur. Bu yüzden anahtar saklama biçimi, sunucunun fiziksel güvenliği kadar dikkat ister. Erişim katmanı zayıf kurulursa, sağlam disk dizisi tek başına anlamını kaybeder.
Offsite kopya ve air-gap yaklaşımı
En az bir kopyayı başka bir fiziksel konuma taşımak, özellikle yangın, hırsızlık, bölgesel kesinti ve fidye yazılımı senaryolarında kritik fark yaratır. Ağ üzerinden sürekli erişilebilen uzak kopya ile belirli zamanlarda bağlanan kapalı kopya aynı risk kümesine girmez; çünkü saldırı yüzeyi farklıdır. Küçük yapılarda bile tek bir dış lokasyon, birincil makineden daha yavaş olsa da çok daha güvenli olabilir. Uzak kopyanın her an açık olması şart değildir; önemli olan, belirli aralıklarla güncellenmesi ve geri dönülebilir durumda tutulmasıdır. Eğer bağlantı kalıcıysa, bu katmana da ayrı yetki ve ayrı parolalar uygulamak gerekir.
Ne zaman uygun, ne zaman yetersiz kalır?
Fiziksel yedekleme sunucusu, yerinde kontrol isteyen, veri hacmi büyümeye açık olan ve geri yükleme süresini kendisi yönetmek isteyen ekipler için uygundur. Özellikle uygulama, veritabanı ve dosya yedeğini tek bir strateji altında toplamak gerektiğinde iyi çalışır. Buna karşılık, bakım yapacak kimse yoksa, offsite kopya oluşturulamıyorsa ya da restore testi için zaman ayrılmıyorsa bu düzen tek başına yeterli sayılmaz. Yani mesele sunucu almak değil, sunucuyu doğrulanmış bir yedek politikasına dönüştürmektir. Aksi halde cihaz vardır ama koruma yoktur.
Doğrulama: Bir yedek gerçekten geri dönebiliyor mu?
Kurulumun başarılı sayılması için yedeğin alınması yetmez; geri dönmesi gerekir. Bu yüzden ilk doğrulama, örnek bir dosyayı veya küçük bir veri kümesini izole bir hedefe geri yüklemekle başlamalıdır. Beklenen sonuç yalnızca dosyanın görünmesi değildir; izinlerin, dosya boyutunun ve mümkünse bütünlüğünün de doğru kalması gerekir. Eğer veritabanı veya sanal makine yedeği tutuyorsanız, test ortamında uygulamanın açılması ve temel işlemlerin çalışması gerekir. İlk ölçümde geri yükleme süresi, hata sayısı ve eksik veri not edilirse sonraki testlerde karşılaştırma yapabilirsiniz. Bu kayıtlar yoksa yedek vardır ama güvenilirlik seviyesi bilinmiyor demektir.
- Dosya testi: Rastgele bir kritik dosyayı geri yükleyin ve açılabildiğini kontrol edin.
- Bütünlük testi: Geri yüklenen örnek dosyayı mevcut kopyayla karşılaştırın.
- Uygulama testi: Veritabanı veya servis varsa test ortamında başlatın.
- Zaman testi: İlk geri yüklemenin ne kadar sürdüğünü kaydedin.
Geri dönüş planı: Saklama ve kopyalama politikası değişirse
Canlı sistemde saklama süresini, silme kuralını veya şifreleme yöntemini değiştirirken önce eski düzeni koruyacak bir geri dönüş yolu bırakın. Özellikle yeni politika ilk kez uygulanıyorsa, eski son bilinen iyi kopyayı hemen silmeyin. Önce yeni ayarla bir test kopyası üretin, sonra geri yükleyin ve ancak başarılı olduğundan emin olduktan sonra eski politikayı daraltın. Eğer süreçte kapasite baskısı oluşursa, silme işini durdurup önceliği kurtarılabilir kopyaları korumaya verin. Bu tür değişikliklerde geri dönüş yolu net değilse, güvenlik değil veri kaybı üretirsiniz.
Son kontrol listesi
- Yedekler üretim sisteminden ayrı bir fiziksel makinede tutuluyor.
- En az bir offsite kopya var.
- Şifreleme ve anahtar saklama düzeni ayrı düşünülmüş.
- Backup hesabı ile yönetici hesabı birbirine karışmıyor.
- Saklama süresi kapasiteyi boğmuyor.
- En az bir örnek restore başarıyla tamamlandı.
- Politika değişikliğinde geri dönüş yolu korunuyor.
Sık Sorulan Sorular
Fiziksel yedekleme sunucusu ile NAS aynı şey mi?
Aynı şey değildir; fiziksel yedekleme sunucusu yedekleme politikasını ve geri dönüş sürecini de taşır, NAS ise çoğu zaman yalnız depolama sağlar. NAS üzerinde yedek tutulabilir, fakat yetki ayrımı, saklama süresi ve restore testi kurulmadıysa koruma düzeyi sınırlı kalır. Bu yüzden rolü doğru tanımlamak önemlidir.
Yedekleme için RAID yeterli mi?
Hayır, RAID yeterli değildir; yalnızca disk arızasına karşı süreklilik sağlar. Yanlış silme, bozuk yedek, fidye yazılımı veya uygulama hatası RAID içinde de aynen durabilir. RAID’i kullanılabilirlik katmanı, yedekleme sunucusunu ise geri dönüş katmanı olarak düşünmek daha doğrudur.
Saklama süresi için iyi bir başlangıç değeri nedir?
İyi bir başlangıç değeri, günlük kısa süreli, haftalık orta süreli ve aylık daha uzun süreli kopyalarla başlamaktır. Kesin sayı, veri değişim hızına ve geri dönme ihtiyacına bağlıdır. İlk ayda kapasite ve restore sonuçlarını izleyip süreleri buna göre daraltmak ya da uzatmak daha güvenlidir.
Offsite kopya gerçekten gerekli mi?
Evet, çoğu gerçek senaryoda gereklidir; çünkü yangın, hırsızlık, bölgesel kesinti ve fidye yazılımı yerel kopyaları birlikte etkileyebilir. Aynı binadaki ikinci disk, ayrı lokasyondaki bir kopya kadar dayanıklı değildir. En az bir uzak kopya, yerel felaketlere karşı önemli bir güvenlik katmanı sağlar.
Restore testi ne sıklıkla yapılmalı?
Restore testi, en azından politika değişikliklerinden sonra ve düzenli aralıklarla yapılmalıdır. Aylık ya da üç aylık bir test, küçük altyapılarda iyi bir başlangıç olabilir; ama önemli olan sıklıktan çok temsil eden bir örneği geri döndürebilmektir. Testte dosya açılmalı, bütünlük korunmalı ve süre kaydedilmelidir.