Bir sunucudaki veriyi kaybetmenin yolu çoktur: silinen bir tablo, bozulan bir disk, başarısız bir güncelleme ya da fidye yazılımı. Yedeğin var olması yetmez; ne zaman, nereye ve nasıl aldığın belirleyici olur. Sağlam bir yedekleme mimarisinin omurgası ise on yıllardır değişmeyen basit bir prensiptir.

Neden Tek Bir Yedek Yetmez?

Çoğu felaket senaryosunda asıl sorun, yedeğin hiç alınmamış olması değil, alınan tek kopyanın da kaybedilen veriyle aynı kaderi paylaşmasıdır. Yedeği üretim diskinin yanındaki ikinci bir partisyona koyduğunuzu düşünün: disk denetleyicisi (RAID controller) arızalanır ya da sunucu odasında bir elektrik dalgalanması yaşanırsa iki kopya da aynı anda gider. Fidye yazılımları ise daha da sinsi davranır; ağ üzerinden erişilebilen tüm bağlı sürücüleri şifreleyerek hem canlı veriyi hem de bağlı yedek alanını kullanılmaz hale getirir. Bu yüzden yedeği yalnızca "almak" değil, onu canlı veriden olabildiğince yalıtmak gerekir.

3-2-1 Kuralı Tam Olarak Ne Söyler?

Kuralın kendisi sayılarla özetlenir ve her rakamın somut bir karşılığı vardır. Amaç tek bir arıza noktasının (single point of failure) tüm yedeklerini birden götürmesini engellemektir. Yıllar içinde bu yaklaşımın 3-2-1-1-0 gibi genişletilmiş türevleri de ortaya çıktı; ek bir 1 çevrimdışı (air-gapped) ya da değiştirilemez (immutable) bir kopyayı, 0 ise doğrulanmış sıfır hatayı temsil eder. Temeli yine de aynıdır:

  • 3 kopya: Verinin biri canlı (production) olmak üzere toplam üç kopyası bulunmalı.
  • 2 farklı ortam: Kopyalar en az iki ayrı medya türünde tutulmalı; örneğin sunucunun yerel diski ile uzak bir nesne depolama (object storage).
  • 1 dış konum: Kopyalardan biri fiziksel olarak farklı bir lokasyonda, yani off-site olmalı.

Bu üçlü yapı, aynı sunucu odasındaki yangından donanım arızasına kadar geniş bir senaryo yelpazesini kapsar.

Tam, Artımlı ve Diferansiyel Yedek

Yedek tipini doğru seçmek hem depolama maliyetini hem de geri dönüş süresini etkiler. Üç temel yaklaşım çoğu hosting senaryosunu karşılar.

Yedek TipiKapsadığı VeriDisk KullanımıGeri Yükleme Hızı
Tam (Full)Tüm veriYüksekHızlı, tek adım
Artımlı (Incremental)Son yedekten beri değişenlerDüşükYavaş, zincir gerekir
DiferansiyelSon tam yedekten beri değişenlerOrtaOrta, iki adım

Yaygın bir düzen haftalık tam yedek, günlük artımlı yedek şeklindedir. Artımlı zincirde tek bir halkanın bozulması sonraki tüm geri yüklemeleri etkileyebileceğinden, zincir uzunluğunu sınırlı tutmak akıllıca olur.

Pratikte: rsync ile Off-site Kopya

Linux tabanlı bir sunucuda dosya seviyesinde off-site kopya almanın en sade yollarından biri rsync'tir. --link-dest parametresiyle sabit bağ (hardlink) tabanlı, az yer kaplayan artımlı anlık görüntüler üretebilirsin.

#!/bin/bash
SRC="/var/www/"
DEST="[email protected]:/backups/web"
DATE=$(date +%F)
PREV=$(ssh [email protected] "ls -1d /backups/web/* | tail -n1")

rsync -aHz --delete \
  --link-dest="$PREV" \
  -e "ssh -p 22" \
  "$SRC" "$DEST/$DATE/"

Bu betiği /etc/cron.daily/ altına koyup çalıştırılabilir yaparsan günlük off-site kopyan otomatikleşir. SSH anahtarı tabanlı kimlik doğrulama kullanmak, parolasız ve güvenli çalışması için şarttır. --link-dest sayesinde değişmeyen dosyalar fiziksel olarak yeniden kopyalanmaz; bunun yerine bir önceki yedeğe sabit bağ verilir, böylece her gün için ayrı bir tam dizin görmenize rağmen disk yalnızca değişen dosyalar kadar büyür. Nesne depolama tarafında ise rclone ile S3 uyumlu bir kovaya (bucket) senkronizasyon, aynı mantığı bulut sağlayıcılarına taşımanın temiz bir yoludur.

