VDS Sunucu Yedekleme: KVM Snapshot, BorgBackup, ZFS ve Veeam Stratejisi

VDS Sunucu Yedekleme: KVM Snapshot, BorgBackup, ZFS ve Veeam Stratejisi

VDS sunucunuzun yedeği, paylaşımlı hosting yedeğinden temelden farklıdır. cPanel paylaşımlı bir paketinizde JetBackup haftalık tam yedeği arka planda alır, panel üzerinden bir tuşla restore edersiniz; hesap, dosya ve veritabanı seviyesinde granular kurtarma standardır. VDS'te ise işletim sistemini siz kuruyor, paneli (varsa) siz yönetiyor, servisleri siz başlatıyorsunuz — yedek stratejisi de sizin sorumluluğunuzda olan bir katmandır.

Buyukweb perspektifi: VDS E5-V4, E5-V2 ve Nested VDS paketlerimizde Veeam altyapısı üzerinden günlük otomatik yedek standarttır; biz arka planda hypervizör seviyesinde sunucunuzun image'ını ve disklerini her gün yedekliyor, Bursa Tier 3 veri merkezimizde tutuyoruz. GPU VDS paketlerinde yedek sorumluluğu müşteridedir; Proxmox snapshot ve disk image araçlarını sağlıyoruz. Dedicated / fiziksel sunucu müşterilerimize talep ederlerse opsiyonel R1Soft / Acronis entegrasyonu açıyoruz. Tüm bunların üstüne bu rehberdeki uygulama-aware (mysqldump, pg_dump) ve off-site (BorgBackup + S3 uyumlu object storage) katmanını siz eklediğinizde, 3-2-1-1-0 modeline tam uyumlu bir VDS yedek mimariniz olur. 0850 302 60 70 numaralı destek hattımız yedek planlaması, R1Soft kurulumu veya restore senaryoları için sizinle çalışmaya hazır.

Bu rehber ID 61 Hosting Yedekleme Stratejisi yazısının bittiği yerden başlar. Orada 3-2-1 kuralı, full/incremental/differential türleri, JetBackup, hosting-level vs application-level katmanlar, BorgBackup ve restic kavramsal genelde işlendi. Burada VDS bağlamında spesifikleşiyoruz: hypervizör snapshot (KVM qcow2, LVM, ZFS, btrfs), agent-bazlı yedek (Veeam Agent for Linux, R1Soft Server Backup Manager, Acronis Cyber Protect), Proxmox Backup Server, kontrol panelsiz sunucuda kendi yedek mimarinizi kurma ve kontrol panelli (cPanel/Plesk üstünde VDS) sunucularda mevcut JetBackup'a ek off-site katman ekleme. Veritabanı tarafında mysqldump ve pg_dump'ın hangi flag'leri olmadan çalıştırılamayacağını, binary log ile point-in-time recovery'nin VDS üzerinde nasıl kurulduğunu, logical vs physical backup ayrımını işleyeceğiz.

VDS Yedek Neden Paylaşımlı Hosting Yedeğinden Farklı?

Paylaşımlı hostingte yedek seninle birlikte gelir. cPanel paketlerimizde JetBackup haftalık çalışır, retention süresi standart, restore self-service. VDS'te tablo değişir:

• Root erişim sende — kurduğun servis, sürüm, dosya layout senin. Sağlayıcı için "müşterinin sunucusunda ne çalışıyor" bir kara kutudur.
• İşletim sistemi senin sorumluluğunda — sistem dosyalarının değişikliği (/etc, /var/lib, /opt) kendi yedek kapsamında olmalı.
• Servis-aware yedek lazım — koşan bir MySQL'in mysql/data dizinini ham kopyalamak veri tutarlılığı olmayan bir snapshot üretir. Servis-aware (uygulama-tutarlı) yedek için uygulamanın kendi araçları (mysqldump, pg_dump, mongodump, redis-cli BGSAVE) ya da quiescing destekli (filesystem freeze + agent) yedek aracı gerekir.
• Hypervizör seviyesinde Buyukweb günlük yedeği vardır ama bu "VM image'ı bir gün öncesinden geri yükleme" hizmetidir; tek bir dosya, tek bir tablo, tek bir kullanıcı kaybı için granular kurtarma sağlamaz.
• 3-2-1 senin elinde tamamlanır — biz birinci yedek katmanını veriyoruz, ikinci medya ve off-site lokasyon senin kararındır.

Önemli: Buyukweb VDS günlük Veeam yedeği "hayat sigortası"dır; VDS host çökerse veya disk array problemi yaşanırsa biz sunucunuzu en geç 24 saatlik image'dan kaldırabiliriz. Ancak DROP TABLE musteriler; komutu, "hocam silmedik biz, mahvolduk" maili, ya da WordPress'te tema güncellemesinin tüm wp_options tablosunu corrupt etmesi gibi dosya/uygulama seviyesi kayıplar için kendi katmanın gerekir. Hypervizör yedeği "olsun" değil, "olmalı" — ama tek başına yetmez.

Yedek Katmanları: VDS İçin Beş Seviye

VDS'te yedek beş farklı seviyede alınır. Pratikte bir profesyonel kurulum üç-dört seviyeyi katmanlı kullanır.

1. Dosya Seviye (File-level)

Sıradan dosyaların kopyası: tar, rsync, cp -a. En basit, en taşınabilir, granular restore en kolay. Limitasyon: çalışan veritabanı dosyaları tutarlı olmaz; servis durdurulmadan veya snapshot alınmadan /var/lib/mysql kopyası kullanılamaz.

2. Uygulama-Aware (Application-Consistent)

Uygulamanın kendi dump aracını kullanır: mysqldump --single-transaction, pg_dump -Fc, mongodump, redis-cli SAVE. Veritabanı motoru iç işlem tutarlığını garanti ederek bir snapshot dosyası üretir. Restore'da binary log/WAL ile point-in-time recovery yapılabilir.

3. Blok Seviye (Block-level)

Diskin tam imajı: dd, ddrescue, Clonezilla, agent-bazlı block tracking. Tüm partition'ı bayt bayt kopyalar, "değişen blok" takibi yapan ajanlar (Veeam Agent, R1Soft) sadece değişimi gönderir. Restore: tüm disk image'ı geri yazılır; granular dosya restore mümkün ama dosya seviye yedek kadar pratik değildir.

4. VM Snapshot (VM/Hypervizör)

KVM qcow2 snapshot, LVM snapshot, ZFS/btrfs snapshot. Sunucu içinde veya hypervizör tarafından alınır. Atomik bir zaman noktası dondurma — ama "snapshot bir yedek değildir" mottosu burada da geçerli: snapshot aynı diskin üstünde durduğu sürece disk arızasından korunamaz, bir başka medyaya aktarılmadıkça yedek sayılmaz.

