Veritabanı Yedekleme Stratejileri: Full, Incremental, Differential ve PITR (2026)

Veritabanı Yedekleme Stratejileri: Full, Incremental, Differential ve Point-in-Time Recovery (2026 Pratik Rehber)

Sunucu çöktü, son yedeğin 6 ay önce mi? Ya da daha kötüsü: yedek var ama geri yükleyemiyor musunuz? DB yedeklemesi "alıyoruz" değil "test ediyoruz" meselesi. Bu rehberde MySQL/MariaDB, PostgreSQL ve MongoDB için yedekleme stratejilerini, RTO/RPO hesabını, point-in-time recovery kurulumunu ve 3-2-1 kuralını uygulanabilir komutlarla anlatıyoruz.

Buyukweb perspektifi: cPanel hosting paketlerimizde JetBackup 5 ile günlük otomatik yedekleme harici sunuculara standart. VDS paketlerimizde (E5-V4, E5-V2, Nested) Veeam altyapısıyla günlük otomatik yedekleme Buyukweb tarafından yapılır. Ancak bu sunucu/dosya seviyesi yedekleme — uygulama-tutarlı DB dump ve point-in-time recovery müşteri sorumluluğu. Eğer sitenizin bir saatteki veri kaybı bile kabul edilemezse binary log + xtrabackup kurulumu sizin tarafınızdan yapılmalı. Tercih etmeyin: "hosting yedek alıyor, benim bir şey yapmama gerek yok" yaklaşımını — sunucu yedekleri felaket kurtarma içindir, geliştirici hatasıyla silinen tablo için değil.

RTO ve RPO: Yedekleme Stratejinizin Temeli

Strateji seçmeden önce iki soruyu cevaplayın:

• RTO (Recovery Time Objective): Kesinti başladıktan kaç dakika/saat sonra sistem ayağa kalkmalı? Blog için 4 saat, e-ticaret için 30 dakika bile çok.
• RPO (Recovery Point Objective): Son kurtarılabilir nokta ne kadar geride olabilir? Günlük yedek = RPO 24 saat — o günün siparişleri gidebilir.

Senaryo	Önerilen RTO	Önerilen RPO	Yedekleme Tipi
Kişisel blog	4-8 saat	24 saat	Günlük full dump + off-site
Kurumsal tanıtım sitesi	2-4 saat	12 saat	Günlük full + haftalık doğrulama
E-ticaret (düşük hacim)	1-2 saat	1-4 saat	Günlük full + binary log
E-ticaret (yüksek hacim)	15-30 dakika	15 dakika	Saatlik incremental + binary log + xtrabackup

Bu tabloyu kendi senaryonuza uyarlayın; yöntem seçimi netleşir.

Full, Incremental, Differential: Fark Nerede?

Full Backup (Tam Yedek)

Tüm veritabanının eksiksiz kopyası. Her şey tek dosyada.

Ne zaman kullanın: Haftalık veya ana yedek olarak; incremental/differential'ın temel noktası.

Avantaj: Geri yükleme en basit — tek dosya, tek komut.
Dezavantaj: En fazla yer, en uzun süre.

Incremental Backup (Artımlı Yedek)

Sadece son yedekten bu yana değişen blokları/kayıtları alır.

Avantaj: En hızlı alma, en az depolama.
Dezavantaj: Geri yükleme karmaşık — Full + her incremental sırayla uygulanmalı. Zincirde tek bozuk halka kurtarmayı engeller.

Differential Backup (Diferansiyel Yedek)

Son full yedekten bu yana değişen her şeyi alır (incremental gibi ama "son yedek" değil, "son full" baz alınır).

Avantaj: Geri yükleme daha basit — Full + son differential.
Dezavantaj: Full'dan sonra zamanla büyür; haftalık full alınmadıysa differential şişer.

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
Geri yükleme karmaşıklığı	Basit	Karmaşık	Orta
Zincir bağımlılığı	Yok	Var (tam zincir)	Sadece full'a bağlı
Point-in-time recovery	Hayır (tek başına)	Binary log ile	Binary log ile