Veritabanını Tutarlı Yedeklemek

Dosya yedeği yeterli değildir; MySQL/MariaDB tablolarını canlıyken kopyalamak tutarsız bir dump üretebilir. mysqldump'ı doğru bayraklarla çağırmak işlemleri kilitlemeden tutarlı bir görüntü almanı sağlar.

mysqldump --single-transaction --quick --routines \
  --triggers --default-character-set=utf8mb4 \
  -u backup -p mydb | gzip > /backups/db/mydb-$(date +%F).sql.gz

InnoDB tabloları için --single-transaction kilitsiz ve tutarlı çalışırken, büyük veri tabanlarında fiziksel yedek için Percona XtraBackup daha düşük kesintiyle iş görür. Paylaşımlı bir web hosting paketinde site dosyalarınızı barındırırken, cPanel'in kendi yedekleme aracı genellikle hem veritabanını hem de e-postaları tek bir arşivde toplar.

Şifreleme ve Saklama Süresi

Off-site'a giden veri yola çıkmadan şifrelenmeli. Açık metin yedekler, depolama sağlayıcısı ele geçirilirse doğrudan sızıntıya dönüşür.

  • Aktarım sırasında: SSH/TLS ile şifreli kanal kullan; düz FTP'den kaçın.
  • Durağan halde: Arşivleri gpg veya openssl enc -aes-256-cbc ile şifrele.
  • Saklama (retention): Örneğin 7 günlük, 4 haftalık, 6 aylık bir GFS (Grandfather-Father-Son) rotasyonu hem geçmişe erişim hem de disk tasarrufu sağlar.

Bogahost Önerisi: Yedekleme işini canlı sunucunun kaynaklarından ayırın. Yedekleri ürettikten sonra ayrı bir sanal sunucu üzerinde toplayıp arşivlemek, hem üretim sunucusunun I/O yükünü hafifletir hem de tek bir makinenin çökmesi durumunda yedeklerinizi güvende tutar.

Geri Yükleme Testi: Yedeğin En Çok Atlanan Kısmı

Test edilmemiş bir yedek, çoğu durumda yedek sayılmaz. Geri yükleme prosedürünü düzenli aralıklarla, tercihen izole bir test ortamında denemek gerekir. Kontrol edilmesi gereken başlıca noktalar:

  • Bütünlük: Arşivin açılabildiğini doğrula (gzip -t, tar -tzf).
  • RTO: Sıfırdan geri yüklemenin gerçekte ne kadar sürdüğünü ölç.
  • RPO: En kötü senaryoda kaç saatlik veri kaybedilebileceğini netleştir.

RTO ve RPO hedeflerini önceden belirlemek, yedek sıklığını ve tipini seçerken sana somut bir pusula verir.

Otomasyon ve İzleme

Manuel yedek er ya da geç unutulur. cron ile zamanlama yapmanın yanında, başarısız işleri raporlayan bir uyarı mekanizması kurmak kritik. Basit bir yaklaşım, betiğin çıkış kodunu kontrol edip başarısızlıkta e-posta veya webhook göndermektir.

# /etc/crontab içinde
30 2 * * * root /usr/local/bin/backup.sh || \
  curl -fsS https://hc-ping.com/UUID/fail

Bu "dead man's switch" mantığı, yedek hiç çalışmadığında bile (sunucu kapalıysa) seni haberdar eder; çünkü beklenen ping gelmez.

Özetle

3-2-1 kuralı modern bir veri koruma stratejisinin temelini kurar: üç kopya, iki ortam, bir dış konum. Doğru yedek tipini seçmek, veritabanını tutarlı almak, şifrelemek ve en önemlisi geri yüklemeyi düzenli test etmek bu temeli sağlamlaştırır. Otomasyonla desteklenen, izlenen bir yedekleme akışı, bir gün gerçekten ihtiyaç duyduğunuzda paniğe değil rahatlamaya dönüşür.

Reklam Alanı

İçerik Altı (728x90)

Yorumlar (0)

Henüz yorum yapılmamış. İlk yorumu siz yapın!

Yorum Yap

Maksimum 2000 karakter