mondragor

Windows Server 2025 friert komplett nach Reboot und Zugriff auf iSCSI-Target ein

back-to-topUmgebung: Windows Server 2025 (Build 26100.3476).


Hallo,

Hergang:
vor gut einem Monat wurde ein neuer Backupserver für unsere Umgebung installiert. Das hat ein Systemhaus vorgenommen.
Dieses wurde in ein separates VLAN gepackt und die Verbindung zwischen diesem und dem Storage (ISCSI) noch mal in ein eigenes.
C: läuft auf M.2 SSD und das ISCSI-Target bindet das 480TB Storage an.
Per Firewall und in den Switchen ist das alles so eingerichtet, dass es nicht aufs Internet zugreifen kann, sicher ist sicher.
Hat alles einen Monat lang super funktioniert mit wirklich sehr guter performance und war sehr zuverlässig.

Nun hatte durch einen Vorfall, bei dem wir viele Systeme wiederherstellen mussten, auch dieser Server einen Fehler und musste neu gestartet werden. Das war der erste Neustart, einen Monat nach Inbetriebnahme des Servers.

Problem:
Danach kam es dazu, dass immer, wenn auf das iSCSI-Target zugegriffen wird, dies zwar (mehr schlecht als recht) funktioniert, der Server dann aber offenbar irgendeinen Deadlock hat, also man sieht nich ganz wenige Frames für den Anfang und dann friert die Sitzung komplett ein. Selbst die Uhrzeit aktualisiert sich nicht mehr. Der Ping auf das System antwortet aber noch.

Es bleibt nicht einmal ein sauberer Reboot über die management-Oberfläche des zugrunde liegenden Terra-Servers.
Einzig ein Power-cycle bzw. force shutdown funktioniert.

Sowohl der Zugriff von Veeam aus als auch aus dem Dateisystem lösen das aus. Deaktiviere ich den Microsoft ISCSI-Dienst, bleibt das Target selbstverständlich im System unsichtbar aber der Server läuft problemlos weiter, seit mehr als einem Tag.

Ein Versuch, die Remotedesktopverbindung neu aufzubauen scheitert ebenfalls, es kommt nicht einmal eine Passwortabfrage. Am Gerät selbst komme ich auch mit Tastatur nicht zu einem Loginscreen. Teils reagiert nicht einmal NumLock.
Wenn der TaskManager während des Einfrierens läuft, sieht man als letzten Frame den Prozess: System (NT Kernel & System) mit 12 K Memory bei 33% CPU Load rödeln. GesamtCPU-Load: ca. 100%.
Verbaut ist ein Xeon E-356G @ 3,2 GHz (6C,12T) und 32 GB RAM.

Vielleicht hilft das noch bei der Einordnung.
Aus den Event views sehe ich nicht viel während dieser Phasen.
Vielmehr scheint er währenddessen so ziemlich gar nichts zu loggen. Nächstes Ereignis ist dann mit großem Zeitabstand mit dem Poswercycle zu verzeichnen.

Frage:
Kennt jemand dieses Verhalten oder weiß, wie man es löst?


Grüße und danke im Voraus.

Mondragor
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilen

Content-ID: 672774

Url: https://administrator.de/forum/windows-server-2025-friert-komplett-nach-reboot-und-zugriff-auf-iscsi-target-ein-672774.html

Ausgedruckt am: 29.05.2025 um 05:05 Uhr

pebcak7123
pebcak7123 07.05.2025 um 17:02:45 Uhr
Goto Top
Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten
Penny.Cilin
Penny.Cilin 07.05.2025 um 17:09:03 Uhr
Goto Top
pebcak7123 07.05.2025 um 17:02:45 Uhr

Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten

Auch hier wieder: Wie man eine Frage richtig stellt!
Liest man die Hilfe nicht?

Gruss Penny.
Mondragor
Mondragor 07.05.2025 aktualisiert um 18:40:27 Uhr
Goto Top
Zitat von @pebcak7123:

Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten


Der Server hat 2 x 10 GBit RJ45 (Intel 210), wobei einer quasi in das Intranet schaut, die andere die Verbindung zum Storage gewährleistet.
Da beide NICs in verschiedene VLANs schauen, kein Teaming, LAG oder dergleichen.
Es macht nicht eben die Anzahl der Jobs als eher der Datenumfang je Fullbackup.
Wie gesagt, es schrieb mit teils über 1 Gigabyte je Sekunde, alles gut soweit. Also Performance passte immer.

Software ist Veeam B&R Standardversion, die man halt damals zur Essentials Plus von VMWare dazu geholt hat. Neueste Version...

Wenn Du noch was konkretes wissen musst, frag halt...

Die 480 TB sind halt, um auch für die Zukunft noch Reserven zu haben, bei einem entsprechenden Vorhaltekonzept. Aktuelle Datenmenge ist ca. 40 TB je Vollsicherung. Größte Server sind Gut 18 und 12.4 TB pro Job.

Ich habe extra dazu geschrieben, dass die Lösung dazu von einem Systemhaus bereitgestellt wurde. Ich finde es müßig, jetzt über solche Einzelheiten zu befinden, wenn ich schreibe, dass es für unser Dafürhalten gut und performant lief, bis zum Neustart. Bitte akzeptiere das als Realität. Das denke ich mir nicht aus.

Grüße
Mondragor
Mondragor
Mondragor 07.05.2025 aktualisiert um 18:33:06 Uhr
Goto Top
Zitat von @Penny.Cilin:

pebcak7123 07.05.2025 um 17:02:45 Uhr

Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten

Auch hier wieder: Wie man eine Frage richtig stellt!
Liest man die Hilfe nicht?

Gruss Penny.

Hallo, auch Du bist herzlich eingeladen, mir konkrete Fragen zu stellen.
Zusammengefasst, wenn ich den ISCSI-initiator nicht aktiv habe, läufts. Wenn er aktiv ist und sich das Storage verbindet, muss nur ein Zugriff stattfinden, damit das System in ca. 30 - 90 Sekunden das beschriebene Verhalten zeigt.
Ich mag mich irren, aber meines Erachtens ist egal, was damit gebackupt wird, welche Software das Backup schreibt oder wo ich geboren bin. Es ist einfach dieser Unterschied, der ausmacht, ob das System einfriert oder nicht, egal, welche Anwendung auf das damit eingebundene "Laufwerk" letztendlich zugreift.

