Genel bir sorun umarım kısa zamanda ayağa kaldırırlar.

Hata her zaman aynı yüzde seviyesinde vermiyor gün içinde denediğimde %50 civarlarında hatayı verdi. 3 adet sanal disk bulunuyor. Snapshot yada consolidation uyarısı yok. Backup proxy auto'da network e alıp test yaptığımda aynı hata devam ediyor. Logları kontrol ettiğimde ise herhangi bir hata mesajı yok. 

yardımlarınız için teşekkür ederim.

Paylaştığınız hata VMware VDDK (Virtual Disk Development Kit) katmanında, sanal disk üzerindeki verilerin okunması sırasında oluşan bir probleme işaret ediyor. Ancak bu hata tek başına VMDK dosyasının bozuk olduğu anlamına gelmez.

Öncelikle üç sanal makineden yalnızca birinde bu sorunun yaşanması ve yedekleme işleminin %70-80 seviyelerine kadar ilerlemesi önemli. Bu nedenle genel Veeam yapılandırmasından önce ilgili sanal makinenin disk ve snapshot yapısını kontrol etmenizi öneririm.

Ben olsam aşağıdaki sırayla ilerlerdim.

İlk olarak vSphere üzerinden ilgili sanal makinenin snapshot durumunu kontrol ederdim. Özellikle "Virtual machine disks consolidation is needed" uyarısı olup olmadığına bakın. Daha önce başarısız olmuş yedekleme işlemlerinden kalan snapshot dosyaları bu tip problemlere neden olabiliyor. Gerekli kontrolleri yaptıktan sonra consolidation işlemini değerlendirebilirsiniz.

İkinci olarak Veeam Backup Proxy üzerinde kullanılan transport modunu kontrol edin. Eğer HotAdd veya Direct Storage Access kullanıyorsanız, test amacıyla Network (NBD) modunu deneyebilirsiniz. Bu şekilde yedekleme başarılı olursa problemin disk erişim yönteminden kaynaklandığını düşünerek proxy tarafına yoğunlaşabiliriz.

Üçüncü olarak ESXi üzerindeki vmkernel.log ve hostd.log dosyalarını incelemenizi öneririm. Özellikle I/O error, read error, NFC ve DiskLib hatalarını kontrol edin. Hata mesajında geçen "Failed to download disk 'Veeam-flat.vmdk'" ifadesi, ilgili sanal diskin okunması sırasında işlemin başarısız olduğunu gösteriyor. Ancak bunun nedeni disk, datastore, snapshot zinciri veya erişim katmanı olabilir.

Bir diğer önemli konu da hatanın sürekli aynı yüzde seviyesinde oluşup oluşmadığı. Eğer her seferinde aynı diskte ve benzer noktada hata alıyorsanız ilgili VMDK ve datastore tarafını daha detaylı incelemek gerekir. Farklı noktalarda hata alıyorsanız bağlantı veya transport kaynaklı problemleri de değerlendirmek gerekir.

Son olarak kullandığınız Veeam 11.0.1.1261 sürümü oldukça eski. VMware altyapınızın sürümünü de dikkate alarak desteklenen güncel bir Veeam sürümüne geçiş planlamanızı öneririm.

Daha net yardımcı olabilmemiz için birkaç sorum olacak:

• ESXi ve vCenter sürümleriniz nedir?

• Hata her zaman aynı yüzde seviyesinde mi oluşuyor?

• İlgili sanal makinede kaç adet sanal disk bulunuyor?

• VM üzerinde snapshot veya consolidation uyarısı var mı?

• Backup Proxy üzerinde hangi transport modunu kullanıyorsunuz?

Özellikle ilk etapta snapshot/consolidation durumunu kontrol etmenizi ve ardından NBD moduyla test gerçekleştirmenizi öneririm. Bu iki kontrol sorunun kaynağını daraltmak açısından oldukça faydalı olacaktır.

Burada sizin hata ile 1:1 aynı hata var, bunu da inceleyebilirsiniz;

https://forums.veeam.com/viewtopic.php?f=24&t=76141&start=0

Veeam üzerinden 3 sanal makinenin her gün yedeğini alıyoruz. Sanal makinelerden 1 tanesi yedek alırken %70-80 arasında hata veriyor. Aşağıdaki hatayı alıyorum. Araştırdığımda böyle bir sorunun çözümünü bulamadım. Sürüm 11.0.1.1261

yardımcı olabilir misiniz 