5. Hypervizör Backup (Veeam / Proxmox PBS / R1Soft)

VM'in dışından, hypervizör katmanından alınan tam yedek. Buyukweb VDS'nin günlük Veeam yedeği bu kategori. Proxmox kullanan dedicated müşteriler için Proxmox Backup Server (PBS) aynı işlevi açık kaynak olarak sağlar. R1Soft Server Backup Manager fiziksel ve sanal sunuculara block-tracking ajan yükleyerek 15 dakikalık incremental seviyelere ulaşır.

Pratik bir kurulum tipik olarak:

• Katman A — Hypervizör (Buyukweb Veeam günlük) — disaster recovery
• Katman B — Uygulama-aware DB dump (saatlik / 4 saatlik) — geliştirici hatası, bozuk migration
• Katman C — Dosya seviye BorgBackup gece (deduplike + şifreli) — uzun retention
• Katman D — Off-site S3 uyumlu (haftalık tam, immutable) — ransomware ve coğrafi izolasyon

RPO ve RTO Matematiği: VDS Senaryosu

ID 61 hosting-yedekleme yazısında RTO/RPO kavramları temel düzeyde işlendi. VDS bağlamında pratik bir matematik egzersizi yapalım.

Senaryo: Orta ölçekli WooCommerce mağazası, günde ~200 sipariş, ortalama 80 TL. Yıllık ciro yaklaşık 5.840.000 TL.

• RPO 24 saat (sadece Buyukweb Veeam günlük yedeği): bir günlük sipariş kaybı = ~16.000 TL. Tablo bozulduğunda kabul edilemez.
• RPO 4 saat (Veeam günlük + 6 saatlik mysqldump cron): maksimum ~2.700 TL kayıp. Kabul edilebilir sınırda.
• RPO 5 dakika (Veeam günlük + 5 dakikalık binary log + point-in-time recovery): maksimum ~60 TL kayıp. Yüksek hacim e-ticaret için altın standart.

RTO tarafı:

• RTO 24 saat (sadece Veeam image restore + DNS propagation): hypervizör seviyesinde image geri çekilir, sunucu açılır, DNS TTL'i bekler. Kabul edilebilir sınırda.
• RTO 4 saat (Veeam image + son DB dump restore): image hızlı geri çekilir, DB dump ayrı bir saatlik snapshot'tan apply edilir. Profesyonel kurulum.
• RTO 30 dakika (cold standby VDS + LVM snapshot + DB replication): hazır bekleyen ikinci VDS'e yedek pointer çevrilir. En pahalı, en hızlı.

Karar: RPO/RTO senin işinin kabul edilebilir kayıp ve kabul edilebilir kesinti olarak tanımladığın sınırlardır. RPO 5 dakika kurmak için binary log + retention storage, RTO 30 dakika için cold/warm standby gerekir; her ikisinin de aylık maliyeti vardır. Tipik KOBİ WooCommerce için RPO 4 saat / RTO 4 saat yeterli ve maliyet-fayda dengelidir.

3-2-1-1-0 Modern Kuralı (VDS Adaptasyonu)

ID 61 yazısında detaylı işlenen 3-2-1-1-0 kuralının VDS senaryosuna uyarlaması:

• 3 kopya — birincisi VDS canlı disk, ikincisi Buyukweb hypervizör Veeam günlük, üçüncüsü kendi BorgBackup repo.
• 2 farklı medya — birincisi VDS'in NVMe disk array, ikincisi farklı bir storage (object storage / ayrı VDS / external).
• 1 off-site — coğrafi olarak Bursa Tier 3'ten ayrı, S3 uyumlu object storage.
• 1 immutable — Object Lock veya WORM kilitli, retention süresi içinde değiştirilemez/silinemez.
• 0 hata — restore drill ayda 1 kez, dump sonrası mysql --execute "CHECK TABLE ..." doğrulama, borg check --repair aylık, restic snapshot listesi haftalık.

VDS'te uygulanan tipik kurulum:

[VDS canlı disk]
  + günlük Buyukweb Veeam yedek (Bursa Tier 3, hypervizör)
  + saatlik mysqldump --single-transaction (yerel dizine)
  + gece BorgBackup yerel repo
  + gece BorgBackup uzak repo (SSH push, S3 uyumlu üzerinden rclone mount)
  + haftalık tam BorgBackup verify (borg check)
  + aylık restore drill: test DB'sine son dump apply + sanity check

rsync Derinlemesine: VDS İçin Pratik Komutlar

