Sunucu Yedekleri Ne Kadar Süre Saklanmalı? 3-2-1 Yaklaşımı

Sunucu Yedekleri Ne Kadar Süre Saklanmalı? 3-2-1 Yaklaşımı gibi sunucu konularında güvenli çözüm, ilk bulunan komutu çalıştırmak değil; servis durumu, kaynak kullanımı, loglar ve geri alma planını birlikte değerlendirmektir.

Sunucu Yedekleri Ne Kadar Süre Saklanmalı için doğru başlangıç

Sunucu tarafında ilk adım değişiklik yapmak değil ölçüm almaktır. Servis durumu, disk/inode, RAM, load ve ilgili error log aynı zaman aralığında kaydedildiğinde semptomun gerçek kaynağı daha hızlı ayrılır.

1. retention

retention aşamasında önce mevcut servis durumunu, kaynak kullanımını ve ilgili log zaman aralığını kaydedin. Bir servisi yeniden başlatmadan veya konfigürasyon değiştirmeden önce hatanın tekrar üretilebilir olup olmadığını doğrulamak teşhisi kolaylaştırır.

• retention: mevcut değer ile hedef sonucu yan yana kaydedin.
• Disk, inode, RAM ve process durumunu ölçün.
• Değişiklikten önce konfigürasyon/yedek alın.
• Düzeltme sonrası web, cron ve bağımlılık testlerini yapın.

2. offsite kopya

offsite kopya için panel arayüzü tek başına yeterli değildir. İşletim sistemi ve servis seviyesindeki loglar, disk/inode kullanımı, process durumu ve port dinleme bilgisi birlikte incelendiğinde sorunun gerçek katmanı ortaya çıkar.

• Servis ve sistem loglarını aynı zaman aralığında inceleyin.
• offsite kopya: mevcut değer ile hedef sonucu yan yana kaydedin.
• Değişiklikten önce konfigürasyon/yedek alın.
• Düzeltme sonrası web, cron ve bağımlılık testlerini yapın.

3. restore testi

restore testi üzerinde düzeltme yaparken önce düşük riskli adımı uygulayın. Dosya silme, paket yükseltme veya servis konfigürasyonu değiştirme gibi geri dönüşü zor işlemlerden önce yedek alın ve önceki yapılandırmayı ayrı dosyada saklayın.

• Servis ve sistem loglarını aynı zaman aralığında inceleyin.
• Disk, inode, RAM ve process durumunu ölçün.
• restore testi: mevcut değer ile hedef sonucu yan yana kaydedin.
• Düzeltme sonrası web, cron ve bağımlılık testlerini yapın.

4. RPO/RTO

RPO/RTO sonrasında yalnız ana sayfayı açmakla yetinmeyin. PHP çalışması, cron, SSL, mail/API bağlantıları ve gerekiyorsa panel işlemleri ayrı ayrı test edilmelidir; çünkü servis ayağa kalksa bile uygulama bağımlılıklarından biri bozuk kalabilir.

• Servis ve sistem loglarını aynı zaman aralığında inceleyin.
• Disk, inode, RAM ve process durumunu ölçün.
• Değişiklikten önce konfigürasyon/yedek alın.
• RPO/RTO: mevcut değer ile hedef sonucu yan yana kaydedin.

Önerilen uygulama sırası

1. Mevcut yapı ve bağımlılıkları kaydedin.
2. Değişikliği mümkün olan en dar kapsamda uygulayın.
3. retention: ilk doğrulama noktasını tamamlamadan sonraki adıma geçmeyin.
4. Kullanıcı akışını ve bağlı servisleri ayrıca test edin.
5. Sonuç beklenen gibi değilse önceki yapılandırmaya dönün ve kök nedeni yeniden ölçün.

Sık yapılan hatalar

Sunucu sorunlarında en riskli yaklaşım, nedeni doğrulamadan log, cache veya yedek dosyalarını topluca silmek ya da servisleri art arda yeniden başlatmaktır. Bu davranış belirtinin kaynağını gizleyebilir. Önce ölçüm alın, sonra tek değişiklik yapın ve sonucu aynı metriklerle karşılaştırın.

Doğrulama ve geri alma

Düzeltme sonrası servis yalnız 'active' görünmemeli; gerçek istek altında doğru cevap vermelidir. HTTP yanıtı, error log, kaynak tüketimi ve arka plan görevlerini birkaç dakika izleyin. Sorun tekrar ederse son değişikliği geri alabilecek dosya/yedek yolunu hazır tutun.

Kaynak ve ilgili hizmet

Teknik ayrıntılarda ürün veya standardın güncel resmî dokümantasyonunu esas alın: resmî teknik kaynak. UST Bilişim tarafında ilgili altyapı veya web projesi için hizmetlerimizi inceleyebilir, mevcut sisteminizin analizi için iletişim sayfasından bize ulaşabilirsiniz.

Bu konuyla birlikte okuyun

• Önceki ilgili rehber
• Sonraki ilgili rehber