Veri Bütünlüğü Doğrulama ve Otomatik Yedek Testi

Hızlı Özet (TL;DR)

Yedekleme yazılımınızın her sabah yöneticiye “İşlem %100 Başarılı” e-postası göndermesi, o yedek dosyasının gerçek bir felaket anında açılabileceğini ve içindeki ERP veritabanının tutarlı olduğunu garanti etmez. Depolama medyasındaki manyetik bozulmalar (Bit Rot), ağ aktarımındaki sessiz paket hataları, ECC olmayan belleklerdeki bit kaymaları ve uygulama tutarlılığı (Application-Consistent) sağlanmadan alınan anlık görüntüler “sessiz veri bozulmasına” yol açar. Gerçek felaket kurtarma güvencesi; ZFS Scrub ile blok bazında kriptografik doğrulama yapmayı, SHA-256 sağlama toplamlarını (Checksum) karşılaştırmayı ve izole kum havuzunda (Sandbox) otomatik sanal makine açma testlerini zorunlu kılar.

“Schrödinger’in Yedeği” Sendromu ve Sessiz Veri Bozulması

Bilgi teknolojileri dünyasında ünlü bir deyiş vardır: “Bir yedeğin durumu, siz onu geri yüklemeyi (Restore) deneyene kadar hem sağlam hem de bozuktur.” Birçok sanayi kuruluşu, yıllarca düzenli yedek aldığını düşünerek kendisini güvende hisseder. Ancak fidye yazılımı saldırısı veya sunucu yangını sonrasında yedek arşivini geri yüklemeye çalıştığında; yüzlerce gigabaytlık imaj dosyasının ortasında “CRC Veri Hatası / Bozuk Arşiv” uyarısıyla veya açılmayan bir SQL veritabanıyla karşılaşır.

Sessiz Veri Bozulması (Silent Data Corruption / Bit Rot) Nedir?

Geleneksel dosya sistemlerinde (NTFS, EXT4, XFS, FAT32) ve standart donanımsal RAID kartlarında, sabit diskin manyetik plakasındaki bir sektör zamanla mıknatıslanma özelliğini kaybettiğinde veya SSD hücrelerinde elektron sızıntısı nedeniyle bir bit 0’dan 1’e dönüştüğünde (Bit Flip), işletim sistemi bunu fark etmez. Disk kontrolcüsü fiziksel bir okuma hatası (Bad Sector) görmediği sürece bozulmuş veriyi sağlam sanarak üst katmana iletir:

• Üretim sunucusundaki bozuk bir blok gece yedekleme görevinde okunduğunda, yedekleme yazılımı bu bozuk veriyi yeni yedek arşivine yazar ve eski sağlam yedeğin üzerine kaydeder.
• Donanımsal RAID 5 veya RAID 6 dizilerinde iki diskteki veri ile parite bloğu arasında uyuşmazlık olduğunda, klasik RAID kartı hangi diskin doğru veriyi tuttuğunu bilemez (RAID Write Hole) ve yanlış bloğu referans alarak sağlam veriyi ezebilir.
• Aylar sonra o dosyaya veya geçmiş yılın muhasebe kayıtlarına ihtiyaç duyulduğunda verinin okunamaz hale geldiği acı bir şekilde ortaya çıkar.

ZFS Dosya Sistemi ve Kendi Kendini Onaran (Self-Healing) Mimari

Kurumsal depolama ve yedekleme sunucularında geleneksel dosya sistemleri yerine OpenZFS tercih edilmesinin temel nedeni, veri bütünlüğünü donanım katmanına bırakmayıp doğrudan kriptografik Merkle Ağacı (Merkle Tree) yapısıyla denetlemesidir.

ZFS dosya sistemi her veri bloğunu (Record) diske yazarken o bloğun SHA-256 veya BLAKE3 kriptografik sağlama toplamını (Checksum) hesaplar. Geleneksel sistemlerin aksine bu sağlama toplamını bloğun kendi yanına değil, bir üst düğümdeki üstveri (Parent Metadata Pointer) bloğuna kaydeder. Böylece disk kontrolcüsü yanlış sektörü okusa veya yazmayı unutsa (Lost Write / Phantom Write) dahi ZFS bunu anında yakalar:

1. Okuma Anında Doğrulama: Bir dosya veya yedek imajı okunduğunda ZFS bloğun sağlama toplamını anlık olarak yeniden hesaplar ve üst düğümdeki kayıtla karşılaştırır.
2. Anında Sessiz Onarım (Self-Healing): Eğer toplam eşleşmezse, ZFS bozuk veriyi uygulamaya kesinlikle teslim etmez. RAID-Z2 veya Mirror (Aynalama) yapısındaki diğer disklerden veya parite bloklarından sağlam veriyi hesaplar, uygulamaya doğru veriyi sunar ve arka planda bozuk diskteki sektörü sağlam veriyle yeniden yazar.
3. ECC RAM Zorunluluğu: Verinin diske yazılmadan önce RAM bellekteyken kozmik radyasyon veya elektriksel parazit nedeniyle bozulmasını önlemek için ZFS tabanlı yedekleme sunucularında mutlaka ECC (Error-Correcting Code) bellek modülleri kullanılır.

