Web Sitesi Yedekleme Rehberi: 3-2-1 Kuralı ve Geri Dönüş Planı

Yedeğin değeri, ona ihtiyaç duyduğunuz gün anlaşılır. Hatalı bir eklenti güncellemesi, yanlışlıkla silinen bir klasör, ele geçirilmiş bir yönetici hesabı veya fidye yazılımı; hepsinin ortak çözümü düzgün alınmış ve geri yüklenebildiği test edilmiş bir yedektir. Bu rehberde neyi, ne sıklıkla, nereye yedeklemeniz gerektiğini ve bir sorun anında nasıl hareket edeceğinizi anlatıyoruz.

Neyi yedeklemelisiniz?

Bir web sitesi tek bir parçadan oluşmaz. Eksiksiz bir yedek şunları kapsamalıdır:

• Dosyalar: Uygulama kodu, tema ve eklentiler, kullanıcıların yüklediği medya dosyaları (örneğin WordPress'te wp-content/uploads).
• Veritabanı: İçerik, kullanıcılar, siparişler, ayarlar. Dinamik sitelerde en sık değişen ve en kritik parçadır.
• Yapılandırma: .env, wp-config.php gibi ayar dosyaları, web sunucusu yapılandırmaları, cron tanımları.
• DNS kayıtları: Alan adınızın tüm kayıtlarının (A, MX, TXT, CNAME) güncel bir dökümü.
• E-posta: E-posta kutuları sitenizle aynı sunucudaysa ayrıca planlanmalıdır.

Ayrıca SSL sertifikalarının özel anahtarları, API anahtarları ve parolalar gibi gizli bilgileri yedeklerken bunların şifreli saklandığından emin olun.

RPO ve RTO: Önce hedefleri belirleyin

Yedekleme planı iki soruya verilen cevaplarla şekillenir:

• RPO (Recovery Point Objective): En fazla ne kadar veri kaybını kabul edebilirsiniz? Günde bir kez yedek alıyorsanız, en kötü durumda son 24 saatlik veriyi kaybedersiniz. Saatte onlarca sipariş alan bir e-ticaret sitesi için bu kabul edilemez olabilir; haftada bir güncellenen bir tanıtım sitesi için ise fazlasıyla yeterlidir.
• RTO (Recovery Time Objective): Bir sorun anında sitenin ne kadar sürede tekrar çalışır hale gelmesi gerekiyor? Bu süre, yedeğin nerede durduğuna, boyutuna ve geri yükleme sürecinin ne kadar hazır olduğuna bağlıdır.

Bu iki değeri belirlemeden yapılan yedekleme planı, genellikle ya yetersiz ya da gereksiz derecede pahalı olur.

3-2-1 kuralı

Yedekleme dünyasında kabul görmüş temel prensip 3-2-1 kuralıdır:

• 3 kopya: Verinin canlı kopyası dahil en az üç kopyası bulunsun.
• 2 farklı ortam: Kopyalar en az iki farklı depolama ortamında veya sisteminde dursun.
• 1 kopya başka konumda: En az bir kopya fiziksel olarak farklı bir konumda (farklı veri merkezi, farklı sağlayıcı) saklansın.

Bu kural, tek bir arızanın ya da olayın tüm kopyaları aynı anda yok etmesini önlemek için tasarlanmıştır. Sitenizle aynı sunucuda duran bir yedek, disk arızasında, sunucunun ele geçirilmesinde veya hesabın kapatılmasında sitenizle birlikte kaybolur.

3-2-1-1-0 genişletmesi

Fidye yazılımlarının yedekleri de hedef alması nedeniyle kural günümüzde sıklıkla şu şekilde genişletiliyor:

• +1 değiştirilemez veya çevrimdışı kopya: Silinemeyen (immutable, örneğin nesne depolamada nesne kilidi) ya da ağdan ayrılmış bir kopya.
• 0 hata: Yedeklerin düzenli olarak doğrulanması ve geri yükleme testlerinin hatasız tamamlanması.

Yedekleme türleri

• Tam yedek: Her seferinde tüm verinin kopyalanması. Geri yüklemesi en basit olandır; ancak en çok alanı ve süreyi gerektirir.
• Artımlı (incremental) yedek: Son yedekten bu yana değişen verinin kopyalanması. Hızlıdır ve az yer kaplar; geri yükleme için zincirin tamamı gerekir.
• Fark (differential) yedek: Son tam yedekten bu yana değişen verinin kopyalanması.
• Snapshot: Sanal sunucunun veya diskin belirli bir andaki görüntüsü. Hızlıdır ve büyük değişikliklerden önce kullanışlıdır; ancak çoğu zaman aynı altyapıda durduğu için tek başına yedek stratejisi yerine geçmez.

Restic, BorgBackup gibi modern araçlar, veri tekrarını önleme (deduplication) ve şifreleme sayesinde sık ve verimli yedek almayı kolaylaştırır.

Pratik örnek: Basit otomatik yedek

Aşağıdaki örnek, bir Linux sunucuda veritabanını ve site dosyalarını günlük olarak yedekleyip eski yedekleri temizleyen basit bir betiktir. Kendi ortamınıza göre uyarlamanız gerekir.

#!/usr/bin/env bash
set -euo pipefail

TARIH=$(date +%F)
HEDEF=/yedek/site
mkdir -p "$HEDEF"

# Veritabanı yedeği (kimlik bilgileri ~/.my.cnf dosyasından okunur)
mysqldump --single-transaction --routines --triggers sitedb \
  | gzip > "$HEDEF/db-$TARIH.sql.gz"

# Site dosyaları
tar -czf "$HEDEF/dosyalar-$TARIH.tar.gz" -C /var/www site

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

--single-transaction parametresi, InnoDB tablolarında siteyi kilitlemeden tutarlı bir döküm alınmasını sağlar. Veritabanı parolasını betiğin içine yazmak yerine yalnızca ilgili kullanıcının okuyabildiği bir yapılandırma dosyasında tutun.

Betiği cron ile her gece çalıştırabilirsiniz:

30 3 * * * /usr/local/bin/site-yedek.sh

Bu betik yedekleri yalnızca aynı sunucuda tutar; 3-2-1 kuralını sağlamak için yedeklerin başka bir konuma da aktarılması gerekir. Örneğin rclone veya restic ile S3 uyumlu bir nesne depolama alanına şifreli olarak gönderebilirsiniz.

Paylaşımlı hosting'de yedekleme

Paylaşımlı hosting kullanıyorsanız sunucuya root erişiminiz olmadığı için seçenekleriniz farklıdır:

• Kontrol panelinin yedekleme aracıyla (örneğin cPanel'de tam hesap yedeği) düzenli yedek alıp bilgisayarınıza veya bulut depolamaya indirin.
• WordPress kullanıyorsanız yedekleri harici bir depolama alanına gönderebilen yedekleme eklentilerini değerlendirin.
• Hosting sağlayıcınızın kendi yedekleme politikasını öğrenin; ancak bunu tek güvenceniz olarak görmeyin.

Geri dönüş planı

Yedek almak işin yarısıdır. Bir sorun anında panik içinde karar vermemek için geri dönüş planınızı önceden yazılı hale getirin.

Planın içermesi gerekenler

1. Sorumlular: Bir olay anında kim karar verecek, kim teknik müdahaleyi yapacak?
2. Erişim bilgileri: Yedek deposuna, sunucuya, DNS paneline ve alan adı kayıt firmasına nasıl erişileceği. Bu bilgilerin tek bir kişinin bilgisayarında durmaması gerekir.
3. Adım adım geri yükleme: Hangi yedek seçilecek, dosyalar ve veritabanı hangi sırayla geri yüklenecek, hangi ayarlar güncellenecek.
4. Doğrulama: Geri yüklemeden sonra kontrol edilecek sayfalar ve işlevler (giriş, form, ödeme adımları).
5. İletişim: Müşterilere ve ekibe nasıl bilgi verileceği.

Saldırı sonrası geri yükleme

Site ele geçirildiyse yalnızca yedeği geri yüklemek yetmez. Saldırganın giriş noktası kapatılmazsa site kısa sürede yeniden ele geçirilir. Bu durumda:

• Saldırının ne zaman başladığını tespit edip ondan önceki temiz bir yedeği seçin.
• Tüm parolaları (yönetici, FTP/SFTP, veritabanı, hosting paneli) değiştirin.
• Çekirdek yazılımı, temaları ve eklentileri güncelleyin; kullanılmayanları kaldırın.
• Sunucu ve uygulama günlüklerini inceleyerek giriş noktasını bulun.

Geri yükleme testi

Hiç geri yüklenmemiş bir yedeğin çalışacağından emin olamazsınız. Belirli aralıklarla (örneğin üç ayda bir) yedeği ayrı bir test ortamına geri yükleyin, sitenin çalıştığını doğrulayın ve geçen süreyi not alın. Bu süre, gerçekçi RTO değerinizdir.

Özet: Yedekleme kontrol listesi

• Dosyaları, veritabanını, yapılandırmayı ve DNS kayıtlarını yedekleyin.
• RPO ve RTO hedeflerinizi belirleyin, yedek sıklığını buna göre ayarlayın.
• 3-2-1 kuralını uygulayın; en az bir kopyayı farklı bir konumda tutun.
• Mümkünse değiştirilemez veya çevrimdışı bir kopya bulundurun.
• Yedekleri şifreleyin ve erişim bilgilerini güvenli saklayın.
• Yedekleme işinin başarısız olması durumunda uyarı alacağınız bir izleme kurun.
• Geri dönüş planını yazılı hale getirin ve düzenli olarak geri yükleme testi yapın.

Sitenizin barındırma altyapısını ve yedekleme ihtiyaçlarınızı birlikte değerlendirmek için Web Hosting, VPS ve VDS sayfalarımıza göz atabilir ya da iletişim sayfamızdan bize ulaşabilirsiniz.