Hosting Yedekleme Stratejisi: 3-2-1 Kuralı, JetBackup ve Restore Drill (2026)

Hosting Yedekleme Stratejisi: 3-2-1 Kuralı, JetBackup ve Restore Drill (2026)

"Yedeğim var" cümlesi, "yedeğim geri yükleniyor" cümlesinden çok farklı bir şeydir. Sysadmin dünyasında bu farkın adı Schrödinger backup'tır: kutuyu açıp restore tatbikatı yapana kadar yedeğinizin canlı mı, ölü mü olduğunu bilemezsiniz. Bu rehber hosting yedekleme stratejisini sıfırdan kurarken (ve eski stratejinizi denetlerken) bilmeniz gereken her şeyi kapsıyor: yedek türleri, 3-2-1 kuralı, hosting-level / application-level / file-level katmanlama, JetBackup'ın gerçekte ne yaptığı, modern offsite araçları (BorgBackup, Restic, rclone) ve en kritik bölüm — restore drill.

Buyukweb perspektifi: cPanel hosting paketlerimizde JetBackup ile haftalık otomatik yedek harici sunuculara standart olarak çalışıyor. "Günlük yedek" reklamı yapan sağlayıcılara karşı bizim çizgimiz net: gerçeği yazıyoruz — haftalık. Günlük RPO ihtiyacınız varsa bu rehberdeki çok katmanlı modeli kurun (JetBackup haftalık + UpdraftPlus gece yarısı + DB cron + offsite rclone). VDS paketlerinde root erişim sizde — BorgBackup veya Restic ile saatlik incremental kurmak teknik olarak mümkün. Bu yazı strateji seviyesinde; cPanel Backup Wizard adım adım için ayrı bir rehberimiz var, veritabanı-spesifik PITR için de ayrı bir rehber.

Neden Yedekleme Kaçınılmaz?

Yedek yokken çöken bir site, kötü bir gün değil kapanan bir iş'tir. Veri kaybı yaşayan KOBİ'lerin yarıdan fazlası altı ay içinde kapanır — sektör araştırmalarının ortak bulgusu. Yedek ihtiyacı yaratan beş ana senaryo:

Ransomware ve malware: 2020 sonrası dünya genelinde KOBİ sitelerine yönelik fidye yazılımı saldırıları katlanarak arttı. Saldırgan dosyaları AES-256 ile şifreler, fidye talep eder. Çözüm: immutable (silinemez) offsite yedek. Detay için ransomware koruma rehberimize bakın.

Donanım arızası: Disk SMART hatası, RAID degradation, datacenter güç anomalisi, anakart ölümü. Tier 3 veri merkezimizde N+1 PSU ve UPS+jeneratör redundancy var ama yine de disk ölür — yedek farklı katmandır.

Geliştirici / sysadmin hatası: Yanlış dizinde rm -rf *, yanlış DB'de DROP TABLE, yanlış config push'u. İnsan hatası tüm üretim kesintilerinin yaklaşık %30'unun kökeninde duruyor. Bu, donanım arızasından daha sık.

Bozuk eklenti / tema güncellemesi: WordPress'te major sürüm geçişi, PHP 8.2'ye atlama, çakışan plugin combo — site beyaz ekrana düşer. Geri dönüş tek yolu: önceki gece alınan yedek.

Site hack ve defacement: SQL injection, dosya yükleme açığı, çalınan admin parolası. Saldırgan içeriği değiştirir, backdoor yerleştirir. Temiz restore yedek olmadan imkânsız.

Doğal afet / fiziksel olay: Yangın, sel, deprem, hırsızlık. Tek lokasyon yedek = hiç yedek. Coğrafi izolasyon şart.

Tercih etmeyin: "RAID 10 var, yedeğe gerek yok" yaklaşımı. RAID yüksek erişilebilirlik çözümüdür, yedek değil. DROP DATABASE komutu RAID'in beş aynasında da aynı anda çalışır. Snapshot da tek başına yedek değil — aynı sistemde duran snapshot sistem patladığında patlar.

Yedek Türleri: Full, Incremental, Differential

Strateji seçmeden önce temel kavramları netleştirin. Bu seçim depolama maliyetinizi, restore süresinizi ve operasyonel karmaşıklığınızı belirler.

Full Backup (Tam Yedek)

