Veritabanı Yedekleme Stratejileri: SQL Server, PostgreSQL, MySQL

Özet: Veritabanı yedekleme, dosya sunucusu yedeklemesinden farklı bir disiplindir; tam (full), diferansiyel ve transaction log seviyesinde katmanlı çalışır. SQL Server için Full + Diff + Log Backup zinciri, PostgreSQL için pg_dump + WAL arşivleme, MySQL için mysqldump + binary log replikasyonu KOBİ ölçeğinde uygulanabilir standart yaklaşımlardır. Doğru kurulan bir yedek zinciri "saat 14:23'e geri dön" gibi sub-dakikalık point-in-time recovery sağlar; yanlış kurulan bir zincir ise gece yedeği aldığını sandığınız sunucunun aslında 6 ay önce başarısız olduğunu gerçek bir kaybın ortasında öğretir.

KOBİ'lerde "veritabanı yedeği var mı?" sorusunun cevabı çoğu zaman "evet, gece yarısı yedek alınıyor" şeklinde. Soruyu derinleştirince: "yedek başarılı mı?" cevap "bilmiyorum, hata uyarısı gelmedi", "geri yüklemesi denendi mi?" cevap "hayır". Bu üçlü senaryoda yedek aldığını sanan KOBİ aslında yedek kaybı riskinden gafildir. Üstelik veritabanı yedeği dosya yedeğinden farklı: tutarlı (consistent) olmalı, transaction'lar yarıda bırakılmamış olmalı, point-in-time recovery için log zinciri kırılmamış olmalı.

Bu yazıda KOBİ ölçeğinde üç yaygın veritabanı motoru için (SQL Server, PostgreSQL, MySQL) yedekleme stratejilerini ele alıyoruz. Hedef kitlemiz IT yöneticileri, sistem yöneticileri ve "veritabanı yedeği" cümlesini somut adımlara dönüştürmek isteyen karar vericiler.

Veritabanı Yedekleme Neden Özel?

Dosya sunucusu yedeği basit: dosya kopyalanır, yedeklenir. Veritabanı çok daha karmaşık.

Veritabanı Yedek Zorlukları

• Tutarlılık (Consistency): Yedek alındığı anda yarım kalmış işlem yok
• Boyut: Tek bir DB onlarca/yüzlerce GB olabilir
• Sürekli yazım: DB sürekli değişiyor — anlık fotoğraf almak teknik
• Point-in-time recovery (PITR): "Saat 14:23'e geri dön" beklenir
• Transaction log: Her işlem ayrıca loglanır
• Şifrelenmiş tablolar: TDE açıksa yedeğin de doğru anahtarla şifrelenmesi gerekir

Bu zorluklar nedeniyle DB motorunun kendi yedek araçları kullanılır; "dosya kopyala" yaklaşımı yetmez.

Yedek Türleri — Genel Kavramlar

Tüm DB motorları üç temel yedek türü sunar:

Full Backup (Tam Yedek)

Veritabanının tamamı. Büyük, ama bağımsız. Geri yükleme tek başına yapılabilir.

Differential Backup (Diferansiyel Yedek)

Son full yedekten beri değişen tüm bloklar. Tam yedeğe göre küçük ama büyür. Geri yükleme: full + en son diff.

Transaction Log Backup (Log Yedek)

Tek tek işlemleri kaydeden log dosyaları. Çok küçük, çok sık alınır (15 dk, 1 saat). Point-in-time recovery için temel.

Tipik Zincir

Pazartesi 02:00 — Full Backup
Salı 02:00       — Diff Backup
Çarşamba 02:00   — Diff Backup
Perşembe 02:00   — Diff Backup
Cuma 02:00       — Diff Backup
Cumartesi 02:00  — Diff Backup
Pazar 02:00      — Yeni Full Backup

Tüm gün boyunca:
Her 15 dakika   — Transaction Log Backup

Bu zincir kullanıcılara haftalık 1 full + günlük diff + 15-dk log koruma sağlar. Recovery point: 15 dakika; Recovery time: 30 dk - birkaç saat.

SQL Server (Microsoft) Yedekleme

KOBİ'lerde Türkiye'de en yaygın DB motoru. Native yedek araçları olgun.

