Dedicated Yedekleme Sunucusu Nasıl Kurulur?

Dedicated yedekleme sunucusu, ana üretim sistemlerinden ayrı tutulan, yalnızca yedek toplama, saklama ve geri yükleme için kullanılan bir sunucudur. Bu yapı, aynı makinede hem uygulama hem yedek çalıştırmaya göre daha güvenlidir; çünkü disk arızası, yanlış silme, fidye yazılımı veya bakım hatası gibi olaylarda iki tarafın birden etkilenme riskini azaltır. Yine de her ortam için tek doğru model yoktur: küçük bir ofiste tek bir Linux sunucusu ve şifreli disk yeterli olabilir, daha yoğun yapılarda ise ayrı ağ segmenti, yetki sınırı, offsite kopya ve düzenli geri yükleme testi gerekir. Buradaki gerçek ölçüt yalnızca “yedek alıyor” olması değildir; geri dönüş süresi, saklama politikası, veri tutarlılığı ve üretim yüküne etkisi birlikte değerlendirilmelidir. İlk kararınız, ne kadar veri kaybına razı olduğunuz ve ne kadar hızlı geri dönmeniz gerektiği olmalı.

Dedicated yedekleme sunucusu için doğru mimari

En sağlıklı kurulum, yedekleme sunucusunu üretim sunucusundan farklı kimlik, farklı ağ erişimi ve mümkünse farklı fiziksel konum ile ayırmaktır. Aynı veri merkezinde olsa bile ayrı VLAN, ayrı yönetim hesabı ve ayrı depolama alanı kullanmak, bir hatanın iki sistemi birden vurmasını zorlaştırır. Sanal makine kullanacaksanız da depolama katmanını dikkatle seçin; yedeklerin aynı storage kümesinde üretimle birlikte yaşaması, rahatlık hissi verse de felaket senaryolarında koruma sağlamayabilir. Bu nedenle dedicated yapı, yalnızca “özel makine” anlamına gelmez; erişimin, depolamanın ve geri dönüş yolunun da ayrılması anlamına gelir.

Yedekleme sunucusunu ne zaman kullanmalısınız? Veri değişim hızı düzenliyse, birkaç saatlik geri dönüş penceresi kabul ediliyorsa ve restore testi için ayrı zaman ayırabiliyorsanız bu model uygundur. Tek bir bilgisayar ya da çok küçük ortamda daha basit çözümler yeterli olabilir; buna karşın müşteri verisi, dosya arşivi, veritabanı veya panel yedeği büyüdükçe ayrı sunucu ihtiyacı netleşir. Asıl hedef, yedek işini üretim trafiğinden koparmaktır.

Disk, kapasite ve saklama süresi nasıl planlanır?

Kapasite planında ilk bakılacak şey toplam veri boyutu değil, günlük değişim oranıdır. Çünkü bir sistemin 2 TB verisi olması, her gün 2 TB yedek yazacağı anlamına gelmez; ama verinin yüzde kaçı her gün değişiyorsa saklama ve aktarım maliyetini o oran belirler. Bu yüzden saklama politikası, yedek sıklığı ve bant genişliği birlikte düşünülmelidir. incremental backup kullanıyorsanız ilk tam yedek sonrası artımlı zincirin büyümesini izleyin; sık değişen log, medya ve veritabanı klasörleri kapasiteyi hızlı tüketebilir. snapshot tek başına hızlı görünse de aynı depolama alanına yaslanıyorsa ayrı bir güvence sayılmamalıdır.

Bu başlangıç değerleri kesin reçete değildir. Değişim oranı yüksek veritabanı, medya ağırlıklı içerik veya sık güncellenen belge depolarında saklama süresi uzatılırken bant dar boğazı daha erken görünür. Küçük bir ofiste ise gereksiz karmaşık bir plan yerine düzenli çalışan, geri yüklenebilen ve kapasitesi izlenen sade bir yapı daha değerlidir.

Yedekleme politikasında hangi katmanlar birlikte çalışmalı?

Tek bir kopyaya güvenmek yerine, farklı işlevleri olan birkaç katmanı birlikte kullanın. Günlük artımlı yedekler kısa geri dönüş noktaları sağlar; haftalık tam kopyalar zincirin bozulması halinde toparlanmayı kolaylaştırır; aylık veya daha uzun dönemli kopyalar ise geçmişe dönük ihtiyaçlar için saklanır. Burada önemli ayrım, yedek ile arşiv arasındadır: arşiv uzun süre tutulur ama sık restore edilmez, yedek ise geri dönme ihtimali yüksek veriyi taşır. İkisini aynı saklama mantığına sıkıştırmak, ya disk alanını boşa harcar ya da geri dönme şansını zayıflatır.

Yetki tarafında en sağlıklı model, yedekleme sunucusunun üretim ortamına sınırlı ama kontrollü erişimle bağlanmasıdır. SSH anahtarı, API token ya da panel hesabı ne kullanırsanız kullanın, bu kimliğin yalnızca gerekli dizinlere erişmesini sağlayın. Yedekleme hesabını günlük yönetici hesabı gibi kullanmayın. Eğer bir saldırgan bu hesaba ulaşırsa, hem üretim hem yedek zinciri tehlikeye girebilir. Şifreleme anahtarları da aynı nedenle sunucunun root diskinde gelişigüzel tutulmamalıdır; anahtar yönetimi, dosya kadar önemli bir bileşendir.

