Veeam Health Check Hatası: Yedek Zinciri Nasıl Kontrol Edilir?

Yedekleme altyapısında karşılaşılan bir Veeam Health Check hatası, sistem yöneticileri ve BT ekipleri için haklı bir endişe kaynağıdır. Ancak bu hata mesajı, tek başına tüm yedeklerin kaybolduğu veya geri yükleme yapılamayacağı anlamına gelmez. Health Check, Veeam Backup & Replication’ın yedek dosyalarındaki metadata’yı ve veri bloklarının bütünlüğünü doğrulamak için çalıştırdığı bir kontrol mekanizmasıdır. Hatanın gerçek etkisini anlamak için öncelikle iş oturumu günlüklerini (job session logs), hatanın ilişkili olduğu geri yükleme noktasını (restore point) ve yedek zincirinin (backup chain) genel durumunu incelemek gerekir.

Veeam Health Check hatası, doğrulama sırasında bir veri bloğunda, metadata yapısında veya depolama erişiminde tutarsızlık saptandığını gösterir; ancak tüm yedeklerin kullanılamaz olduğu anlamına gelmez. İlk adım olarak dosyaları elle silmeden veya değiştirmeden Veeam konsolundaki iş oturumu günlüklerini, etkilenen geri yükleme noktasını ve depolama alanının (repository) erişilebilirliğini kontrol etmelisiniz.

Veeam Health Check Nedir ve Nasıl Çalışır?

Veeam Health Check, yedekleme depolarında (backup repository) saklanan geri yükleme noktalarının bütünlüğünü periyodik olarak doğrulayan yerleşik bir kontrol sürecidir. Temel amacı, olası bir veri bozulmasını (data corruption) veya tutarsızlığı, gerçek bir felaket anında geri yükleme yapmaya çalışmadan önce tespit etmektir.

Resmî Veeam Backup & Replication Health Check belgelerinde belirtildiği üzere bu mekanizma, yedek dosyalarının metadata’sını ve veri bloklarını doğrulamak için CRC (Cyclic Redundancy Check) ve hash kontrollerinden yararlanır. Yedekleme sırasında hesaplanan sağlama toplamları (checksum), doğrulama sırasında yeniden hesaplanan değerlerle karşılaştırılır. Eğer depolanan veri blokları ile beklenen değerler arasında bir uyuşmazlık varsa veya dosya yapısında okunamayan bir bölümle karşılaşılırsa Health Check işlemi hata verir.

Burada dikkat edilmesi gereken en önemli nokta, kontrolün kapsamının sabit olmamasıdır. Health Check’in hangi dosyaları, ne sıklıkla ve hangi derinlikte kontrol ettiği; kullanılan Veeam Backup & Replication sürümüne, yedekleme işinin (backup job) türüne, seçilen yedekleme yöntemine (backup method) ve hedef repository türüne göre değişiklik gösterir. Örneğin, nesne depolama (object storage) veya ölçeklenebilir yedekleme deposu (Scale-Out Backup Repository - SOBR) kullanılan ortamlarda doğrulama davranışı, standart bir yerel disk deposundan farklı işleyebilir. Bu nedenle her Health Check oturumunun tüm yedek geçmişindeki her dosyayı aynı biçimde taradığını varsaymak doğru değildir.

Veeam Health Check Hatası Ne Anlama Gelir, Ne Anlama Gelmez?

Bir doğrulama hatasıyla karşılaşıldığında paniğe kapılmadan önce, hatanın teknik olarak neyi ifade ettiğini ve neyi ifade etmediğini net biçimde ayırmak gerekir. Yanlış bir varsayım, sağlam olan yedeklerin de risk altına girmesine yol açabilir.

Veeam Health Check hatası şunları ifade edebilir:

