Günlük yedekleme planı, yalnızca her gece dosya kopyalamak değildir. Plan; hangi verinin korunacağını, ne kadar veri kaybının kabul edildiğini, hizmetin ne kadar sürede geri döneceğini ve geri yüklemeyi kimin yapacağını tanımlar. Bu rehber, bir web sitesi için uygulanabilir bir plan ve kaynağın üzerine yazmadan yapılan dosya geri yükleme deneyi oluşturur.
Görselin adım adım açıklaması
- 3 kopya: Üretim verisi ve iki yedek bulundur.
- 2 ortam: Aynı arıza alanına bağımlılığı azalt.
- 1 ayrı konum: Felakete karşı coğrafi ayrım yap.
- Geri yükle: Süreyi ve veri bütünlüğünü ölç.
Önce kurtarma hedeflerini belirleyin
RPO, son kullanılabilir yedekten sonra kaybedilebilecek veri aralığıdır. RTO, hizmetin yeniden kullanılabilir olması için hedeflenen süredir. Her gece tek yedek alan bir sistem, gün içinde yedekleme başarısızlığı da yaşanırsa 24 saatten fazla veri kaybedebilir. Sipariş veya sürekli işlem alan bir veritabanının RPO hedefi birkaç dakika ise günlük dosya yedeği tek başına yeterli değildir; ürünün desteklediği log/PITR veya daha sık yedekleme tasarımı gerekir.
Örnek planı kendi veri hacminiz ve sözleşmenizle doğrulayın:
| Alan | Örnek karar | Kabul kontrolü |
|---|---|---|
| Korunan veri | Site dosyaları, yapılandırma, uygulamaya uygun DB yedeği | Eksik yükleme dosyası veya secret bağımlılığı yok |
| Zaman | Her gün 03:00 UTC; Europe/Istanbul 06:00 | Zamanlayıcının gerçek saat dilimi kaydedildi |
| Saklama | 14 günlük kopya ve 4 haftalık kopya | Alan kapasitesi ve geri dönülebilir tarihler ölçüldü |
| İkinci kopya | Ayrı erişim hesabıyla korunan başka hata alanı | Ana hesabın ele geçirilmesi iki kopyayı da silemiyor |
| Sorumluluk | İşletim sorumlusu ve yedek kişi | Başarısız/kaçırılmış iş bildirimi gerçek alıcıya ulaşıyor |
| Kurtarma | Önce ayrı hedefte, ardından kontrollü geçiş | Veri doğruluğu ve gerçekleşen süre kaydedildi |
Bu süreler bir FibaCloud hizmet taahhüdü değildir. Panelde bulunan özellikleri, kota/ücretleri, şifreleme ve saklama seçeneklerini seçtiğiniz hizmetin güncel kapsamıyla doğrulayın. Ekran adlarının veya tüm planlarda aynı seçeneklerin bulunduğunu varsaymayın.
Tutarlı bir yedek alın
Veritabanı dosyalarını çalışan sunucudan sıradan tar ile kopyalamak tutarlı yedek oluşturmaz. MySQL için uygun dump/fiziksel yedek, PostgreSQL için uygun dump/base-backup ve log stratejisi gerekir. MySQL yönetim rehberi ayrı hedefe dump geri yüklemeyi gösterir; PostgreSQL rehberinde ürünün kendi yöntemini izleyin.
Aşağıdaki alıştırma yalnız değişmeyen örnek dosyalar içindir. Gerçek uygulamada dosya/veritabanı eşleşmesi için bakım penceresi, uygulamanın yedekleme mekanizması veya belgelenmiş snapshot tutarlılığı kullanın. Snapshot ve HA, bağımsız yedekle aynı şey değildir.
umask 077
lab_dir=$(mktemp -d)
mkdir "$lab_dir/source" "$lab_dir/backups" "$lab_dir/restore"
printf '%s\n' 'Backup verification' > "$lab_dir/source/index.txt"
printf '%s\n' 'version=1' > "$lab_dir/source/config.txt"
tar -czf "$lab_dir/backups/site.tar.gz" -C "$lab_dir/source" .
sha256sum "$lab_dir/backups/site.tar.gz" > "$lab_dir/backups/site.tar.gz.sha256"
sha256sum --check "$lab_dir/backups/site.tar.gz.sha256"
tar -tzf "$lab_dir/backups/site.tar.gz"Başarılı komut çıkışı, boş olmayan arşiv ve beklenen dosya listesi birlikte kontrol edilir. Hash, kopyanın değişip değişmediğini gösterir; dosyaların uygulama açısından tutarlı olduğunu veya arşivin güvenilir kaynaktan geldiğini tek başına kanıtlamaz. Arşiv ve hash aynı saldırgan tarafından değiştirilebiliyorsa bu kontrol yeterli değildir.
Ayrı hedefe geri yükleyin
Kendi oluşturduğunuz arşivi, boş restore dizinine açın. Bilinmeyen bir arşivi üretim dizinine veya root yetkisiyle çıkarmayın.
tar -xzf "$lab_dir/backups/site.tar.gz" --no-same-owner -C "$lab_dir/restore"
diff -r "$lab_dir/source" "$lab_dir/restore"diff fark göstermemeli. Bu deney veri eşitliğini sınar; gerçek site kabulü ayrıca HTTP yanıtını, kritik kullanıcı akışını, DB bağlantısını, dosya izinlerini ve gerekli eklentileri içerir. Geri dönüş denemesinde e-posta, ödeme, webhook ve zamanlanmış işlerin yanlışlıkla gerçek müşterilere işlem yapmasını önleyin. Kaynak site çalışırken üzerine geri yükleme yapmayın.
Başlangıç/bitiş zamanını, arşiv tarihini, dosya ve DB nesne sayılarını, uygulama testini ve sorumlu kişiyi kaydedin. Hedef RTO ile ölçülen süreyi karşılaştırın. Başarısız bir deney “yedek var” kabulüyle kapatılmaz; sorun giderildikten sonra yeniden denenir.
Zamanlama ve uyarıları doğrulayın
Ürünün zamanlayıcısında veya işletim sisteminde bir iş oluştururken çalışacak hesabı, açık saat dilimini, çakışan işleri ve başarısız çıkış kodlarını belirleyin. Secretları cron satırına yazmayın; yalnız iş hesabının okuyabildiği bir dosya veya secret yönetimi kullanın. Test verisiyle başarısız bir iş ve kaçırılmış bir zaman aralığı üretip bildirimin gerçekten ulaştığını doğrulayın.
Saklama temizliği yalnız yeni yedek ve ikinci kopya başarıyla doğrulandıktan sonra uygulanmalıdır. Son kullanılabilir kopyayı otomatik silen örnek komutlar kullanmayın. Şifreleme anahtarını yedeklerle aynı tek hata alanında tutmayın; kurtarma yetkisinin ve anahtar erişiminin de test edilmesi gerekir.
Bakım ve geri dönüş planı
Veri büyüklüğü, uygulama sürümü veya depolama hedefi değiştiğinde planı yeniden ölçün. Örnek olarak aylık tam geri yükleme tatbikatı ve her önemli değişiklik sonrasında ek test belirlenebilir; gerçek sıklık iş gereksiniminize bağlıdır. Test dizinlerini silmeden önce $lab_dir değerini ve içeriğini kontrol edin; üretim yollarına dönüştürülmüş değişkenlerle temizlik yapmayın.
Yeni zamanlama başarısız olursa önceki çalışan işi ve son geçerli yedeği koruyun. Hedefi değiştirmek veya başarısız kopyayı temizlemek, tek kullanılabilir yedeği silmeye yol açmamalıdır.
Kaynaklar
- CISA: yedeklerin ayrılması ve geri yükleme testi
- GNU tar: yedekleme ve geri yükleme
- MySQL 8.4: mysqldump ve tutarlılık sınırları
- PostgreSQL 16: SQL dump ile yedekleme
Teknik içerik ve kaynaklar 4 Ekim 2026 tarihinde gözden geçirildi. Sürüm veya sağlayıcı değişikliğinde ilgili resmî belgeyi yeniden kontrol edin.
Bir yanıt yazın