# Kurumsal ZFS yedekleme havuzunun (backup-pool) bütünlük ve hata durumunu sorgulama
zpool status -v backup-pool

# Veri bütünlüğünü uçtan uca doğrulamak için kriptografik Scrub işlemini başlatma
zpool scrub backup-pool

# Kritik yedek veri setinde kriptografik doğrulama algoritmasını SHA-256 olarak ayarlama
zfs set checksum=sha256 backup-pool/erp-vms

Yedekleme Doğrulama Yöntemleri Karşılaştırma Tablosu

Sadece yedekleme görevinin tamamlandığına dair bildirim almak ile uçtan uca otomatik kurtarma testi yapmak arasındaki teknik farklar aşağıda özetlenmiştir:

Doğrulama Seviyesi	Kontrol Edilen Katman	Yakalayabildiği Hatalar	Gözden Kaçırdığı Kritik Riskler	Güvenilirlik
1. Görev Log Kontrolü	Sadece yedekleme yazılımının çıkış kodu (Exit 0)	Ağ kopması, disk doluluğu, erişim reddi	Bozuk disk blokları, çökmüş OS, bozuk SQL veritabanı	Çok Düşük (%20)
2. Dosya Sağlama Toplamı (SHA-256)	Yedek arşiv dosyasının bit düzeyinde bütünlüğü	Aktarım sırasındaki paket bozulmaları	Yedeklenen sistemin aslında hiç açılmaması (Boot hatası)	Orta (%55)
3. ZFS Scrub + PBS Verify	Tüm veri parçalarının (Chunks) kriptografik sağlamlığı	Bit rot, disk plaka bozulmaları, eksik bloklar	Uygulama içi mantıksal veritabanı tutarsızlıkları	Yüksek (%85)
4. Otomatik Sandbox Restore Testi	Sanal makine önyükleme (Boot), OS, Ağ ve SQL servisi	Mavi ekran, bozuk MBR/UEFI, çalışmayan ERP veritabanı	Hiçbir riski gözden kaçırmaz (Tam doğrulama)	Maksimum (%99.9)

Uygulama Tutarlılığı (Application-Consistent Backup) Neden Kritik?

Bir sanal makinenin disk dosyaları fiziksel olarak %100 sağlam olsa bile, yedek alınırken veritabanı motoru (MS SQL Server, PostgreSQL, Oracle) o anda RAM bellekteki işlemleri diske yazma aşamasındaysa alınan yedek “Çökme Tutarlı” (Crash-Consistent) olur. Yani sunucunun fişini prizden çekmişsiniz gibi bir anlık görüntü oluşur. Böyle bir yedeği geri yüklediğinizde veritabanı “Recovery Pending / Suspect Mode” hatasına düşebilir ve son saatlerdeki üretim, stok ve muhasebe fişleri bozulabilir.

Bu sorunu önlemek için sanallaştırma katmanında QEMU Guest Agent veya VMware Tools üzerinden işletim sistemi içindeki VSS (Volume Shadow Copy Service) veya Linux fsfreeze kancaları (Hooks) tetiklenir:

• Yedekleme başlamadan birkaç saniye önce veritabanı motoruna “Bellekteki tüm açık işlemleri (Transactions) diske yaz ve G/Ç (I/O) kuyruğunu dondur” komutu verilir.
• Disk anlık görüntüsü (Snapshot) milisaniyeler içinde alındıktan hemen sonra veritabanı normal çalışmasına devam eder.
• Böylece yedeklenen imajın içindeki Özel ERP & CRM ve İmalat Çözümleri ile Stok Takip ve Barkodlu Depo Yazılımı veritabanları %100 işlem tutarlılığına (Transactional Integrity) sahip olur.

Otomatik Test Geri Yükleme (SureBackup / Sandbox) Mimarisi

Bilgi işlem personelinin her hafta onlarca sanal makine yedeğini tek tek elle geri yükleyip açılıp açılmadığını kontrol etmesi zaman ve iş gücü açısından imkânsızdır. Kurumsal otomatik test mimarisi bu süreci tamamen insansız bir boru hattına (Pipeline) dönüştürür:

1. İzole Sanal Laboratuvar (Fenced Sandbox Network)

Canlı fabrika ağıyla IP veya MAC adresi çakışması yaşamayan, dış dünyaya ve üretim VLAN’larına tamamen kapalı sanal bir ağ anahtarı (Virtual Bridge) oluşturulur. Küçük bir yardımcı yönlendirici (Virtual Appliance) bu izole ağ ile test motoru arasında yalnızca doğrulama ping/port trafiğine izin verir.

2. Yedekten Anında Başlatma (Instant Recovery / Live Restore)

Terabaytlarca büyüklükteki yedekleme dosyasının test sunucusuna saatlerce kopyalanması beklenmez. Yedekleme sunucusu (örneğin Proxmox Backup Server veya Veeam vPower NFS), yedek imajını ağ üzerinden doğrudan sanal bir disk olarak sunar ve sanal makine 15 saniye içinde doğrudan yedek havuzu üzerinden başlatılır.