Pratik öneri: Full (haftalık) + incremental/differential (günlük) + binary log (sürekli) — üçü birlikte RTO'yu kısaltır, RPO'yu dakikaya indirir.

3-2-1 Yedekleme Kuralı

Kural	Ne Demek?	Örnek
3 kopya	Orijinal + 2 yedek	Prod DB + yerel disk yedek + uzak sunucu yedek
2 farklı medya	İki farklı depolama tipi	NVMe SSD + ayrı SATA disk veya object storage
1 uzak lokasyon	Farklı fiziksel yer	Farklı VDS veya S3-uyumlu object storage

Yerel disk yedek sunucu yangınında işe yaramaz. Buyukweb hosting paketlerinde JetBackup 5 harici sunuculara (uzak lokasyon) yedek atar — bu "1 uzak" koşulunu karşılar. Kendi rclone kurulumunuzla S3-uyumlu object storage veya başka bir VDS ekleyerek 3-2-1'i tamamlarsınız.

MySQL / MariaDB Yedekleme Stratejileri

mysqldump: Mantıksal Yedek (Küçük-Orta DB)

MariaDB 10.6 LTS / MySQL 8.0 için standart araç; tablo yapısını + verileri SQL formatında çıkarır.

# Tek veritabanı — InnoDB tutarlı (single-transaction şart)
mysqldump -u root -p --single-transaction --quick \
  sitem_db | gzip > /backups/sitem_$(date +%Y%m%d_%H%M).sql.gz

# Tüm veritabanları
mysqldump -u root -p --single-transaction --all-databases \
  | gzip > /backups/all_$(date +%Y%m%d_%H%M).sql.gz

# Sadece şema (yapı) — veri olmadan
mysqldump -u root -p --no-data sitem_db > /backups/schema_$(date +%Y%m%d).sql

# Binary log pozisyonuyla birlikte (PITR için şart)
mysqldump -u root -p --single-transaction --master-data=2 \
  sitem_db | gzip > /backups/sitem_full_$(date +%Y%m%d).sql.gz

Tercih etmeyin: phpMyAdmin > Export acil kurtarma için yeterli ama GZIP olmadan büyük sitede dosya boyutu onlarca GB'a ulaşır. Üstelik otomatikleştirilemez — production'da cron zorunlu.

Percona XtraBackup 8.0: Fiziksel Yedek (Büyük DB, Sıfır Kesinti)

InnoDB tablolarını kilit olmadan kopyalar. Incremental desteği var; büyük veritabanlarında (10 GB+) tercih edilmeli.

# Kurulum (Debian/Ubuntu)
apt install percona-xtrabackup-80

# Full backup
xtrabackup --backup \
  --target-dir=/backups/xb_full \
  --user=root --password=SIFRE

# Incremental backup (full'ü baz alır)
xtrabackup --backup \
  --target-dir=/backups/xb_inc1 \
  --incremental-basedir=/backups/xb_full \
  --user=root --password=SIFRE

# Restore — önce prepare
xtrabackup --prepare --target-dir=/backups/xb_full

# Incremental'ı full'e merge et
xtrabackup --prepare \
  --target-dir=/backups/xb_full \
  --incremental-dir=/backups/xb_inc1

# Kopyala (MySQL durdurulmuş olmalı)
xtrabackup --copy-back --target-dir=/backups/xb_full
chown -R mysql:mysql /var/lib/mysql

MariaDB için eşdeğer araç MariaDB Backup (mariabackup):

mariabackup --backup \
  --target-dir=/backups/mb_full \
  --user=root --password=SIFRE

Binary Log ile Point-in-Time Recovery (PITR)

Binary log (binlog), iki full dump arasındaki her işlemi kayıt altına alır. Geliştirici DROP TABLE çalıştırdığında son full dump'a dön + binlog replay ile o ana kadar geri gel.

# /etc/mysql/mariadb.conf.d/50-server.cnf — binlog aktif
[mysqld]
log_bin = /var/log/mysql/binlog
binlog_format = ROW
expire_logs_days = 7
max_binlog_size = 100M

-- Aktif binary log dosyalarını listele
SHOW BINARY LOGS;