So stellt sich das Problem für mich dar und daher weiß ich nicht, welche Information Euch fehlt. Einen Link dazu zu posten, wie man eine Frage stellt, hilft mir da leider nicht, weil ich denke, dass ich mir Mühe gegeben habe, die von mir bereits gewonnenen Erkenntnisse soweit einzuflechten, sodass (meines Erachtens) überflüssige Informationen nicht unbedingt noch rein müssen.

Wenn dann etwas konkretes fehlt, bitte nachfragen. Ich gebe mir Mühe, entsprechend nachzuliefern.

Was mir bisher jedoch noch nie weiter geholfen hat, sind Leute, die aus Prinzip genau solche Kommentare schreiben, ohne je im Verlauf "wieder" irgendetwas Hilfreiches beizutragen.
Warum verschwendet man seine Lebenszeit damit, so einen Kommentar zu posten?
Nichts davon nimmt auch nur einen Funken an Bezug auf die Informationen, die ich bereits geliefert habe, konkretisiert, was angeblich fehlt oder nimmt Bezug die Frage, die ich gestellt habe.

Grüße
Mondragor
C.R.S.
C.R.S. 07.05.2025 um 18:58:51 Uhr
Goto Top
Hallo,

sinnvolle nächste Schritte wären, das Volume auf einem alternativen Rechner/OS zu mounten und jeweils abzuschichten, ob schon das Einhängen der Disk oder erst des Volumes zum Problem führt. Wahrscheinlich liegt halt ein Dateisystemfehler vor, der beim Parsing des Dateisystems zu dem Crash führt.

Den könnte man prinzipiell an der eingehängten Disk diagnostizieren, oder auch Daten mit alternativen Parsern wiederherstellen. Aber bei einem Backup-Ziel ist es an sich naheliegender, in einem solchen Fall das Volume neu aufzubauen und die Backups nachzuholen.

Grüße
Richard
em-pie
em-pie 07.05.2025 um 19:39:41 Uhr
Goto Top
Moin,

Vorweg: iSCSI ist ein Thema, bei dem ich nur weiß, wie man es schreibt und dass es auf EthernetFrames basiert face-wink

Zergliedere das Problem:
Hast du mal alle Veeam-Dienste deaktiviert, die Kiste neu gestartet und dann das iSCSI-Target wieder verbunden? Wenn das stabil läuft: kannst du gesichert per Explorer drauf arbeiten?
Wenn es stabil läuft: VEEAM in den Fokus holen. Welche Version setzt du ein? 12.3.1?

Wenn der Explorer-Zugriff auch schon scheitert: mal am Target eine weitere LUN angelegt und die gemounted?
Wurden im Rahmen des Reboots Updates (Windows) installiert?
Wie verhält sich ein anderer Initiator (wie oben schon beschrieben)…


Am Rande: sehr gewagt, VEEAM/ Windows nur mit einem Bein an das Target anzubinden. Werden Daten geschrieben und während dessen bricht dir die Verbindung (physisch) weg, kann das zu Datensalat führen. Mit einer Mehrport-Verbindung (MPIO) fährst du besserface-wink Ist es im übrigen eine DualPort-Karte oder zwei Single? Oder sind die onBoard?

Noch ne Frage: ist die NIC direkt mit dem Target verbunden oder hängt da noch ein Switch zwischen?
Coreknabe
Coreknabe 07.05.2025 um 22:42:01 Uhr
Goto Top
Moin,

Deiner Beschreibung nach hängt zwischen Server und Storage ein Switch. Verbinde doch einmal testweise den Server direkt mit dem Storage. Bleibt der Fehler, kannst Du Dir die Fehlersuche am Switch im Grunde sparen.

Ansonsten:
  • Verwendet Ihr Jumbo Frames?
  • Ping läuft, OK. Aber hast Du auch einen Dauerping mit -f laufen lassen? Bei Jumbo Frames bspw. ping -f 8972. Paketverluste? Oder gar ein Hinweis auf Fragmentierung?
  • Flow Control aktiv und an den entscheidenden Stellen entsprechend konfiguriert?
  • Intel Netzwerkkarte, NVM stimmt mit Treiberversion Intel ProSet überein?
  • Da RJ45, Kabelspezifikation reicht für 10Gbit aus? Testweise Kabeltausch?
  • Ihr habt das iSCSI-Target hoffentlich nicht mit ReFS formatiert?

Das mal so als spontane Ideen face-wink

Gruß
pebcak7123
pebcak7123 08.05.2025 um 08:54:27 Uhr
Goto Top
Wegen was für einem Fehler musste der Server denn neu gestartet werden ? Danach scheinen ja die Probleme angefangen zu haben.
Wurde schon mal neu installiert ? Für die Intel i210 gabs vorletzte Woche neue Treiber, wurden die evtl aktualisiert ?
Mal versucht sich wenn der hängt sich falls möglich über powershell draufzuschalten ?
Wenn Windows-Logs nichts aussagen was sagen die Logs vom Baseband Management ?
MysticFoxDE
MysticFoxDE 08.05.2025 um 09:20:56 Uhr
Goto Top
Moin @Coreknabe,

meine Kristallkugel sagt mir, dass du damit ...

* Ihr habt das iSCSI-Target hoffentlich nicht mit ReFS formatiert?

... wahrscheinlich schon ins schwarze getroffen hast.

Denn Veeam mault schon seit Jahren ein Backup-Target an, wenn es mit NTFS formatiert ist und weist darauf hin, dass man dieses mit ReFS formatieren sollte. 😬

Was jedoch total bescheuert ist, da ReFS über iSCSI und vor allem bei derart grossen LUN's, überhaupt nicht stabil läuft. 😔

Gruss Alex
MysticFoxDE
MysticFoxDE 08.05.2025 aktualisiert um 09:33:36 Uhr
Goto Top
Moin @Mondragor,

ich mach es kurz, aber leider nicht schmerzlos.

Wenn das was @Coreknabe betreffend ReFS schon erwähnt hat zutrifft, sprich, wenn du die iSCSI LUN tatsächlich mit ReFS formatiert hast und oder das Systemhaus, was am Ende des Tages auch vollkommen egal ist, da hier die Schuld definitiv bei Microsoft und auch bei Veeam liegt, dann habe ich für dich eine schlechte Nachricht, denn die Wahrscheinlichkeit, dass dir das ReFS um die Ohren geflogen ist, liegt meiner eigenen Erfahrung nach leider bei > 99%.

Denn genau das was du beschreibst, ist uns selbst schon vor mehreren Jahren bei einem Kunden passiert. 😭