3. Otomatik Servis ve Veritabanı Sağlık Testleri

Sanal makine açıldıktan sonra test betiği sırasıyla şu doğrulamaları gerçekleştirir:

• Hipervizör Kalp Atışı (Guest Heartbeat): İşletim sistemi çekirdeğinin mavi ekrana (BSOD) veya Kernel Panic hatasına düşmeden başarıyla açıldığı doğrulanır.
• Ağ ve Servis Port Kontrolü: Sanal makinenin IP aldığı ve üzerindeki kritik portların (MS SQL için 1433, PostgreSQL için 5432, Web/ERP için 443) bağlantıya açık olduğu test edilir.
• SQL Bütünlük Sorgusu: Veritabanı içinde otomatik olarak DBCC CHECKDB veya örnek bir tablo okuma sorgusu çalıştırılarak tablo indekslerinin sağlam olduğu kanıtlanır.

4. Raporlama, Ekran Görüntüsü Kanıtı ve İmha

Tüm testler başarıyla geçildiğinde sanal makinenin açık olan konsol ekranının görüntüsü (Screenshot) alınır, kriptografik test raporu oluşturulur ve yöneticiye iletilir. Ardından geçici sanal makine kapatılarak kum havuzu bir sonraki test için temizlenir.

ZFS Scrub ve Proxmox Backup Server (PBS) Doğrulama Periyodu

Kurumsal depolama ve yedekleme sunucularında iki katmanlı periyodik denetim takvimi işletilmelidir:

• ZFS Scrub Takvimi: Her ayın 1. ve 15. günlerinde gece mesai saatleri dışında ZFS Scrub görevi zamanlanmalıdır. Scrub işlemi havuzdaki tüm terabaytları baştan sona okuyarak sağlama toplamlarını denetler ve olası disk arızalarını henüz veri kaybı yaşanmadan (S.M.A.R.T. verileriyle birlikte) önceden haber verir.
• Tekilleştirilmiş Parça (Chunk) Doğrulaması: Yedekleme sunucusunda her hafta sonu Verify Job çalıştırılarak, tekilleştirilmiş (Deduplicated) veri parçalarının SHA-256 özetleri yeniden hesaplanır; bozulan tek bir parça bile tespit edilirse bir sonraki yedeklemede kaynak sunucudan otomatik olarak yeniden çekilerek onarılır.

Sessiz veri bozulmasına karşı kendi kendini onaran kurumsal depolama ve doğrulanmış yedekleme sistemleri için Ortak Dosya Sunucusu ve Yedekleme sayfamızı ziyaret edebilirsiniz.

Sıkça Sorulan Sorular

Yedekleme yazılımım her gün “Yedekleme Başarılı” mesajı gönderiyor, yine de yedeklerim bozuk olabilir mi?

Evet, çünkü standart yedekleme yazılımları görev sırasında yalnızca kaynak diskten okunan blokların hedef diske yazılıp yazılamadığını kontrol eder. Eğer kaynak sunucudaki bir dosya zaten bozulmuşsa, işletim sisteminin önyükleme (Boot) dosyaları hasar görmüşse veya yedekleme havuzundaki disklerde aylar içinde manyetik bozulma (Bit Rot) oluşmuşsa, yedekleme raporu yeşil görünmeye devam eder. Yedeğin gerçekten çalışıp çalışmadığını kanıtlamanın tek yolu, kriptografik blok doğrulaması (Scrub/Verify) ve izole ortamda otomatik geri yükleme (Restore) testidir.

ZFS Scrub işlemi çalışırken fabrikadaki kullanıcılar yavaşlama hisseder mi?

ZFS Scrub işlemi arka planda düşük öncelikli (Low Priority I/O) bir görev olarak çalışacak şekilde tasarlanmıştır. Kullanıcıların veya ERP sunucusunun anlık okuma/yazma talepleri geldiğinde ZFS Scrub hızını otomatik olarak kısar ve önceliği canlı üretime verir. Yine de yüksek IOPS tüketen büyük fabrikalarda Scrub görevlerinin gece yarısı veya hafta sonu vardiyalarına zamanlanması en iyi mühendislik pratiğidir.

Otomatik yedek testi (Sandbox Test) canlı ağdaki ERP sistemiyle çakışma yaratır mı?

Hayır, otomatik yedek testi tamamen izole edilmiş, sanal güvenlik duvarıyla çevrili bir “Kum Havuzu” (Sandbox / Fenced Network) VLAN’ı içinde gerçekleştirilir. Test için açılan sanal makine canlı sistemle birebir aynı IP adresine ve bilgisayar adına sahip olsa bile, paketleri fiziksel fabrika ağına asla çıkamaz. Böylece canlı üretimde çalışan kullanıcılar hiçbir kesinti veya IP çakışması hissetmeden arka planda felaket kurtarma tatbikatı tamamlanmış olur.