Tüm veri setinin eksiksiz kopyası. Tek dosya, tek restore komutu.

Avantaj: Restore en basit — tek dosya, tek komut.
Dezavantaj: En fazla depolama, en uzun alma süresi.

Kullanım: Haftalık veya aylık ana yedek; incremental zincirinin başlangıç noktası.

Incremental Backup (Artımlı)

Sadece son yedekten bu yana değişen blokları/dosyaları alır. İlk yedek full olur, sonrakiler incremental.

Avantaj: En hızlı alma, en az depolama.
Dezavantaj: Restore karmaşık — full + tüm incremental zinciri sırayla uygulanmalı. Zincirde tek bozuk halka kurtarmayı bitirir.

Kullanım: Günlük veya saatlik yüksek frekanslı yedek.

Differential Backup (Diferansiyel)

Son full yedekten bu yana değişen her şeyi alır (incremental gibi ama referans her zaman son full).

Avantaj: Restore daha basit — full + son differential, iki dosya.
Dezavantaj: Full'dan uzaklaştıkça differential şişer; aralarda full alınmalı.

Kullanım: Orta zemin — günlük differential, haftalık full kombinasyonu.

Synthetic Full

Sunucu, incremental'lardan synthetic full inşa eder; istemciye yeniden full almadan retention süresi yönetilir. Veeam, Bareos ve modern enterprise araçlarda standart.

Avantaj: Ağ ve istemci yükü minimum, ama restore tek dosya gibi davranır.

Mirror / Sync (yedek değil — DR farklı)

rsync --delete ile canlı kopya. Kaynakta silinen hedefte de silinir. Bu yedek değildir — yanlışlıkla silinen veri hedefe ulaşır.

Snapshot

Filesystem veya hypervisor seviyesinde zaman noktası dondurması. Yazma sırasında copy-on-write — anlık ve atomik.

• LVM snapshot — kısa süreli, freeze için
• ZFS / Btrfs snapshot — uzun süreli retention destekli
• KVM / qcow2 snapshot — hypervisor seviyesinde tüm VM
• VPS sağlayıcı snapshot — Buyukweb'de teknik destek hattıyla özel snapshot talebi

Önemli: Snapshot aynı sistemde durduğu sürece yedek değil. Yedek olması için offsite'a transfer şart — ZFS'te zfs send | ssh veya rclone gibi araçlarla.

Karşılaştırma Tablosu

Özellik	Full	Incremental	Differential
Yedek alma süresi	Uzun	Çok kısa	Kısa→orta
Depolama alanı	Yüksek	Düşük	Orta
Restore karmaşıklığı	Basit	Karmaşık (zincir)	Orta (2 dosya)
Zincir bağımlılığı	Yok	Tam zincir	Sadece son full
Bozuk yedek riski	Sadece kendisi	Sonraki tüm restore'ları engeller	Sadece kendisi
Önerilen frekans	Haftalık	Günlük/saatlik	Günlük

Pratik kombinasyon: Haftalık full + günlük incremental + sürekli binary log (DB için PITR) = hem dakika RPO hem operasyonel hız.

RTO, RPO ve Retention: Üç Sayı

Yedek stratejisinin matematik tarafı üç metrikten ibarettir. Mühendislik kararı bu üçü tartışmadan alınamaz.

RPO — Recovery Point Objective

"Ne kadar veri kaybı kabul edilebilir?" — son geçerli yedekten itibaren kaç dakika/saatlik veri yitirmeye razıyız?

Senaryo	Tipik RPO	Anlamı
Kişisel blog	24 saat	Günlük yedek yeterli
Kurumsal tanıtım	12 saat	Günde 2 yedek
Küçük e-ticaret	1-4 saat	Saatlik incremental
Yüksek hacim e-ticaret	5-15 dakika	Binary log + replikasyon
Bankacılık / kritik	<1 dakika	Senkron replikasyon

RTO — Recovery Time Objective

"Kesinti başladıktan kaç dakika/saat sonra sistem tekrar canlı olmalı?" — restore + DNS + smoke test sürecinin tamamı.

Senaryo	Tipik RTO
Kişisel blog	4-8 saat
Kurumsal tanıtım	2-4 saat
E-ticaret	30 dakika - 2 saat
SaaS / mission critical	<15 dakika

