Problem BackupExec (B2D)2Tape Proxmox VE8

mhert

Well-Known Member
Jul 5, 2017
87
1
48
44
Hallo Leute,

wir betreiben einen eigenständigen Proxmox-Server mit einer Windows Server 2019 VM, in der BackupExec 20.6 installiert ist.

Die Systemplatte (C: ) der VM liegt auf einem ZFS-Storage mit 2 SSD's (Mirror).
Der Backupspeicher (D: ) liegt ebenfalls auf einem (eigenen) ZFS-Storage mit 2 HDD's (Mirror), die in der Windows-VM eingebunden sind.
Die Tapelibrary (HP) mit 2 Tapedrives wird per PCI-Passthrough (SAS-HBA) ebenfalls in der Windows-VM eingebunden, was soweit auch fehlerfrei funktioniert.

Backup2Disk läuft problemlos (Sicherung von Windows-VM's auf einem Proxmox-Cluster).

Nun passiert beim Kopieren der Backups (2Tape) irgendwann irgendwas und der Backupspeicher ist anscheinend nicht mehr (so richtig) verfügbar. Das kann bei 4GB sein
oder bei 400GB. Das Backup (1,8TB) wird auf jeden Fall nicht abgeschlossen und irgendwann wird der Plattenspeicher wg. EA-Fehlern von BackupExec "offline" geschaltet.
In der Ereignissanzeige sind dann unzählige Fehler zu finden.

Es fängt an mit (minütlich):

vioscsi 129 Ein Zurücksetzen auf Gerät "\Device\RaidPort2" wurde ausgegeben. (Obwohl das Backup an dieser Stelle trotzdem noch weiterzulaufen scheint).

gefolgt von:

Ntfs (Microsoft-Windows-Ntfs) 140 Die Daten konnten nicht in das Transaktionsprotokoll verschoben werden. Die Daten sind möglicherweise beschädigt:
Volume-ID: "D:", Gerätename: "\Device\HarddiskVolume4". (Das E/A-Gerät hat einen E/A-Fehler gemeldet.)


und:

Backup Exec 57600 Auf GerΣt "Plattenspeicher 0001" trat ein unbekannter Fehler auf.

Backup Exec 33808 Beim Verarbeiten eines Backup-to-Disk-Befehls ist ein Fehler aufgetreten. Drive: ReadMTFData() ReadFile failed (D:\BEData\B2D000379.bkf)
3773858. Error=1117

Backup Exec 58057 Backup Exec-Meldung: Medienfehler (Server: "ISER-BK02X") Der Datenträger ist offline.

Backup Exec 58053 Backup Exec-Meldung: Speicherfehler (Server: "ISER-BK02X") Der Gerätestatus wurde aufgrund eines E/A-Fehlers auf offline eingestellt.


bis zu:

Disk 153 Der E/A-Vorgang an der logischen Blockadresse "0x39de0460" für den Datenträger "1" (PDO-Name: \Device\00000027) wurde wiederholt.

Ich habe bisher alle Gerätetreiber des SAS-HBA, der Library, der Tape-Drives sowie Proxmox und Windows aktualisiert. Außerdem habe ich mit mehreren
Versionen des VirtIO SCSI-Passthrough Treibers (100.93.104.24000 sowie 100.93.104.20400, weil ich gelesen habe, die neueren hätten ein Problem) rumgespielt, aber
insgesamt ist die Situation unverändert.

Was ich komisch daran finde, ist die Tatsache, dass der/die Fehler ab einem Zeitpunkt X auftreten und nicht sofort zu Beginn des Backups. Und wie schon erwähnt läuft
die Backup2Disk-Sicherung (auf den Plattenspeicher) problemlos - erst bei der Kopie auf Tape gibt's diese Probleme.

Im Geräte-Manager der VM sieht es folgendermaßen aus:

1695797332442.png

Die Hardware-Konfiguration der VM:

1695797431078.png

Disks

1695797482795.png

ZFS

1695797510106.png


Hat jemand einen Tipp, an was das liegen kann bzw. wie man es beheben könnte?

Gruß, Oliver
 
Last edited:
Noch was vergessen:

Async IO habe ich (für die Datenplatte) auf "native" geändert, weil ich da was wg. "io_uring" gelesen habe. Anfänglich sah es auch tatsächlich so aus,
wie wenn die Geschwindigkeit der Bandsicherung höher wäre, aber im Endeffekt dann wieder die gleichen Fehler.

1695798048368.png
 
Last edited:
ist währenddessen irgednwas im host syslog/journal zu sehen?
 
Ich finde darin nichts spezifisches, was das problem betreffen könnte... ich glaube der host bekommt davon gar nichts mit...
 
kannst du trotzdem das journal post ungefähr zu der zeit wenn der fehler auftritt? (vielleicht sehen wir ja was, das doch relevant ist)
 
Der Server wurde um kurz nach 13.00 Uhr neu gestartet (26.09.23) und das Backup (Disk)2Tape startete um 13.14 Uhr.

1695818384532.png

Um 13.19 Uhr fangen dann die Fehler an... (aber das Backup scheint trotzdem zu laufen)

1695818636671.png

Um 15:13 dann die ersten Bexec-Fehler:

1695818729459.png

Ungefähr zum gleichen Zeitpunkt auch NTFS-Fehlermeldungen:

1695818915290.png


Um 16:17 wurde die VM hart "gekilled" weil sich Windows in dem Zustand nicht herunterfahren / neu starten ließ...
 
Last edited:
Kann den Code wg. der Länge nicht posten... ist im Anhang...

Ausgabe journalctl -b (nicht von den Fehlern "prox11 kernel: sd 11:0:0:0: [sde]" verwirren lassen... da hängt noch ne HDD drin, die anscheinend nicht richtig erkannt wird...)
 

Attachments

  • journal.txt
    304.3 KB · Views: 3
Last edited:
Wenn ich das richtig sehe hast du einen ZFS Pool aus 2 HDDs für die Backups. Hast du dir mal die Smart Werte angeschaut? Eventuell beim B2T auch hohen IO Delay?
Ich würde vermuten, dass die HDDs mit dem Random IO nicht klar kommen. Am Anfang war das ja mal Sequenzieller IO, aber durch das COW hast du mit der Zeit immer mehr Random.
 
Sorry. Kann dir nicht ganz folgen...

Was hat die Kuh damit zu tun? ;-)