Bei diesem hatten wir auch ein ~ 250 TB grosse iSCSI-LUN an Veeam drangehängt und hatten diese dann auch mit ReFS formatiert, weil es Veeam damals schon "empfohlen" hat. Diese ReFS formatierte LUN ist dann jedoch innerhalb von einem Jahren zwei Mal komplett um die Ohren geflogen, mit ähnlichen Effekten wie bei dir. Danach wurde die LUN mit NTFS und einer Block-Size von 64K formatiert und seitdem läuft diese nun seit einigen Jahren ohne Probleme.

Gruss Alex
MysticFoxDE
MysticFoxDE 08.05.2025 aktualisiert um 09:46:59 Uhr
Goto Top
Moin @Mondragor,

ich glaube, du solltest dir das ...

https://www.borncity.com/blog/2025/04/02/windows-server-2019-2025-maerz- ...

... und auch das ...

https://www.veeam.com/kb2792

... mal etwas genauer durchlesen. 😬

Insbesondere denn folgenden Hinweis von Veeam ...

windows server 2025 friert komplett nach reboot und zugriff auf iscsi-target ein - 01

... finde ich schon sehr spannend.

Denn bei der Einrichtung selbst, weist Veeam einfach nur darauf hin, dass es anstelle eines NTFS formatierten Volume, lieber ein ReFS formatiertes Volume hätte, ohne auch nur eine Silbe über die damit auch verbundenen Risiken zu erwähnen. 😔

Gruss Alex
Coreknabe
Coreknabe 08.05.2025 aktualisiert um 10:32:24 Uhr
Goto Top
Moin,

@mysticfox

Denn Veeam mault schon seit Jahren ein Backup-Target an, wenn es mit NTFS formatiert ist und weist darauf hin, dass man dieses mit ReFS formatieren sollte.

Man beachte hier auch die Historie. Erst von Veeam empfohlen und propagiert, dann verschämt in KB-Einträgen versteckt, dass das keine gute Idee ist, als Krönung erfolgt IMMER NOCH (aktuelle Version 12.3.1) eine Warnung in Veeam. Hammer...

Dazu muss man sagen, ich hatte hier auch diverse Dinge zum Thema iSCSI gepostet, wenn man sich drauf einlässt, der Datendurchsatz ist mit ReFS tatsächlich fast doppelt so hoch, wie mit NTFS! Zumindest habe ich das nach einigen kurzen Tests so beobachtet. Wenn man also vorher nicht recherchiert hat und sich auf die Veeam-Warnung verlässt, wird die Begeisterung bis zum ersten Einschlag anhalten...

Aber das sind alles Spekulationen, solange der TO sich hier nicht mehr äußert face-wink

Gruß
MysticFoxDE
MysticFoxDE 08.05.2025 aktualisiert um 12:36:26 Uhr
Goto Top
Moin @Coreknabe,

Man beachte hier auch die Historie. Erst von Veeam empfohlen und propagiert

das wird es seit ~2016 bis heute immer noch.

https://www.veeam.com/blog/advanced-refs-integration-coming-veeam-availa ...
https://www.veeam.com/resources/wp-availability-suite-advanced-refs-inte ...
https://www.veeam.com/resources/videos/storage-best-practices-recorded-d ...

😔

Interessant finde ich dem ersten Link auch die folgende Aussage.

„The advanced ReFS integration supports ReFS volumes on internal, direct-attached storage (DAS) and Storage Spaces — both classic and Storage Spaces Direct (S2D).“

Sprich, hier steckt meiner Ansicht nach eigentlich schon ein Hinweis, dass ReFS nur für DAS oder S2D geeignet ist.

By the way, die Backups mit auf das produktive S2D abzulegen, ist fürchte ich auch nicht wirklich eine sehr kluge Idee und ein extra S2D nur für Backups zu implementieren, ist meiner Ansicht nach fast noch bescheuerter. 😔

Somit bleibt nur noch DAS übrig, wobei auch hier kein RAID-Kontroller dazwischen stecken sollte, da sich diese auch gerne mit ReFS beissen. 🙃

Somit bleibt für ReFS nur noch ein einzelnes Laufwerk, was direkt per SAS oder PCIe am Veeam Server dranhängt als mögliches Backupziel übrig und diese Konstellation, ist eher alles andere als alltagstypisch.

dann verschämt in KB-Einträgen versteckt, dass das keine gute Idee ist, als Krönung erfolgt IMMER NOCH (aktuelle Version 12.3.1) eine Warnung in Veeam. Hammer...

Tja, vielleicht verstehst du nun etwas besser, warum ich mir in letzter Zeit, insbesondere die Software Hersteller besonders gerne vorknöpfe. 😉

Dazu muss man sagen, ich hatte hier auch diverse Dinge zum Thema iSCSI gepostet, wenn man sich drauf einlässt, der Datendurchsatz ist mit ReFS tatsächlich fast doppelt so hoch, wie mit NTFS! Zumindest habe ich das nach einigen kurzen Tests so beobachtet. Wenn man also vorher nicht recherchiert hat und sich auf die Veeam-Warnung verlässt, wird die Begeisterung bis zum ersten Einschlag anhalten...

Ja, ReFS bringt bei gewissen Dingen durchaus einen Zugewinn, aber nicht wirklich in jeder Umgebung und es hat vor allem auch enorme Nachteile, vor allem was dessen Stabilität angeht.

Darüber spricht jedoch so gut wie kein Hersteller, zumindest nicht besonders offen.

Einer meiner ersten Artikel die ich hier geschrieben habe, war übrigens dieser …

Warum ihr keine ReFS Formatierung für CSVs verwenden solltet, die von einem SAN bereitgestellt werden

… hier.

Und es hat am Ende des Tages über 2 Jahre gedauert, bis Microsoft die entsprechende Dokus so überarbeitet hat, dass in diesen ReFS nicht mehr pauschal auch für CSV’s empfohlen wird. 😔

Aber das sind alles Spekulationen, solange der TO sich hier nicht mehr äußert

Ich fürchte, der TO ist wahrscheinlich schon dabei seinen Diensleister wegen dem ReFS zu kloppen. 😬

Gruss Alex
Mondragor
Mondragor 08.05.2025 um 12:59:55 Uhr
Goto Top
Ja, das Dateisystem ist ReFS, was bei der Größe schon "fast nicht mehr anders geht"... und weils Veeam halt empfiehlt.

Aber das Problem war hier - zumindest in unserem Fall - offenbar der Windows Defender.