• Veri bloğu veya metadata tutarsızlığı: Kontrol edilen yedek dosyasındaki belirli bir veri bloğunda ya da metadata kaydında beklenen hash/CRC değeriyle uyuşmayan bir durum saptanmış olabilir.
• Belirli bir geri yükleme noktasında sorun olasılığı: Hatanın tespit edildiği oturuma ait geri yükleme noktası (restore point) veya bu noktanın bağımlı olduğu zincir halkası güvenilirliğini yitirmiş olabilir.
• İşin hata (Error) durumuyla sonlanması: Yedekleme işi veya bağımsız doğrulama görevi başarısız olarak işaretlenir; yapılandırmaya bağlı olarak yeniden deneme (retry) mekanizması tetiklenebilir.
• Altyapı veya erişim kaynaklı kesinti: Doğrulama sırasında depolama alanına erişimde yaşanan geçici bir ağ kopması, I/O daralması, disk kapasite sorunu veya izin hatası da Health Check’in başarısız olmasına neden olabilir.

Veeam Health Check hatası şunları ifade etmez:

• Tüm yedek zincirinin kaybolduğu: Tek bir geri yükleme noktasında veya belirli bir artımlı dosyada yaşanan sorun, zincirdeki diğer tüm noktaların (örneğin daha önceki tam yedeklerin veya ikincil kopyaların) otomatik olarak kullanılamaz olduğu anlamına gelmez.
• Kaynak sunucudaki verinin bozulduğu: Health Check, kaynak sanal makinedeki (VM) veya fiziksel sunucudaki canlı veriyi değil, repository üzerindeki yedek dosyalarını kontrol eder.
• Kesin donanım arızası: Hata, mutlaka disklerin fiziksel olarak bozulduğu anlamına gelmez; yazılımsal bir kilitlenme, beklenmedik bir sunucu kapanması veya ağ kesintisi de aynı sonucu doğurabilir.

VBK, VIB ve VBM Dosyaları Yedek Zincirinde Nasıl Çalışır?

VBK VIB yedek zinciri hatası gibi durumları doğru yorumlayabilmek için Veeam’in dosya yapısını ve bu dosyaların birbirine olan bağımlılığını anlamak şarttır. Resmî Veeam Backup Chain ve Veeam Backup Methods dokümanlarına göre yedek zinciri temel olarak üç dosya türünden oluşur:

<table><tbody><tr><td><strong>Dosya Türü</strong></td><td><strong>Genel Rolü</strong></td><td><strong>Sorunda Neden İncelenir?</strong></td></tr><tr><td><strong>VBK</strong></td><td>Tam yedek (Full Backup)</td><td>Temel verileri ve zincir ilişkisini anlamak için</td></tr><tr><td><strong>VIB</strong></td><td>Artımlı yedek (Incremental Backup)</td><td>Değişiklikleri ve belirli restore point bağımlılıklarını kontrol etmek için</td></tr><tr><td><strong>VBM</strong></td><td>Metadata (Backup Metadata)</td><td>Yedek ve restore point yapısına ilişkin bilgiyi değerlendirmek için</td></tr></tbody></table>

Bu tablo, dosyaların genel işlevini özetlemektedir; kullanılan yedekleme yöntemine (örneğin Forward Incremental, Forever Forward Incremental veya Reverse Incremental) göre dosyaların sayısı ve zincirdeki yeri değişebilir.

Bir geri yükleme noktası, çoğu zaman tek bir dosyadan ibaret değildir. Örneğin ileri yönlü artımlı (Forward Incremental) bir zincirde, belirli bir güne ait geri yükleme noktasını açabilmek için o günün VIB dosyasına, aradaki diğer VIB dosyalarına ve zincirin başındaki VBK dosyasına ihtiyaç duyulur. Eğer zincirdeki gerekli bir VIB dosyası eksikse veya okunamıyorsa, o noktaya ve ondan sonraki bağımlı artımlı noktalara erişim etkilenebilir.

Bu bağımlılık nedeniyle, işletim sistemi üzerinden (Windows Explorer veya Linux terminali aracılığıyla) VBK, VIB veya VBM dosyalarını elle silmek, taşımak ya da yeniden adlandırmak son derece risklidir. Veeam, zincir bütünlüğünü VBM dosyası ve kendi veritabanı üzerinden takip eder. Dosya sisteminden yapılan yetkisiz bir müdahale, Veeam’in zinciri tanıyamamasına ve sağlam olan diğer geri yükleme noktalarının da erişilemez hâle gelmesine yol açabilir.

Olası Nedenler Nasıl Sınıflandırılır?