Retention — Saklama Süresi

Yedek tipi	Tipik retention
Saatlik incremental	24-48 saat
Günlük full/incremental	7-14 gün
Haftalık full	4-8 hafta
Aylık full	6-12 ay
Yıllık arşiv	7 yıl (mali kayıt, e-fatura, KVKK)

Veritabanı-spesifik RTO/RPO matematiği için ayrı veritabanı yedekleme rehberimize bakabilirsiniz; bu yazı hosting katmanı seviyesinde kalıyor.

3-2-1 Yedekleme Kuralı (ve Modern Uzantısı)

Yedekleme sektörünün altın standardı:

• 3 kopya — orijinal + en az 2 yedek
• 2 farklı medya — iki farklı depolama tipi (yerel disk + cloud, NVMe + SATA, vb.)
• 1 offsite — farklı coğrafi konum (yangın/sel/deprem izolasyonu)

Modern Uzantı: 3-2-1-1-0

Veeam ve modern DR ekipleri 3-2-1 üstüne iki katman daha ekler:

• +1 immutable — değiştirilemez bir kopya (object lock, WORM, air-gap)
• +0 hata — restore drill ile sıfır hata doğrulaması

Bu uzantı özellikle ransomware sonrası kritik: saldırgan online erişebildiği tüm yedekleri de şifreler. Immutable katman olmadan ransomware sonrası kurtarma çok zorlaşır.

3-2-1 Pratiğe Nasıl Döker?

Tipik bir Buyukweb cPanel kurulumu için somut örnek:

Katman	Kopya	Medya	Lokasyon
1	Canlı site	NVMe SSD	Bursa Tier 3
2	JetBackup haftalık	Harici backup sunucusu	Buyukweb backup pool
3	UpdraftPlus + S3-uyumlu object storage	Object storage	Farklı şehir/sağlayıcı

İlk üç kopya — tamam. İki farklı medya tipi (NVMe + object storage) — tamam. Bir offsite (object storage farklı sağlayıcıda) — tamam. 3-2-1 tamamlandı.

Hosting Yedekleme Katmanları: Dört Katman Modeli

Modern hosting yedekleme stratejisi tek araca güvenmez — dört katmanı paralel kurar.

Katman 1: Hosting-Level Backup

Hosting sağlayıcının panel veya sunucu seviyesinde aldığı yedekler.

• JetBackup (cPanel/WHM) — Buyukweb cPanel paketlerinde standart
• Plesk Backup Manager — Plesk paketlerinde
• Acronis Cyber Backup — hipervizör seviyesi (bazı sağlayıcılar)
• R1Soft / Idera — blok-tabanlı sunucu yedek (admin tarafı)

Avantaj: Hiçbir şey yapmadan çalışır. Self-service restore arayüzü kullanıcıda.
Limit: Tek katman. Sunucu seviyesinde patlama hem canlıyı hem yedek pool'unu vurabilir (aynı backup network'te ise).

Katman 2: Application-Level Backup

Uygulama içinde çalışan yedek eklentisi/aracı.

• UpdraftPlus (WordPress) — free + premium, S3-uyumlu object storage, SFTP, OneDrive entegre
• Duplicator (WordPress) — clone + backup, staging/migration odaklı
• Akeeba Backup (Joomla başlangıç, WordPress versiyonu da var)
• BackWPup (WordPress) — eski ama hâlâ aktif
• WP Time Capsule — incremental WordPress yedek
• ManageWP — çoklu site yönetim + yedek
• WP-CLI — wp db export komut satırı, cron'da çalışır

Avantaj: Uygulama-tutarlı (WordPress wp-content + wp-options + DB tablo şeması), restore tek tık.
Limit: Server yetkisi yok — mail spool, DNS zone, cron job dışında kalır.

Katman 3: File/Storage-Level Backup (VDS / root erişim)

VDS ve dedicated paketler için — root erişiminiz varsa modern dedup'lı araçlar.

• BorgBackup — dedup + encryption + compression, remote SSH repo, snapshot mantığı
• Restic — Go ile yazılmış, S3-uyumlu / SFTP / Local, snapshot + AES-256
• Duplicity — GnuPG şifreli incremental, rsync benzeri
• rsnapshot — rsync + hard link snapshot rotation
• rsync + cron — klasik, SSH + key tabanlı
• rclone — cloud sync, 50+ S3-uyumlu sağlayıcı desteği
• Bacula / Bareos — enterprise tape ve disk tabanlı yedek
• Veeam Agent for Linux — image-level sunucu yedek