İlk kurulum akışı nasıl ilerlemeli?

1. Sunucuyu üretimden ayrı bir host, ayrı bir sanal ağ ya da en azından ayrı yönetim segmenti üzerine kurun.
2. İşletim sistemi güncellemelerini yapın ve saat senkronizasyonunu kontrol edin; yanlış zaman damgası yedek zincirini karıştırır.
3. Yedek alanını sistem diskinden ayırın; mümkünse ayrı volume, ayrı disk veya ayrı storage kullanın.
4. Yedekleme hesabını oluşturun, yazma izinlerini sınırlandırın ve gereksiz interaktif erişimi kapatın.
5. İlk tam yedeği alın, ardından artımlı planı devreye sokun.
6. Offsite kopyayı etkinleştirin; tek konumda kalan yedek eksik sayılır.
7. Log, kapasite ve son başarı zamanı için izleme ekleyin.

Komut tarafında tek bir evrensel servis adı yoktur; dağıtıma göre cron, crond, rsync, restic veya borg benzeri farklı servis adları görülebilir. Gerçek servis adını önce sistemde doğrulamak daha doğrudur. Aşağıdaki kontrol, hangi servislerin görünür olduğunu ve disklerin nasıl bağlandığını hızlıca anlamaya yardım eder:

lsblk
df -h
systemctl list-units --type=service | grep -E 'cron|crond|rsync|restic|borg'

Beklenen durum, yedek disklerinin doğru bağlanmış görünmesi, boş alanın planı karşılaması ve kullandığınız yedekleme aracının ya da zamanlayıcının servis listesinde yer almasıdır. Hiçbir servis görünmüyorsa yedek işi çalışmıyor olabilir; bu durumda panel, paket adı veya systemd birimi yeniden kontrol edilmelidir.

Doğrulama: yedekten dönmeden güvenme

Yedekleme sisteminin çalışıp çalışmadığını anlamanın tek yolu, bir örnek geri yüklemeyi gerçekten denemektir. Önce küçük bir dosya, ardından mümkünse küçük bir uygulama verisi veya veritabanı kopyası seçin. Dosyanın yeni bir klasöre açıldığını, izinlerinin doğru geldiğini ve içeriğin okunabildiğini kontrol edin. Eğer veritabanı da yedekleniyorsa, ayrı bir test ortamında dump dosyasının geri alınabildiğini görmek çok daha değerlidir. Bu test, yalnızca arşiv dosyasının varlığını değil, saklanan verinin bozulmadığını da gösterir.

Doğrulamada şu sorulara kısa cevap arayın: Yedek dosyası beklenen tarihte oluştu mu? Zincirde eksik gün var mı? Restore edilen dosya orijinaliyle aynı mı? Geri yükleme süresi kabul edilebilir mi? Bu sorulardan biri bile boş kalıyorsa, yapı canlı kullanım için hazır sayılmaz. Uygulamada başarı, sadece yedek almak değil, yedekten dönünce işin devam etmesidir.

Geri dönüş planı: yeni sunucuya geçerken eski yolu açık tutun

Canlı değişikliklerde en sık yapılan hata, yeni yedek sunucusu sorunsuz görünür görünmez eski zinciri silmektir. Bunu yapmayın. Yeni hedefe geçişte en az bir başarılı yedek ve bir başarılı restore görmeden eski hedefi kapatmayın. Yeni iş başarısız olursa, işi durdurup hedefi eski sunucuya geri döndürün, gerekirse anahtarı ve firewall kuralını eski hale getirin ve son iyi kopyayı koruyun. Eğer yetki modeli değiştiyse, önce yeni erişimi doğrulayıp sonra eskisini kapatın. Bu sıra, veri kaybını değil kontrollü geçişi hedefler.

Bir diğer pratik nokta da geri dönüş süresidir. Yeni kurulumun kağıt üzerinde iyi olması yetmez; restore testi 5 dakika sürüyorsa ama üretimde 2 saat bekleniyorsa, RTO beklentiniz ile mimari arasında kopukluk vardır. Bu farkı en iyi gösteren şey, zaman ölçümlü bir test kaydıdır.

Canlıya almadan önce kısa kontrol

• Yedek sunucusu üretimden ayrı kimlik ve ayrı erişimle çalışıyor mu?
• Saklama süresi, kapasite ve değişim hızı arasında mantıklı bir denge kuruldu mu?
• Şifreleme anahtarları güvenli ve ayrı bir yerde mi tutuluyor?
• Offsite kopya gerçekten başka bir konumda var mı?
• Bir dosya ve bir veri parçası geri yüklenip okunabilir olduğu kanıtlandı mı?
• Yeni plan başarısız olursa eski hedefe dönüş yolu hazır mı?

Bu soruların tamamına net yanıt veremiyorsanız kurulum tamamlanmış sayılmamalıdır. Yedekleme altyapısında asıl kalite, sessizce çalışan bir işi değil, stres anında geri dönen bir işi kurabilmektir.