Bir Veeam yedek doğrulama hatasıyla karşılaşıldığında, kesin nedeni belirlemeden önce olası senaryoları mantıksal kategorilere ayırmak gerekir. Aşağıdaki liste "kesin nedenler" değil, somut günlükler ve altyapı verileriyle doğrulanması gereken olasılık alanlarıdır:

1. Yedek Dosyası veya Metadata Bütünlüğü Sorunları: Yedekleme veya sentetik tam yedek (synthetic full) oluşturma sırasında yaşanan beklenmedik bir kesinti, VBK/VIB dosyalarında eksik bloklara veya VBM dosyasının güncel kalmamasına neden olabilir.
2. Eksik, Taşınmış veya Erişilemeyen Zincir Bileşenleri: Zincirdeki bir dosyanın yanlışlıkla silinmesi, başka bir dizine taşınması veya bir bakım işlemi sırasında erişilemez duruma düşmesi doğrulamayı başarısız kılar.
3. Repository Kapasite, Dosya Sistemi veya I/O Sorunları: Depolama alanının tamamen dolması, dosya sisteminde (NTFS, ReFS, XFS vb.) tutarsızlıklar oluşması, RAID denetleyicisi uyarıları veya yüksek disk gecikmesi (latency) okuma/yazma hatalarına yol açabilir.
4. Altyapı Bileşenleri Arası İletişim Sorunları: Backup Server, Backup Proxy, Gateway Server veya Repository servisleri arasındaki ağ bağlantısının kopması, kimlik doğrulama (credentials) süresinin dolması veya servislerin beklenmedik şekilde durması doğrulamayı yarıda kesebilir.
5. Operasyonel Çakışmalar ve Bakım Pencereleri: Yedekleme işinin çalışma süresiyle çakışan depolama anlık görüntüleri (storage snapshots), antivirüs taramaları veya eşzamanlı çalışan yoğun işler dosya kilitlenmelerine neden olabilir.
6. Fidye Yazılımı veya Yetkisiz Değişiklik Şüphesi: Yedek dosyalarının şifrelenmesi, dosya uzantılarının değişmesi veya repository üzerinde tanımlanamayan silme/değiştirme hareketleri görülmesi durumunda güvenlik olayı ihtimali değerlendirilmelidir.

Herhangi bir donanım veya dosya sistemi arızasını ilan etmeden önce, bu kategorilerin her biri ilgili sistem günlükleri ve depolama izleme araçlarıyla teyit edilmelidir.

İlk Güvenli Kontrol Sırası

Üretim ortamında (production) rastgele değişiklikler yapmak yerine, durumu netleştirecek güvenli bir inceleme sırası izlenmelidir. Veeam Backup & Replication sürümüne ve repository türüne göre menü adları farklılık gösterebilse de temel kontrol adımları şu şekildedir:

1. Ortam Bilgilerini Kaydedin: Kullanılan Veeam Backup & Replication sürümünü (örneğin v12 veya v13), hatanın alındığı işin türünü, repository türünü ve ilgili iş yükünü (VM veya fiziksel sunucu) not edin.
2. Tam Hata Metnini ve Günlükleri Saklayın: Veeam konsolundaki iş oturumu günlüklerini (job session log) açın. Tam hata metnini, hatanın görüldüğü zaman damgasını ve varsa ilgili görev (task) ayrıntılarını dışa aktarın veya ekran görüntüsüyle kayıt altına alın.
3. Etkilenen Geri Yükleme Noktasını Belirleyin: Hatanın hangi geri yükleme noktası (restore point) veya hangi spesifik dosya (VBK/VIB/VBM) üzerinde raporlandığını arayüzden tespit edin.
4. Sonraki Oturumları ve Retry Durumunu Kontrol Edin: Hata sonrasında işin yeniden deneme (retry) yapıp yapmadığını veya bir sonraki zamanlanmış oturumun başarıyla tamamlanıp tamamlanmadığını inceleyin.
5. Repository Erişilebilirliğini ve Kapasitesini Doğrulayın: Yedekleme deposunun çevrimiçi (online) olup olmadığını, yeterli boş alan bulunup bulunmadığını ve depolama donanımı/işletim sistemi tarafında I/O ya da disk hatası uyarısı olup olmadığını altyapı izleme kayıtlarıyla karşılaştırın.
6. Yedek Zincirinin Envanter Durumunu İnceleyin: Veeam konsolunda Backups > Disk (veya ilgili repository görünümü) altından yedek zincirinin nasıl listelendiğini, eksik veya uyarı işaretli bir nokta olup olmadığını kontrol edin.
7. Alternatif Sağlam Noktaları ve İkincil Kopyaları Belirleyin: Herhangi bir düzeltme adımına geçmeden önce, aynı iş yüküne ait daha eski sağlam geri yükleme noktalarının, Backup Copy Job kopyalarının veya teyp/bulut arşivlerinin mevcut olup olmadığını tespit edin.
8. Resmî Dokümantasyon veya Destek Kanalına Başvurun: Sürümünüze ve repository mimarinize özgü onarım veya doğrulama prosedürleri için resmî Veeam Help Center belgelerini inceleyin ya da yetkin destek kanallarıyla iletişime geçin.