BorgBackup örneği — gece 03:00'te VDS'ten remote backup sunucusuna:

# /etc/cron.d/borg-backup
0 3 * * * root /usr/local/bin/borg-backup.sh

# borg-backup.sh
export BORG_PASSPHRASE='guclu-parola'
borg create --stats --compression zstd,3 \
  [email protected]:/srv/borg/${HOSTNAME}::${HOSTNAME}-$(date +%Y-%m-%d-%H%M) \
  /etc /home /var/www /var/lib/mysql

# Eski yedekleri temizle (retention)
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 \
  [email protected]:/srv/borg/${HOSTNAME}

Restic ile S3-uyumlu object storage'a:

export RESTIC_REPOSITORY="s3:https://endpoint.ornek.com/buyukweb-yedek"
export RESTIC_PASSWORD="guclu-parola-aes256"
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

restic backup /var/www /etc /home --tag daily
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Katman 4: Snapshot-Level Backup

Filesystem ve hypervisor seviyesinde atomik snapshot.

• LVM snapshot — kısa süreli (DB freeze için)
• ZFS snapshot + zfs send — uzun süreli, dedup, sıkıştırma, atomik
• Btrfs snapshot — read-only ve writable snapshot
• KVM libvirt snapshot — qcow2 backing file ile sürüm zinciri
• VPS sağlayıcı snapshot — Buyukweb VDS için teknik destek hattıyla snapshot talep edilebilir

ZFS örneği — saatlik snapshot + günlük offsite send:

# Saatlik snapshot
zfs snapshot tank/www@hourly-$(date +%Y%m%d%H)

# Günlük gece offsite gönderim
zfs send -i tank/www@daily-dun tank/www@daily-bugun | \
  ssh backup@offsite "zfs receive tank/www"

# Retention — 24 saatlik snapshot tut
zfs list -t snapshot -o name -H | grep hourly | \
  head -n -24 | xargs -n1 zfs destroy

Önemli: Snapshot tek başına yedek değil — offsite gönderim şart. Aynı sunucuda duran snapshot disk arızasında siner.

JetBackup: Buyukweb cPanel Paketlerinde Standart

cPanel paketlerinde JetBackup haftalık otomatik full yedek çalışıyor. Bu detayları net olarak verelim — yanıltıcı olmamak adına:

Ne yapar?

