Search results

@Falk R. Hast du nur den SCSI Treiber in der Windows-VM ausgetauscht oder die Platten als "VirtIO Block" neu angehängt (PVE)? Funktioniert das so einfach oder muß man erst ein Testdevice einbinden, damit Treiber installiert werden (so wie bei der Umstellung einer VM von IDE/SATA auf SCSI)?

Ich glaube so langsam doch, daß es am Treiber liegen muß... Ich habe zwar keine Erklärung dafür, daß B2D und Kopie Festplattenspeicher 1 > 2 funktioniert und B2Tape nicht (weder direkt noch von Disk), aber eben ist folgendes passiert: Ich hatte neben dem durchgereichten Stripeset (2 HDD's) 2...

keine einzige Fehlermeldung im Eventlog bisher... hier mal ein auszug aus dem bexec auftragslog: Der Tapejob (Full Backup) wurde am 01.10 gestartet und bisher 2x "restored" nach Absturz der VM... Dazwischen liefen die differentiellen B2D Jobs auf den ZFS-Stapel. Der Job am 01.10 wurde wohl...

Läuft immer noch...

nur die vm... der host ist unbeeindruckt von dem ganzen... no message about it (syslog/dmesg)..

I don' get it.... Heute morgen ist der Server 2x abgestürzt und nun laufen parallel 2 Jobs bisher klaglos weiter (der direkte B2Tape-Job wurde jedesmal "restored". Der 2te Job ist eine Kopie eines B2D-Jobs per BackupExec vom (ZFS-)Datenstapel auf das durchgereichte Windows-Stripeset.

Das Tape bzw. die Library mit 2 Tape-Drives hat einen eigenen SAS-HBA, der exklusiv an die VM durchgereicht wird...

Die Devices benutzen ja alle denselben Treiber...

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????!

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...

Cool. Das werde ich mal testen... Danke für den Tip.

Unterschied der Pools sind die verschiedenen Plattenstapel (2x SSD vs. 2x HDD). Sind aber aber beide an der gleichen Backplane angeschlossen. Siehe Screenshot oben...

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...

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...

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...

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...

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...)

Der Server wurde um kurz nach 13.00 Uhr neu gestartet (26.09.23) und das Backup (Disk)2Tape startete um 13.14 Uhr. Um 13.19 Uhr fangen dann die Fehler an... (aber das Backup scheint trotzdem zu laufen) Um 15:13 dann die ersten Bexec-Fehler: Ungefähr zum gleichen Zeitpunkt auch...

Ich finde darin nichts spezifisches, was das problem betreffen könnte... ich glaube der host bekommt davon gar nichts mit...

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.