Sunucu Yedekleme Stratejisi: Snapshot mı, Yedek mi?

Snapshot, sunucunun o anki halinin aynı altyapıda tutulan bir kopyasıdır; hızlı geri dönüş için idealdir ama yedek yerine geçmez. Gerçek yedek, verinin sunucudan bağımsız bir yerde, sürümlü olarak saklanmasıdır. Sağlıklı bir strateji ikisini birlikte kullanır: değişiklik öncesi snapshot, düzenli olarak da dışarıda tutulan yedek.

Snapshot ile yedek farkı

Snapshot ne zaman kullanılır?

• Sistem güncellemesi öncesinde
• Panel veya web sunucusu yapılandırması değiştirmeden önce
• Yeni bir uygulama sürümü yayınlamadan önce
• Riskli bir denemeden önce (kütüphane yükseltmesi, kernel değişikliği)

Kural: snapshot'ı işleme başlamadan hemen önce alın ve iş bittiğinde silin. Uzun süre tutulan snapshot'lar disk tüketir ve bazı sistemlerde performansı etkiler.

3-2-1 kuralı

Verinin üç kopyası olsun, iki farklı ortamda saklansın, bir kopya bulunduğunuz yerin dışında dursun. Sunucu senaryosunda karşılığı: canlı sistem, sağlayıcının veya sizin düzenli yedeğiniz ve farklı bir sağlayıcıda/lokasyonda tutulan üçüncü kopya.

Amaç fazlalık değil, tek bir olayın (donanım arızası, hesap askıya alınması, fidye yazılımı, hatalı silme) tüm kopyaları aynı anda yok etmesini engellemektir.

Neyi, ne sıklıkla?

Saklama politikası

Yalnızca son yedeği tutmak yeterli değildir: bir sorunun fark edilmesi günler sürebilir ve son yedek de bozulmuş veriyi içerebilir. Yaygın bir düzen şudur: son 7 günlük günlük yedek, son 4 haftalık haftalık yedek ve son 6–12 aylık aylık yedek. Saklama süresi, sektörünüzün gerekliliklerine göre uzayabilir; kişisel veri saklıyorsanız süreyi hukuk danışmanınızla belirleyin.

Geri dönüş provası

1. Test için ayrı bir sunucu veya alan hazırlayın.
2. Son yedekten geri yükleyin.
3. Uygulamanın açıldığını, verilerin güncel olduğunu doğrulayın.
4. Süreyi ölçün: gerçek bir kayıpta ne kadar sürede ayağa kalkarsınız (RTO)?
5. Ne kadar veri kaybedeceğinizi belirleyin (RPO): son yedekten bu yana geçen süre.
6. Sonuçları yazılı hale getirin.

RTO ve RPO değerleri, yedekleme sıklığınızın doğru olup olmadığını gösteren tek somut ölçüttür.

Sık yapılan hatalar

• Yedeği aynı sunucuda veya aynı altyapıda tutmak
• Yedeğin başarıyla tamamlandığını kontrol etmemek
• Geri dönüşü hiç denememek
• Veritabanını tutarlı biçimde değil, çalışırken kopyalamak
• E-posta ve yapılandırma dosyalarını plana dahil etmemek
• Snapshot'ı yedek sanmak

Otomasyon ve izleme

Yedekleme işlerini zamanlanmış görevle otomatikleştirin ve sonucu bir bildirim kanalına bağlayın. "Yedek alınıyordur" varsayımı, veri kaybı vakalarının en yaygın ortak noktasıdır. Disk doluluğu nedeniyle sessizce başarısız olan yedek işleri sık görülür; disk eşiği uyarısını da kurun.

Panel üzerinden yedekleme adımlarını cPanel'de yedek alma, WordPress tarafını WordPress yedekleme yazısında anlattık.

Netx'te yedekleme

Sunucu paketlerinde yedekleme kapsamını ve saklama süresini sipariş öncesinde teyit edin; VDS, VPS ve dedicated sunucu sayfalarından seçenekleri inceleyebilirsiniz. Yedekleme kurgusunu ve geri dönüş provasını devretmek isterseniz sunucu yönetim hizmeti kapsamında değerlendirilebilir.

Sık sorulan sorular

Snapshot yedek yerine geçer mi?

Geçmez. Aynı altyapıda durduğu için altyapı kaynaklı bir olayda birlikte kaybolabilir.

Kaç sürüm saklamalıyım?

En az son yedi gün. Sorunun geç fark edilme ihtimaline karşı haftalık ve aylık kopyalar da tutun.

Veritabanı yedeği çalışırken alınabilir mi?

Alınabilir ama tutarlılık için uygun yöntem kullanılmalıdır; aksi halde yarım işlemler yedeğe yansır.

Yedek nereye konmalı?

Sunucudan bağımsız bir depolama alanına. Mümkünse farklı bir sağlayıcı veya lokasyon tercih edin.

Fidye yazılımı yedekleri de şifreler mi?

Yedek alanına sunucudan sürekli yazma erişimi varsa şifreleyebilir. Bu yüzden erişim tek yönlü ve sınırlı olmalıdır.