Processing Veeam Error: VDDK async operation error: 1. Value: 0x0000000000000001
Failed to upload disk. Skipped arguments: ;
Agent failed to process method {DataTransfer.SyncDisk}.
Exception from server: VDDK async operation error: 1. Value: 0x0000000000000001
Unable to retrieve next block transmission command. Number of already processed blocks: .
Failed to download disk 'Veeam-flat.vmdk'.

Anlattığınız senaryoda doğrudan donanım yetersizliği demek çok doğru olmaz. Özellikle 4 kullanıcıda sorun olmayıp 7 kullanıcı civarında yavaşlaması ve sunucu yeniden başlatıldığında bir süre normale dönmesi doğrudan donanım demek olmaz.

İlk etapta SQL tarafında bellek kullanımı, blocking veya disk I/O tarafına bakın, çünkü kullanıcı sayısı arttıkça kayıt işlemlerinin beklemesi genelde SQL üzerinde bir bekleme oluştuğunu veya disk tarafının cevap veremediğini düşündürüyor.

Sorun tekrar oluştuğunda mümkünse sunucuyu hemen restart etmeyin. Öncelikle sadece SQL Server servisini restart edip sonucu kontrol edin. Eğer sadece SQL servisini restart ettiğinizde sistem normale dönüyorsa konu büyük ihtimalle SQL tarafındadır. SQL servisini restart etmek çözmüyor ancak sunucuyu yeniden başlatmak düzeltiyorsa bu durumda disk, SMB paylaşımı, antivirus veya işletim sistemi kaynaklarını incelemek gerekir.

Sorun olduğu anda Task Manager üzerinden CPU, RAM ve özellikle disk kullanımını kontrol edin. Disk Active Time %100 seviyesine çıkıyor mu, RAM tamamen doluyor mu bunlara bakmak lazım.

Aynı anda SQL Server üzerinde de blocking olup olmadığını kontrol etmenizi öneririm.

SELECT
    r.session_id,
    r.status,
    r.command,
    r.blocking_session_id,
    r.wait_type,
    r.wait_time,
    r.cpu_time,
    r.logical_reads,
    r.reads,
    r.writes,
    DB_NAME(r.database_id) AS database_name
FROM sys.dm_exec_requests r
WHERE r.session_id <> @@SPID
ORDER BY r.wait_time DESC;

Burada blocking_session_id alanında 0 dışında değerler görüyorsanız bir oturum diğer işlemleri bekletiyor olabilir. Ticari uygulamalarda özellikle kayıt sırasında bu tip durumlarla karşılaşılabiliyor.

SQL Server'ın ne kadar RAM kullandığını da kontrol edin.

SELECT
    name,
    value,
    value_in_use
FROM sys.configurations
WHERE name IN ('min server memory (MB)','max server memory (MB)');

Eğer SQL Server için maksimum bellek sınırı bırakılmadıysa zaman içerisinde sunucudaki belleğin büyük bölümünü SQL kullanıyor olabilir. Bu durumda Windows ve uygulamanın diğer bileşenleri kaynak sıkıntısı yaşayabilir.

Disk tarafını da mutlaka kontrol etmek gerekir. Dell T360 üzerinde kullanılan disklerin tipi, RAID yapısı ve özellikle SQL database ile log dosyalarının bulunduğu disk önemli. Kullanıcı sayısı arttığında veri kaydı çok bekliyorsa SQL log yazma performansı tarafında problem olması da oldukça muhtemel.

Bir diğer konu antivirus veya Windows Defender. SQL database ve log dosyalarının bulunduğu klasörler ile Zirve'nin yoğun kullandığı klasörlerin gerçek zamanlı taranması performansı etkileyebilir. Burada gerekli exclusion tanımlarının yapılıp yapılmadığını kontrol etmekte fayda var.

Ben olsam şu sırayla ilerlerdim:

Sorun oluştuğunda önce sadece SQL servisini restart edin. Ardından CPU, RAM ve disk kullanımını kontrol edin. SQL blocking ve wait durumlarına bakın. SQL Server max memory ayarını kontrol edin. Sonrasında disk/RAID performansı ve Defender exclusion tarafına geçin.

Bir de "zirvenet klasörüne bağlanarak çalışıyor" demişsiniz. Burada uygulamanın bir kısmı SQL üzerinden, bir kısmı SMB dosya paylaşımı üzerinden çalışıyor olabilir. Dolayısıyla sadece SQL değil ağ paylaşımı tarafını da gözden kaçırmamak gerekir.

CPU modeli, toplam RAM, kullanılan disklerin tipi ve RAID yapısı, SQL Server'ın Express mi Standard mı olduğu ve mümkünse sorun yaşandığı anda Task Manager ekran görüntüsünü paylaşırsanız daha net yorum yapılabilir.