Am Anfang war das iSCSI-Target ja noch unbeschrieben und daher wohl auch nicht das Problem, dass der aktiv war.

Nach dem Reboot einen Monat später sah das aber anders aus, 60 TB belegt und der hat dann offenbar den RAM vollgeballert und alle Prozesse "blockiert", die darauf zugreifen wollten. Ob der Defender vorher kein Problem hatte, weil beim Booten das Volume noch nicht eingebunden war oder es zwar da aber leer war, weiß ich nicht.

Wir haben also für den Defender den Ausschluss des Laufwerksbuchstaben des iSCSI-targets mit ReFS eingetragen, Neustart - alles wieder gut. RAM ist nur zu 25% belegt, alles läuft flüssig, keine Aussetzer oder Freezes mehr. Veeam schreibt und liest wieder auch im Bereich von >1 GByte/s.

Ob sich der Defender nun am ReFS stört oder an der Größe / Menge der darauf befindlichen Daten, ist mir mehr oder minder Bums.

Der Rechner darf nur für Updates ins Internet schauen, danach wird das über die Firewall wieder geschlossen.
Die Rückrichtung ist ohnehin ausgeschlossen. Somit sehe ich eher keinen Anlass, warum die Veeam-Backups vom Defender durchsucht werden sollten.

MysticFoxDE 08.05.2025 aktualisiert um 09:46:59 Uhr
Markiere als 'Lösung'
Goto Top
Moin @Mondragor,

ich glaube, du solltest dir das ...

https://www.borncity.com/blog/2025/04/02/windows-server-2019-2025-maerz- ...

Da steht was vom Veeam Agent. Ich denke das ist der Windows Endpoint Backup Agent, der da gemeint ist, also dass der Probleme hat, ReFS als Quelle zu handhaben, kann mich aber irren.
Das neueste Windows Update ist jetzt installiert und nächste Woche kommt ja wieder ein neues. Die Meldungen aus März sind dann vielleicht auch wieder hinfällig, zumal es ohnehin ein anderes Problem gab mit ISCSI beim Booten ... Aber das sollte glaube ich ab dem April-Update schon gelöst gewesen sein...

Aber unser Server bootet von SSD.

Ich gehe davon aus, dass das Problem erstmal gelöst ist. Werde aber Tipps bezüglich ReFS im Hinterkopf behalten, falls da nochmal trotz des Ausschlusses vom Defender ein ähnlich gelagertes Problem auftreten sollte.

Danke nochmal an alle, die sich Mühe gegeben haben, mir zu helfen.

Grüße
Mondragor
Coreknabe
Coreknabe 08.05.2025 um 15:48:53 Uhr
Goto Top
Moin,

gutgemeinter Rat: Solange Du noch die Möglichkeit hast, verwende NTFS! Ansonsten, Trauergeschichten gibt es im Netz mehr als genug, läufst Du Gefahr, dass Deine Daten von gleich auf jetzt weg sind.

Gruß
Mondragor
Mondragor 08.05.2025 um 16:13:31 Uhr
Goto Top
Wir schauen uns das nochmal an. Danke für den Hinweis.

Grüße
Mondragor
MysticFoxDE
MysticFoxDE 08.05.2025 aktualisiert um 17:27:15 Uhr
Goto Top
Moin @Mondragor,

Ja, das Dateisystem ist ReFS, was bei der Größe schon "fast nicht mehr anders geht"... und weils Veeam halt empfiehlt.

wie du aber gemäss des folgenden und bereits erwähnten Veeam-Artikels …

https://www.veeam.com/kb2792

… sehen kannst, ist ReFS auch seitens Veeam, nicht wirklich für dein Setup geeignet. 😔

Und auch in der folgenden Doku von Microsoft …

https://learn.microsoft.com/en-us/windows-server/storage/refs/refs-overv ...

… wird der Einsatz von ReFS bei iSCSI-Targets, …

windows server 2025 friert komplett nach reboot und zugriff auf iscsi-target ein - 02

… nur bedingt empfohlen.

Aber das Problem war hier - zumindest in unserem Fall - offenbar der Windows Defender.

OK, der mit dem Defender ist auch gut. 🙃

Du solltest die Ausnahme jedoch nicht nur für das Backup-Target konfigurieren, sondern auch für …

https://community.veeam.com/blogs-and-podcasts-57/updated-av-exclusions- ...

… diverse weitere Verzeichnisse/Dateierweiterungen. 😉

Ich gehe davon aus, dass das Problem erstmal gelöst ist. Werde aber Tipps bezüglich ReFS im Hinterkopf behalten, falls da nochmal trotz des Ausschlusses vom Defender ein ähnlich gelagertes Problem auftreten sollte.

Bei uns, respektive, bei dem entsprechenden Kunden, sind die ReFS formatierten LUN’s auch erst um die Ohren geflogen, als > 150 TB an Daten auf diesen gespeichert waren, sprich, auch erst nach einigen Monaten. 😔

Zudem hatte der Kunde in der Zeit wo das Backup-Ziel noch auf ReFS war, auch extrem viele Probleme mit den Backupjobs selber, weil diese nicht immer sauber durchgelaufen sind. Immer wieder musste ein Full-Backup von Hand erstellt werden, damit die Jobs wieder von alleine durchlaufen.😭

Gruss Alex
regnor
regnor 08.05.2025 aktualisiert um 17:37:34 Uhr
Goto Top
Allgemein abraten von ReFS würde ich jetzt nicht. Wichtig ist eben, dass die darunterliegende Hardware ReFS unterstützt, bzw. es sich um zertifizierte Hardware handelt. Und das ist weniger ein Veeam Thema, sondern liegt bei Microsoft und den Hardware Herstellern. Deswegen auch die Hinweise im KB Artikel oder im Helpcenter:
All ReFS supported configurations must use Windows Server Catalog certified hardware. For other requirements, limitations and known issues, see this Veeam KB article.

Wenn die Hardware passt, dann würde ich wegen den Vorteilen von Fast Clone ReFS immer NTFS vorziehen.
Das Microsoft aber des öfteren durch Updates Probleme gemacht hat würde ich nicht abstreiten. Das letzte Thema wurde ja bereits oben verlinkt und trifft nicht exklusiv den Veeam Agent sondern auch alle anderen Lösungen (und vermutlich jede Software die ReFS Features nutzt).

Was ich jetzt eventuell überlesen habe, welches iSCSI Storage Ihr einsetzt?


