Kurumsal veritabanı sunucularında canlı yedekleme: MS SQL Transaction Log, PostgreSQL WAL arşivleme, Always On ve sıfır veri kaybı yedekleme kılavuzu.
Hızlı Özet (TL;DR)
Bir üretim fabrikasının, lojistik merkezinin veya B2B ticaret işletmesinin en kritik dijital varlığı, üzerinde ERP, MES, WMS ve finansal muhasebe kayıtlarının tutulduğu ilişkisel veritabanıdır (Microsoft SQL Server veya PostgreSQL). Çalışan bir veritabanı sunucusunun ham disk dosyalarını (MDF/LDF veya PostgreSQL PGDATA dizinini) işletim sistemi üzerinden kopyala-yapıştır yöntemiyle yedeklemeye çalışmak, bellekte (RAM Buffer Pool) henüz diske yazılmamış aktif işlemler (Dirty Pages) bulunduğu için tutarsız ve kurtarılamaz (bozuk) bir yedek ortaya çıkarır. Bu nedenle kurumsal veritabanlarında servisleri hiç durdurmadan çalışan Canlı Yedekleme (Hot Backup), Fark Yedeği (Differential) ve saniyeler bazında zamanda geriye dönüş imkânı veren İşlem Günlüğü (Transaction Log / WAL Archiving) mimarisi uygulanmalıdır.
Canlı Veritabanında ACID Kuralları ve Yedekleme Felsefesi
Veritabanı motorları yüksek performans sağlamak için her INSERT, UPDATE veya DELETE işlemini anında ana veri dosyasına (MDF veya Heap/Table dosyaları) yazmaz. Önce işlemi sıralı olarak İşlem Günlüğüne (Transaction Log / Write-Ahead Log - WAL) kaydeder ve değişikliği RAM bellekteki önbellek sayfalarında tutar; ardından belirli aralıklarla (Checkpoint) topluca diske yazar.
Eğer veritabanı motoruyla konuşmayan sıradan bir dosya kopyalama programı kullanırsanız, tablonun yarısı güncellenmiş, diğer yarısı eski kalmış şekilde kopyalanır ve geri yükleme sırasında veritabanı SUSPECT (Şüpheli / Bozuk) moduna düşer. Gerçek bir canlı yedekleme; uygulama farkındalıklı VSS (Volume Shadow Copy Service - SQL Writer) veya veritabanının kendi yerel akış protokollerini (BACKUP DATABASE / pg_basebackup) kullanarak kullanıcıları hiç kilitlemeden tam tutarlı (Transactional Consistent) kesit alır.
1. Microsoft SQL Server Canlı Yedekleme Mimarisi
Türkiye’deki kurumsal ERP yazılımlarının (Logo, Mikro, Netsis, SAP, Canias ve geliştirdiğimiz Özel ERP Çözümleri) büyük çoğunluğu MS SQL Server üzerinde çalışır. Sıfıra yakın veri kaybı için veritabanı kurtarma modeli mutlaka FULL Recovery Model olarak ayarlanmalı ve üç katmanlı zincir kurulmalıdır:
- Tam Yedek (Full Backup -
.bak): Her gece (veya hafta sonu) tüm veri sayfalarını ve o andaki aktif işlem günlüğünü tek bir.bakdosyasına sıkıştırarak (WITH COMPRESSION, CHECKSUM) yazar. - Fark Yedeği (Differential Backup -
.dif): Büyük veritabanlarında (örneğin 2 TB+) her saat tam yedek almak imkânsızdır. Fark yedeği yalnızca son Full yedekten bu yana değişen 8KB’lık veri kapsamlarını (Extents) yedekler; çok hızlı alınır ve geri yükleme süresini (RTO) kısaltır. - İşlem Günlüğü Yedeği (Transaction Log Backup -
.trn): Her 5 veya 15 dakikada bir çalışır. Son günlük yedeğinden bu yana gerçekleşen her bir SQL komutunu sıralı olarak kaydeder ve şişen.ldfdosyasının içini güvenli şekilde boşaltır (Log Truncation).
SQL Server’da Yaygın Yapılan “Simple Recovery” Hatası
Birçok sistem yöneticisi LDF dosyasının diski doldurmasını engellemek için veritabanını SIMPLE kurtarma moduna alır. Ancak Simple modda Transaction Log yedeği alınamaz! Gece 23:00’te tam yedek aldığınızı ve ertesi gün öğleden sonra saat 16:30’da sunucunun çöktüğünü veya bir personelin yanlışlıkla sipariş tablosunu sildiğini düşünün; Simple moddaysanız sabah 08:00’den 16:30’a kadar girilen 8,5 saatlik tüm üretim, irsaliye ve fatura verisini kalıcı olarak kaybedersiniz.
2. PostgreSQL Canlı Yedekleme ve Sürekli WAL Arşivleme
Açık kaynak dünyasının en güçlü kurumsal veritabanı olan PostgreSQL’de eski tip pg_dump komutu yalnızca mantıksal bir dışa aktarımdır; büyük veritabanlarında geri yüklenmesi saatler sürer ve işlem günlüğü içermediği için anlık kurtarma (PITR) sağlamaz. Kurumsal PostgreSQL mimarisinde şu yapı uygulanır:
- Fiziksel Temel Yedek (
pg_basebackup) vepgBackRest: Veritabanı kümesinin fiziksel blok düzeyinde canlı kopyası alınır. Büyük ölçekli yapılarda paralel sıkıştırma, blok düzeyinde artımlı (Incremental) yedekleme ve S3 nesne depolama entegrasyonu sunan pgBackRest veya Barman araçları kullanılır. - Sürekli WAL Arşivleme (Continuous WAL Archiving): PostgreSQL her işlemi 16 MB’lık
WAL (Write-Ahead Log)segmentlerine yazar. Doldurulan her WAL segmentiarchive_commandveya gerçek zamanlıpg_receivewalakışıyla anında yedekleme sunucusuna kopyalanır. Böylece veri kaybı riski (RPO) saniyenin altına iner.
MS SQL Server ve PostgreSQL Yedekleme Stratejilerinin Kıyaslaması
| Teknik Kriter | Microsoft SQL Server (Enterprise / Standard) | PostgreSQL (Kurumsal Üretim Ortamı) |
|---|---|---|
| Mantıksal / Şema Yedeği | DACPAC / BACPAC veya Generate Scripts | pg_dump / pg_dumpall (Küçük DB ve tablo bazlı kurtarma) |
| Fiziksel Canlı Tam Yedek | BACKUP DATABASE ... WITH COMPRESSION, CHECKSUM (.bak) | pg_basebackup veya pgBackRest --type=full |
| Blok Bazlı Fark Yedeği | Yerleşik WITH DIFFERENTIAL (.dif) desteği | pgBackRest --type=diff / incr (veya PG 17+ yerel Incremental) |
| Sürekli Günlük Yedeği (PITR) | BACKUP LOG (.trn) — 5/15 dakikalık periyotlar | Sürekli WAL Archiving + pg_receivewal (Sıfır RPO akışı) |
| Yüksek Erişilebilirlik (HA) | Always On Availability Groups / Failover Cluster | Patroni + Streaming Replication (Senkron / Asenkron) |
| Bozulma ve Bütünlük Testi | DBCC CHECKDB ile sayfa ve indeks doğrulaması | pg_checksums (Data Checksums) ve pg_amcheck |
Point-in-Time Recovery (PITR): Zamanda İstenilen Saniyeye Dönüş
Canlı günlük yedeklemesinin en büyük gücü donanım arızasından ziyade insan hatalarında ve yazılım bug’larında ortaya çıkar. Bir kullanıcının veya hatalı bir güncelleme betiğinin saat 14:32:10 anında DELETE FROM StokHareketleri komutunu WHERE koşulu olmadan çalıştırdığını varsayalım. Eğer sadece sıcak replikasyon (Always On veya Streaming Replication) kullanıyorsanız, silme komutu aynı milisaniyede yedek sunucudaki veriyi de siler!
Point-in-Time Recovery (PITR) yeteneği sayesinde:
- Önce gece alınan Full Backup (ve varsa öğlen alınan Differential Backup)
NORECOVERYmodunda geri yüklenir. - Ardından saat 14:32’ye kadar alınan Transaction Log (
.trn) veya WAL dosyaları sırayla işletilir ve SQL Server’daSTOPAT = '2026-10-31 14:32:05', PostgreSQL’de iserecovery_target_time = '2026-10-31 14:32:05'parametresi verilir. - Veritabanı, silme işleminin gerçekleşmesinden tam 5 saniye önceki eksiksiz haliyle ayağa kalkar.
Yedeklerin Bütünlük Kontrolü ve Fidye Yazılımı (Immutability) Koruması
Alınan veritabanı yedeklerinin diskteki sessiz sektör bozulmalarına (Bit Rot) karşı korunması için yedekleme öncesinde veya test sunucusunda düzenli olarak DBCC CHECKDB (MS SQL) ve veri sağlama toplamı (Data Checksums - PostgreSQL) kontrolleri otomatikleştirilmelidir. Ayrıca veritabanı yedeklerinin tutulduğu depolama alanı ağdan gelen fidye yazılımlarına karşı Değiştirilemez (Immutable / WORM - Write Once Read Many) olarak kilitlenmeli ve sunucu güvenliği Sızma Testi (Pentest) ile denetlenmelidir.
Kurumsal veritabanı yedekleme, Always On kümeleme ve felaket kurtarma çözümlerimiz için Ortak Dosya Sunucusu ve Yedekleme sayfamızı inceleyin.
Sıkça Sorulan Sorular
Gün içinde her 10 dakikada bir Transaction Log veya WAL yedeği almak ERP programını yavaşlatır mı?
Hayır, aksine veritabanı sağlığını korur. Transaction Log ve WAL yedeklemesi veri tablolarını okumaz; yalnızca son 10 dakikada oluşan küçük günlük kayıtlarını sıralı (Sequential Read) olarak okur ve diske yazar. Modern SSD/NVMe disklerde bu işlem birkaç saniye sürer, tabloları kilitlemez (Non-blocking) ve işlem günlüğü dosyasının kontrolsüz şişerek diski kilitlemesini önler.
Sanal makine (VMware / Hyper-V) düzeyinde imaj yedeği alıyoruz; yine de ayrıca SQL yedeği almamız gerekir mi?
Eğer kullandığınız sanal makine yedekleme yazılımı (örneğin Veeam) üzerinde Application-Aware Processing (Uygulama Farkındalıklı İşleme) ve SQL Log Truncation özelliği aktif değilse, alınan sanal makine yedeği veritabanı açısından “çökme tutarlı” (Crash-Consistent) olur ve işlem günlüklerini temizlemez. En güvenli kurumsal pratik; hem VM bazlı imaj yedeği almak hem de veritabanı motorunun kendi yerel .bak/.trn veya WAL arşivlemesini ayrı bir yedekleme havuzuna (Repository) göndermektir.
Çok büyük (örneğin 5 Terabayt) bir veritabanında tek bir tablodaki silinen 100 satırı kurtarmak için tüm veritabanını mı geri yüklemeliyiz?
Hayır, canlı üretim veritabanını kapatmanıza gerek yoktur. Yedek dosyası izole bir test sunucusuna veya yedekleme yazılımının Anında Veritabanı Yayınlama (Instant Database Publish) özelliğiyle doğrudan yedek deposu üzerinden farklı bir isimle (ERP_Kurtarma_DB) saniyeler içinde bağlanır. Silinen 100 satır INSERT INTO ... SELECT sorgusuyla canlı veritabanına aktarılır ve işlem kesintisiz tamamlanır.