-- Yeni log dosyası başlat (full yedek öncesi)
FLUSH BINARY LOGS;

-- Belirli zaman aralığını replay et
-- (mysqlbinlog ile)

# DROP TABLE 14:32'de yapılmışsa — 14:31'e kadar replay
mysqlbinlog --start-datetime="2026-05-08 08:00:00" \
            --stop-datetime="2026-05-08 14:31:00" \
            /var/log/mysql/binlog.000023 \
  | mysql -u root -p sitem_db

PITR için şart: Full dump alırken --master-data=2 ekleyin — dump hangi binlog pozisyonunda alındığını yazar, oradan replay yaparsınız.

Otomatik Cron Yedekleme

#!/bin/bash
# /usr/local/bin/db-backup.sh

BACKUP_DIR="/backups/databases"
DATE=$(date +%Y%m%d_%H%M)
RETENTION_DAYS=14
DB_USER="backupuser"
DB_PASS="SIFRE_BURAYA"

mkdir -p "$BACKUP_DIR"

# InnoDB tutarlı dump
mysqldump -u "$DB_USER" -p"$DB_PASS" \
  --single-transaction --master-data=2 \
  --all-databases | gzip > "$BACKUP_DIR/all_${DATE}.sql.gz"

# Eski yedekleri temizle
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +"$RETENTION_DAYS" -delete

echo "Tamamlandi: $BACKUP_DIR/all_${DATE}.sql.gz"

# /etc/cron.d/db-backup — her gece 02:30
30 2 * * * root /usr/local/bin/db-backup.sh >> /var/log/db-backup.log 2>&1

PostgreSQL Yedekleme Stratejileri

pg_dump: Mantıksal Yedek

# Custom format — en hızlı restore, sıkıştırma dahil
sudo -u postgres pg_dump -Fc sitem_db \
  > /backups/pg_sitem_$(date +%Y%m%d).dump

# SQL format
sudo -u postgres pg_dump sitem_db \
  | gzip > /backups/pg_sitem_$(date +%Y%m%d).sql.gz

# Tüm cluster (roller + DB metadata dahil)
sudo -u postgres pg_dumpall \
  | gzip > /backups/pg_all_$(date +%Y%m%d).sql.gz

# Restore — custom format
sudo -u postgres pg_restore -d sitem_db /backups/pg_sitem_20260508.dump

pg_basebackup + WAL: PITR

# Fiziksel full backup
sudo -u postgres pg_basebackup \
  -D /backups/pgbase \
  -Fp -Xs -P -R

WAL (Write-Ahead Log) arşivleme — postgresql.conf:

archive_mode = on
archive_command = 'cp %p /backups/wal/%f'
wal_level = replica

# PITR restore — recovery.conf (PostgreSQL 12 öncesi) veya postgresql.conf
# restore_command = 'cp /backups/wal/%f %p'
# recovery_target_time = '2026-05-08 14:31:00'

MongoDB Yedekleme

# mongodump — tüm veritabanları
mongodump --out /backups/mongo_$(date +%Y%m%d) --gzip

# Tek veritabanı
mongodump --db sitem_db \
  --out /backups/mongo_$(date +%Y%m%d) --gzip

# Restore
mongorestore --gzip /backups/mongo_20260508/

# Replica set üyesinden dump (prod yükü azaltır)
mongodump --host replica2.internal:27017 \
  --out /backups/mongo_$(date +%Y%m%d) --gzip

Not: MongoDB 4.0+ sessions ile tutarlı dump alın; daha büyük veri kümelerinde fiziksel snapshot tercih edin.

Şifreli Yedekleme (Encrypted Backup)

Yedeği off-site'a göndermeden önce şifreleyin — yedek depolama noktasına erişim olsa bile içerik okunamaz.

# GPG simetrik şifreleme
mysqldump -u root -p --single-transaction sitem_db \
  | gzip \
  | gpg --symmetric --cipher-algo AES256 \
        --batch --passphrase-file /etc/backup.key \
  > /backups/sitem_$(date +%Y%m%d).sql.gz.gpg

# Çözme
gpg --batch --passphrase-file /etc/backup.key \
    --decrypt /backups/sitem_20260508.sql.gz.gpg \
  | gunzip | mysql -u root -p sitem_db