Bezüglich dem Windows Defender und auch allen anderen Security Lösungen sollten die Ausnahmen entsprechend gesetzt werden. Ohne diese kann es zu Performance- und Stabilitäts-Problemen, bis hin zu defekten Backup Files kommen.
https://www.veeam.com/kb1999
MysticFoxDE
MysticFoxDE 08.05.2025 um 18:18:45 Uhr
Goto Top
Moin @regnor,

Allgemein abraten von ReFS würde ich jetzt nicht. Wichtig ist eben, dass die darunterliegende Hardware ReFS unterstützt, bzw. es sich um zertifizierte Hardware handelt. Und das ist weniger ein Veeam Thema, sondern liegt bei Microsoft und den Hardware Herstellern.

eher nur bei Microsoft, weil sie ReFS ohne grossartige Rücksprache mit der Hardware-Welt geboren haben. 😔
Und externe SAN's oder NAS Geräte, können die seid ihrem S2D-Tripp, eh nicht mehr wirklich gut leiden.

All ReFS supported configurations must use Windows Server Catalog certified hardware. For other requirements, limitations and known issues, see this Veeam KB article.

Ja, aber dann gilt immer noch das ...

For SANs, if features such as thin provisioning, TRIM/UNMAP, or Offloaded Data Transfer (ODX) are required, NTFS must be used.

... hier. 🙃

Gruss Alex
Mondragor
Mondragor 09.05.2025 um 12:00:15 Uhr
Goto Top
Das Storage ist ein QSAN XS3324D mit SFP+
Jeder Controller ist mit 2 Modulen verbunden.
Switch ist ein Aruba 5406R zl2 mit 2 SFP+-Modulen
von denen jeder Controller auf jedes dieser Module je 1 Verbindung hat.
Diese sind dann je QSAN-Controller zu LAG zusammengefasst.

Die Verbindung Backup-Server ist mit Cat6a-Kabel auf den selben Switch
mit 10 GBit RJ45.

Durch VLans schauen die beiden NICs in verschiedene Netze, einmal zum
Abrufen der Daten aus der VMWare und einmal zum Schrieben auf das Target.

Die HDDs sind 24 TB SAS HDDs im Raid 6.

Habe ich noch was vergessen??

Grüße
Mondragor
MysticFoxDE
MysticFoxDE 09.05.2025 aktualisiert um 12:40:37 Uhr
Goto Top
Moin @Mondragor,

Das Storage ist ein QSAN XS3324D mit SFP+
Jeder Controller ist mit 2 Modulen verbunden.

OK, ein QSAN, sieht auch nicht schlecht aus, zumindest auf dem Papier.

https://www.qsan.com/data/dl_files/qs_ds_XS3300_(en).pdf

Und auf diesem sehe ich, dass das Ding seinen Speicherplatz ja auch per SMB bereitstellen,
sprich auch ein NAS sein kann. 😁

Wenn ja, dann empfehle ich dir eher, das Backup-Repository per SMB mit Multichannel anzubinden,
das hat sich zumindest bei den Systemen unserer Kunden (Hyper-V + Veeam), sich als die besserer Lösung erwiesen. 😉

Switch ist ein Aruba 5406R zl2 mit 2 SFP+-Modulen

Bitte sicherstellen, dass auf den Ports über die insbesondere der iSCSI-Datenverkehr läuft, Flow-Controll aktiviert ist, auch auf den entsprechenden NIC's der Server.
Aber Vorsicht, wenn du FC aktivierst oder deaktivierst, geht der entsprechende Port kurz down!

Diese sind dann je QSAN-Controller zu LAG zusammengefasst.

Das würde ich so nicht machen, sondern eher über MPIO bündeln.

Durch VLans schauen die beiden NICs in verschiedene Netze, einmal zum
Abrufen der Daten aus der VMWare und einmal zum Schrieben auf das Target.

👍

Die HDDs sind 24 TB SAS HDDs im Raid 6.

Machen wir auch sehr ähnlich, nur mit dem Unterschied, dass wir keine QSAN's, sondern die folgenden ...

https://www.infortrend.com/de/products/families/gs/3000

... "Unified" SAN's verwenden, die übrigens auf nur 4HE's bis zu 90 3,5" Bay's bereitstellen können.

Gruss Alex
C.R.S.
C.R.S. 09.05.2025 um 13:41:05 Uhr
Goto Top
SMB, NTFS... Bestehende Hard- und Software kann/muss man immer nach Möglichkeit zusammenwürfeln, um es irgendwie zum Laufen zu bekommen. Erklärt aber nicht, warum Kunden von angeblichen "Systemhäusern" so regelmäßig hinter die Fichte geführt werden.

ReFS und Veeam sind jeweils robuste, gut dokumentierte Lösungen. Wenn ich Veeam einsetze, will ich ReFS. Daher brauche ich einen Storage-Stack, der ReFS stabil unterstützt. Erste Wahl Storage-Spaces. Zweite Wahl eine gleichwertiger DAS-Resilienzschicht - schon das unter Verzicht auf die Interoperabilität von Dateisystem/Integritätsschicht und Resilienzschicht. Demenstsprechend dann lange nichts, dann dritte Wahl ein dünnes Sortiment an SANs unter engen Rahmenbedingungen.

Kann man sich also aus technischen Grundlagen herleiten. Muss man aber nicht, man kann einfach stupide den empfohlenen Design-Patterns von Veeam folgen und kommt auch so zu Storage Servern. Letzte Instanz vor DAS: Der Veeam Data Mover.
Das ist ein Kernkonzept dieser Lösung. Vieles andere geht, wenig davon ist sinnvoll, in den meisten Fällen beschneidet es teuer bezahlte Features.

Aber nein, man will ja die Lieblings-Storage-Appliance und iSCSI-Klöppeleien verkaufen, weil man das schon immer so gemacht hat, ohne irgendwas dazuzulernen. Im Zweifel ist der Hersteller schuld, im Einrichtungsassistenten keinen Idiotentest einzubauen, und die misratene Integration darf beim Kunden auf einem Bein weiterhumpeln - zum ursprünglichen Preis, zzgl. der herausfordernden "Entstörung" der vermeintlichen Herstellerversäumnisse natürlich.
MysticFoxDE
MysticFoxDE 09.05.2025 aktualisiert um 14:38:29 Uhr
Goto Top
Moin @c.r.s.,

ReFS und Veeam sind jeweils robuste, gut dokumentierte Lösungen.