rsync, VDS yedek dünyasının "İsviçre çakısı"dır. Tek başına bir yedek aracı değildir (delete flag'i ile mirror'a dönüşür, yanlışlıkla silinen veri off-site'ta da silinir), ama uygun flag kombinasyonu ve --link-dest ile hardlink incremental yapabilir.

Temel rsync Flag'leri

Flag	Anlam	VDS yedek için
-a	Archive — sembolik link, izin, sahiplik, mtime korur	Zorunlu
-v	Verbose — ne kopyalandığını yazar	Cron'da log için
-z	Sıkıştırma — ağ trafiği azalır	Uzak hedeflerde
-x	Filesystem boundary'i geçme	/ yedeklerken /proc /sys atlamak için
-H	Hardlink'leri koru	Mailbox, deduplike kaynak için
--delete	Kaynakta olmayan hedefte de silinir	Mirror için; yedek için DİKKAT
--link-dest=DIR	Önceki yedek dizininin değişmeyen dosyalarını hardlink yap	Snapshot incremental
--exclude=PATTERN	Hariç tut	/proc, /sys, /tmp için
-e "ssh -p 2222"	SSH transport (özel port)	Uzak hedef için
--bwlimit=10000	Bandwidth sınırı KB/s	Saat 09-18 arası ağ tıkamak istemiyorsan

Hardlink Incremental (rsync Snapshot Trick)

# Hedef dizin layout
# /backup/daily/0  -> bugün
# /backup/daily/1  -> dün
# /backup/daily/2  -> önceki gün
# ...

# Bugünkü yedek (önceki gün dizininden değişmeyen dosyalar hardlink)
rsync -av --delete \
  --link-dest=/backup/daily/1/ \
  /var/www/ \
  /backup/daily/0/

Sonuç: değişmeyen dosyalar disk üzerinde yeniden kopyalanmaz, hardlink olarak görünür. 30 günlük retention, sadece değişen veri kadar yer kaplar. Restore: hangi gün dizinine bakarsan tam dosya görürsün — hardlink saydam.

rsnapshot: rsync Wrapper

rsnapshot, yukarıdaki hardlink trick'i hourly/daily/weekly/monthly olarak rotate eden bir Perl wrapper'dır. /etc/rsnapshot.conf üzerinden retention politika yazılır:

retain hourly  6
retain daily   7
retain weekly  4
retain monthly 12

Cron entry'leri:

0 */4 * * * /usr/bin/rsnapshot hourly
30 3 * * * /usr/bin/rsnapshot daily
0 4 * * 1 /usr/bin/rsnapshot weekly
0 5 1 * * /usr/bin/rsnapshot monthly

Tek bir yedek dizininde aynı anda son 6 saat + son 7 gün + son 4 hafta + son 12 ay görünür, depolama hardlink sayesinde patlama yapmaz. Granular restore: /var/cache/rsnapshot/daily.3/localhost/var/www/index.php dosyasını al, üstüne kopyala.

rsync Üzerinden SSH Push (Uzak Hedef)

rsync -avzH \
  --delete \
  -e "ssh -p 2222 -i /root/.ssh/backup_key" \
  /var/www/ \
  [email protected]:/backup/vds-prod/www/

İpucu: uzak hedef için ayrı SSH key, restricted shell (rrsync), ve append-only hedef dizin izinleri kullan. Compromise olan kaynak sunucu uzak yedeği silemesin.

rsync Daemon Mode

Tek seferlik aktarımlar için SSH yeterlidir; sürekli senkron için rsync --daemon modu (port 873) vardır. SSH'siz, TLS opsiyonel (stunnel ile sarılabilir). KOBİ için genelde gerekmez; SSH transport yeterli.

BorgBackup: Deduplikasyon ve Şifreleme

BorgBackup (kısa: borg), VDS dünyasının en sevilen modern yedek aracıdır. Content-defined chunking ile dosyaları içerik bazlı parçalara böler, aynı içerikli parçaları tek kez saklar — sonuç tipik olarak %90-95 deduplikasyon oranı. Bir 100 GB sitenin 30 günlük yedeği BorgBackup'ta 150-200 GB civarında tutulur, klasik tam yedek olsa 3 TB ederdi.

Repository Init ve İlk Yedek

# Repo init (repokey mode — şifre repository'de tutulur, encrypted)
borg init --encryption=repokey /backup/borg-repo

# Veya keyfile mode (anahtar ayrı dosyada — daha güvenli)
borg init --encryption=keyfile /backup/borg-repo

# İlk yedek
export BORG_PASSPHRASE="cok-uzun-bir-parola"
borg create --stats --progress \
  /backup/borg-repo::"vds-prod-$(date +%Y%m%d-%H%M)" \
  /etc /home /var/www /root \
  --exclude '/var/cache' \
  --exclude '/var/tmp'

Encryption Modları

Mod	Anahtar Yeri	Güvenlik	Kullanım
repokey	Repository içinde (şifrelenmiş)	İyi — parola gerekir	Çoğu senaryo için
keyfile	~/.config/borg/keys/ yerel	En iyi — anahtar ayrı	Hassas veri
authenticated	Sadece HMAC — şifreleme yok	Düşük	Güvenli ağda
none	Şifreleme yok	Yok	Test/dev

Üretim için keyfile veya repokey kullan; repository compromise olsa bile parola/keyfile olmadan veriler okunamaz.

Append-Only Flag (Ransomware Koruması)

borg init --encryption=repokey --append-only /backup/borg-repo

Append-only repo'ya yeni yedek eklenebilir ama eski yedekler silinemez. Compromise olan istemci, yedekleri silemez. Retention için ayrı bir "admin" SSH key ile periyodik borg compact çalıştırılır. Ransomware koruması için ZORUNLU mod.

Prune Politikası

borg prune --list \
  --keep-hourly  24 \
  --keep-daily    7 \
  --keep-weekly   4 \
  --keep-monthly 12 \
  --keep-yearly   5 \
  /backup/borg-repo

# Disk alanını fiilen geri al
borg compact /backup/borg-repo

GFS (Grandfather-Father-Son) retention'ı tek komutla. --keep-hourly 24 son 24 saati saatte bir tutar, --keep-daily 7 son 7 günü, vb.

borgmatic: BorgBackup Wrapper

borgmatic, BorgBackup üzerine YAML config + cron + monitoring eklentisi ekleyen bir wrapper'dır. /etc/borgmatic/config.yaml:

source_directories:
  - /etc
  - /home
  - /var/www
  - /root

repositories:
  - path: /backup/borg-local
  - path: ssh://[email protected]:2222/./borg-repo

exclude_patterns:
  - /var/cache
  - /var/tmp
  - '*.pyc'

retention:
  keep_daily: 7
  keep_weekly: 4
  keep_monthly: 12

consistency:
  checks:
    - name: repository
      frequency: 2 weeks
    - name: archives
      frequency: 1 month

healthchecks:
  ping_url: https://hc-ping.com/abcdef-uuid

postgresql_databases:
  - name: all
    hostname: localhost
    username: postgres

mysql_databases:
  - name: all
    hostname: localhost
    username: backup
    password: ${MYSQL_BACKUP_PASS}

YAML ile DB dump + filesystem backup + remote push + retention + healthcheck tek dosyada toplanır.

restic: BorgBackup Alternatifi

restic, BorgBackup ile aynı problem alanını çözen Go yazılı modern bir araçtır. Bazı kritik farklar:

Özellik	BorgBackup	restic
Yazıldığı dil	Python	Go (tek statik binary)
Repository yeri	Yerel, SSH	Yerel, SFTP, S3 uyumlu object storage, REST API
Multi-host repo	Lock manager karmaşık	Native (concurrent backup)
Encryption	repokey/keyfile	Built-in (her zaman AES-256)
Deduplikasyon	Content-defined chunking	Content-defined chunking
Append-only	Var (--append-only)	Var (S3 Object Lock ile)
Hız	Yüksek (single-thread)	Çok yüksek (parallel)
Eski sürüm uyumluluğu	Strict — sürüm karışmaz	Forward-compatible

Karar matrisi:

• Yerel ya da SSH üzerinden tek hedefe yedek alıyorsan → BorgBackup daha olgun, ekosistem geniş, borgmatic çok güzel.
• S3 uyumlu object storage'a doğrudan yedek atıyorsan → restic ideal, native backend desteği var.
• Multi-host paralel yedek alıyorsan (çoklu VDS aynı repo'ya) → restic, lock yönetimi daha temiz.

restic Repository Init (S3 Uyumlu)

# S3 protokolü standart env var adlarını kullanır.
# Herhangi bir S3 uyumlu object storage (MinIO self-host, Cloudflare R2, kurumsal NAS S3 modu) ile aynı isimle çalışır.
export RESTIC_REPOSITORY="s3:https://object-storage.example.com/vds-prod-backup"
export AWS_ACCESS_KEY_ID="ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="SECRET_KEY"
export RESTIC_PASSWORD="cok-uzun-bir-parola"

restic init

restic backup /etc /home /var/www /root \
  --exclude /var/cache \
  --exclude /var/tmp \
  --tag "vds-prod" \
  --tag "$(date +%Y-%m-%d)"

S3 uyumlu hedeflerin çoğu Object Lock özelliği destekler. restic forget --keep-daily 7 çalıştırılır ama silinen snapshot'lar Object Lock retention süresince fiilen silinemez — ransomware koruması.

restic Snapshot Listesi ve Restore

restic snapshots
# Listede ID, tarih, host, tags görünür

restic restore SNAPSHOT_ID --target /restore/test
# Tam restore

restic restore SNAPSHOT_ID --target / --include /var/www/site
# Sadece tek dizin restore

restic mount /mnt/restic
# FUSE mount — tüm snapshot'lar dizin gibi gezilir

restic mount özellikle "son 30 gün içinde silinen bir dosyayı arıyorum, hangi snapshot'taydı bilmiyorum" senaryolarında altın değerinde — tüm snapshot'ları FUSE üzerinden gezilebilir bir dizin gibi görürsün.

Veritabanı Yedek: Pratik Komutlar

Veritabanı yedek için ayrı bir veritabanı yedekleme rehberimiz var. Burada VDS bağlamında en sık gereken komutları derliyoruz.

mysqldump (MySQL / MariaDB)

mysqldump \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --master-data=2 \
  --quick \
  --hex-blob \
  --default-character-set=utf8mb4 \
  -u backup -p"${MYSQL_BACKUP_PASS}" \
  --all-databases | gzip > /backup/mysql/full-$(date +%Y%m%d-%H%M).sql.gz

Flag açıklamaları:

• --single-transaction — InnoDB için tutarlı snapshot, tablo lock'u yapmaz (canlı sistem için zorunlu). MyISAM tablolar için --lock-tables gerekir, ama günümüzde InnoDB standarttır.
• --routines — stored procedure ve function'ları dahil et (varsayılan olarak ALMAZ).
• --triggers — tablo trigger'larını dahil et (varsayılan olarak ALIR ama açık yazmak iyi pratik).
• --events — scheduled event'leri dahil et.
• --master-data=2 — yedek üst kısmına binary log pozisyonunu yorum olarak yazar; point-in-time recovery için kritik.
• --quick — büyük tablolarda satır satır akış, RAM patlatmaz.
• --hex-blob — binary kolonları hex'e çevirir, charset hatasız restore.

Logical vs Physical Backup

Tip	Araç	Format	Restore Hızı	Avantaj
Logical	mysqldump	SQL text	Yavaş (saatler)	Sürümler arası taşınabilir, kısmi restore kolay
Physical	Percona XtraBackup, MariaBackup	Binary (datadir kopyası)	Hızlı (dakikalar)	Büyük DB için tek seçenek

100 GB altı veritabanları için mysqldump yeterli. 100 GB üstü için XtraBackup düşünün — InnoDB'nin tablespace'ini doğrudan kopyalar, sıcak yedek (online), restore çok hızlı.

# XtraBackup tam yedek
xtrabackup --backup --target-dir=/backup/xtra/full \
  --user=backup --password="${MYSQL_BACKUP_PASS}"

# Prepare (transaction log'u apply et)
xtrabackup --prepare --target-dir=/backup/xtra/full

# Incremental
xtrabackup --backup --target-dir=/backup/xtra/inc1 \
  --incremental-basedir=/backup/xtra/full

pg_dump (PostgreSQL)

# Custom format (-Fc) — paralel restore destekler, en hızlı format
pg_dump -h localhost -U postgres -Fc \
  --compress=9 \
  -f /backup/pg/db-$(date +%Y%m%d-%H%M).dump \
  veritabani_adi

# Tüm DB'ler için pg_dumpall
pg_dumpall -h localhost -U postgres \
  | gzip > /backup/pg/all-$(date +%Y%m%d-%H%M).sql.gz

# Paralel dump (büyük DB için -j flag)
pg_dump -h localhost -U postgres -Fd \
  -j 4 \
  -f /backup/pg/db-dir-$(date +%Y%m%d-%H%M) \
  veritabani_adi

PostgreSQL'de:

• -Fc (custom) — en yaygın format, paralel restore (pg_restore -j 4) destekler.
• -Fd (directory) — paralel dump (-j N flag), büyük DB için ideal.
• -Fp (plain SQL) — text format, küçük DB veya başka sürüme taşıma için.

pg_basebackup ise physical backup'tır; WAL archiving ile birlikte point-in-time recovery kurulur.

mongodump (MongoDB) ve redis-cli BGSAVE

# MongoDB
mongodump --uri="mongodb://backup:${PASS}@localhost:27017" \
  --out=/backup/mongo/$(date +%Y%m%d-%H%M) \
  --gzip

# Redis — BGSAVE (background save)
redis-cli BGSAVE
# Output: "Background saving started"
# /var/lib/redis/dump.rdb dosyası güncellenir, yedeklenebilir

Point-in-Time Recovery (PITR)

MySQL binary log + tam mysqldump kombinasyonu:

# my.cnf'te aktifleştir
[mysqld]
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 14
sync_binlog = 1
binlog_format = ROW

Restore senaryosu: 14:00 günlük tam yedek, 16:45'te yanlışlıkla DROP TABLE çalıştı. Yapılacak:

1. Tam yedeği geri yükle: zcat full-20260511-1400.sql.gz | mysql
2. 14:00'tan 16:44:59'a kadar binary log replay et:

mysqlbinlog \
  --start-datetime="2026-05-11 14:00:00" \
  --stop-datetime="2026-05-11 16:44:59" \
  /var/log/mysql/mysql-bin.000123 \
  | mysql -u root -p

PostgreSQL tarafında WAL archiving ile recovery_target_time parametresi aynı işi yapar.

File System Snapshot: LVM, btrfs, ZFS

LVM Snapshot (Read-Only Anlık Çekim)

# /dev/vg0/data partition'unun snapshot'ı
lvcreate --snapshot \
  --name data_snap \
  --size 10G \
  /dev/vg0/data

# Snapshot'ı mount et — readonly
mount -o ro /dev/vg0/data_snap /mnt/snap

# rsync veya borg ile yedek al
borg create /backup/borg-repo::"snap-$(date +%Y%m%d)" /mnt/snap

# Snapshot'ı kaldır (yedek bitince)
umount /mnt/snap
lvremove /dev/vg0/data_snap

LVM snapshot kısa süreli olmalı — copy-on-write performansı snapshot süresince etkilenir. Yedek alıp hemen kaldır politikası geçerli.

LVM Snapshot + Database Quiescing Trick

InnoDB için FLUSH TABLES WITH READ LOCK ile kısa bir lock, sonra LVM snapshot, sonra lock release:

mysql -e "FLUSH TABLES WITH READ LOCK; SYSTEM lvcreate --snapshot --name data_snap --size 10G /dev/vg0/data; UNLOCK TABLES;"

InnoDB'de --single-transaction zaten consistent snapshot verdiği için bu trick MyISAM eski sistemler için tipik.

btrfs Snapshot ve send/receive

btrfs sub-volume'ler için anlık snapshot, incremental send/receive:

# Snapshot al (readonly)
btrfs subvolume snapshot -r /data /data/.snapshots/snap-$(date +%Y%m%d)

# İlk full send (yeni hedefe)
btrfs send /data/.snapshots/snap-20260511 | btrfs receive /backup/btrfs/

# Incremental — sadece iki snapshot arası fark
btrfs send -p /data/.snapshots/snap-20260510 \
  /data/.snapshots/snap-20260511 | \
  btrfs receive /backup/btrfs/

btrfs send/receive block seviye incremental üretir — rsync'ten çok daha hızlı, çok daha az trafik. Hedef de btrfs olmalı.

ZFS Snapshot ve send/receive

ZFS dünyası benzer ama daha olgun:

# Snapshot al
zfs snapshot pool/data@$(date +%Y%m%d)

# Listele
zfs list -t snapshot

# İlk full send (uzak host'a SSH üzerinden)
zfs send pool/data@20260511 | \
  ssh -p 2222 backup@uzak-vds "zfs receive backup/data"

# Incremental
zfs send -i pool/data@20260510 pool/data@20260511 | \
  ssh backup@uzak-vds "zfs receive backup/data"

ZFS, snapshot'a "compressed + deduplicated + encrypted" özelliklerini ekleyebilen tek filesystem'dir. Off-site replication için zfs send -i (incremental) trafiği son ZFS snapshot'tan beri değişen blok kadar.

zrepl veya sanoid/syncoid gibi araçlar bu döngüyü cron + retention politika ile otomatikleştirir.

KVM qcow2 ve Hypervizör Seviye Snapshot

VDS, KVM tam sanallaştırması ile çalışır. Buyukweb VDS müşterileri kendi root erişimi içinde misafir OS snapshot'ları alabilir (qemu-img araçları guest VM içinden çalışmaz; misafir, host hypervizöre erişemez). Ancak Proxmox kullanan dedicated müşteri veya Nested VDS üzerinde KVM kuran müşteri için qcow2 araçları geçerli.

qcow2 Internal Snapshot

# VM kapatılı veya çalışırken
qemu-img snapshot -c snap1 /var/lib/libvirt/images/vm-disk.qcow2
qemu-img snapshot -l /var/lib/libvirt/images/vm-disk.qcow2

# Geri yükle
qemu-img snapshot -a snap1 /var/lib/libvirt/images/vm-disk.qcow2

Internal snapshot qcow2 dosyasının içindedir — dosya şişer. Snapshot kaldırılırsa şişme geri alınmaz (sparse compact gerekir). Performans etkisi yüksek.

qcow2 External Snapshot (Daha Modern Yaklaşım)

virsh snapshot-create-as VM_ADI snap1 \
  --disk-only --atomic --quiesce \
  --diskspec vda,snapshot=external,file=/var/lib/libvirt/images/vm-disk-snap1.qcow2

External snapshot yeni bir qcow2 dosyası açar; orijinal dosya "base" olur, yazma yeni dosyaya gider. Backup için orijinal "base" dosya kopyalanır, ardından external snapshot virsh blockcommit ile merge edilir. Performans etkisi minimum, üretimde tercih edilen.

Proxmox Backup Server (PBS) — Buyukweb Proxmox Müşterileri İçin

Proxmox VE üzerinde dedicated/fiziksel kullanan müşterilerimiz için Proxmox Backup Server (PBS) açık kaynak ve mükemmel bir hypervizör backup çözümüdür:

• Tüm VM ve LXC konteynerleri için block-level incremental
• Deduplikasyon + sıkıştırma + AES-256 client-side encryption
• Web UI üzerinden retention, sync (off-site), garbage collection
• Granular file restore — VM image içindeki tek bir dosyayı geri alabilirsin
• Tape integration (LTO) opsiyonel

Tipik Buyukweb dedicated Proxmox müşterisinin yedek mimarisi:

[Proxmox VE host] (Buyukweb Bursa Tier 3)
  → günlük backup → [PBS host] (aynı veya ayrı VLAN)
                  → haftalık sync → [S3 uyumlu uzak object storage] (off-site immutable)

Veeam Agent for Linux (Kavramsal)

Buyukweb VDS yedeği arka planda Veeam altyapısı kullanır — hypervizör seviyesinde. Bu VM image seviyesindeki yedektir.

Veeam Agent for Linux ise misafir VM içine kurulan bir ajandır. Müşteri sunucusu içindeki dosya/uygulama seviyesinde granular yedek alır, kendi seçtiği hedefe (yerel disk, NFS share, S3 uyumlu) yazar.

İki Veeam katmanını karıştırmamak önemli:

• Veeam B&R (Backup & Replication) — hypervizör seviye, Buyukweb tarafından yönetilir, müşteri sunucusunu komple yedekler.
• Veeam Agent for Linux — guest OS içine kurulur, müşteri yönetir, dosya/uygulama seviyesi.

Ücretsiz sürümü tek host için yeterli; kurumsal sürümler centralized management sağlar.

# Repo ekle (örnek)
wget -O- https://repository.veeam.com/keys/VeeamSoftwareRepoKey.gpg | \
  apt-key add -
echo "deb [arch=amd64] https://repository.veeam.com/backup/linux/agent/dpkg/debian/public stable veeam" | \
  tee /etc/apt/sources.list.d/veeam.list

apt update
apt install veeam veeamsnap

# Konsol UI
veeamconfig

Kavramsal akış: ajan installdan sonra interactive UI üzerinden "Backup Job" tanımlanır (kaynak, hedef, schedule, retention), arka planda block-level tracking ile sadece değişen blok aktarılır.

R1Soft Server Backup Manager (Dedicated Müşteri Opsiyonu)

Buyukweb dedicated/fiziksel sunucu müşterileri için talep edilirse açtığımız bir opsiyondur. R1Soft, block-level Continuous Data Protection (CDP) sağlar — değişen disk bloklarını 15 dakikalık seviyelere kadar tracking yapar.

Mimari:

[Müşteri dedicated sunucu] -- R1Soft Agent --
                  ↓ block-level CDP
[Buyukweb R1Soft Backup Manager Server]
                  ↓ replication / retention
[Off-site uzak storage]

Granular file restore, bare-metal restore, exchange/mssql/mysql/oracle uygulama-aware modülleri mevcut. Web UI üzerinden customer self-service restore.

Maliyet: R1Soft lisanslama ek hizmet bedellidir; tipik aylık ek ücret kapsamına göre konuşulur. Buyukweb destek hattından öneri alabilirsin.

WordPress Yedek Bağlamı (VDS Üstünde)

VDS üzerinde WordPress çalıştıran müşterilerimiz için yedek katmanları:

• Hypervizör katmanı — Buyukweb Veeam günlük (disaster recovery)
• Filesystem katmanı — /var/www/wp-site/ BorgBackup gece, deduplike
• DB katmanı — wp_* tabloları mysqldump 4 saatte bir, binary log aktif
• Uygulama katmanı — UpdraftPlus haftalık (uploads + DB), Google Drive / S3 uyumlu uzak hedef
• CDN/cache — Cloudflare cache purge restore senaryosunda

JetBackup, paylaşımlı cPanel'de etkili ama VDS'de cPanel kurulu değilse JetBackup yok. cPanel kurulu VDS'te ise JetBackup mevcut sözleşmenize göre opsiyonel olarak aktifleştirilir.

İlişkili kaynaklarımız: WordPress Otomatik Yedekleme: UpdraftPlus, VDS'de WordPress Kurulumu, Veritabanı Yedekleme: Full/Incremental/Differential.

Otomasyon: Cron, systemd Timer ve Healthchecks

Yedek script'i yazıldıktan sonra periyodik olarak çalışmalı ve çalıştığı doğrulanmalı. İki standart araç:

Cron (Klasik)

# /etc/cron.d/backup
# Saatlik mysqldump
15 * * * * root /usr/local/sbin/backup-mysql.sh >> /var/log/backup-mysql.log 2>&1

# Gece BorgBackup
30 2 * * * root /usr/local/sbin/backup-borg.sh >> /var/log/backup-borg.log 2>&1

# Haftalık restic verify
0 4 * * 0 root /usr/local/sbin/restic-verify.sh >> /var/log/restic-verify.log 2>&1

systemd Timer (Modern)

systemd timer cron'a göre daha iyi log yönetimi, dependency desteği, randomize delay sağlar.

# /etc/systemd/system/backup-borg.service
[Unit]
Description=BorgBackup nightly job
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup-borg.sh

# /etc/systemd/system/backup-borg.timer
[Unit]
Description=Run BorgBackup nightly

[Timer]
OnCalendar=02:30
RandomizedDelaySec=15min
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now backup-borg.timer
systemctl list-timers

Persistent=true flag'i — sunucu yedek saatinde kapalıydıysa, açıldığında bir kez çalıştır.

Healthchecks.io Dead-Man's Switch

Yedek script'inin çalıştığını bilmek yeterli değil; çalışmadığında haberdar olmak kritik. Healthchecks.io tarzı bir servis "ping bekleyen" bir endpoint sağlar. Yedek script'i başarıyla bittiyse ping atar; ping belirli süre içinde gelmezse servis sana mail/SMS/Slack atar.

#!/bin/bash
# /usr/local/sbin/backup-borg.sh
set -euo pipefail

URL="https://hc-ping.com/abcdef-uuid"

# Başla
curl -fsS -m 10 --retry 5 -o /dev/null "${URL}/start"

# Yedek
borgmatic --config /etc/borgmatic/config.yaml --verbosity 1

# Başarılı
curl -fsS -m 10 --retry 5 -o /dev/null "${URL}"

# Hata durumunda Bash exit handler ile fail ping
trap 'curl -fsS -m 10 --retry 5 -o /dev/null "${URL}/fail"' ERR

Sonuç: gece 02:30'da yedek başlamadıysa, başladı ama 3 saat içinde bitmediyse, ya da hata kodu döndüyse, telefonuna 03:00'da bildirim düşer. Sessiz arıza kalkar.

Restore Drill: Schrödinger Backup'tan Çıkmak

ID 61 ve ID 176 yazılarında restore drill kavramı işlendi. VDS için pratik bir checklist:

Aylık Restore Drill Adımları

1. Test ortamı hazırla — küçük bir test VDS (1 vCPU, 1 GB RAM) ya da Docker container.
2. En son BorgBackup arşivinden dosya restore: borg extract /backup/borg-repo::vds-prod-LATEST var/www
3. En son mysqldump'ı test DB'ye apply: zcat full-LATEST.sql.gz | mysql -u root
4. Sanity check — beklenen tablo sayısı, son sipariş tarihi, kullanıcı sayısı kontrol et.
5. WordPress restore ise wp-config.php URL/DB ayarını test domain'ine çevir, WordPress aç.
6. Sonuç logla — /var/log/restore-drill-$(date +%Y%m).log dosyasına özet yaz.
7. Bir şey patladıysa — yedek prosedürünü gözden geçir, eksik flag/dump-step varsa düzelt.

Yıllık Disaster Recovery Drill

Yılda bir kez tam restore dene: yeni bir VDS'e tüm yedeği uygula, son binary log replay et, DNS test bölgesi üzerinden eriş, fonksiyonel olduğunu kanıtla. 4-6 saatte bitmiyorsa RTO hedefin gerçekçi değil — strateji revize.

Encryption ve Key Management

Yedek dışarı çıktığı andan itibaren şifreli olmalı. Key management ihmal edilirse iki tip felaket olur:

• Anahtar kaybı → yedek var ama içeri giremiyorsun (encrypted brick).
• Anahtar açıkta → yedek var ama saldırgan da içeri girebiliyor.

GPG + Asymmetric

# GPG anahtar üret (sunucuya özel)
gpg --full-generate-key

# Yedek dosyasını şifrele (public key ile)
gpg --encrypt --recipient [email protected] full-20260511.sql.gz

# Restore için private key gerekli
gpg --decrypt full-20260511.sql.gz.gpg > full-20260511.sql.gz

Avantaj: public key sunucuda dursa bile saldırgan private key olmadan açamaz. Private key off-site (hardware token / parolayla şifreli USB) tutulur.

age (Modern Alternatif)

GPG yerine modern, daha basit bir araç olan age (age-encryption.org) kullanılabilir:

age-keygen -o ~/.age/backup.key
# Public key: age1xxxxx...

age -r age1xxxxx... -o backup.age full-20260511.sql.gz
age -d -i ~/.age/backup.key -o full-20260511.sql.gz backup.age

BorgBackup ve restic — Native Encryption

BorgBackup repokey/keyfile ve restic'in built-in AES-256 zaten encrypted by default sağlar. Ayrıca GPG katmanı eklemek isteğe bağlı.

Anahtar Yedek Politikası

• Anahtar birden fazla yerde olmalı (anahtarın yedeği de olmalı).
• Anahtar paroladan farklı korunmalı (parola dump'lanırsa anahtar hâlâ güvende olmalı).
• Anahtar periyodik rotate edilmeli (yılda 1 kez).
• Eski anahtarlar silmeden önce restore drill ile kontrol edilmeli.

Immutable / WORM: Object Lock S3 Uyumlu

Ransomware modern hayatın gerçeği. Saldırgan VDS'e girdiğinde önce mevcut yedekleri silmeye çalışır — kurban ödemeye zorlanmasın diye. Karşı önlem: immutable yedek.

S3 Object Lock

S3 uyumlu object storage'ların çoğu Object Lock özelliği destekler. Bucket level retention politika tanımlanır:

• Compliance mode — root hesap dahil hiç kimse retention süresince silemez.
• Governance mode — özel yetkili kullanıcılar override edebilir.

# restic ile S3 uyumlu hedef + Object Lock
export RESTIC_REPOSITORY="s3:https://object-storage.example.com/vds-immutable"
restic backup /etc /home /var/www
# Bucket'a Object Lock retention 30 gün politika uygulanmışsa,
# restic forget --keep-daily 7 çalıştırılsa bile snapshot'lar 30 gün boyunca fiilen silinmez.

BorgBackup --append-only

Yerel veya SSH hedefte BorgBackup'ın --append-only modu mantıksal immutable sağlar. Saldırgan ssh ile yedeği silemez, ancak borg compact çalıştırma yetkisi olan ayrı bir hesap retention politika çalıştırır.

WORM ve Tape (Kurumsal)

Büyük kurumlarda LTO tape kullanılır; tape fiziksel olarak yazılır ve raftan alınır, yazma engellenir (write-once-read-many). En yüksek koruma seviyesi ama maliyet ve karmaşıklık yüksek; KOBİ için S3 Object Lock yeterli.

Off-Site Stratejisi: Coğrafi İzolasyon

3-2-1 kuralının "1 off-site" maddesi, Buyukweb Bursa Tier 3 veri merkezinden coğrafi olarak ayrı bir lokasyona yedek atmayı gerektirir. Üç pratik yaklaşım:

A. S3 Uyumlu Object Storage (Önerilen — KOBİ)

Buyukweb dışında konumlandırılmış bir S3 uyumlu object storage sağlayıcısına BorgBackup veya restic ile push. Jenerik referans: rclone üzerinden mount ile her endpoint S3 uyumlu (örn. MinIO self-host, çeşitli ticari sağlayıcılar) hedef olur. Maliyet: GB başına aylık 0.5-3 cent tipik, retention politika ile optimize edilir.

B. İkinci VDS (Coğrafi Olarak Farklı)

Buyukweb içinde tek bir Bursa lokasyonumuz var; coğrafi izolasyon için ikinci datacenter opsiyonu Buyukweb içinde değil, harici bir sağlayıcıda olur. Bu yaklaşım Buyukweb'in tek başına önerdiği değildir — siz seçersiniz. Pratikte BorgBackup veya rsync SSH push ile yedek atılır.

C. VPN Tünel + Uzak rsync (Self-Hosted)

İki ofis arası ya da müşteri kendi data merkezi ile Buyukweb arası WireGuard / OpenVPN tüneli kurulup uzak rsync hedefine push. Detay: VPN sunucu rehberi — VDS üzerinde kendi VPN'inizi kurabilir, ayrı bir ofis sunucusuna güvenli kanal üzerinden yedek pushlayabilirsiniz.

Buyukweb VDS İçin Önerilen Yedek Mimarisi

Bütün bunları üst üste koyduğumuzda, tipik bir Buyukweb VDS müşterisi için önerilen mimari:

[VDS canlı NVMe disk]
  │
  ├── Buyukweb Veeam günlük hypervizör yedeği (Bursa Tier 3)
  │   └── Disaster recovery, hypervizör seviye
  │
  ├── Yerel saatlik mysqldump (--single-transaction --routines --triggers
  │   --events --master-data=2 --quick) → /backup/mysql/
  │   └── Binary log aktif, point-in-time recovery
  │
  ├── Gece BorgBackup yerel repo (/backup/borg-local)
  │   └── /etc, /home, /var/www, /backup/mysql dahil
  │   └── Retention: 7 gün
  │
  ├── Gece BorgBackup uzak repo (SSH push uzak host)
  │   └── append-only mode
  │   └── Retention: 30 gün, haftalık compact (admin key)
  │
  ├── Haftalık restic push S3 uyumlu object storage
  │   └── Object Lock 90 gün
  │   └── Off-site + immutable
  │
  └── Healthchecks.io dead-man's switch
      └── 24 saat ping yoksa SMS + mail bildirim

Aylık restore drill: yedek arşivinden son durumu test ortamına kur,
WordPress aç, sanity check, log dosyasına özet yaz.

Karar Matrisi: Hosting'de mi VDS'de mi?

Bu rehber VDS sahibi için ama "hâlâ hosting mi VDS mi" karar verenler için kısa bir özet:

Kriter	Paylaşımlı cPanel	VDS
Yedek yönetimi	JetBackup hazır, panel üzerinden self-service	Sen kuruyorsun, sen yönetiyorsun
Granular restore	Tek dosya / DB / hesap	Kendi araçlarınla — BorgBackup mount, restic restore
Backend storage	Buyukweb hazır	Yerel disk + uzak hedef sen seçiyorsun
Frekans seçimi	Buyukweb politikası	Cron / systemd timer ile sen ayarla
Application-aware	cPanel JetBackup MySQL-aware	Sen --single-transaction flag'lerini bilmeli
Off-site	Buyukweb arka planda	Sen kuruyorsun (S3 uyumlu push)
Maliyet	Pakete dahil	Object storage + ek storage VDS / S3 ücretli
Esneklik	Düşük (cPanel sınırlı)	Yüksek (root erişim, istediğini yap)

VDS'i tercih etmenin yedek tarafından maliyeti: aylık 50-300 TL ekstra (object storage + extra VDS storage). Karşılığında: %100 kontrol, point-in-time recovery, granular restore, retention politikası özelleştirme.

Yaygın Yedek Hataları

VDS müşterilerinde gördüğümüz en sık problemler:

• Yedek test edilmemiş. En klasik. "Yedek alıyoruz" deniyor, ama 6 ay sonra disk çöktüğünde dosyaların yarısı eksik çıkıyor.
• Yedek aynı host'ta. /backup/ dizini VDS'in ana diskinde. Disk çöküyor, yedek de gidiyor. Off-site şart.
• Encryption key kaybı. Yedek var, şifreli, anahtar Slack'te kaybolmuş. Yedek artık brick.
• DB lock'lı dump. mysqldump --single-transaction flag'i olmadan, canlı sistemi 20 dakika dondurarak alınıyor. Müşteriler şikayet ediyor.
• Parola yedekte plaintext. backup.sh dosyasında MySQL parolası dümdüz yazılı, dosya ~/scripts/'te 644 izinli. /etc/mysql/conf.d/backup.cnf 600 izinli kullan.
• Binary log devre dışı. Point-in-time recovery için zorunlu olan log_bin aktif değil. RPO 24 saat olur, daha aşağı inemezsin.
• Retention politikası yok. Yedekler 5 yıl birikiyor, disk patlamış. borg prune veya restic forget cron'da olmalı.
• Cloudflare cache vs origin tutarsızlığı. Restore sonrası Cloudflare cache eski içerikten serve etmeye devam ediyor; purge everything adımı restore prosedüründe olmalı.
• JetBackup dışı dosyalar dışlanmış. cPanel'li VDS'te JetBackup /home dışındaki /etc ve /var/www-extra gibi yerleri yedeklemiyor.
• DB user yedek için root. Yedek script'i root user kullanıyor. Sadece SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER, PROCESS, RELOAD yetkili özel backup user'ı yarat.

Sık Sorulan Sorular

"Buyukweb VDS günlük yedek alıyor ama benim de mysqldump yapmama gerek var mı?"

Evet. Buyukweb Veeam yedeği hypervizör seviyesindedir; VM image'ını ve disklerini bir gün öncesinden geri çekme imkanı verir. Ancak DROP TABLE veya bozuk migration gibi senaryolarda tek bir tablo / tek bir veritabanı / tek bir kullanıcı seviyesinde restore yapamayız — VM tamamı geri çekilir. Üstüne kendi mysqldump cron'unu eklediğinde, son saat içindeki bir hatayı tek tablo seviyesinde geri alabilirsin. RPO'yu 24 saatten 1 saate düşürür.

"BorgBackup mı restic mi seçeyim?"

Yerel disk + SSH üzerinden ikinci bir VDS'e yedek atıyorsan BorgBackup daha olgun, borgmatic ile YAML config çok rahat, append-only ransomware koruması güzel. S3 uyumlu object storage'a doğrudan push istiyorsan restic native backend desteği ile daha pratik. İkisini birden de kullanabilirsin: BorgBackup yerel + SSH, restic uzak S3.

"mysqldump çok yavaş, 100 GB veritabanım var. Ne yapayım?"

100 GB üstü InnoDB veritabanları için Percona XtraBackup veya MariaBackup kullan — physical backup, hot (canlı sistem üstünde), incremental destekli, restore çok hızlı. mysqldump 100 GB için saatler sürebilir, XtraBackup dakikalar.

"Binary log aktif edersem disk patlatır mı?"

expire_logs_days = 14 ayarı ile 14 günden eski binary log dosyaları otomatik temizlenir. sync_binlog = 1 ile her transaction sonrası disk'e flush — küçük performans cezası ama veri kaybı garantisi. Aktif sistemlerde binary log günlük 1-5 GB üretebilir; /var/log/mysql partition'una 50-100 GB ayır yeterli.

"Restore drill yapmak için zaman bulamıyorum. Otomatik bir yol var mı?"

Aylık restore drill için bir cron script'i yazabilirsin: yeni bir Docker container kaldır, son BorgBackup arşivinden DB dump çek, container içinde restore et, beklenen tablo/kayıt sayısını kontrol et, sonucu mail ile gönder. 30-45 dakikada biter, manuel müdahale gerekmez. Yine de yılda 1 kez manuel full DR drill öneriyoruz — script gözden kaçırdığı sürprizler insan gözüyle yakalanır.

"GPU VDS aldım, yedek nasıl?"

GPU VDS müşterilerinde yedek sorumluluğu müşteridedir; biz Proxmox snapshot araçlarını sağlıyoruz. Tipik kurulum: Proxmox UI üzerinden VM snapshot al, snapshot'tan VM image export et, S3 uyumlu uzak hedefe atış. Veya guest OS içinde BorgBackup/restic kur, dosya/uygulama seviyesi kendi yedeğini yönet. 0850 302 60 70 numaralı destek hattımız GPU VDS yedek planlaması için sizinle çalışır.

"Dedicated sunucu için R1Soft mu Acronis mi öneriyorsunuz?"

İkisi de profesyonel block-level backup çözümleridir. R1Soft tipik olarak hosting/VDS dünyasında, Acronis kurumsal dünyada daha popüler. Buyukweb'de hangi opsiyonun aktif olduğunu destek hattımızdan teyit etmek gerekiyor; talep ettiğin müşteride sizin senaryonuza uyanı seçeriz.

Sonuç ve Sonraki Adımlar

VDS yedek mimarisi, hosting yedek mimarisinden temelden farklı bir disipliner alandır. Üç temel ders:

1. Buyukweb hypervizör yedeği "hayat sigortası"dır, "günlük restore aracı" değildir. Hayatın koşulları gerektirdiğinde 24 saatlik image'dan dönersin; ama dosya/uygulama seviyesi günlük kayıplar için kendi katmanın lazım.
2. 3-2-1-1-0 modelini katmanla: Veeam (hypervizör) + mysqldump (uygulama) + BorgBackup (dosya) + restic S3 Object Lock (off-site immutable).
3. Restore drill olmadan yedek "Schrödinger" durumunda kalır. Aylık dosya/DB drill, yıllık tam DR drill — yedek varlığını doğrulayan tek mekanizma.

Buyukweb VDS paketlerinde (E5-V4, E5-V2, Nested) günlük Veeam yedeği standarttır; GPU VDS'te yedek sorumluluğu müşteridedir; dedicated sunucularda R1Soft/Acronis opsiyonel olarak açılabilir. Üstüne bu rehberdeki BorgBackup + restic + mysqldump katmanlarını eklediğinde, KVKK uyumlu, ransomware'a dayanıklı, RPO 4 saat / RTO 4 saat seviyesinde profesyonel bir VDS yedek altyapın olur.

---

İlgili Büyükweb Kaynakları

• VDS Sunucu Paketleri — E5-V4, E5-V2, Nested VDS, GPU VDS seçenekleri
• Hosting Yedekleme Stratejisi: 3-2-1, JetBackup, Restore Drill — Genel yedek stratejisi temel rehberi
• Veritabanı Yedekleme: Full, Incremental, Differential, PITR — DB-spesifik derinlemesine
• WordPress Otomatik Yedekleme: UpdraftPlus — WP eklenti tabanlı yedek
• cPanel Backup Wizard Tam Site Yedek — cPanel arayüzü ile yedek
• VDS Sunucu Kurulumu — Sıfırdan başlangıç rehberi
• VDS Sunucu İzleme: Zabbix, Netdata, Prometheus — Yedek başarısızlığını yakalayan monitoring
• VDS RAM/CPU Seçimi — Doğru paket için kaynak hesaplama
• Ransomware Koruma — Immutable yedek bağlamı

VDS yedek mimarisi planlamanız, BorgBackup veya restic kurulumu için yardım, R1Soft/Acronis dedicated sunucu opsiyonu, ya da restore senaryosu drill desteği için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezimizden VDS E5-V4, E5-V2, Nested VDS ve GPU VDS paketleri ile profesyonel yedek altyapısı kurarız.