# OpenSSL ile şifreleme
gzip < /backups/sitem.sql \
  | openssl enc -aes-256-cbc -pbkdf2 -iter 100000 \
                -pass file:/etc/backup.key \
  > /backups/sitem_$(date +%Y%m%d).sql.gz.enc

Anahtar saklama: Anahtarı yedeklediğiniz sunucuda saklamayın — farklı konumda (parola yöneticisi, ayrı sunucu) tutun. Anahtarı kaybederseniz yedek açılmaz.

Off-Site Yedekleme: rclone ile Otomatik Transfer

# rclone kurulumu
curl https://rclone.org/install.sh | sudo bash

# S3-uyumlu object storage yapılandır
rclone config
# → s3 provider seçin, endpoint + key bilgilerini girin

# Yerel yedeki off-site'a kopyala
rclone copy /backups/databases/ remote:buyukweb-backups/databases/

# Script'e entegre — yedek al + şifrele + off-site gönder
mysqldump -u root -p --single-transaction sitem_db \
  | gzip \
  | gpg --symmetric --cipher-algo AES256 --batch \
        --passphrase-file /etc/backup.key \
  | rclone rcat remote:backups/sitem_$(date +%Y%m%d).sql.gz.gpg

restic ile versiyonlu off-site yedekleme:

# restic repo başlat + DB dump pipe ile gönder
restic -r sftp:user@backup-server:/backups/restic init
mysqldump -u root -p --single-transaction sitem_db \
  | gzip \
  | restic -r sftp:user@backup-server:/backups/restic \
      backup --stdin --stdin-filename sitem_$(date +%Y%m%d).sql.gz

# Eski snapshotları temizle (30 günden eski)
restic -r sftp:user@backup-server:/backups/restic forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune

Restore Drill: Yedeği Test Etmek

Yedek almak yetmez; geri yüklemeyi test etmezseniz felaket anında öğrenirsiniz.

# Test ortamı DB oluştur + mysqldump restore
mysql -u root -p -e "CREATE DATABASE test_restore_db;"
gunzip < /backups/sitem_20260508.sql.gz | mysql -u root -p test_restore_db

# Tablo ve kayıt sayısı kontrolü
mysql -u root -p test_restore_db \
  -e "SELECT table_name, table_rows FROM information_schema.tables \
      WHERE table_schema='test_restore_db';"

# PostgreSQL test restore
sudo -u postgres createdb test_restore_pg
sudo -u postgres pg_restore -d test_restore_pg /backups/pg_sitem_20260508.dump

# Temizle
mysql -u root -p -e "DROP DATABASE test_restore_db;"

Aylık restore drill kontrol listesi:

[ ] Test ortamında geri yükleme yapıldı
[ ] Tablo + kayıt sayıları kontrol edildi
[ ] Geri yükleme süresi ölçüldü (RTO ile karşılaştır)
[ ] Sonuçlar kayıt altına alındı

WordPress Özel Senaryosu

DB dump tek başına WordPress yedeği değil. Eksiksiz site yedeği şunları kapsamalı:

# DB dump
mysqldump -u root -p --single-transaction wp_db \
  | gzip > /backups/wp_db_$(date +%Y%m%d).sql.gz

# Uploads (medya dosyaları)
tar -czf /backups/wp_uploads_$(date +%Y%m%d).tar.gz \
  /var/www/html/wp-content/uploads/

# Tema + eklentiler (isteğe bağlı — repo'dan yeniden kurulabilir)
tar -czf /backups/wp_content_$(date +%Y%m%d).tar.gz \
  /var/www/html/wp-content/

# wp-config.php (DB bağlantı bilgisi burada)
cp /var/www/html/wp-config.php /backups/wp-config_$(date +%Y%m%d).php

Tercih etmeyin: Sadece phpMyAdmin > Export ile alınan dump'ı "site yedeği" saymayı. wp-content/uploads klasörünü dahil etmediğinizde medya kütüphaneniz gider. Üstelik bu yöntem otomatikleştirilemez.

Buyukweb Hosting + VDS Yedekleme Yaklaşımı