was Veeam angeht, so trifft deine Aussage durchaus zu, bei ReFS ist das jedoch definitiv nicht der Fall,
vor allem was dessen Dokumentation angeht.

Wenn ich Veeam einsetze, will ich ReFS.

Aha und warum genau, sprich was für ein Wunder erhoffst du dir davon?

Daher brauche ich einen Storage-Stack, der ReFS stabil unterstützt.

Selbst Microsoft, empfiehlt ReFS nur bedingt und setzt bei den Boot-Drives auch noch nach wie vor auf NTFS und selbst beim SQL-Server wird (wieder) ausschliesslich NTFS empfohlen.

Erste Wahl Storage-Spaces. Zweite Wahl eine gleichwertiger DAS-Resilienzschicht - schon das unter Verzicht auf die Interoperabilität von Dateisystem/Integritätsschicht und Resilienzschicht. Demenstsprechend dann lange nichts, dann dritte Wahl ein dünnes Sortiment an SANs unter engen Rahmenbedingungen.

Ähm sorry, aber spättestens hier, hast du dich gewaltigst vergriffen.
Denn sowohl das vom TO verwendete QSAN als auch die von mir empfohlenen Infortrend Units, sind im Vergleich zu einem S2D System, welches diese Kapazitäten überhaupt händeln kann, mit vergleisweise sehr maggeren Hardware bestückt. Aber, aus dieser relativ überschaubaren Hardware, schaffen es beide Hersteller eine enorme Leistung herauszukitzeln und im Falle von Infortrend, kann ich dir garantieren, dass diese Leistung auch mindestens bereitgestellt wird. Und das schaffen diese Units unter anderem deshalb, weil deren OS nur auf performante Datenbereitstellung getrimmt ist und nicht noch sonstigen Schnickschnack mit sich schleppen muss.

Also nein, du kannst ein erwachsenes Enterprise-SAN nicht wirklich mit einem S2D System vergleichen,
oder das letztere als gar überlegen darstellen, denn das ist meiner Ansicht und auch Erfahrung nach, schlichtweg Augenwischerei.

Kann man sich also aus technischen Grundlagen herleiten.

Nein, das kann man eben nicht, vor allem wenn man auch noch extra ein S2D System nur als Backup-Storage aufsetzen möchte.

Aber nein, man will ja die Lieblings-Storage-Appliance und iSCSI-Klöppeleien verkaufen, weil man das schon immer so gemacht hat, ohne irgendwas dazuzulernen.

Ja, wir haben die Units früher auch über iSCSI angebunden, aber, wie ich schon geschrieben habe, machen wir das aus diversen Gründen mittlerweile per SMB. Zumindest in Verbindung mit Hyper-V und Veeam, hat sich das als die bisher stabilste und auch performanteste Variante bewiesen.

Sprich, dazulernen können wir schon, dazu muss man sich aber nicht von jeglichem Schnickschnack auch gleich vollständig blenden lassen. 😉

Gruss Alex
regnor
regnor 09.05.2025 um 16:49:47 Uhr
Goto Top
Einige Modelle von QSAN sind schon einmal in der Veeam Ready Datenbank gelistet als iSCSI Target; was aber nicht einschließt, dass ReFS unterstützt ist. Gegebenenfalls direkt beim Hersteller nachfragen oder ReFS als "nicht supported" annehmen. Auf NTFS zu wechseln wäre dann die sicherere Variante, aber ansonsten mindestens die Health Checks konfigurieren und 3-2-1 noch mehr beachten.
https://www.veeam.com/partners/alliance-partner-technical-programs.html? ...

@MysticFoxDE: Unterstützen die Infortrend Systeme continuous availability und falls ja, habt ihr das dann für die Shares aktiviert?
MysticFoxDE
MysticFoxDE 09.05.2025 aktualisiert um 21:22:45 Uhr
Goto Top
Moin @regnor,

@MysticFoxDE: Unterstützen die Infortrend Systeme continuous availability

aber selbstverständlich ...

Infortrend’s HA (High Availability) service is a powerful solution for storage clusters, enabling enterprises to provide continuous availability for their data and applications. Supported on scale-out unified storage solutions, EonStor GS for enterprises and EonStor GSe for SMB, the HA service ensures uninterrupted operations with site resilience, achieving near-zero Recovery Time Objective (RTO) and zero Recovery Point Objective (RPO). The HA service is utilized in scenarios where data accessibility and system uptime are critical, helping to avoid reputational damages and revenue losses caused by potential disruptions in services.

Quelle:
https://www.infortrend.com/global/solutions/ha-service

... . 😉

und falls ja, habt ihr das dann für die Shares aktiviert?

Auf einer Unit mit zwei Controllern muss man für das HA, respective "continuous availability" selber, nichts extra konfigurieren, hier erfolgt das Failover/Failback vollkommen automatisch.

Die Infortrend GS Units unterstützen sogar "Immutable Backup" ...

https://www.infortrend.com/event2023/202308-gs-g3/202308-backup-solution ...

... . 😁

Gruss Alex
C.R.S.
C.R.S. 10.05.2025 um 13:52:50 Uhr
Goto Top
Zitat von @MysticFoxDE:

Wenn ich Veeam einsetze, will ich ReFS.

Aha und warum genau, sprich was für ein Wunder erhoffst du dir davon?

Veeam lagert Verwaltungsoperationen an ReFS aus. Das Dateisystem des Repos beeinflusst daher maßgeblich die Dauer der Backup-Jobs, im Ergebnis die mögliche Parallelisierung und damit das Sizing, betriebswirtschaftlich den ROI.

Wenn man es anders sieht, macht man es anders. Es ist nur eine begründete Empfehlung.

Hier sind Fälle dokumentiert, wo es eben nicht anders gemacht wurde, weil das abgewogen und entschieden worden wäre. Die Empfehlung wird in diesen Fällen durchaus umgesetzt, jedoch in einer untauglichen Integration. Erst sobald sich dies zeigt, wird gezwungenermaßen von der Empfehlung abgewichen und auf einen insoweit reduzierten Funktionsumfang umkonfiguriert.
Der Kunde muss damit leben, weil… äh… die Empfehlung des Software-Herstellers falsch ist, genau.

Selbst Microsoft, empfiehlt ReFS nur bedingt und setzt bei den Boot-Drives auch noch nach wie vor auf NTFS und selbst beim SQL-Server wird (wieder) ausschliesslich NTFS empfohlen.