Die Platten sind neu und die Smartwerte entsprechend top.

Was kann man ändern?

Ich wollte auch schon die Platten direkt an die VM durchreichen (also ohne ZFS-Basis). Ist bisher aber aus anderen Gründen gescheitert.

Wäre das ein vielversprechender Ansatz?
 
Im Vergleich zum Cluster ist der IO Delay definitv höher, allerdings sind dort durchweg Enterprise SSD's verbaut. Der Vergleich hinkt also...

Generell habe ich aber tatsächlich einen höheren Durchsatz erwartet...
 
COW steht für Copy on Write.
Es ist allgemein bekannt, das HDDs mit ZFS recht langsam werden und ab 80% Füllstand fast unbenutzbar.
Ein durchreichen an die VM sollte deutlich performanter sein.
 
kannst du mal die gesamte vm config ( qm config ID) und die storage config posten (/etc/pve/storage.cfg)

was ist denn der unterschied von rpool-data vs local-zfs ?
 
root@prox11:~# qm config 101 agent: 1 bios: seabios boot: order=scsi0;ide2 cores: 4 cpu: host hostpci0: 0000:19:00,pcie=1,rombar=0 ide2: local:iso/virtio-win-0.1.240.iso,media=cdrom,size=612812K machine: pc-q35-8.0 memory: 16384 meta: creation-qemu=8.0.2,ctime=1691603826 name: xxx net0: virtio=7A:DC:F9:F0:F3:1C,bridge=vmbr0,firewall=1 net1: virtio=56:62:40:96:4F:21,bridge=vmbr1,firewall=1 numa: 1 onboot: 1 ostype: win10 scsi0: local-zfs:vm-101-disk-0,backup=0,discard=on,iothread=1,size=100G,ssd=1 scsi1: rpool-data:vm-101-disk-0,aio=native,backup=0,iothread=1,size=10000G scsihw: virtio-scsi-single smbios1: uuid=a3bd94b4-abea-470e-96f3-ca3b64ea4494 sockets: 2 vmgenid: 058475bc-e3e2-4bf5-835f-a8a839efecf7

root@prox11:~# cat /etc/pve/storage.cfg dir: local path /var/lib/vz content iso,backup,vztmpl zfspool: local-zfs pool rpool/data content rootdir,images sparse 1 zfspool: rpool-data pool rpool-data content rootdir,images mountpoint /rpool-data nodes prox11
 
Wie gesagt Backup2Disk läuft problemlos (OK. Durchsatz ist relativ gering...).
Ich habe jetzt mal einen Verify-Job (B2D) losgetreten und der läuft fehlerfrei (auch Ereignisanzeige) mit einem Durchsatz > 200 MB/s.

Nur bei Backup2Tape aus dem Storage treten die Fehler auf. Egal ob direkt nach B2D (also im gleichen Job) oder händisch angestoßen.
Ist ja aber eigentlich auch nur lesen, oder? Verify habe ich bei den differentiellen Backups deaktiviert.

Wenn die Library einen Fehler schmeißen würde oder der HBA oder die Passthrough-Geschichte, könnte ich das ja noch verstehen...
 
Unterschied der Pools sind die verschiedenen Plattenstapel (2x SSD vs. 2x HDD). Sind aber aber beide an der gleichen Backplane angeschlossen.

Siehe Screenshot oben...
 
Last edited:
Hi, ich habe gerade bei einem Kunden ebenfalls Probleme mit einer VM gehabt. Da ist ein SQL drauf, der massive Reads verursacht. Jedes mal wenn viel gelesen wurde, ist der SQL gecrasht und im Eventlog waren die gleichen Meldungen wie bei dir.
Wir haben es gelöst, indem wir die Platten von SCSI auf VirtIO Block geändert haben. Jetzt macht die VM statt 700-800 MB Read, bis zu 1,5 GB/s Read. Da scheint irgend etwas im argen zu sein mit den aktuellen Treibern für Windows.
 
Habe eben 2 weitere Platten eingebunden (an VM durchgereicht) und per Windows-Funktion (Server-Manager) ein Stripeset gebastelt. Danach habe ich per BackupExec eine Kopie eines Vollbackups von Festplattenspeicher 1 (Proxmox ZFS) auf Festplattenspeicher 2 (Windows VM Stripeset) durchgeführt. Dabei wurden bei 1,9TB Datenvolumen 0 (!) Fehler protokolliert und das Ganze lief mit Top-Speed.

Danach habe ich eine weitere Kopie gestartet: Vom Plattenspeicher 2 (Windows VM Stripeset) auf Band und siehe da: Nach wenigen GB dasselbe
Problem wie vorher vom ZFS-Stapel...

Muß also das von dir erwähnte Problem mit dem VirtIO-Treiber sein...

Werde jetzt mal auf VirtIO-Block umstellen und nochmal testen...
 
Full Stop! :)

Habe gerade gemerkt, daß das auch keinen Sinn macht...

Er kopiert klaglos mit diesem Treiber Daten von der virtuellen Disk (vom darunterliegenenden ZFS) auf die durchgereichten Platten...
Und davon aber nicht auf Tape????!
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!