Fiziksel vs Mantıksal Yedekleme Felsefesi: RPO/RTO, Snapshot ve PITR Yönetimi

▸1. Mantıksal Yedekleme Neden Üretim Yedeği Değildir?

Çoğu junior DBA veya yazılımcı pg_dump veya mysqldump komutunu bir cronjob'a bağlayıp sistemin yedeklendiğini düşünür. Bu, 50 GB'ın üzerindeki her kurumsal veritabanı için felaketle sonuçlanan bir yanılgıdır:

1Geri Yükleme Süresi (RTO Felaketi): 500 GB'lık bir mantıksal dökümü geri yüklemek; tüm SQL INSERT komutlarının tek tek çalıştırılması, tabloların yeniden yazılması ve tüm indekslerin sıfırdan inşa edilmesi demektir. 500 GB'lık bir SQL dump'ın restore edilmesi 18-36 saat sürebilir!
2Kayıp Penceresi (RPO Felaketi): Dün gece 02:00'de alınan bir dump, bugün 16:30'da sistem çöktüğünde aradaki 14.5 saatlik tüm verinin kaybolması demektir (RPO = 14.5 saat).
3Tutarlılık ve Kilit Maliyeti: Mantıksal yedekler uzun süren snapshot kilitleri veya MVCC snapshot izolasyonu gerektirir; bu durum veritabanında satır şişmesine (bloat) ve transaction log birikmesine yol açar.

▸2. Fiziksel Yedekleme ve Blok Düzeyinde Veri Transferi

Fiziksel yedekleme araçları (pgBackRest, Percona XtraBackup, mariabackup); veritabanı motorunun ham disk bloklarını doğrudan kopyalar:

•PostgreSQL (pgBackRest): 8KB'lık sayfaları doğrudan okur. Yalnızca değişen blokları (Differential veya Incremental) yedekler. Sıkıştırma ve paralel I/O ile 1 TB veriyi 20 dakikada yedekleyebilir.
•MySQL (Percona XtraBackup): InnoDB motoru canlı yazma kabul ederken fiziksel sayfaları kopyalar; kopyalama sırasında üretilen Redo Log'u arkadan okuyarak yedekleme anındaki çökmüş (inconsistent) blokları otomatik düzeltir (prepare aşaması).

▸3. PITR (Point-in-Time Recovery): Saniyelik Geri Dönüş

Fiziksel yedeklemenin gerçek gücü, veritabanının işlem logları (PostgreSQL WAL, MySQL Binary Log) ile birleştiğinde ortaya çıkar.

Mimari Akış & Topoloji Şeması (Mermaid)

Mermaid şeması çiziliyor...

1Sürekli Arşivleme: Üretilen her WAL segmenti (16MB) veya Binlog dosyası anında güvenli bir nesne depolama alanına (AWS S3, MinIO, Ceph) gönderilir.
2Hedef Kurtarma Hedefi (Recovery Target): Yanlışlıkla DROP TABLE users; çalıştırıldığında, log analiz edilerek drop işleminden tam 1 saniye öncesi belirlenir:

sql

   -- postgresql.auto.conf (veya recovery.signal)
   recovery_target_time = '2026-10-27 14:32:09 UTC'
   recovery_target_action = 'promote'

1Veritabanı pazar günkü tam yedeği açar, aradaki artımlı blokları uygular ve logları tam 14:32:09'a kadar oynatarak sıfır veri kaybıyla ayağa kalkar.

▸4. 3-2-1-1-0 Kurumsal Yedekleme Standardı

Modern finans ve telekom altyapılarında uygulanan altın standart:

•3 Kopya: Verinin 1 orijinali + en az 2 yedeği bulunmalı.
•2 Farklı Medya: Yerel NVMe diskler + Uzak Nesne Depolama (S3).
•1 Uzak Lokasyon: Bir kopya mutlaka ana veri merkezinden coğrafi olarak farklı bir bölgede olmalı.
•1 Değiştirilemez (Immutable) Kopya: Fidye yazılımlarına (Ransomware) karşı S3 Object Lock (WORM - Write Once Read Many) ile kilitlenmiş kopya.
•0 Hata: Haftalık otomatik geri yükleme tatbikatı ile doğrulanmış (checksum verified) yedek.

▸5. Uygulamalı Laboratuvar Tatbikatı

Yedekleme mimarisini teoride bırakmayın; izole bir ortamda mantıksal ve fiziksel geri yükleme adımlarını bizzat test edin: 👉 [PostgreSQL İlk Restore Tatbikatı: Ölçülebilir Geri Yükleme ve Doğrulama Rehberi](/postgresql/runbooks/first-restore-drill) — Tek komutla (npm run test:drill) izole Docker kümesinde yedek alma, hata senaryosu, veri bütünlüğü ve yetki doğrulaması.