Neler Yapılmamalı? (Riskli Müdahaleler)

Hata mesajını hızlıca ortadan kaldırma isteği, bazen telafisi mümkün olmayan veri kayıplarına yol açabilir. Aşağıdaki müdahalelerden kesinlikle kaçınılmalıdır:

• VBK, VIB veya VBM dosyalarını elle silmek, taşımak veya yeniden adlandırmak: Dosya sisteminden yapılan manuel değişiklikler, Veeam veritabanı ile diskteki dosyalar arasındaki eşleşmeyi bozar ve sağlam geri yükleme noktalarını da okunamaz hâle getirebilir.
• Veeam işi çalışırken repository dosyalarına müdahale etmek: Aktif bir yedekleme, birleştirme (merge) veya doğrulama işlemi sırasında dosyalara dokunmak, açık dosya tutamaçlarının (file handles) kesilmesine ve zincirin tamamen bozulmasına neden olur.
• Nedeni bilmeden saklama (retention) ayarlarını değiştirmek: Sorunun kaynağını anlamadan saklama politikasını kısaltmak, kurtarma için ihtiyaç duyabileceğiniz eski ve sağlam geri yükleme noktalarının sistem tarafından otomatik olarak silinmesine yol açabilir.
• Tek bir hataya bakarak tüm repository’yi biçimlendirmek: Tek bir zincirdeki veya noktadaki sorun nedeniyle tüm depolama alanını sıfırlamak, o alanda barındırılan diğer tüm iş yüklerinin yedeklerini de yok eder.
• Fidye yazılımı şüphesi varken kontrolsüz işlem yapmak: Güvenlik ihlali ihtimali varsa etkilenmiş sistemleri yeniden başlatmak, şüpheli kimlik bilgileriyle repository’ye bağlanmak veya temizlik yazılımları çalıştırmak olay kanıtlarını (forensic evidence) yok edebilir ve saldırının yedeklere sıçramasına zemin hazırlayabilir.

Onarım, Retry ve Geri Yükleme Kararları

Health Check hatası sonrasında "yeniden dene (retry) butonuna basınca düzelir" veya "Health Check özelliğini kapatarak hatadan kurtulabilirim" gibi yaklaşımlar kurumsal veri güvenliği açısından risklidir. Health Check’i devre dışı bırakmak sorunu çözmez, yalnızca görünürlüğünü ortadan kaldırır.

Veeam’in bazı senaryolarda otomatik iyileştirme (auto-heal) veya eksik blokları kaynaktan yeniden okuma davranışları bulunabilir; ancak bu davranışlar her iş türü, her repository tipi ve her Veeam sürümü için aynı şekilde çalışmaz. Karar verirken şu üç unsuru birlikte değerlendirmelisiniz:

• Kaynak sistemin durumu: Yedeklenen sunucu hâlâ çalışıyor ve verileri sağlamsa, yeni bir aktif tam yedek (Active Full) alma seçeneği değerlendirilebilir.
• Son başarılı oturum ve etkilenen nokta: Sorun yalnızca tek bir eski artımlı dosyadaysa ve sonraki noktalar/ikincil kopyalar sağlamsa müdahale stratejisi farklılaşır.
• Gerçek geri yükleme testi (Test Restore): Bir geri yükleme noktasının gerçekten kullanılabilir olup olmadığını anlamanın en güvenilir yolu kontrollü bir test geri yüklemesi yapmaktır. Bu testi, mümkünse üretim ağından izole edilmiş bir test ortamında ve kurumun değişiklik yönetimi prosedürlerine uygun olarak gerçekleştirmek gerekir. Ancak unutulmamalıdır ki tek bir geri yükleme noktasının başarıyla açılması, zincirdeki diğer tüm geçmiş noktaların da sorunsuz olduğunun mutlak garantisi değildir.

Fidye Yazılımı Şüphesinde Öncelikler

Eğer Veeam Health Check hatası, aynı zaman aralığında sistemlerdeki olağandışı yavaşlamalar, şüpheli dosya uzantısı değişiklikleri, yedek dosyalarının silinmesi veya repository üzerinde yetkisiz erişim izleriyle birlikte görülüyorsa, bunu sıradan bir teknik arıza olarak değil, potansiyel bir güvenlik olayı olarak ele almak gerekir.

CISA’nın güncel StopRansomware Rehberi doğrultusunda, böyle bir senaryoda öncelik "hemen yedeği geri yüklemek" değil, olayı sınırlandırmaktır. Etkilenen sistemlerin ağdan izole edilmesi, yedekleme altyapısının (özellikle değişmez/immutable yedeklerin ve çevrimdışı kopyaların) korunması ve olay müdahale sürecinin koordine edilmesi hayati önem taşır. Kanıt kaybına yol açabilecek kontrolsüz sunucu kapatma veya disk temizleme kararları yerine, olay müdahale ekibinin yönlendirmesine göre hareket edilmelidir.

Güvenilir kimlik bilgileri doğrulanmadan ve temiz bir geri yükleme noktası kesinleştirilmeden yapılacak geri yüklemeler, zararlı yazılımın sisteme tekrar girmesine neden olabilir. Bu kritik aşamada izlenecek adımlar için fidye yazılımı saldırısında ilk müdahale adımları rehberini inceleyerek olayın ilk dakikalarını doğru yönetebilirsiniz.

Tekrarı Azaltma ve Yedek Doğrulama Alışkanlıkları

Gelecekte benzer doğrulama hatalarıyla karşılaşma riskini azaltmak için yedekleme operasyonlarını bütüncül bir yaklaşımla yönetmek gerekir. Ancak her kurumun altyapısı, iş yükü kritiklik seviyesi, yedekleme penceresi ve kurtarma hedefleri (RPO/RTO) farklı olduğundan, tek bir "evrensel doğru ayar" yoktur.

• Health Check Zamanlamasını Dengeleyin: Doğrulama işlemlerini, depolama ve ağ kaynaklarının en yoğun olduğu yedekleme pencereleriyle çakışmayacak şekilde planlayın.
• Günlükleri ve Depolama Alarmlarını İzleyin: Sadece Veeam iş sonuçlarını değil, alt katmandaki disk dizini, RAID ve dosya sistemi uyarılarını da merkezi bir izleme sistemine bağlayın.
• 3-2-1-1-0 Kuralını Gözetin: Yedeklerin farklı medyalarda, kurum dışı (offsite) ve mümkünse değiştirilemez (immutable) kopyalarını bulundurarak tek bir zincir hatasına karşı direnç kazanın.
• İş Durumu ile Testi Ayırın: Bir yedekleme işinin "Success" (Başarılı) görünmesi, o yedeğin her koşulda geri yüklenebileceğinin tek başına kanıtı değildir. Periyodik ve otomatikleştirilmiş (örneğin SureBackup gibi) veya manuel test geri yüklemeleriyle doğrulama kültürünü standart hâle getirin.

Veeam Yedek Kurtarma Hizmeti Ne Zaman Düşünülür?

Bazı durumlarda standart konsol kontrolleri ve yeniden deneme adımları sorunu çözmeye yetmeyebilir. Özellikle şu senaryolarda profesyonel bir inceleme ve kurtarma desteği almak, mevcut veriyi koruma şansını artırabilir:

