DIABOLIKSS
RehberlerVeeam Backup Job Hataları: En Sık 10 Hata ve Çözümleri
Sorun Giderme · Veeam Backup & Replication v12

Veeam Backup Job Hataları:En Sık 10 Hata ve Çözümleri

VBR v12.xVMware & Hyper-VTemmuz 2026

Backup job'unuz kırmızıya döndü, e-posta uyarısı geldi ve şimdi log dosyasında ne aradığınızı bile bilmiyorsunuz. Bu rehber, Veeam ortamlarında en sık karşılaşılan 10 hatayı kök nedenleriyle birlikte sıralıyor — kopyala-yapıştır çözüm değil, neden olduğunu anlayıp kalıcı şekilde çözmeniz için.

01

Hata Kategorilerine Genel Bakış

Veeam hataları genelde 4 katmandan birinde çıkar: kaynak taraf (hypervisor, VSS, izinler), proxy taraf (kaynak ve hedef arası veri transferi), hedef/repository taraf (depolama, izinler, alan) ve network (port, firewall, DNS). Sorunu hızlı çözmenin sırrı, önce hatayı bu dört kategoriden hangisine ait olduğunu belirlemek.

🖥️
Kaynak Taraf
VSS, snapshot, izinler
🔀
Proxy Taraf
Transport mode, kaynak yetersizliği
💾
Repository Taraf
Disk alanı, immutability, izinler
🌐
Network
Port, firewall, DNS çözümleme
💡
İlk Adım Her Zaman Aynı: Job içinde başarısız olan görevi (task) açın ve hangi VM/disk'te, hangi aşamada (snapshot, data transfer, finalize) durduğuna bakın. Aşama bilgisi, hatanın hangi katmandan geldiğini büyük ölçüde daraltır.
02

Failed to Create Snapshot

En sık görülen kaynak-taraf hatasıdır. VMware tarafında VSS (Volume Shadow Copy Service) ile snapshot oluşturma adımında başarısız olur.

Olası NedenBelirtiÇözüm
Eski/yarım kalmış snapshotVM Snapshot Manager'da fazladan snapshot görünürManuel "Delete All" ile temizle, ardından job'u yeniden çalıştır
Datastore alanı azSnapshot oluşturma %95+ doluluk sonrası başarısızDatastore'da en az snapshot boyutu kadar boş alan bırak
VSS provider hatası (Windows guest)Application-aware processing açıkken hataGuest içinde vssadmin list writers ile bozuk writer'ı tespit et, ilgili servisi yeniden başlat
VMware Tools güncel değilQuiescing aşamasında zaman aşımıVMware Tools'u güncelle, guest'i yeniden başlat
⚠️
Application-Aware Processing Kapatmayın: Hata mesajını hızlıca geçiştirmek için "Enable application-aware processing" seçeneğini kapatmak cazip gelebilir, ama bu durumda SQL/Exchange gibi uygulamalar crash-consistent (uygulama-tutarsız) yedeklenir. Kök nedeni çözün, ayarı kapatmayın.
03

NFC Connection Has Been Closed

NFC (Network File Copy), Veeam'in VMware ile veri transferinde kullandığı protokoldür. Bu hata genelde transfer sırasında bağlantının beklenmedik şekilde kopmasıyla oluşur.

1
ESXi Host Kaynaklarını Kontrol Edin

Host'ta CPU/RAM darboğazı NFC servisinin zaman aşımına uğramasına neden olabilir. vCenter'dan host performans grafiklerine bakın.

2
Transport Mode'u Doğrulayın

Hot-Add veya Direct SAN Access kullanılamıyorsa Veeam otomatik Network mode'a düşer — bu yavaş ve hataya açıktır. Proxy'nin datastore'a doğrudan erişimi olduğundan emin olun.

3
vCenter/ESXi Sertifika ve Saat Senkronizasyonunu Kontrol Edin

