Yedekleme Stratejisi: 3-2-1 Kuralı ile Veri Güvenliği

Yedeğiniz var mı sorusuna çoğu site sahibi “hosting alıyor zaten” diye yanıt verir. Sonra bir eklenti güncellemesi veritabanını bozar, hata iki gün fark edilmez ve o iki günün yedeği döngüden çıkmıştır. Yedekleme stratejisi tam da bu boşluğu kapatan plandır: kaç kopya, nerede, ne sıklıkla ve geri dönüş kaç dakika sürer.

Bu yazıda 3-2-1 kuralını LIONFIN web hosting hesabındaki tipik bir siteye (dosyalar, veritabanı, e-posta) uyguluyor, cron ile otomatikleştiriyor ve en çok atlanan adımı, geri yükleme testini, ölçülebilir hâle getiriyoruz.

3-2-1 yedekleme stratejisi nedir?

Kural üç rakamla özetlenir ve her rakam ayrı bir riski kapatır:

Hosting sağlayıcısının günlük yedeği yalnızca ilk rakamın bir parçasıdır: kopya aynı altyapıda durur ve döngü süresi sınırlıdır. Kuralı tamamlayan, sizin aldığınız ve başka yere koyduğunuz kopyalardır. Güncel yorumlarda kurala bir “1” daha eklenir: bir kopya çevrimdışı ya da değiştirilemez (immutable) olsun; fidye yazılımı, bağlı olduğu her diski şifreler.

Neden hosting yedeği tek başına yetmez?

LIONFIN hosting paketlerinde günlük yedek vardır ve çoğu kazada ilk başvurulan kaynaktır. Yine de yedekleme stratejisinin tamamı olamaz; çünkü:

• Döngü süresi: Sağlayıcı yedekleri belirli gün geriye kadar tutar; fark edilmesi haftalar süren bir veri bozulması döngüden çıkar.
• Aynı altyapı: Yedek, canlı veriyle aynı veri merkezinde ve aynı hesap altındadır; hesap erişimini kaybederseniz yedeğe de ulaşamazsınız.
• Ayrıntı düzeyi: Sağlayıcı yedeği tüm hesabı geri yükler; tek bir tabloyu ya da tek bir klasörü geri almak sizin kendi yedeğinizle daha hızlıdır.
• Uygulama tutarlılığı: Dosya ve veritabanının aynı anda alındığından emin olmak için yedeği uygulama düzeyinde planlamak gerekir.

Sağlayıcı yedeğini “ilk kopya”, kendi otomatik yedeğinizi “ikinci ortam”, harici depoya kopyaladığınız sürümü “sunucu dışı kopya” olarak konumlandırdığınızda kural tamamlanır.

Web sitesi için uygulama: dosyalar ve veritabanı

Tipik bir sitede yedeklenecek iki şey vardır: dosyalar (public_html, yüklemeler, tema ve eklentiler) ve veritabanı. Uygulama adımları:

1. Panel yedeği: cPanel’de Backup Wizard ile tam ya da kısmi yedek, Plesk’te Backup Manager ile zamanlanmış yedek tanımlayın; adımlar cPanel yedek alma ve geri yükleme ve Plesk yedekleme ve geri yükleme rehberlerinde.
2. Uzak hedef: Plesk Backup Manager yedeği doğrudan FTP/SFTP ya da bulut depolamaya gönderebilir; cPanel’de yedek dosyasını cron ile uzak sunucuya kopyalayın.
3. Yerel kopya: Haftada bir yedeği bilgisayarınıza ya da ofis NAS’ına indirin; bu kopya çevrimdışı olduğu için fidye yazılımından etkilenmez.
4. Sıklık: İçerik her gün değişiyorsa günlük, e-ticarette sipariş kaybını önlemek için veritabanı saatlik.
5. Saklama: Günlükleri iki hafta, haftalıkları iki ay, aylıkları bir yıl tutan kademeli düzen hem alan hem geçmiş sağlar.

Sitenin büyüklüğü hosting kotasını zorluyorsa yedekleri hesap içinde biriktirmeyin; kota takibi için cPanel disk kotası yazısına bakın.

Otomasyon: cron ile günlük yedek betiği

Kendi ikinci kopyanızı almak için hosting hesabınızda çalışacak basit bir betik yeterlidir. /home/kullanici/yedek.sh dosyasını oluşturun:

#!/bin/bash
TARIH=$(date +%F)
HEDEF=/home/kullanici/yedek

mysqldump -u DB_KULLANICI -pDB_SIFRE DB_ADI | gzip > $HEDEF/db-$TARIH.sql.gz
tar -czf $HEDEF/site-$TARIH.tar.gz /home/kullanici/public_html

# 14 günden eski yedekleri sil
find $HEDEF -type f -mtime +14 -delete

Ardından panelden her gece 03:00’te çalışacak bir cron görevi tanımlayın:

0 3 * * * /bin/bash /home/kullanici/yedek.sh > /dev/null 2>&1

Cron görevinin nasıl ekleneceği cPanel cron job oluşturma ve Plesk zamanlanmış görevler rehberlerinde anlatılmıştır. Üçüncü kopya için betiğin sonuna rsync ya da rclone ile uzak depolamaya kopyalama satırı ekleyin; böylece sunucu dışı kopya da elle işlem gerektirmez.

RPO, RTO ve geri yükleme testi

İyi bir yedekleme stratejisi iki soruya sayıyla yanıt verir: en fazla ne kadarlık veri kaybı kabul edilebilir (RPO) ve site en geç ne kadar sürede ayağa kalkmalı (RTO)?

Hedefleri belirledikten sonra test edin: üç ayda bir yedeği bir alt alan adına ya da yerel ortama açın, sitenin çalıştığını ve son kayıtların yerinde olduğunu doğrulayın, süreyi not edin. Ölçülen süre RTO hedefini aşıyorsa düzeni değiştirin. Test edilmemiş yedek, geri yükleme günü keşfedilen bir sürprizdir; en sık görülen sürprizler eksik veritabanı, bozuk arşiv ve yanlış klasör yoludur.

E-posta ve kontrol listesi

Web sitesi kadar e-posta da yedeklenmelidir; kurumsal mail hesaplarında sunucu tarafı yedek ve arşiv politikası bu işi görür, mail hostingde ise istemci arşivlerini düzenli kopyalamak gerekir. Ayrıntı kurumsal mail yedekleme ve arşivleme ve e-posta arşivleme stratejileri yazılarında.

Kontrol listesi:

• Canlı veri dışında en az iki kopya var.
• Kopyalardan biri farklı bir ortamda, biri sunucu dışında.
• En az bir kopya çevrimdışı ya da değiştirilemez.
• Yedek otomatik alınıyor, sonuç e-postayla ya da izleme aracıyla bildiriliyor.
• Veritabanı ve dosyalar tutarlı biçimde aynı zamanda yedekleniyor.
• RPO ve RTO hedefi yazılı, son test tarihi ve süresi kayıtlı.
• Yedek dosyaları belge kökü dışında ve erişimi kısıtlı.
• Ele geçirme senaryosu için temiz bir tarihe dönüş planı var; adımlar web sitesi hacklendi: ne yapmalı yazısında.