• Haftalık full yedek (günlük değil — bu önemli)
• Yedekleri harici backup sunucularına atar (3-2-1'in offsite kısmı)
• Retention paket bazlı: 4-8 hafta (paketinize göre değişir)
• Self-service restore — kullanıcı kendi cPanel'inden geri yükler
• Granular restore — tek dosya, tek tablo, tek mail hesabı geri al

Granular restore neleri kapsar?

Restore Tipi	Ne Kapsar?
File-level	public_html/, .htaccess, tek dosya
Database-level	Tek MySQL/MariaDB DB veya tek tablo
Email-level	Tek e-posta hesabı / Inbox / mesaj
Cron Jobs	Zamanlanmış görev tanımları
DNS Zone	A/CNAME/MX/TXT kayıtları
FTP Accounts	FTP kullanıcı tanımları
Forwarders / Filters	E-posta yönlendirme kuralları

Limit ve dürüst gerçek

JetBackup haftalık çalışıyor — günlük değil. Pazartesi yedek alınmışsa Pazar sabahı kaybedilen veri 6 günlük olabilir. Eğer e-ticaret veya yüksek hacim site işletiyorsanız tek katman JetBackup yetersizdir. Bu durumda çift katman kurun:

1. Hosting-level: JetBackup haftalık (bu zaten standart, ek bedel yok)
2. App-level: UpdraftPlus gece yarısı (günlük) + S3-uyumlu object storage offsite
3. DB-level: cron + mysqldump --single-transaction saatlik (yüksek hacim için)
4. Restore drill: aylık tatbikat

Bu üç ek katman JetBackup'ın haftalık döngüsünü dakika seviyesinde RPO'ya çeker.

WordPress Eklenti Yedekleme: Pratik Karşılaştırma

Eklenti	Free Versiyon	Object Storage	Incremental	Restore UX
UpdraftPlus	Var	Premium'da S3-uyumlu/SFTP/OneDrive	Premium	Çok iyi
Duplicator	Var	Pro'da	Pro	Migration odaklı
Akeeba Backup	Var	Pro	Pro	Çok iyi (Joomla'dan miras)
BackWPup	Var	S3-uyumlu	Yok	Orta
WP Time Capsule	Yok	Var	Var	İyi

UpdraftPlus tipik cron kurulumu

WordPress admin → UpdraftPlus → Settings:

• Files backup schedule: Daily, retain 14
• Database backup schedule: Daily, retain 14
• Remote Storage: S3-uyumlu object storage / SFTP / OneDrive
• Email reports: Yedek bitince admin'e mail

Buyukweb cPanel + UpdraftPlus kombinasyonu:

• JetBackup haftalık (sağlayıcı tarafı, ücretsiz, kendi pool'u)
• UpdraftPlus günlük (uygulama tarafı, S3-uyumlu offsite)
• Toplam: haftalık + günlük + offsite = 3-2-1'in büyük kısmı

WP-CLI cron örneği

# /etc/cron.d/wp-yedek
0 2 * * * www-data cd /var/www/site && wp db export /backups/db-$(date +%F).sql && gzip /backups/db-$(date +%F).sql
30 2 * * * www-data tar czf /backups/files-$(date +%F).tar.gz /var/www/site/wp-content

Tercih etmeyin: Tek eklenti yedeklemeye %100 güven. Eklenti güncellemesi sırasında bozulursa yedek tablonuz da bozulabilir. Her zaman ikinci bir katman kurun (JetBackup, manuel cron, ya da farklı eklenti).

Veritabanı Yedekleme (Kısa Özet)

DB yedekleme bu yazının kapsamı dışında — ayrı veritabanı yedekleme rehberimiz var. Ama hızlı özet:

• mysqldump — logical (SQL dosyası), küçük-orta DB için ideal
• mariabackup / xtrabackup — physical (binary), hot backup, büyük DB için
• pg_dump / pg_basebackup — PostgreSQL logical / physical
• mongodump — MongoDB binary dump
• Binary log + Point-in-Time Recovery (PITR) — dakika seviyesinde RPO

mysqldump --single-transaction InnoDB tutarlı dump için zorunlu — bunu unutmak sayısız sysadmin'e veri tutarsızlığı yaşatmıştır.

Offsite ve Object Storage Stratejisi

Offsite yedek coğrafi izolasyon ister. Aynı binada başka bir disk = offsite değil.

Object Storage (S3-uyumlu jenerik)

Çoğu modern yedek aracı S3 API destekler — sağlayıcı bağımsız:

• Hot tier — anında erişim, daha pahalı GB başı
• Cold / archive tier — Glacier-tarzı, ucuz GB başı, restore yavaş (saatler)

Şifreleme — ZORUNLU

Offsite yedek mutlaka şifreli olmalı. Üçüncü tarafta duran ham backup = potansiyel veri sızıntısı.

• GPG (GnuPG) — yedek dosyasını AES-256 ile şifrele
• age — modern, basit, modern crypto
• Restic / BorgBackup — built-in AES-256 (parola passphrase ile)

GPG örneği:

# Yedek + şifre
mysqldump --single-transaction db | gzip | \
  gpg --symmetric --cipher-algo AES256 --batch --passphrase-file /root/.backup-key > db-$(date +%F).sql.gz.gpg

# rclone ile offsite
rclone copy db-$(date +%F).sql.gz.gpg yedek:bucket/db/

Coğrafi izolasyon

Buyukweb Bursa Tier 3 veri merkezinde. Offsite kopyanız farklı bir şehir/ülkede olmalı. Bir başka VDS sağlayıcı, başka bir S3-uyumlu object storage, ya da kendi ofisinizdeki Synology Hyper Backup NAS — hepsi geçerli.

Schedule + Retention: Örnek Politika

Tipik bir KOBİ / e-ticaret için somut takvim:

Yedek Tipi	Frekans	Retention	Lokasyon
Saatlik DB incremental	Saatlik	24-48 saat	Yerel + offsite
Günlük full	Günlük 03:00	7 gün	Offsite object storage
Haftalık full	Pazar 03:00	4 hafta	Offsite object storage
Aylık full	Ayın 1'i	12 ay	Offsite + immutable
Yıllık arşiv	Yılbaşı	7 yıl	Cold archive + immutable
Restore drill	Aylık	—	Test environment

Bu politika RPO 1 saat, RTO 30 dakika ve mali kayıt yasal süresine (7 yıl) uygun.

Immutable Backup: Ransomware'a Karşı Hayat Sigortası

Ransomware modern dünyada en yıkıcı tehdit. Saldırgan canlı sisteme girer, erişebildiği tüm yedekleri de şifreler. Bu yüzden online erişimli yedek tek başına yetmez.

Immutable seçenekler

• Object Lock (compliance mode) — S3-uyumlu sağlayıcılarda standart; nesneyi belirli süre içinde silinmez ve değiştirilmez kılar
• WORM (Write Once Read Many) — tek yazma, çoklu okuma; eski enterprise gelenek, modern object storage'da yazılım katmanında
• ZFS snapshot read-only retention — zfs set readonly=on ve snapshot freeze
• Air-gapped tape — LTO tape, fiziksel ayrı kasada (eski kurumsal, hâlâ çalışıyor)

Ayrıntı ve ransomware sonrası kurtarma adımları için ransomware koruma rehberimize bakın.

Restore Drill: "Yedeğim Var" ≠ "Restore Çalışır"

Bu bölüm en kritik. Yedek almak iş yarısı; geri yükleme çalıştığını doğrulamak işin diğer yarısı. Sektördeki acı slogan:

"Schrödinger backup: bir restore drill yapana kadar yedeğinizin canlı mı, ölü mü olduğunu bilemezsiniz."

Restore drill nedir?

Düzenli (en az aylık) yapılan, gerçek bir restore tatbikatı. Sahte felaket, gerçek geri yükleme.

Adımlar

1. Test environment hazırla — staging cPanel hesabı veya ayrı VDS
2. Yedek seç — son haftalık full + son günlük incremental
3. Restore'u baştan sona çalıştır — gerçek müşteri verisini test'e geri yükle
4. Doğrula — site açılıyor mu, DB sorguları sonuç dönüyor mu, mail çalışıyor mu, admin giriş yapabiliyor mu
5. RTO ölç — restore başlangıcından siteye normal trafik dönene kadar geçen süreyi kaydet
6. Hash sum doğrula — sha256sum ile yedek dosya bütünlüğü
7. Belgele — sistem yöneticisi tatildeyken ekipteki başka biri aynı adımları takip edebilmeli

Restore drill checklist

• Aylık takvim girişi (Outlook/Google Calendar)
• Test environment hazır (staging cPanel veya VDS)
• Restore prosedürü yazılı (runbook)
• RTO ölçümü kayıt altında
• Hash sum doğrulama scripti
• Eksik dosya / bozuk DB raporu
• Sonuç ekip toplantısında konuşuluyor

Tercih etmeyin: "Yedeklerin var, çalışıyor olmalı" varsayımı. Sektördeki en yaygın felaket — restore anında yedeğin bozuk veya eksik çıkması. Aylık 30 dakikalık drill bu felaketi önler.

Buyukweb Paket Karşılaştırma: Yedek Odaklı

Hangi paket size uyar? Yedek perspektifinden:

Paket	Sağlayıcı Yedek	Müşteri Sorumluluğu	Önerilen Ek Katman
cPanel paylaşımlı	JetBackup haftalık, harici sunucu	App-level (UpdraftPlus)	Günlük plugin + S3-uyumlu offsite
VDS (root erişim)	Opsiyonel JetBackup; teknik destek snapshot	Tam strateji	BorgBackup / Restic + offsite
Dedicated	Sağlayıcı talep üzerine	Tam kontrol	Snapshot + offsite + immutable

Detaylı karşılaştırma için paket karşılaştırma sayfamıza bakın.

Yaygın Yedek Hataları (Sektörün Klasiği)

Yıllarca operasyonel deneyimden damıtılmış hata listesi. Bunlardan en az ikisini her ekip yapar — sizinki de istisna olmasın diye:

1. Restore drill yapmamak — En sık ve en yıkıcı. Yedek var, restore yok.
2. Aynı sunucuda yedek tutmak — Sunucu patlar, hem canlı hem yedek gider.
3. RAID'i yedek sanmak — RAID erişilebilirlik, yedek değil. DROP TABLE RAID'in beş aynasında da çalışır.
4. Mail spool ve log unutmak — Tipik backup config sadece /home ve DB kapsar; /var/spool/mail, /var/log dışarıda kalır.
5. Hot backup'ı transaction ortasında almak — mysqldump --single-transaction olmadan InnoDB tutarsız çıkar.
6. Şifresiz offsite — Bulutta duran ham yedek = potansiyel veri sızıntısı.
7. Tek eklenti / tek araca güven — UpdraftPlus tek başına yedek katmanı değil, bir katman.
8. Domain expire ölü site — DNS + EPP code'u da yedekle; domain düşerse en güçlü site yedek bile boş.
9. Retention politikası yok — Disk dolar, eski yedekler temizlenmez, sistem patlar.
10. Restore prosedürü tek kişide — Sistem yöneticisi tatil → kurtarma duruyor. Runbook ekibe açık olmalı.

Sık Sorulan Sorular

Buyukweb gerçekten günlük mü haftalık mı yedek alıyor?

Haftalık. JetBackup ile cPanel paketlerinde haftalık otomatik full yedek harici sunucuya gider. Eğer günlük RPO ihtiyacınız varsa UpdraftPlus veya WP-CLI cron ekleyin — sağlayıcı katmanın üstüne kendi app-level katmanınızı koyun. "Günlük yedek" reklamı yapan sağlayıcılarda detayını sorun: hangi katmanda, ne retention, restore ücretli mi?

3-2-1 kuralını uygulamak ne kadar maliyetli?

Şart değil pahalı olsun. Buyukweb cPanel paketi JetBackup haftalık offsite'ı zaten karşılıyor (ücretsiz). Üstüne UpdraftPlus free + S3-uyumlu object storage (ayda ~birkaç TL, GB başı) ekleyince 3-2-1 tamamlanır. Toplam maliyet aylık yüz lira altında bir KOBİ sitesi için.

Restore drill'i ne sıklıkla yapmalıyım?

Aylık minimum, kritik e-ticaret için iki haftalık. Ayrıca her major sürüm geçişinden (PHP, WP, plugin major) sonra ekstra. Bir yıl boyunca hiç restore drill yapmadıysanız yedeklerinizin gerçek durumunu bilmiyorsunuz demektir.

Snapshot yedek midir, değil midir?

Snapshot tek başına yedek değildir — aynı sistemde durduğu sürece. Sistem disk arızası snapshot'ı da götürür. Ama zfs send ile offsite gönderilen snapshot yedek olur. Ayrım önemli.

WordPress için en kritik üç katman hangileri?

(1) JetBackup haftalık (sağlayıcı, otomatik), (2) UpdraftPlus günlük + S3-uyumlu object storage (uygulama, otomatik), (3) Aylık restore drill (manuel ama kısa). Bu üçü hazırsa veri kaybı senaryolarının %95'inden korunuyorsunuz.

Sonuç

Yedekleme "al ve unut" değil, "katmanla, şifrele, offsite gönder, her ay test et" döngüsüdür. JetBackup haftalık iyi bir başlangıç ama tek katman yetmez — modern strateji üç-dört katman ister. 3-2-1 kuralı temel; immutable + restore drill modern uzantısı. En kritik tek tavsiye: yedek almaktan değil, restore test etmemek'ten korkun.

Hosting paketleri ve yedek stratejisi konusunda destek için: 0850 302 60 70 veya iletişim sayfamız.

---

İlgili Büyükweb Hizmetleri

Yedekleme stratejisi için altyapı paketleri:

• cPanel Web Hosting — JetBackup haftalık dahil
• WordPress Hosting — JetBackup + LiteSpeed Cache
• VDS Sunucu — root erişim, BorgBackup/Restic kurulumu
• E5 v4 VDS — yüksek IOPS NVMe, snapshot dostu
• Fiziksel Dedicated — tam kontrol, offsite + immutable kurulumu
• Paket Karşılaştırma — yedek özellikleri kıyas

Sorularınız için 0850 302 60 70 numaralı destek hattımıza yazabilirsiniz.