ReFS ist für manches geeignet, für anderes nicht. Verschiedene Technik für verschiedene Anwendungsfälle. Völlig egal, denn hier, d.h. vom Standpunkt der umzusetzenden Backup-Lösung gesehen, ist es geeignet, vom Hersteller ausdrücklich empfohlen und objektiv empfehlenswert.

Denn sowohl das vom TO verwendete QSAN als auch die von mir empfohlenen Infortrend Units, sind im Vergleich zu einem S2D System, welches diese Kapazitäten überhaupt händeln kann, mit vergleisweise sehr maggeren Hardware bestückt...

Storage-Spaces ist nicht gleich S2D, auch das geht am Thema vorbei. Der springende Punkt ist:

ReFS ist ein Verbunddateisystem mit Storage-Spaces als Resilienzschicht. Die andere zentrale Zielsetzung von ReFS neben Resilienz ist Integrität, d.h. unter keinen Umständen falsche Daten zu liefern. Die Resilienzschicht ist die Arbeitsvoraussetzung der Integritätsschicht; speziell Storage-Spaces als durch das Dateisystem steuerbare Resilienzschicht ist Arbeisvoraussetzung hinsichtlich der Datenkorrektur. Ansonsten bleibt nur die Verweigerung der Ausgabe zur Erfüllung des Integritätsparadigmas.

Über diesen Aufbau muss man sich im Klaren sein, wenn man Storage-Spaces als Resilienzschicht ersetzt. Je fragiler der Signalweg zwischen Resilienz- und Integritätsschicht, desto geringer die Verfügbarkeit der Resilienzschicht aus Sicht des Dateisystemtreibers, desto größer die Sollbruchstelle.
Daran können auch SAN-Hersteller im Grundsatz nichts ändern, sondern es eben mitigieren und gegen Fehlerbedingungen testen, validieren. Es bleibt eine Sollbruchstelle, mal größer, mal kleiner, mal mehr oder weniger relevant. Keine Fage, das kann man alles differenziert abwägen und anhand der konkreten Gegebenheiten zu jedem denkbaren Ergebnis kommen.
Es passiert aber offensichtlich nicht, sondern in kompletter Ignoranz der technischen Zusammenhänge werden Sollbruchstellen von der Größe des Grand Canyon eingebaut und dann Legenden gesponnen, wenn die Daten weg sind.
regnor
regnor 10.05.2025 um 14:28:42 Uhr
Goto Top
@MysticFoxDE Die Seite hatte ich auch schon gefunden aber war mir dann nicht sicher, ob continuous availability eingesetzt wird oder das im Text als Feature dargestellt wird😅
Gewundert hatte ich mich auch, weil sie zwar als Object und iSCSI Repository in der Veeam Ready gelistet sind, nicht aber als SMB Repository.

Für alle anderen die SMB einsetzen (wollen), ist folgender KB Artikel interessant.
https://www.veeam.com/kb3124
MysticFoxDE
MysticFoxDE 11.05.2025 um 07:07:39 Uhr
Goto Top
Moin @MysticFoxDE,

Die Seite hatte ich auch schon gefunden aber war mir dann nicht sicher, ob continuous availability eingesetzt wird oder das im Text als Feature dargestellt wird. 😅

ich kann dir eins versichern, da wo andere Hersteller gerne übertreiben, mach Infortrend genau das Gegenteil davon,
sprich, sie versprechen eher weniger, als sie anschliessend liefern.

Siehe ...

Infortrend DS4000U - Meine neue Liebe . . . natürlich nur SAN technisch

... und laut Infortrend selber, sollte die Unit eigentlich nur max. 1.000.000 IO/s bringen. 😁

Gewundert hatte ich mich auch, weil sie zwar als Object und iSCSI Repository in der Veeam Ready gelistet sind, nicht aber als SMB Repository.

Ist wahrscheinlich seitens Infortrend nicht gemacht worden, weil bisher noch kein Kunde dies verlangt hat. 🙃

Gruss Alex
MysticFoxDE
MysticFoxDE 11.05.2025 um 07:28:26 Uhr
Goto Top
Moin @c.r.s.,

Storage-Spaces ist nicht gleich S2D

ja, das eine ist ein lokales Software-RAID was im Gegensatz zu einem Hardware-RAID schon einen ordentlichen Overhead produziert und das andere ist zusätzlich noch über das Netzwerk verteilt, was die Sache noch schlimmer macht, weil hier noch der Netzwerk-Overhead mit dazukommt. Und ja, ich weiss, den Netzwerkoverhead kann man mit RDMA reduzieren, jedoch nicht komplet eliminieren.

Was den Rest angeht, so habe ich den Worten von Microsoft betreffend ReFS auch mal blind vertraut.

Das Ergebniss war das Folgende ...

Warum ihr keine ReFS Formatierung für CSVs verwenden solltet, die von einem SAN bereitgestellt werden

... sprich, am Ende hat Microsoft dann doch eingesehen, dass ReFS bei CSV die durch ein SAN bereitgestellt werden,
alles andere als eine geile Idee ist, vor allem performancetechnisch.

Sprich, nein, leider ist bei weitem nicht alles ein Wunder was Microsoft gerne als ein solches verhaufen möchte und dazu zählt insbesondere ReFS, aber auch so Dinge wie RSC, was übrigens insbesondere auch für S2D, ein absolutes Performance-Gift ist.

Gruss Alex
Mondragor
Mondragor 13.05.2025 um 13:57:22 Uhr
Goto Top
Okay, also es hat sich leider bestätigt, er hat zwar Freitag noch alle Backups gezogen, die in der VMware lagen, ist dann aber eingefroren (Windows-seitig).
Dementsprechend haben wir auf ein Storage, das noch zur Verfügung stand, ein Full BU geschrieben und das "alte" ReFS-Storage einmal neu mit NTFS und 128 kb Blockgröße formatiert.
Das ließ sich machen, nachdem in der Registry ein Eintrag gesetzt wurde, der das Caching für ReFS auf 0 gesetzt hat, sodass Veeam nach dem Start nicht mehr das System einfrieren lässt.
Der Verbrauch des RAMs ist nun DEUTLICH bescheidener und so kann man arbeiten, denken ich.

Das Voll-BU von dem "Zwischenstorage" wird nun durch Veeam dorthin migriert und darauf kann dann ab heute Abend wieder ein inkrementelles aufgebaut werden, so die Hoffnung...

Vielen Dank für all die Hinweise, zumindest konnte ich mir am Wochenende schon denken, woran es liegt, dass er wieder eingefroren war und war zwar nicht entspannt, aber konnte mir schon mal einen Plan machen, wie damit umzugehen ist.

