Sanal sunucu imaj yedeklemesi mi dosya bazlı yedekleme mi? Karşılaştırma, kurtarma hızları, depolama verimliliği ve doğru tercih rehberini keşfedin. İnceleyin.
Hızlı Özet (TL;DR)
Kurumsal veri koruma ve felaket kurtarma (Disaster Recovery) stratejisi oluştururken BT yöneticilerinin karşılaştığı en temel mimari karar; sanal veya fiziksel sunucuyu işletim sistemi, kayıt defteri (Registry), veritabanı motoru ve tüm disk bölümleriyle birlikte tek bir blok düzeyinde mi (İmaj Bazlı Yedekleme - Image-Level Backup), yoksa yalnızca sunucu içindeki belirli dizin ve dökümanları mı (Dosya Bazlı Yedekleme - File-Level Backup) yedekleyecekleridir. Her iki yaklaşımın da kurtarma süresi (RTO), veri kaybı toleransı (RPO) ve depolama alanı tüketimi açısından kendine özgü güçlü ve zayıf yönleri vardır. Doğru kurgulanmış bir endüstriyel yedekleme mimarisinde bu iki yöntem birbirinin rakibi değil, 3-2-1-1-0 yedekleme kuralının ayrılmaz iki tamamlayıcısı olarak konumlandırılmalıdır.
Felaket Anında Gerçek Sınav: RTO ve RPO Kavramları
Bir yedekleme sisteminin kalitesi, yedek alırken ne kadar sessiz çalıştığıyla değil; Cuma akşamı bir fidye yazılımı (Ransomware) saldırısı gerçekleştiğinde veya RAID kontrolcüsü yandığında sistemi kaç dakika içinde ayağa kaldırabildiğiyle ölçülür. Bu noktada iki mühendislik metriği devreye girer:
- RPO (Recovery Point Objective - Kurtarma Noktası Hedefi): Felaket anında en fazla kaç saatlik veya dakikalık veri kaybına tahammül edilebileceğini belirler.
- RTO (Recovery Time Objective - Kurtarma Süresi Hedefi): Arıza veya saldırı tespit edildikten sonra sunucunun ve üretim takip yazılımı gibi kritik servislerin tekrar çalışır hale gelmesi için geçen maksimum süreyi ifade eder.
Yalnızca dosya bazlı yedekleme yapan bir fabrikada, ERP sunucusunun işletim sistemi çöktüğünde önce yeni bir Windows Server kurulması, güncellemelerin yapılması, SQL Server motorunun yüklenmesi, IIS servislerinin ayarlanması ve ardından yedekteki dosyaların geri dönülmesi gerekir ki bu süreç 8 ila 24 saat sürer. Oysa imaj bazlı yedeklemede tüm sunucu imajı Instant VM Recovery teknolojisiyle doğrudan yedekleme ünitesi üzerinden 5 ila 15 dakika içinde canlıya alınır.
İmaj Yedekleme ve Dosya Bazlı Yedeklemenin Teknik Kıyaslaması
Aşağıdaki tablo, VMware ESXi, Microsoft Hyper-V ve Proxmox VE gibi sanallaştırma ortamlarında kullanılan iki yedekleme yaklaşımını temel mühendislik kriterlerine göre karşılaştırmaktadır:
| Karşılaştırma Kriteri | İmaj Bazlı Yedekleme (Image / Snapshot-Level) | Dosya Bazlı Yedekleme (File / Folder-Level) |
|---|---|---|
| Yedekleme Kapsamı | İşletim sistemi, boot sektörü, sistem durumu, kurulu yazılımlar, ayarlar ve tüm sanal diskler (.vmdk, .vhdx). | Yalnızca seçilen klasörler, belgeler, CAD çizimleri ve dışa aktarılmış (.bak, .sql) dosyalar. |
| Tam Sunucu Kurtarma Hızı (RTO) | Çok Hızlı (5 – 15 Dakika): Instant Recovery ile sunucu doğrudan yedek deposundan boot edilir. | Çok Yavaş (6 – 24 Saat): Önce sıfırdan işletim sistemi ve uygulamalar kurulmalı, sonra veri kopyalanmalıdır. |
| Tekil Dosya Kurtarma Hızı | Yüksek (1 – 3 Dakika): Modern yedekleme yazılımları imajın içini açmadan tek bir Excel/CAD dosyasını çekebilir (Granular Restore). | Çok Hızlı (Saniyeler içinde): Doğrudan hedef klasördeki ilgili dosya kaynak dizine kopyalanır. |
| Çalışan Veritabanı Tutarlılığı | Tam Tutarlı: Microsoft VSS (Volume Shadow Copy) ile RAM’deki veriler diske yazılarak (Quiescing) dondurulur. | Riskli: Açık olan .mdf veya .ldf veritabanı dosyaları dosya kopyalama sırasında kilitli olduğu için atlanır veya bozuk kopyalanır. |
| İnkremental (Artımlı) Hız | CBT (Changed Block Tracking): Milyonlarca dosyayı taramaz; yalnızca değişen disk bloklarını saniyeler içinde okur. | Dosya Tarama Darboğazı: Milyonlarca küçük dosya (Inode/MFT) tek tek taranacağı için yedekleme penceresi saatlerce uzar. |
| Depolama Alanı Verimliliği | Blok bazlı tekilleştirme (Deduplication) ve sıkıştırma (Compression) ile yüksek verim sağlar. | Sadece seçilen saf veri tutulduğu için başlangıç boyutu küçüktür ancak çoklu versiyonlamada büyür. |
Sanal Sunucu İmaj Yedeklemesi (CBT ve VSS Mimarisi) Nasıl Çalışır?
Kurumsal sanallaştırma altyapılarında (VMware vSphere API for Data Protection - VADP veya Hyper-V RCT) imaj yedeklemesi, sanal makineyi kapatmadan veya yavaşlatmadan arka planda gerçekleşir:
1. Application-Aware Processing (Uygulama Duyarlı Dondurma)
Yedekleme görevi başladığında yazılım, sanal sunucu içindeki VSS (Volume Shadow Copy Service) servisine sinyal gönderir. Active Directory, Microsoft SQL Server, Exchange veya PostgreSQL gibi kritik servisler o an bellekte (RAM) bekleyen yarım işlemleri diske yazar (Flush) ve birkaç saniyeliğine I/O işlemlerini dondurur. Böylece alınan yedek, sunucu fişten çekilmiş gibi (Crash-Consistent) değil, tüm veritabanı işlemleri tamamlanmış (Transactionally Consistent) durumda olur.
2. Changed Block Tracking (Değişen Blok Takibi - CBT)
İlk gün alınan tam yedekten (Full Backup) sonra, her gece terabaytlarca diski baştan sona okumak yerine Hypervisor katmanındaki CBT / RCT tablosu sorgulanır. Hypervisor, bir önceki yedekten bu yana diskin yalnızca hangi sektörlerinin (bloklarının) değiştiğini hafızasında tutar. Bu sayede 2 TB büyüklüğündeki bir ERP ve MRP sunucusunun gece yapılan artımlı (Incremental) yedeği yalnızca değişen 15 GB’lık blokları okuyarak 4-5 dakika içinde tamamlanır.
Dosya Bazlı Yedeklemenin Vazgeçilmez Olduğu Senaryolar
İmaj yedeklemesi sistem kurtarmada rakipsiz olsa da dosya bazlı yedeklemenin daha avantajlı olduğu spesifik alanlar mevcuttur:
- Devasa Arşiv ve CAD/PDM Dosya Paylaşımları: İçerisinde 15-20 TB boyutunda SolidWorks, AutoCAD, video ve PDF arşivi barındıran NAS cihazları veya fiziksel dosya sunucularında yalnızca değişen proje klasörlerini farklı bir bulut nesne depolama alanına (S3 Object Storage) veya ikinci bir NAS kutusuna dosya bazlı senkronize etmek lisans ve disk maliyetini düşürür.
- Uzun Vadeli Yasal Saklama (7–10 Yıllık Arşiv): Muhasebe e-Defter beratları, kalite sertifikaları ve 5651 yasal loglama arşivleri gibi işletim sisteminden bağımsız, 10 yıl sonra bile herhangi bir bilgisayarda doğrudan açılması gereken veriler açık dosya formatında saklanmalıdır.
- Kullanıcı Bilgisayarları (Endpoint Backup): Mühendislik ve yönetim dizüstü bilgisayarlarındaki
MasaüstüveBelgelerimklasörlerinin merkezi sunucuya yedeklenmesinde hafif dosya ajanları tercih edilir.
Hibrit Yedekleme Stratejisi: İkisini Birlikte Nasıl Kurgulamalı?
Maysa Yazılım olarak sanayi kuruluşlarında uyguladığımız altın standart Hibrit Katmanlı Yedekleme mimarisidir:
- Katman 1 (Günlük İmaj Yedekleme & Replikasyon): Tüm sanal sunucular (DC, ERP, MES, WMS, File Server) günde en az 1 veya 2 kez uygulama duyarlı imaj yedeklemesiyle ayrı bir fiziksel yedekleme sunucusuna (NAS/SAN) yedeklenir.
- Katman 2 (Saatlik Veritabanı ve Dosya Yedeği): ERP veritabanının
.bakve Transaction Log yedekleri her saat başı alınarak RPO süresi 1 saatin altına çekilir; ortak dosya sunucusunda ise günde 3 kez Volume Shadow Copy (Önceki Sürümler) aktif edilerek kullanıcıların sildiği dosyaları kendi başlarına saniyeler içinde geri getirmesi sağlanır. - Katman 3 (Çevrimdışı / Değiştirilemez Kopya - Immutable Backup): Alınan imaj ve dosya yedeklerinin bir kopyası, fidye yazılımlarının şifreleyemeyeceği WORM (Write Once, Read Many / Değiştirilemez Linux Hardened Repository) disk alanına veya fabrika dışındaki felaket kurtarma lokasyonuna aktarılır.
Fabrikanızın sunucu, sanallaştırma ve fidye yazılımına dayanıklı yedekleme altyapısını kurgulamak için Ortak Dosya Sunucusu ve Yedekleme sayfamızı inceleyebilir, ağ güvenliği için Güvenlik Duvarı Çözümleri hizmetlerimizden yararlanabilirsiniz.
Sıkça Sorulan Sorular
İmaj bazlı yedek aldığımızda, kullanıcı yanlışlıkla sadece tek bir Excel veya SolidWorks dosyasını silerse koca sunucuyu mu geri yüklememiz gerekir?
Hayır. Modern kurumsal imaj yedekleme çözümlerinde Granular File-Level Recovery (Tekil Dosya Kurtarma) özelliği bulunur. Yedekleme yazılımı, alınan tam sunucu imajını saniyeler içinde sanal bir disk gibi bağlar (Mount eder) ve içindeki klasör ağacını önünüze açar. Sunucuyu yeniden başlatmaya veya tamamını geri yüklemeye gerek kalmadan, sadece silinen o tek Excel veya CAD dosyasını seçip 1 dakika içinde kullanıcının masaüstüne geri kopyalayabilirsiniz.
Sanal sunucu üzerinde “Snapshot” almak imaj yedeği yerine geçer mi?
Kesinlikle geçmez ve bu en tehlikeli yanılgılardan biridir. Hypervisor (VMware/Hyper-V) üzerinde alınan Snapshot bir yedek değildir; sadece ana diski dondurup yeni yazılan verileri ayrı bir fark dosyasına (delta.vmdk) yönlendiren geçici bir işlem kaydıdır. Eğer sunucunun bulunduğu fiziksel disk dizisi (RAID) bozulursa veya fidye yazılımı ana veri deposunu şifrelerse, hem ana sanal makine hem de aldığınız tüm Snapshot’lar aynı anda yok olur. Gerçek imaj yedeği, üretim sunucusundan tamamen bağımsız bir donanıma aktarılmalıdır.
Fidye yazılımı (Ransomware) bulaştığında yedek sunucusundaki imaj yedeklerimiz de şifrelenir mi?
Eğer yedekleme hedefinizi ağ üzerinde herkesin erişebildiği standart bir Windows paylaşımı (\\NAS\Yedekler) olarak bırakırsanız, saldırganlar sunucu şifresini ele geçirdiğinde yedekleri de silebilir veya şifreleyebilir. Bunu engellemek için yedekleme deposu ağdan izole bir VLAN’da konumlandırılır, SMB paylaşımları kapatılır ve Immutable (Silinemez ve Değiştirilemez) Yedekleme kilidi uygulanır. Bu sayede Domain Admin yetkisi ele geçirilse dahi belirlenen saklama süresi (Örn. 14 gün) dolmadan hiçbir yedek dosyası silinemez veya değiştirilemez.