Recovery Model Seçimi

SQL Server'da üç recovery model var:

Model	Log Backup	PITR	KOBİ Uygunluğu
Simple	Yok	Yok	Geliştirme/test
Bulk-Logged	Sınırlı	Sınırlı	ETL ağırlıklı
Full	Evet	Evet	Production önerilir

Production için Full recovery model standart. Log backup zorunlu olur.

Full Backup Komutu

BACKUP DATABASE [SirketDB]
TO DISK = 'D:\Backups\SirketDB_Full_20260503.bak'
WITH COMPRESSION, CHECKSUM, INIT;

Differential Backup

BACKUP DATABASE [SirketDB]
TO DISK = 'D:\Backups\SirketDB_Diff_20260503.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;

Transaction Log Backup

BACKUP LOG [SirketDB]
TO DISK = 'D:\Backups\SirketDB_Log_20260503_1430.trn'
WITH COMPRESSION, CHECKSUM;

Maintenance Plan veya Ola Hallengren Scripts

Manuel komut yerine SQL Server Maintenance Plan veya Ola Hallengren'in topluluk script'leri (en yaygın) kullanılır. Otomatik zincir, retention yönetimi, başarısız yedek uyarısı sunar.

Restore — Point-in-Time

-- 1. Full restore (NORECOVERY)
RESTORE DATABASE [SirketDB]
FROM DISK = 'D:\Backups\SirketDB_Full.bak'
WITH NORECOVERY, REPLACE;

-- 2. Latest diff (NORECOVERY)
RESTORE DATABASE [SirketDB]
FROM DISK = 'D:\Backups\SirketDB_Diff.bak'
WITH NORECOVERY;

-- 3. Log backups sırayla, son log STOPAT belirli zaman
RESTORE LOG [SirketDB]
FROM DISK = 'D:\Backups\SirketDB_Log_1430.trn'
WITH STOPAT = '2026-05-03T14:23:00', RECOVERY;

PostgreSQL Yedekleme

KOBİ'de açık kaynak DB motoru olarak yaygınlaşıyor.

Yedek Yöntemleri

Yöntem	Açıklama	KOBİ Uygunluğu
pg_dump	Logical backup, SQL formatında	Küçük-orta DB
pg_basebackup	Physical backup, file system kopya	Büyük DB
WAL archiving	Continuous archiving	PITR için şart
pg_dumpall	Tüm cluster (kullanıcı, role dahil)	Yıllık snapshot

pg_dump

pg_dump -U postgres -d sirket_db -F c -f sirket_db_20260503.dump

-F c custom format — sıkıştırılmış, parallel restore destekli.

Continuous Archiving + Base Backup

Production için pg_dump tek başına yetmez; WAL archiving + base backup kombinasyonu PITR sağlar.

postgresql.conf:

wal_level = replica
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/wal_archive/%f'

Base backup periyodik (haftalık), WAL sürekli.

pgBackRest / Barman

Production'da pgBackRest veya Barman araçları tercih edilir:

• Otomatik full + incremental + WAL
• Retention politikası
• Encryption ve compression
• Restore test komutları
• KOBİ ölçeğinde docker'da bile çalışır

Restore — PITR

# Base backup restore
tar xf base_backup.tar -C /var/lib/postgresql/data

# recovery.conf veya postgresql.auto.conf
restore_command = 'cp /var/lib/postgresql/wal_archive/%f %p'
recovery_target_time = '2026-05-03 14:23:00'

MySQL / MariaDB Yedekleme

E-ticaret, web uygulamaları için yaygın.

Yedek Yöntemleri

Yöntem	Açıklama
mysqldump	Logical backup, SQL formatında
mysqlpump	mysqldump'a göre daha modern
XtraBackup (Percona)	Physical backup, tutarlı
Binary log (binlog)	Replication + PITR
MyDumper	Parallel logical backup

mysqldump

mysqldump --single-transaction --quick --routines --triggers \
  --events --hex-blob --master-data=2 \
  -u root -p sirket_db > sirket_db_20260503.sql

--single-transaction consistent snapshot için kritik (InnoDB).

Binlog ile PITR

my.cnf:

log_bin = /var/log/mysql/mysql-bin
binlog_format = ROW
expire_logs_days = 14

Binlog'lar transaction-level kayıt tutar. Full + binlog ile PITR.

Restore — PITR

# 1. Full restore
mysql -u root -p sirket_db < sirket_db.sql

# 2. Binary log replay until specific time
mysqlbinlog --stop-datetime="2026-05-03 14:23:00" \
  /var/log/mysql/mysql-bin.000123 | mysql -u root -p sirket_db

Percona XtraBackup

Büyük DB'lerde mysqldump yetmez (saatler sürer). XtraBackup hot physical backup sağlar — DB durmaz.

Yedek Sıklığı ve Retention

KOBİ ölçeğinde tipik politika:

Yedek Tipi	Sıklık	Retention
Full backup	Haftalık (Pazar 02:00)	4 hafta
Differential	Günlük (02:00)	1 hafta
Transaction log	Her 15 dakika	24 saat
Aylık snapshot	Her ayın 1'i	12 ay
Yıllık snapshot	Her yılın 1'i	7 yıl (mali yasal)

Yedek Doğrulama (Verification)

Yedek alındı; ama açılır mı? CHECKSUM ve restore testleri:

CHECKSUM ve VERIFY

• SQL Server: WITH CHECKSUM ve RESTORE VERIFYONLY
• PostgreSQL: pg_basebackup CHECKSUM, restore test
• MySQL: mysqldump output check, mysqlbinlog --verify

Restore Drill — Aylık

Gerçek geri yükleme:

1. Test ortamına en son full restore et
2. Diff ve log uygula
3. DB açılıyor mu? Birkaç sorgu çalışıyor mu?
4. RTO ölçümü yap
5. Sonucu raporla

Test edilmemiş yedek = yedek değildir.

Yedek Saklama Yeri

Yedeklerin nerede saklanacağı kritik:

Yanlış: Aynı Sunucu

DB sunucusunun kendi diskinde yedek tutmak — disk arızasında ikisi birden gider.

Yanlış: Aynı Domain'deki NAS

Domain admin parolası ele geçirilirse hem DB hem yedek erişilebilir.

Doğru: 3-2-1 + Immutable

• DB sunucu lokal yedek (hızlı geri yükleme)
• Yedek NAS / yedek sunucu
• Bulut immutable katman (önceki yazıda detayı)
• Aylık offline disk

TDE (Transparent Data Encryption) ile Yedek

Hassas veri içeren DB'lerde TDE açıksa:

• Yedek dosyası da şifreli
• Restore için doğru anahtar gerekir
• Anahtar yedek de ayrı saklanmalı (HSM, secret manager)
• Anahtar kayıp = yedek de kayıp

Yamanlar Bilişim Olarak Sunduğumuz Hizmetler

KOBİ ölçeğinde DB yedek destek alanlarımız:

• Mevcut DB yedek mimarisi denetimi
• SQL Server / PostgreSQL / MySQL yedek otomasyon
• Ola Hallengren / pgBackRest / XtraBackup kurulum
• Point-in-time recovery yapılandırma
• Aylık restore testi ve raporlama
• Bulut immutable entegrasyonu
• TDE ve anahtar yönetimi
• Yıllık DR tatbikatı

Sıkça Sorulan Sorular

Sonuç

Veritabanı yedekleme, KOBİ siber dayanıklılığının en kritik halkalarından biridir. Doğru kurulan bir Full + Diff + Log zinciri, herhangi bir noktaya geri dönüş esnekliği sağlar; aylık restore testleri ile doğruluk kanıtlanır; immutable bulut katmanı ransomware'e karşı son savunmayı oluşturur. SQL Server, PostgreSQL, MySQL — her birinin kendine has araçları var; standart pratiklerin uygulanması KOBİ ölçeğinde zor değil, sadece düzenli operasyon disiplini ister.

Yamanlar Bilişim olarak DB ölçeğinize ve motoruna göre özelleştirilmiş yedek stratejileri tasarlıyor, otomasyonu kuruyoruz; veritabanınızı "umarız geri yüklenir" konumundan "her ay test ediliyor, her zaman hazır" konumuna taşıyoruz.