• Veeam arayüzünde kritik geri yükleme noktalarına hiçbir şekilde erişilemiyorsa,
• Zincirdeki temel VBK veya ara VIB dosyalarının kaybolduğu ya da ciddi biçimde bozulduğu düşünülüyorsa,
• Repository dosya sistemi veya depolama birimi ağır hasar görmüşse,
• Fidye yazılımı saldırısı sonrası şifrelenmiş veya kısmen bozulmuş yedek dosyalarının güvenli biçimde analiz edilmesi gerekiyorsa.

Bu tür karmaşık ve yüksek riskli durumlarda, dosyalara rastgele müdahale etmek yerine Veeam yedek kurtarma konusunda uzmanlaşmış bir ekibin değerlendirmesine başvurmak en güvenli yoldur. Kurtarılabilirlik oranı ve kapsamı; her zaman mevcut yedek dosyalarının fiziksel durumu, repository yapısı ve bozulmamış veri bloklarının varlığı incelendikten sonra netleşir.

Sık Sorulan Sorular (SSS)

1. Veeam Health Check hatası yedeğin bozulduğu anlamına mı gelir?

Hayır, her zaman anlamına gelmez. Hata bir veri bloğu tutarsızlığına işaret edebileceği gibi, doğrulama sırasındaki geçici bir depolama erişim kesintisinden, I/O daralmasından veya ağ sorunundan da kaynaklanabilir. Kesin durum iş günlükleri ve dosya kontrolü ile anlaşılır.

2. Health Check hangi dosya veya verileri kontrol eder?

Health Check, yedek dosyalarının metadata bilgilerini ve veri bloklarının bütünlüğünü (CRC ve hash değerleri üzerinden) kontrol eder. Kontrol edilen kapsam, kullanılan Veeam sürümüne, iş türüne ve repository yapılandırmasına göre değişebilir.

3. Veeam Health Check hatası sonrası otomatik onarım her zaman çalışır mı?

Hayır. Veeam’in bazı durumlarda yeniden deneme veya eksik blokları onarma mekanizmaları bulunsa da, bu davranış her hata türü, her yedekleme yöntemi ve her repository tipi için otomatik olarak devreye girmez.

4. VBK ve VIB dosyalarının yedek zincirindeki farkı nedir?

VBK, ilgili iş yükünün tam yedeğini (Full Backup) içeren temel dosyadır. VIB ise yalnızca bir önceki noktadan sonra değişen veri bloklarını saklayan artımlı yedek (Incremental Backup) dosyasıdır.

5. Zincirde bir VIB dosyası eksikse hangi geri yükleme noktaları etkilenebilir?

İleri yönlü artımlı (Forward Incremental) bir zincirde, eksik olan VIB dosyasına ait geri yükleme noktası ve o dosyaya bağımlı olan sonraki artımlı geri yükleme noktaları açılamayabilir. Önceki sağlam noktalar genellikle etkilenmez.

6. Health Check hatası sonrası yedekleme job’unu hemen yeniden çalıştırmalı mıyım?

Hatanın nedenini anlamadan işi hemen yeniden çalıştırmak önerilmez. Önce depolama alanının boş yerini, erişilebilirliğini ve iş günlüklerindeki tam hata mesajını incelemek gerekir; aksi hâlde aynı hata tekrarlanabilir veya mevcut zincir daha fazla zorlanabilir.

7. Fidye yazılımı şüphesinde yedek repository’sine bağlanmak güvenli midir?

Hayır. Fidye yazılımı şüphesi varsa, etkilenmiş olabilecek sunucular veya şüpheli kimlik bilgileri üzerinden repository’ye bağlanmak saldırının yedeklere sıçramasına veya kanıtların bozulmasına yol açabilir. Önce sistemler izole edilmeli ve olay müdahale prosedürü izlenmelidir.

8. Yedeğin gerçekten kullanılabilir olduğunu nasıl doğrulayabilirim?

Yedeğin kullanılabilirliğini doğrulamanın en kesin yolu, üretim ortamından izole edilmiş güvenli bir alanda kontrollü bir test geri yüklemesi (Test Restore) gerçekleştirmektir.