Hosting

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

Sunucu Yedekleri Ne Kadar Süre Saklanmalı? 3-2-1 Yaklaşımı konusunda güvenli uygulama, doğrulama ve sık yapılan hatalar için UST Bilişim teknik rehberi.

Sunucu Yedekleri Ne Kadar Süre Saklanmalı? 3-2-1 YaklaşımıTeknik bilgi • Uygulanabilir yaklaşım
Sunucu Yedekleri Ne Kadar Süre Saklanmalı? 3-2-1 Yaklaşımı konusunda güvenli uygulama, doğrulama ve sık yapılan hatalar için UST Bilişim teknik rehberi.

Yedek politikasını yalnız “günlük yedek alınıyor” bilgisiyle değerlendirmeyin. Kaç saatlik veri kaybına izin verildiği, kaç saatte geri dönüleceği ve geçmişte kaç noktaya dönülebileceği yazılı olmalıdır.

1. Saklama tablosu belirleyin

Küçük bir kurumsal site için örnek başlangıç: 7 günlük, 4 haftalık, 6 aylık kopya. Yoğun sipariş alan sitede günlük veritabanı yedeği yeterli olmayabilir; veri kaybı hedefi saatlik veya daha sık yedek gerektirebilir. Yasal saklama gereksinimini bu teknik örnekten çıkarmayın.

2. Kopyanın bütünlüğünü kontrol edin

gzip -t site-veritabani.sql.gz
sha256sum site-veritabani.sql.gz > site-veritabani.sql.gz.sha256
sha256sum -c site-veritabani.sql.gz.sha256

Bu komutlar gzip/aktarım bütünlüğünü sınar; veritabanının geri yüklenebildiğini kanıtlamaz. Dosya ve SQL yedeğinin aynı uygulama sürümüyle uyumlu olduğunu kaydedin.

3. Sunucu dışında ayrı erişimli kopya tutun

Aynı diskteki ikinci klasör, disk kaybına karşı yedek değildir. Harici depolamayı farklı yetkilerle kullanın; üretim hesabının tüm geçmiş kopyaları kolayca silememesini sağlayın. Şifreleme anahtarının kurtarma kopyasını da erişilebilir ama ayrı koruyun.

4. Silme politikasını önce raporlayın

find /srv/backups/ornek-site -maxdepth 1 -type f -name '*.sql.gz' -mtime +30 -print

Bu yalnızca adayları listeler; otomatik silmez. Dosya adından haftalık/aylık kopyayı ayıramıyorsanız zaman filtresiyle silme eklemeyin. Yedek yazılımının retention mekanizmasını tercih edin.

5. Geri dönüş tatbikatı

Aylık olarak izole test ortamına dosya ve veritabanı geri yükleyin. E-posta, ödeme ve webhook çıkışlarını kapatın. Giriş, içerik, dosya yükleme ve örnek sipariş akışını test edip süreyi kaydedin. Başarısız tatbikatta eski kopyaları silmeyi durdurun.

Ölçülebilir bir politika kaydı

AlanÖrnek hedef
RPOEn fazla 4 saatlik veri kaybı; iş ihtiyacına göre
RTO2 saatte hizmete dönüş; tatbikatta ölçülür
KopyalarÜretim + yerel yedek + farklı yetkili harici kopya
TatbikatAylık izole geri yükleme

Bu örnek hedefler tüm işletmelere uygun değildir. Sipariş hacmi yüksekse RPO daha kısa olabilir. Tatbikat 5 saat sürüyorsa kâğıttaki 2 saat hedefini gerçekleşmiş saymayın; aktarım, import ve doğrulama sürelerini ayrı ölçün.

UST Bilişim Yaklaşımı

Bilgiyi uygulanabilir projeye dönüştürelim.

İhtiyacınızı teknik, operasyonel ve ticari açıdan değerlendirip doğru çözüm yol haritasını birlikte oluşturalım.

Projenizi Anlatın