Saat farkı (NTP senkronizasyonsuz host) SSL handshake hatalarına ve bağlantı kopmalarına yol açabilir.

04

Proxy That Should Process VM Is Offline

Veeam proxy sunucusuna ulaşamıyor ya da proxy servisleri ayakta değil demektir.

  • Proxy sunucusunda Veeam Installer Service ve Veeam Data Mover Service çalışıyor mu kontrol edin
  • VBR sunucusu ile proxy arasında 6160-6162 portlarının açık olduğunu doğrulayın
  • Proxy'nin "Max concurrent tasks" ayarı doluysa job kuyrukta bekleyip zaman aşımına uğrayabilir — eşzamanlı görev sayısını proxy kaynaklarına göre ayarlayın
  • Birden fazla proxy varsa, Backup Infrastructure → Backup Proxies altından proxy durumunu (yeşil/kırmızı) tek tek doğrulayın
  • 💡
    Tek Proxy Riski: Tüm job'lar tek bir proxy üzerinden geçiyorsa, o proxy'nin kaynak yetersizliği (özellikle RAM) zincirleme job başarısızlıklarına yol açar. Kritik ortamlarda en az 2 proxy ile yük dağıtımı önerilir.
    05

    Insufficient Privileges to Backup VM

    Veeam'in vCenter'a bağlandığı servis hesabının yetkileri eksik veya kısıtlanmış demektir — genelde yeni bir vCenter rol ataması ya da parola/hesap değişikliği sonrası ortaya çıkar.

    BelirtiKontrol Noktası
    Tüm job'lar aynı anda başarısız olduvCenter servis hesabının parolası değişmiş olabilir — Backup Infrastructure → Managed Servers altında yeniden doğrula
    Sadece belirli VM'ler etkilendivCenter'da o VM'lerin bulunduğu klasör/resource pool için rol ataması eksik olabilir
    Snapshot alınamıyor ama backup connection sağlıklı"Cryptographic operations" izni vSphere 6.7+ ile zorunlu hale geldi, rol tanımında eksik olabilir
    06

    Unable to Truncate Transaction Logs

    SQL Server veya Exchange için application-aware processing açıkken, log kesme (truncation) işlemi başarısız olur. Backup'ın kendisi genelde başarılıdır ama transaction log'lar disk üzerinde birikmeye devam eder.

    🚨
    Görmezden Gelmeyin: Log truncation sürekli başarısız olursa, SQL/Exchange sunucusunda disk dolup uygulamanın tamamen durmasına kadar gidebilir. Bu hata bir "kozmetik uyarı" değil, üretim riski sinyalidir.
    1
    Guest İşletim Sistemi İzinlerini Doğrulayın

    Application-aware processing için kullanılan hesabın guest içinde sysadmin (SQL) veya Organization Management (Exchange) yetkisi olmalı.

    2
    Üçüncü Parti Log Yönetimi Çakışmasını Kontrol Edin

    Native SQL maintenance plan'ları veya başka bir backup ajanı aynı anda log truncation yapmaya çalışıyorsa çakışma oluşur.

    3
    Recovery Model'i Doğrulayın

    SQL veritabanı Simple recovery model'deyse, transaction log backup zaten anlamsızdır — Full recovery model gerekir.

    07

    Out of Free Disk Space on Repository

    Repository'de yeterli boş alan kalmadığında job duraklatılır ya da başarısız olur. Bu hata genelde retention politikası ile gerçek veri büyümesinin uyumsuzluğundan kaynaklanır.

    📈
    Kapasite Planlama
    Aylık büyüme trendini izleyin, %20 tampon bırakın
    🗑️
    Retention Gözden Geçir
    GFS (Grandfather-Father-Son) ayarlarını gerçek ihtiyaca göre düzenle
    🔒
    Immutability Etkisi
    Immutable repository'lerde süresi dolmamış eski restore point'ler silinemez, alan hesaplamasına dahil edin
    ⚠️
    Immutability + Disk Doluluğu: Immutable backup kullanıyorsanız, immutability süresi dolmadan o restore point silinemez — bu, "alan dolu" hatasının normal retention temizliğiyle çözülemeyeceği anlamına gelir. Kapasite planlamasını immutability süresini dahil ederek yapın.
    08

    RPC Function Call Failed / Job Hangs

    Job ilerleme çubuğu donmuş gibi görünür, saatlerce hiçbir değişiklik olmaz. Genelde proxy ile repository ya da proxy ile kaynak arasındaki veri akışının bir noktada tıkanmasından kaynaklanır.

    1
    Veeam Data Mover Servislerini Yeniden Başlatın

    Proxy ve repository sunucusunda Veeam Data Mover servisini yeniden başlatmak çoğu "donmuş" durumu çözer.

    2
    Antivirüs/EDR İstisnası Tanımlayın

    Endpoint koruma yazılımları Veeam Data Mover process'lerini taradığında transfer ciddi şekilde yavaşlayabilir veya kilitlenebilir. Veeam dizinlerini ve proseslerini AV taramasından muaf tutun.

    3
    MTU ve Network Donanımını Kontrol Edin

    Jumbo frame uyumsuzluğu (bazı switch portlarında MTU 9000, bazılarında 1500) büyük veri transferlerinde paket kaybına ve donmaya neden olabilir.

    09

    Network Connection Timed Out

    Genelde firewall, port engelleme veya DNS çözümleme sorunlarından kaynaklanır.

    BağlantıPortKontrol
    VBR → Proxy6160-6162/TCPtelnet veya Test-NetConnection ile doğrula
    VBR → Repository6160-6162, 2500-3300/TCPRepository sunucusunda Windows Firewall kuralını kontrol et
    VBR → vCenter443/TCPSSL sertifika geçerliliğini doğrula
    Proxy → ESXi Host902, 443/TCPNFC trafiği için gereklidir
    💡
    DNS'i Unutmayın: Tüm bileşenler hostname ile değil IP ile de test edilmeli. Çoğu "intermittent" (aralıklı) network hatası, aslında DNS çözümleme tutarsızlığından kaynaklanır.
    10

    Log Okuma Metodolojisi

    Hata mesajını Google'da aramadan önce, doğru log dosyasına bakmak çoğu zaman gerçek kök nedeni saniyeler içinde gösterir.

    C:\ProgramData\Veeam\Backup\<Job Adı>\Job.<tarih>.vbm.log
    C:\ProgramData\Veeam\Backup\<Job Adı>\<VM Adı>.<tarih>.log

    Job genel logu, hangi aşamada (Creating snapshot / Processing / Finalizing) ve hangi makinede durduğunu gösterir. VM-bazlı log ise o aşamadaki tam hata zincirini (genelde İngilizce, ayrıntılı) içerir.

  • Hata mesajının tamamını okuyun — Veeam genelde gerçek nedeni mesajın ortasında veya sonunda "Details:" ile verir
  • Job başarısız olmadan önceki son başarılı çalışmayla karşılaştırın — ortamda ne değişti? (parola, sertifika, ağ, kapasite)
  • Veeam Support'a başvuracaksanız Veeam Log Collector aracıyla toplanan log paketini hazır bulundurun, çözüm süresini kısaltır
  • ESH Bilişim

    Veeam Ortamınızda Tekrarlayan Hatalar mı Var?

    ESH Bilişim, Veeam Backup & Replication kurulumlarında kapasite planlaması, proxy mimarisi ve sürekli başarısız olan job'ların kök neden analizinde saha deneyimiyle destek sağlar. Tek seferlik bir hata mı, yoksa mimari bir sorun mu olduğunu birlikte netleştirelim.

    VeeamSorun GidermeBackupTroubleshooting
    ↑ Başa Dön

    Adım Takibi

    0/10
    Paylas

    Bu Rehberle İlgili AI Araçlar