Veeam-Backup nach Plattentausch superlangsam
Moin,
mein Thema passt hier nur teils rein, weil es auch um Hardware geht, ich probiere es trotzdem einmal.
Wir haben zur Sicherheit unsere alten Server weiterlaufen lassen, dort landen die Replikas, die mit Veeam 11 gesichert wurden.
Server:
- Fujitsu Primergy RX300 S8 mit 192GB RAM
- RAID FTS Ctrl SAS 6G 5/6 512MB
Ursprünglich waren dort für die Datenpartition 4x Seagate ST3600057SS verbaut und liefen in einem RAID 5. Schlaufuchsalarm, ich schaufle mal eben mehr Spreicherplatz und tausche die Seagate-Platten gegen 4x Toshiba MG03SCA400 aus. Wow, Speicher satt. RAID 5 neu aufgebaut, schick.
Jetzt kopiere ich auf eine USB-Platte gesicherten Veeam-Replikas wieder auf das neue RAID zurück. Na dann, schubse ich mal den Replikationsjob wieder an.
Und jetzt gibt's große Augen, hatte ich vorher einen Datendurchsatz von mindestens 93MB/s (Gbit-Netzwerk), so komme ich jetzt nur noch auf 10-13MB/s...
Mir war klar, dass die Toshiba-Platten langsamer sind, aber so viel langsamer???
Der RAID-Verbund ist als Write-Through / Kein read-ahead konfiguriert.
Wo ist mein Fehler, sind die neuen Platten tatsächlich derart lahm?
EDIT: Der Ressourcenmonitor auf dem Zielserver zeigt während des Backups tatsächlich eine Datenträgeraktivität von fast dauerhaft 100%.
Gruß
mein Thema passt hier nur teils rein, weil es auch um Hardware geht, ich probiere es trotzdem einmal.
Wir haben zur Sicherheit unsere alten Server weiterlaufen lassen, dort landen die Replikas, die mit Veeam 11 gesichert wurden.
Server:
- Fujitsu Primergy RX300 S8 mit 192GB RAM
- RAID FTS Ctrl SAS 6G 5/6 512MB
Ursprünglich waren dort für die Datenpartition 4x Seagate ST3600057SS verbaut und liefen in einem RAID 5. Schlaufuchsalarm, ich schaufle mal eben mehr Spreicherplatz und tausche die Seagate-Platten gegen 4x Toshiba MG03SCA400 aus. Wow, Speicher satt. RAID 5 neu aufgebaut, schick.
Jetzt kopiere ich auf eine USB-Platte gesicherten Veeam-Replikas wieder auf das neue RAID zurück. Na dann, schubse ich mal den Replikationsjob wieder an.
Und jetzt gibt's große Augen, hatte ich vorher einen Datendurchsatz von mindestens 93MB/s (Gbit-Netzwerk), so komme ich jetzt nur noch auf 10-13MB/s...
Mir war klar, dass die Toshiba-Platten langsamer sind, aber so viel langsamer???
Der RAID-Verbund ist als Write-Through / Kein read-ahead konfiguriert.
Wo ist mein Fehler, sind die neuen Platten tatsächlich derart lahm?
EDIT: Der Ressourcenmonitor auf dem Zielserver zeigt während des Backups tatsächlich eine Datenträgeraktivität von fast dauerhaft 100%.
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1498954781
Url: https://administrator.de/forum/veeam-backup-nach-plattentausch-superlangsam-1498954781.html
Ausgedruckt am: 10.04.2025 um 10:04 Uhr
13 Kommentare
Neuester Kommentar
Moin,
die Toshiba nutzen SMR als Technik, iirc, d.h. die Spuren überlappen sich. Dadurch muß ggf. die Nachbarspur nochmal geschrieben werden, wenn eine Spur geschrieben wurde. Das bremst die Dinger bis fast zum Stand aus, wen man die für RAID nimmt (siehe z.B. https://www.elefacts.de/test-160-nas_festplatten_mit_smr_oder_cmr_ein_ue ..).
Du hast schlicht die falschen Platten für diesen Einsatzzweck.
lks
die Toshiba nutzen SMR als Technik, iirc, d.h. die Spuren überlappen sich. Dadurch muß ggf. die Nachbarspur nochmal geschrieben werden, wenn eine Spur geschrieben wurde. Das bremst die Dinger bis fast zum Stand aus, wen man die für RAID nimmt (siehe z.B. https://www.elefacts.de/test-160-nas_festplatten_mit_smr_oder_cmr_ein_ue ..).
Du hast schlicht die falschen Platten für diesen Einsatzzweck.
lks
Zitat von @Coreknabe:
Aber für meine Begriffe ist Write-Through performanter?
https://stackoverflow.com/questions/27087912/write-back-vs-write-through ...
Aber für meine Begriffe ist Write-Through performanter?
https://stackoverflow.com/questions/27087912/write-back-vs-write-through ...
Nein - nicht zwingend. Bei WT musst du warten bis die Platte das wirklich weggeschrieben hat (is normal wenn z.B. kein Batterie-Cache da is). Je mehr Daten da sind umso mehr Suchvorgänge hast du dann natürlich auch um freie Bereiche zu finden. Wenn du nen Cache hast schreibst da halt rein und die Platte macht wenn die soweit is, ohne wartest du. Wenn du viele kleine Daten hast dann wirds natürlich noch schlimmer weil der Kopf/die Köpfe erst mal fröhlich munter immer suchen...
Generell wird nen Cache immer schneller sein als nen direktes schreiben weil das eben über den RAM gepufftert wird welcher erheblich schneller ist als die langsame drehende Scheibe (ok, bei SSDs ggf. nich mehr wirklich ein unterschied). Grad grössere Speichersysteme haben hier ja aus gutem Grund oft die Option eines SSD-Caches drin.
Aber normalerweise schaltet man den Cache der einzelnen Platten im RAID ab, so kenne ich es auch. Der Cache für den RAID ist dann eine eigenständige SSD.
Du kopierst aber auch große Datenmengen, da ist dann Cache egal, da passt eh nicht alles rein. Die Platte fällt also auf Schreibgeschwindigkeit zurück. Aus meiner Sicht kann der Cache nicht das Problem sein, ich würde ihn erstmal ganz abschalten um konstante Ergebnisse zu erzielen.
Von SMR wird definitiv in RAIDs abgeraten, ich wusste gar nicht das es "Enterprise" Platten mit SMR gibt... Ob das soviel ausmacht kann ich nicht sagen. Aber die Platte ist definitiv nicht RAID geeignet.
Du kopierst aber auch große Datenmengen, da ist dann Cache egal, da passt eh nicht alles rein. Die Platte fällt also auf Schreibgeschwindigkeit zurück. Aus meiner Sicht kann der Cache nicht das Problem sein, ich würde ihn erstmal ganz abschalten um konstante Ergebnisse zu erzielen.
Von SMR wird definitiv in RAIDs abgeraten, ich wusste gar nicht das es "Enterprise" Platten mit SMR gibt... Ob das soviel ausmacht kann ich nicht sagen. Aber die Platte ist definitiv nicht RAID geeignet.
Zitat von @ukulele-7:
Aber normalerweise schaltet man den Cache der einzelnen Platten im RAID ab, so kenne ich es auch. Der Cache für den RAID ist dann eine eigenständige SSD.
Aber normalerweise schaltet man den Cache der einzelnen Platten im RAID ab, so kenne ich es auch. Der Cache für den RAID ist dann eine eigenständige SSD.
Kenne ich überhaupt nicht so. "Normalerweise" Plattencache AN und Raid Cache AN, BBU an den Controller und USV an den Server, dann passiert hier auch nichts.
Du kopierst aber auch große Datenmengen, da ist dann Cache egal, da passt eh nicht alles rein. Die Platte fällt also auf Schreibgeschwindigkeit zurück.
Genau DANN brauchst Du den Plattencache, sonst kannst Du die Bits auch gleich selber schneller mit Lupe und Magnet auf die Platte schreiben. Ohne Plattencache ist die Schreibgeschwindigkeit sonst richtig mies.
cu,
ipzipzap
Hallo zusammen,
ich habe auch vor kurzem einen ganz ähnlichen Server als Backup für Proxmox eingerichtet und ebenfalls 4 Platten Toshiba MG04ACA verbaut. Ich hatte extra geschaut, dass ich HDDs mit CMR Verfahren kaufe. Dabei kam ich genau auf den Typ, denn bei Heise wird dort nämlich CMR angegeben, siehe Bild!
Mir wäre jetzt auch nicht aufgefallen, dass dieser Raid Verbund langsam wäre und ich komme auch annähernd auf die 100 MByte beim Kopieren. Schwankt so zwischen 85 - 108 MByte.
Ich habe allerdings den WB-Cache schon aktiviert, eine BBU ist ebenfalls dran. USV sollte ich langsam mal anschließen........
Grüße - Markus
ich habe auch vor kurzem einen ganz ähnlichen Server als Backup für Proxmox eingerichtet und ebenfalls 4 Platten Toshiba MG04ACA verbaut. Ich hatte extra geschaut, dass ich HDDs mit CMR Verfahren kaufe. Dabei kam ich genau auf den Typ, denn bei Heise wird dort nämlich CMR angegeben, siehe Bild!
Mir wäre jetzt auch nicht aufgefallen, dass dieser Raid Verbund langsam wäre und ich komme auch annähernd auf die 100 MByte beim Kopieren. Schwankt so zwischen 85 - 108 MByte.
Ich habe allerdings den WB-Cache schon aktiviert, eine BBU ist ebenfalls dran. USV sollte ich langsam mal anschließen........
Grüße - Markus
Zitat von @ipzipzap:
Kenne ich überhaupt nicht so. "Normalerweise" Plattencache AN und Raid Cache AN, BBU an den Controller und USV an den Server, dann passiert hier auch nichts.
Was passiert denn mit den Daten im Platten Cache wenn dein Strom ausfällt? Die sind vermutlich weg, deine HDDs hängen ja nicht am BBU.Zitat von @ukulele-7:
Aber normalerweise schaltet man den Cache der einzelnen Platten im RAID ab, so kenne ich es auch. Der Cache für den RAID ist dann eine eigenständige SSD.
Aber normalerweise schaltet man den Cache der einzelnen Platten im RAID ab, so kenne ich es auch. Der Cache für den RAID ist dann eine eigenständige SSD.
Kenne ich überhaupt nicht so. "Normalerweise" Plattencache AN und Raid Cache AN, BBU an den Controller und USV an den Server, dann passiert hier auch nichts.
Zitat von @Coreknabe:
Was den Festplatten-Cache angeht, konnte ich keine großen Unterschiede (an / aus) erkennen, dürfte also eher zu vernachlässigen sein.
@4400667902
Nun mit dem selben Argument braucht auch der RAID Controller keine BBU, ist ja dann auch an der USV. Das kann funktionieren wenn die USV sichergestellt ist, (also keine Einschränkungen wie ein Netzteil oder so), kann aber auch Probleme geben.Was den Festplatten-Cache angeht, konnte ich keine großen Unterschiede (an / aus) erkennen, dürfte also eher zu vernachlässigen sein.
@4400667902
Was passiert denn mit den Daten im Platten Cache wenn dein Strom ausfällt? Die sind vermutlich weg, deine HDDs hängen ja nicht am BBU.
Sollte doch aber egal sein, wenn eine USV dran hängt, dann bleibt der Strom ja ausreichend lang?Ich befasse mich nicht oft mit dem Thema aber wenn ich mir solche Systeme angeschaut habe war die klassische Konfiguration HDD Cache aus, fertig. Ich wüsste auch nicht was so ein 64MB Cache jetzt für einen Geschwindikeitszuwachs liefern soll wenn der RAID Controller irgendwo mit 8GB Cache um die Ecke kommt oder sogar ein SSD Cache dran hängt. Ich bin nicht allwissend aber wenn ich 1GB auf eine Platte ohne RAID Controller schreibe falle ich auf die Plattenschreibgeschwindigkeit zurück sobald der Platten-Cache voll ist, das kann ich gut mit ATTO nachvollziehen.
Zitat von @ukulele-7:
Ich befasse mich nicht oft mit dem Thema aber wenn ich mir solche Systeme angeschaut habe war die klassische Konfiguration HDD Cache aus, fertig. Ich wüsste auch nicht was so ein 64MB Cache jetzt für einen Geschwindikeitszuwachs liefern soll wenn der RAID Controller irgendwo mit 8GB Cache um die Ecke kommt oder sogar ein SSD Cache dran hängt. Ich bin nicht allwissend aber wenn ich 1GB auf eine Platte ohne RAID Controller schreibe falle ich auf die Plattenschreibgeschwindigkeit zurück sobald der Platten-Cache voll ist, das kann ich gut mit ATTO nachvollziehen.
Zitat von @Coreknabe:
Was den Festplatten-Cache angeht, konnte ich keine großen Unterschiede (an / aus) erkennen, dürfte also eher zu vernachlässigen sein.
@4400667902
Nun mit dem selben Argument braucht auch der RAID Controller keine BBU, ist ja dann auch an der USV. Das kann funktionieren wenn die USV sichergestellt ist, (also keine Einschränkungen wie ein Netzteil oder so), kann aber auch Probleme geben.Was den Festplatten-Cache angeht, konnte ich keine großen Unterschiede (an / aus) erkennen, dürfte also eher zu vernachlässigen sein.
@4400667902
Was passiert denn mit den Daten im Platten Cache wenn dein Strom ausfällt? Die sind vermutlich weg, deine HDDs hängen ja nicht am BBU.
Sollte doch aber egal sein, wenn eine USV dran hängt, dann bleibt der Strom ja ausreichend lang?Ich befasse mich nicht oft mit dem Thema aber wenn ich mir solche Systeme angeschaut habe war die klassische Konfiguration HDD Cache aus, fertig. Ich wüsste auch nicht was so ein 64MB Cache jetzt für einen Geschwindikeitszuwachs liefern soll wenn der RAID Controller irgendwo mit 8GB Cache um die Ecke kommt oder sogar ein SSD Cache dran hängt. Ich bin nicht allwissend aber wenn ich 1GB auf eine Platte ohne RAID Controller schreibe falle ich auf die Plattenschreibgeschwindigkeit zurück sobald der Platten-Cache voll ist, das kann ich gut mit ATTO nachvollziehen.
Moin,
das BBU-Cache ist ganz einfach: Die Batterie hält normalerweise den Cache für mehrere TAGE aktiv (teils sogar wochen). Solltest du in der Zeit den Server nich wieder aktiv haben brauchst du den vermutlich ja auch nich mehr ;). Wenn die Platten dann aktiv werden schreibt der Controller halt die Daten.
Beim Cache ist es ähnlich wie beim RAM: Zuviel gibt es nicht ;). Der Platten-Cache ist im Raid eher zweite Wahl - da der Controller ja erst mal die Daten aufteilen muss. Nehmen wir einfach mal nen Raid5 mit 3 Platten an: Da muss der Controller ja erst mal die Daten zwischen Platte 1+2 aufteilen UND die Checksumme dann für Platte 3 berechnen. Damit die Daten also in den Plattencache kommen können muss der Controller die auch erst mal haben. DA hilft dann bereits der Cache.
Und natürlich: Nen 8 GB-Cache hilft dir wenig wenn du ne 10 GB Datei bearbeitest. Nur: In den meisten Fällen sind die Daten ja eh eher kleiner. Und das du die vollständige Datei neu schreibst passiert sogar noch seltener. Hier kommt es jetzt ja auch z.B. auf die Nutzung an - und danach wählt man ja auch das Speichersystem aus. Wenn ich heute z.B. für nen Medien-Studio was machen würde bei dem die Daten durchaus mal einige zig GB haben würde ich sicher auch ein anderes System nutzen als bei nem normalen Office-Fileserver. Da wäre z.B. nen SSD-Cache dann eher meine Wahl - weil auch da sind heute flotte Platten mit 500GB+ nicht mehr so extrem teuer. Dann kann ich dahinter eben auch "günstigere" x TB-Platten packen die eben rotieren, ist dann auch nicht mehr Wild. Bei nem Office-Fileserver würde dagegen vermutlich der 8 GB Cache schon fast reichen (normales Office mit 10-20 Leuten), selbst da würde nen 128GB-SSD nich schaden, dann halt eher auf Lese-Zugriff optimiert (da die Chance ja hoch ist das die eher lesen als schreiben werden).
Aber generell ist es fast nie verkehrt nen Cache einzuschalten... Da gibt es nur sehr wenig Systeme die da an Leistung verlieren...