Grüße
Mondragor
Coreknabe
Coreknabe 13.05.2025 um 21:27:46 Uhr
Goto Top
Moin,

@Mondragor
Vielen Dank, dass Du hier noch ein Feedback postest, ist (leider) nicht selbstverständlich!
Drücke die Daumen, dass alles klappt!

Gruß
MysticFoxDE
MysticFoxDE 14.05.2025 aktualisiert um 08:57:08 Uhr
Goto Top
Moin @Mondragor,

Das ließ sich machen, nachdem in der Registry ein Eintrag gesetzt wurde, der das Caching für ReFS auf 0 gesetzt hat, sodass Veeam nach dem Start nicht mehr das System einfrieren lässt.

ähm, Moment, das bedeutet ja, dass du die iSCSI LUN direkt als CSV an die Hyper-V Nodes angebunden hast. 😬

Aha und wie genau ist diese an den Veeam Server angebunden?

Das ist übrigens keine wirklich gute Idee, denn die iSCSI LUN sollte eher am Veeam Server dran hängen und nicht direkt am HV-Cluster.

Gruss Alex
Mondragor
Mondragor 14.05.2025 um 10:00:09 Uhr
Goto Top
Das ließ sich machen, nachdem in der Registry ein Eintrag gesetzt wurde, der das Caching für ReFS auf 0 gesetzt hat, sodass Veeam nach dem Start nicht mehr das System einfrieren lässt.

ähm, Moment, das bedeutet ja, dass du die iSCSI LUN direkt als CSV an die Hyper-V Nodes angebunden hast. 😬

Nein, das ist ein Missverständnis. Wir haben in der Registry des VEEAM-Servers einen Registry-Wert gesetzt, der zuvor noch nicht bestand. Genau gesagt war es wohl in der "HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\" das DWORD "FileCacheLimitPercent", das wir auf 0 festgelegt haben.
Insofern war meine Aussage "Caching für ReFS" auf 0 gesetzt nicht richtig, sorry dafür.

Aber jedenfalls ist eben dieses Caching durch VEEAM das, was in der Konstellation die Maschine hat einfrieren lassen.

Davon abgesehen nutzen wir VMware. Der VEEAM-Server und das Backup-Ziel hängen im selben VLAN, die VMware hat darauf keinen direkten Zugriff.

Grüße
Mondragor
MysticFoxDE
MysticFoxDE 15.05.2025 aktualisiert um 07:35:18 Uhr
Goto Top
Moin @Mondragor,

Nein, das ist ein Missverständnis.

ja, das sehe ich jetzt auch und du hast ja auch mehrfach VMware geschrieben ... keine Ahnung wie ich da auf Hyper-V rübergekommen bin. 🙃

Wir haben in der Registry des VEEAM-Servers einen Registry-Wert gesetzt, der zuvor noch nicht bestand. Genau gesagt war es wohl in der "HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\" das DWORD "FileCacheLimitPercent", das wir auf 0 festgelegt haben.
Insofern war meine Aussage "Caching für ReFS" auf 0 gesetzt nicht richtig, sorry dafür.

😯 ... das wiederum sieht sehr interessant aus, denn es hat mich schon immer genervt, dass der Veeam Server beim Sichern den RAM mit dem zwischencachen zu sehr vollballert.

Hast du die Einstellung so belassen?
Wenn ja, hat sich das irgendwie auf deine Sicherungsperformance/Sicherungszeit ausgewirkt?

Davon abgesehen nutzen wir VMware. Der VEEAM-Server und das Backup-Ziel hängen im selben VLAN, die VMware hat darauf keinen direkten Zugriff.

👍👍👍

Gruss Alex
Mondragor
Mondragor 16.05.2025, aktualisiert am 20.05.2025 um 10:16:23 Uhr
Goto Top
Hi @MysticFoxDE oder Alex, wenn's beliebt,

wir haben den Registryeintrag so belassen, meine ich, kann mich am Montag auch noch einmal vergewissern.
Würde Dir das Ergebnis dann am Montag mitteilen.
Nachtrag: Der Registry-Eintrag steht nach wie vor auf 0.
Aber die RAM-Last ist jetzt echt gechillt, auch wenn er schiebt und sichert. Das ist ein Riesenunterschied. Der ist in der Regel unter 10 GB RAM-Last. Drum gehe ich mal davon aus, dass er nicht cachet (schreibt man das so in denglisch?).

Flashcenhals dürften momentan die 2.5" HDDs sein, die zu 25 Stück das Raid 6 der (meisten) VMware VMs bilden.

Meines Erachtens hat sich an der Geschwindigkeit beim Sichern nicht maßgeblich geändert. Ein inkrementelles Backup aller VMs in 4 Klassen (SQL selbst, SQL dependent, SQL independent und eine ohne ApplicationAware...) dauert zusammen keine Stunde mehr. FullBackup der insgesamt ca. 21 TB dauert eine knappe "Nacht". Größte VM mit 12.4 TB ist in 7:54 Stunden durch.

SQL Full hat eine höchstgeschwindigkeit von > 1 GByte/s (lässt sich halt gut komprimieren).
Der Rest so zwischen 500 und 800 je nach Größe und Datenbeschaffenheit.
Wenn man bedenkt, dass die meisten VMs noch auf 2.5" HDDs liegen, finde ich das mehr als ordentlich.

Was das Caching betrifft, würde ich annehmen, dass das v.a. dann interessant wird, wenn das Ziel mit dem Schreiben nicht hinterher kommt. Aber bei uns ist die Quelle mit 10 GBit an einer Nic angebunden und das Ziel auf der anderen Nic ebenfalls. Lesen ist momentan von 25 x 2,5" HDD Raid6 und schreiben auf 24 x 3.5" HDD Raid6. Später dann von SSD auf HDD.
Da teste ich dann noch einmal, aber momentan veranlasst mich erst einmal nix, den Cache wieder einzuschalten.

Was noch hinzu kommen wird, ist die Migration der Produktionsdaten von einem Helios Fileserver auf einen Windows Dateiserver. Das geht dann komplett auf SSDs im Raid 6. Dafür fällt das Raid6 mit SSDs der aktuellen Helios-Fileserver-Konfig als neues Ziel der anderen VMware VMs an. Dann ist alles produktive auf SSDs im Raid6 und die Backups und Replications auf recht performanten HDDs.

So sieht erst einmal der Fahrplan aus...

Grüße
Mondragor