Buyukweb cPanel hosting paketlerinde JetBackup 5 ile günlük otomatik yedekleme harici sunuculara yapılır. Bu yedekler cPanel > JetBackup 5 > Databases menüsünden tek tıkla restore edilebilir. Hosting paketlerimizde bu standart olarak geliyor.

VDS paketlerimizde (E5-V4, E5-V2, Nested) Veeam altyapısıyla günlük otomatik yedekleme Buyukweb tarafında yapılır — snapshot seviyesinde. Uygulama-tutarlı DB dump ve binary log yönetimi müşteri sorumluluğundadır. RPO 24 saatin altındaysa veya PITR gerekiyorsa yukarıdaki cron + binlog kurulumunu VDS'inize uygulayın.

GPU VDS'te yedekleme müşteri sorumluluğundadır; Proxmox snapshot araçları sağlanır.

Sıkça Sorulan Sorular

Full backup mı, incremental mı seçmeliyim?

İkisini birlikte kullanın. Haftalık full + günlük incremental/differential kombinasyonu hem depolama verimliliği hem de makul restore süresi sağlar. Büyük DB'lerde tek başına günlük full disk ve süre sorununa yol açar.

RTO ve RPO hedeflerimi nasıl belirlerim?

"Kaç saat kesinti kabul ederim?" ve "kaç saatlik veri kaybı kabul ederim?" — iki soruyu cevaplayın. E-ticaret için tipik: RTO 1 saat, RPO 15 dakika. Blog için: RTO 4-8 saat, RPO 24 saat.

Binary log olmadan point-in-time recovery mümkün mü?

Hayır. mysqldump tek başına dump anındaki veriyi geri getirir; arası gider. PITR için binlog aktif + dump sırasında --master-data=2 + binlog dosyalarının saklanması şart.

Şifreli yedek almak performansı etkiler mi?

GPG AES-256 şifreleme modern CPU'da yüzde 5-10 ek süre ekler — 1 GB dump için 2-5 saniyelik ek maliyet. Asıl maliyet ağ transferi ve disk I/O.

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

Bir cron + rclone (veya restic) kurulumu yeterli. Buyukweb hosting paketlerinde JetBackup 5 "uzak kopya" koşulunu karşılıyor; ek olarak kendi rclone kurulumunuzla S3-uyumlu bir object storage ekleyerek tam 3-2-1'i tamamlarsınız.

WordPress için JetBackup yeterli mi?

JetBackup 5 cPanel hosting'de dosya + DB yedekler — iyi bir başlangıç. Binary log + aylık restore drill eklendiğinde katman tamamlanır. Yüksek hacimli WooCommerce için DB-level saatlik ek yedek gerekir.

Yedeklerimi ne kadar süre saklamalıyım?

Günlük yedekleri 14 gün, haftalık yedekleri 4 hafta, aylık yedekleri 3-6 ay. KVKK gereği işlem kayıtlarını daha uzun saklamanız gerekiyorsa arşiv ayrıca yönetilmeli.

Sonuç

Yedekleme stratejisi "al ve unut" değil; "al, şifrele, off-site gönder, her ay test et" döngüsü. Buyukweb hosting ve VDS altyapısı sunucu seviyesinde günlük yedek sağlar — bu temel katman. Üzerine cron dump + binary log (PITR), şifreli off-site (3-2-1) ve aylık restore drill eklendiğinde gerçek bir strateji oluşur. Küçük blog için günlük full yeterli; aktif e-ticaret için xtrabackup incremental + binlog şart.

Destek için: 0850 302 60 70 veya iletişim sayfamız.

---

İlgili Büyükweb Hizmetleri

Veritabanı ve yedekleme altyapısı için paketler:

• cPanel Web Hosting — JetBackup 5 dahil, günlük otomatik yedek
• VDS Sunucu — Veeam ile günlük yedek, root erişim
• E5 v4 VDS — Yüksek IOPS NVMe, binlog + xtrabackup için ideal
• Fiziksel Dedicated — Tam kontrol, opsiyonel yedek hizmeti
• WordPress Hosting — JetBackup + LiteSpeed

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