20
VEEAM-Backups auf NAS langsam
Hallo Community,
ich habe einen Kunden mit einem Server-Cluster, zwei Hosts, ein SAN, läuft mit VMware, vCenter Version 6.5.
Gesichert wird die Umgebung mit VEEAM 11 (11.0.1.1261), welches auf einem dedizierten Host läuft.
Sicherungsziel ist ein Repository, welches auf einem NAS liegt. Angebunden sind alle Komponenten an einen Gigabit-Switch via Kupfer. Gesichert wird reverse incremental, täglich.
Die Backups sind unglaublich langsam, wir sprechen von Geschwindigkeit vom 2MB/s bis max. ~10MB/s.
Zu Beginn war das Ganze natürlich schneller (~90-120MB/s), und ist nun aus mir unerklärlichen Gründen so langsam.
Durchgeführte Tests:
Hat von euch jemand eine Idee, warum das Kopieren von Dateien aufs NAS schnell (~120MB/s) ist, sichern in ein frisches Repository bei ~65MB/s, und ins "alte" Repository bei ~2-10MB/s liegt?
Die gesamte Umgebung hat mehrere Terrabyte, die Sicherungen laufen weit über 24h, und somit kann nicht täglich gesichert werden. Kann mir jemand einen Tipp geben, wie ich weiter vor gehen könnte?
Gruß
ITguy52
ich habe einen Kunden mit einem Server-Cluster, zwei Hosts, ein SAN, läuft mit VMware, vCenter Version 6.5.
Gesichert wird die Umgebung mit VEEAM 11 (11.0.1.1261), welches auf einem dedizierten Host läuft.
Sicherungsziel ist ein Repository, welches auf einem NAS liegt. Angebunden sind alle Komponenten an einen Gigabit-Switch via Kupfer. Gesichert wird reverse incremental, täglich.
Die Backups sind unglaublich langsam, wir sprechen von Geschwindigkeit vom 2MB/s bis max. ~10MB/s.
Zu Beginn war das Ganze natürlich schneller (~90-120MB/s), und ist nun aus mir unerklärlichen Gründen so langsam.
Durchgeführte Tests:
- Anlegen eines neuen Repositorys, welches lokal auf dem dedizierten Backupserver selbst liegt, und Sicherung dort hin -> schnell (~90MB/s), was für mich heißt, das Lesen der Daten vom Cluster ist nicht das Problem
- Kopieren von Dateien vom Backup-Server aufs Ziel-NAS -> schnell (~120MB/s), die Anbindung des NAS ist wohl auch nicht das Problem
- Anlegen eines neuen Repositorys auf dem NAS -> mäßig, hier konnte ich mit ca. ~65MB/s sichern, was mich ehrlich gesagt absolut nicht weiter bringt...
Hat von euch jemand eine Idee, warum das Kopieren von Dateien aufs NAS schnell (~120MB/s) ist, sichern in ein frisches Repository bei ~65MB/s, und ins "alte" Repository bei ~2-10MB/s liegt?
Die gesamte Umgebung hat mehrere Terrabyte, die Sicherungen laufen weit über 24h, und somit kann nicht täglich gesichert werden. Kann mir jemand einen Tipp geben, wie ich weiter vor gehen könnte?
Gruß
ITguy52
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6021770322
Url: https://administrator.de/contentid/6021770322
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
20 Kommentare
Neuester Kommentar
Hi,
im Veeam steht immer dabei, was bei der letzten Sicherung die Geschwindigkeit und wer das Bottleneck war.
Dort musst du ansetzen.
Klingt für mich nach Cache + SMR Platten.
Der Cache sorgt dafür, dass es am Anfang relativ zügig geht, sobald der Cache voll ist fällt die Übertragungsgeschwindigkeit stark ab.
SMR Platten sind beim ersten Beschreiben auch noch ganz ok, dann wirds extrem lahm.
Schau doch mal nach, welche HDDs in dem NAS drin sind.
Grundsätzlich wäre hilfreich: Welches NAS, welche Platten (SSD? HDD? Mit oder ohne Cache-SSD?) usw.
Gruß
Drohnald
im Veeam steht immer dabei, was bei der letzten Sicherung die Geschwindigkeit und wer das Bottleneck war.
Dort musst du ansetzen.
das Kopieren von Dateien aufs NAS schnell (~120Mbit/s)
Das wäre bei einer großen Datei und Gigabitanbindung auch schon viel zu wenig. Bei mehreren kleinen noch erklärbar.sichern in ein frisches Repository bei ~65Mbit/s,
Im Durchschnitt? Wie lange lief das?Klingt für mich nach Cache + SMR Platten.
Der Cache sorgt dafür, dass es am Anfang relativ zügig geht, sobald der Cache voll ist fällt die Übertragungsgeschwindigkeit stark ab.
SMR Platten sind beim ersten Beschreiben auch noch ganz ok, dann wirds extrem lahm.
Schau doch mal nach, welche HDDs in dem NAS drin sind.
Grundsätzlich wäre hilfreich: Welches NAS, welche Platten (SSD? HDD? Mit oder ohne Cache-SSD?) usw.
Gruß
Drohnald
Und die Backup Proxy sind auch vorhanden? Min. 1 VM pro host. Hast du daran gedacht?
Hi Drohnald,
als Bottleneck gibt Veeam bei den langsamen Sicherungen das Target an.
Beim NAS handelt es sich um ein Synology RS2418+, es sind zwölf WD Red 2TB SMR (WD20EFAX) im RAID6 verbaut.
Schneller als die 120Mbit/s war es noch nie (wenn mein Gedächtnis mich nicht täuscht).
als Bottleneck gibt Veeam bei den langsamen Sicherungen das Target an.
Beim NAS handelt es sich um ein Synology RS2418+, es sind zwölf WD Red 2TB SMR (WD20EFAX) im RAID6 verbaut.
Schneller als die 120Mbit/s war es noch nie (wenn mein Gedächtnis mich nicht täuscht).
Im Durchschnitt? Wie lange lief das?
Ich habe hier nur eine 100GB VM als Test gesichert, siehe Screenshot (hier wird tatsächlich nicht mehr das Target, sondern die Source als Bottleneck angegeben):Zitat von @Crusher79:
Und die Backup Proxy sind auch vorhanden? Min. 1 VM pro host. Hast du daran gedacht?
Und die Backup Proxy sind auch vorhanden? Min. 1 VM pro host. Hast du daran gedacht?
Uff, what? Ne, da ist nichts konfiguriert, aber meines Wissens wird das auch nicht benötigt? Das haben wir bei keinem Kunden konfiguriert, damit hatte ich bisher noch keinen Probleme...
Zitat von @Crusher79:
https://helpcenter.veeam.com/docs/backup/qsg_vsphere/vmware_setup_proxy. ...
https://helpcenter.veeam.com/docs/backup/vsphere/backup_proxy.html?ver=1 ...
https://helpcenter.veeam.com/docs/backup/qsg_vsphere/vmware_setup_proxy. ...
https://helpcenter.veeam.com/docs/backup/vsphere/backup_proxy.html?ver=1 ...
Okay, die schreiben hier wie man den Proxy aufsetzt. Aber notwendig ist er nicht oder?
Warum war das Backup dann mal schnell, ist es nun aber nicht mehr?
Warum ändert sich die Geschwindigkeit, wenn ich ein neues Repository anlege?
80 MB/s (NICHT MBit/s!) wären völlig in Ordnung.
40 GB wurden dabei übertragen, wenn dort ne 128GB SSD als Cache-Platte drin ist, wäre es erwartbar, dass bei einigen TB plötzlich die Geschwindigkeit massiv abfällt.
Evtl. reicht sogar der eingebaut >Cachce
Grundsätzlich werden SMR-Platten bei großen Datenmengen und der Zeit immer langsamer, weshalb diese Dinger für mich nichts in einer Business-Umgebung zu suchen haben.
Unterschied siehe hier: https://www.reichelt.de/magazin/ratgeber/smr-cmr-welche-festplatte-eigne ...
WD hatte vor ein paar Jahren bei WD RED einfach von CMR auf SMR umgestellt ohne was zu sagen, CMR gibt es nur noch bei der RED PLUS und RED PRO Reihe.
Ich persönlich würde die austauschen und die "alten" SMRs an Mitarbeiter verschenken. Können die vll. Urlaubsbilder drauf speichern.
Edit:
Zumindest wäre das meine Einschätzung.
40 GB wurden dabei übertragen, wenn dort ne 128GB SSD als Cache-Platte drin ist, wäre es erwartbar, dass bei einigen TB plötzlich die Geschwindigkeit massiv abfällt.
Evtl. reicht sogar der eingebaut >Cachce
Grundsätzlich werden SMR-Platten bei großen Datenmengen und der Zeit immer langsamer, weshalb diese Dinger für mich nichts in einer Business-Umgebung zu suchen haben.
Unterschied siehe hier: https://www.reichelt.de/magazin/ratgeber/smr-cmr-welche-festplatte-eigne ...
WD hatte vor ein paar Jahren bei WD RED einfach von CMR auf SMR umgestellt ohne was zu sagen, CMR gibt es nur noch bei der RED PLUS und RED PRO Reihe.
Ich persönlich würde die austauschen und die "alten" SMRs an Mitarbeiter verschenken. Können die vll. Urlaubsbilder drauf speichern.
Edit:
Warum ändert sich die Geschwindigkeit, wenn ich ein neues Repository anlege?
Entweder war es Zufall, weil die Datenmenge zum Sichern zu gering war (Test mit 40GB vs. TBs bei allen VMs), oder es musste nichts "rumgeschoben" werden, wie das bei SMR durchaus nötig ist, wenn dort bereits Daten sind.Zumindest wäre das meine Einschätzung.
1
https://forums.veeam.com/veeam-backup-replication-f2/read-this-first-fre ...
Da schon mal geschaut? Allgemein was die Flaschenhälse angeht....
Da schon mal geschaut? Allgemein was die Flaschenhälse angeht....
Mit welchem Protokoll sicherst du aufs NAS? SMB/CIFS oder NFS?
Ich würde auch als erstes die SMR Platten rauswerfen, die sind bzw. werden garantiert zum Problem werden ( v.a. wenn du ein Raid5 damit betreibst).
Edit: Erst jetzt gesehen, dass es ein Raid 6 ist ... also noch problematischer
Edit: Erst jetzt gesehen, dass es ein Raid 6 ist ... also noch problematischer
Hi,
zu allererst: Komm mal bitte mit MB/s und MBit/s klar, damit fängt die Basis an.
Damit hat Veeam Recht.
Dein Screenshot zeigen 71MB/s, das ist für deine NAS schon super. Ansonsten SSDs rein und den 10GBit/s-Uplink aktivieren.
VG
zu allererst: Komm mal bitte mit MB/s und MBit/s klar, damit fängt die Basis an.
Damit hat Veeam Recht.
Beim NAS handelt es sich um ein Synology RS2418+, es sind zwölf WD Red 2TB SMR (WD20EFAX) im RAID6 verbaut.
Die Festplatten sind für ein Datengrab ausgelegt, nicht als performantes Backupmedium.Schneller als die 120Mbit/s war es noch nie (wenn mein Gedächtnis mich nicht täuscht).
Wenn die NAS mit 1 GBit/s angeschlossen ist, sind 120MB/s das Maximum.Dein Screenshot zeigen 71MB/s, das ist für deine NAS schon super. Ansonsten SSDs rein und den 10GBit/s-Uplink aktivieren.
VG
1
Mal abgesehen von den fehlerhaften Angaben von MegaBit und MegaBytes (so was durcheinander zu hauen finde ich schon extremst peinlich )...
Bei einen 1Gbit Netzwerk kann man wenns alles gut läuft maximal 120 MegaBytes pro Sekunde durchjagen.
Will aber sicherlich niemand, weil dann bei nen Backup ansonsten von den Host gar nichts mehr gehen würde ( offene Snapshots von Veeam auf den VMs ohne Fehlermeldungen).
Proxys machen durchaus Sinn weil man schon mal nicht durch das Management Netzwerk eingeschränkt wird (max um die 20% also nur um die 200 Mbit) und noch ein bischen was rauskomprimiert werden kann durch den Proxy.
Zur Durchsatzangabe in Veeam, die sagt nichts zur "Sicherungsgeschwindigkeit" aus sondern zur Verarbeitungsgeschwindigkeit....da kann man bei einer VM ohne Veränderungen auch mal auf ein Gigabyte pro Sekunde kommen, obwohl das physikalisch nicht bei einen Gigabit Netzwerk möglich ist.
Dedizierter Backupserver ist auch schön und gut, aber wie ist der ausgestattet ?
Wenn er schon dediziert ist, warum wird auf ein NAS gesichert ?
Oder ist das nur eine dedizierte VM ?
Erfüllt der Server die Mindestvorgaben von Veeam ?
Wie ist das Netzwerk aufgebaut ?
Irgendwelche VLANS vorhanden ?
Wie werden die verarbeitet ?
War jemand faul und hats über die Firewall gemacht ?
Und Terrabyte grosse VMs und nur 1GBit ?
Schon mal an Restoretest oder Desaster Recovery gedacht ?
Bringt Dir ein Backup was wenn du nicht weisst ob du es nutzen kannst ?
Wie teuer ist es wenn das Recovery von einer einzigen VM mehrere Stunden dauert ?
70MegaBytes pro Sekunde Verarbeitungsgeschwindigkeit halte ich bei einen Gigabit Netzwerk für absolut akzeptabel, da würde ich keine Sekunde Zeit mit Optimierung verschwenden, weil jedes Stellschräubchen wo man da dreht etwas anderes kaputt macht. Veeam B&R mag in den Standard Einstellungen nicht optimal für alle Einsatzbereiche sein, aber was Optimierung angeht kann man nicht pauschal Empfehlungen geben.
Schon gar nicht wenn das Mindestmass an Einarbeitung wie hier gegeben ist.
Bei einen 1Gbit Netzwerk kann man wenns alles gut läuft maximal 120 MegaBytes pro Sekunde durchjagen.
Will aber sicherlich niemand, weil dann bei nen Backup ansonsten von den Host gar nichts mehr gehen würde ( offene Snapshots von Veeam auf den VMs ohne Fehlermeldungen).
Proxys machen durchaus Sinn weil man schon mal nicht durch das Management Netzwerk eingeschränkt wird (max um die 20% also nur um die 200 Mbit) und noch ein bischen was rauskomprimiert werden kann durch den Proxy.
Zur Durchsatzangabe in Veeam, die sagt nichts zur "Sicherungsgeschwindigkeit" aus sondern zur Verarbeitungsgeschwindigkeit....da kann man bei einer VM ohne Veränderungen auch mal auf ein Gigabyte pro Sekunde kommen, obwohl das physikalisch nicht bei einen Gigabit Netzwerk möglich ist.
Dedizierter Backupserver ist auch schön und gut, aber wie ist der ausgestattet ?
Wenn er schon dediziert ist, warum wird auf ein NAS gesichert ?
Oder ist das nur eine dedizierte VM ?
Erfüllt der Server die Mindestvorgaben von Veeam ?
Wie ist das Netzwerk aufgebaut ?
Irgendwelche VLANS vorhanden ?
Wie werden die verarbeitet ?
War jemand faul und hats über die Firewall gemacht ?
Und Terrabyte grosse VMs und nur 1GBit ?
Schon mal an Restoretest oder Desaster Recovery gedacht ?
Bringt Dir ein Backup was wenn du nicht weisst ob du es nutzen kannst ?
Wie teuer ist es wenn das Recovery von einer einzigen VM mehrere Stunden dauert ?
70MegaBytes pro Sekunde Verarbeitungsgeschwindigkeit halte ich bei einen Gigabit Netzwerk für absolut akzeptabel, da würde ich keine Sekunde Zeit mit Optimierung verschwenden, weil jedes Stellschräubchen wo man da dreht etwas anderes kaputt macht. Veeam B&R mag in den Standard Einstellungen nicht optimal für alle Einsatzbereiche sein, aber was Optimierung angeht kann man nicht pauschal Empfehlungen geben.
Schon gar nicht wenn das Mindestmass an Einarbeitung wie hier gegeben ist.
1
Hallo woenk0
Stimmt, der TO freut sich natürlich , wenn er hier nach Hilfe fragt, und ihn jemand derart an den virtuellen Pranger stellt! Ich finde deinen "Ton" ebenso extremst peinlich....., v.a. wurde er in den vorigen Antworten schon paarmal drauf hingewiesen.
Abgesehen davon hat der TO hauptsächlich gefragt , warum es am Anfang so schnell geht, und es plötzlich so langsam wurde.
Die 12 SMR Platten im Raid6 sind hier m.E. der größte Flaschenhals. Solange nicht Spuren überschrieben werden lief das Ganze warhrscheinlich relativ gut. Werden jetzt aber Spuren überschrieben dann werden die Platten unter der Belastung den Raid Controller die meiste Zeit warten lassen. Da hilft auch eine 10 Gbit Anbindung nicht viel.
Hier müssen "passende" Platten rein ( auf der Synology Webseite gibts eine HCL)
Das die Netzwerkanbindung mit 1Gbit bei den Datenmengen nicht optimal ist, ist wohl klar, aber man durchaus auch mehrere TB drüber sichern und restoren, wenn die Rahmenbedingungen stimmen ( Protokolle , Datenmengen ...etc)
Mit ShureBackup und InstantRecovery muss ich auch die Maschinen erstmal komplett zurücksichern, sondern starte die VM's direkt aus dem Backup raus. Das geht natürlich nicht mit diesen Platten und auch hier nur beschränkt auf wenige VMs, wenn diese gleichzeitig gestartet werden müssen. (Und dieses Szenario habe ich schon erfolgreich getestet).
Idealerweise wird die Synology hier auch mit 10Gbit angebunden.
Ich habe mir bei Veeam auch schon paarmal danebengegriffen, u.a. weil auch zwei Supporter verschiedene Meinungen hatten...
Grüße
Zitat von @WoenK0:
Mal abgesehen von den fehlerhaften Angaben von MegaBit und MegaBytes (so was durcheinander zu hauen finde ich schon extremst peinlich )...
Mal abgesehen von den fehlerhaften Angaben von MegaBit und MegaBytes (so was durcheinander zu hauen finde ich schon extremst peinlich )...
Stimmt, der TO freut sich natürlich , wenn er hier nach Hilfe fragt, und ihn jemand derart an den virtuellen Pranger stellt! Ich finde deinen "Ton" ebenso extremst peinlich....., v.a. wurde er in den vorigen Antworten schon paarmal drauf hingewiesen.
Abgesehen davon hat der TO hauptsächlich gefragt , warum es am Anfang so schnell geht, und es plötzlich so langsam wurde.
Die 12 SMR Platten im Raid6 sind hier m.E. der größte Flaschenhals. Solange nicht Spuren überschrieben werden lief das Ganze warhrscheinlich relativ gut. Werden jetzt aber Spuren überschrieben dann werden die Platten unter der Belastung den Raid Controller die meiste Zeit warten lassen. Da hilft auch eine 10 Gbit Anbindung nicht viel.
Hier müssen "passende" Platten rein ( auf der Synology Webseite gibts eine HCL)
Das die Netzwerkanbindung mit 1Gbit bei den Datenmengen nicht optimal ist, ist wohl klar, aber man durchaus auch mehrere TB drüber sichern und restoren, wenn die Rahmenbedingungen stimmen ( Protokolle , Datenmengen ...etc)
Mit ShureBackup und InstantRecovery muss ich auch die Maschinen erstmal komplett zurücksichern, sondern starte die VM's direkt aus dem Backup raus. Das geht natürlich nicht mit diesen Platten und auch hier nur beschränkt auf wenige VMs, wenn diese gleichzeitig gestartet werden müssen. (Und dieses Szenario habe ich schon erfolgreich getestet).
Idealerweise wird die Synology hier auch mit 10Gbit angebunden.
Ich habe mir bei Veeam auch schon paarmal danebengegriffen, u.a. weil auch zwei Supporter verschiedene Meinungen hatten...
Grüße
1
Moin.
SHR oder "natives" RAID6?
Generell würde ich um Parity-RAIDs immer einen möglichst großen Bogen machen und immer RAID1 oder RAID10 den Vorzug geben. Klar, kostet mehr, zahlt sich aber im täglichen Betrieb durch quasi Null-Administration aus. Fire and forget.
Cheers,
jsysde
Zitat von @ITguy52:
[...]Beim NAS handelt es sich um ein Synology RS2418+, es sind zwölf WD Red 2TB SMR (WD20EFAX) im RAID6 verbaut.
Und du stellst auf der Syno LUNs bereit, auf die Veeam zugreift? Oder SMB-Shares? NFS?[...]Beim NAS handelt es sich um ein Synology RS2418+, es sind zwölf WD Red 2TB SMR (WD20EFAX) im RAID6 verbaut.
SHR oder "natives" RAID6?
Generell würde ich um Parity-RAIDs immer einen möglichst großen Bogen machen und immer RAID1 oder RAID10 den Vorzug geben. Klar, kostet mehr, zahlt sich aber im täglichen Betrieb durch quasi Null-Administration aus. Fire and forget.
Cheers,
jsysde
Servus,
schau mal ins Log mit welcher Methode gesichert wird. Hot-Add oder NBD?
Ich tippe auf NBD.
Hier gab es mal ein paar Anpassungen und Restriktionen von Veeam und VMWare die dazu führen, dass über das MNGT Interface der Traffic beschnitten wird.
Mit einem virtuellen Veeam Proxy wird das umgangen und per Hot-Add gesichert. Dann auch wieder schnell.
Hört sich alles zumindest genau danach an... Wir sind auch darüber gestolpert.
Gruß und viel Erfolg
schau mal ins Log mit welcher Methode gesichert wird. Hot-Add oder NBD?
Ich tippe auf NBD.
Hier gab es mal ein paar Anpassungen und Restriktionen von Veeam und VMWare die dazu führen, dass über das MNGT Interface der Traffic beschnitten wird.
Mit einem virtuellen Veeam Proxy wird das umgangen und per Hot-Add gesichert. Dann auch wieder schnell.
Hört sich alles zumindest genau danach an... Wir sind auch darüber gestolpert.
Gruß und viel Erfolg
wenn er hier nach Hilfe fragt, und ihn jemand derart an den virtuellen Pranger stellt!
Bezogen auf ein Administrator Forum ist das aber schon nicht ganz falsch was der Kollege @WoenK0 da angemerkt hat! Den korrekten Umgang damit sollte man schon voraussetzen für eine fundierte Beschreibung.warum es am Anfang so schnell geht, und es plötzlich so langsam wurde.
Klassischer Sliding Windows Effekt. https://www.ibm.com/docs/de/spectrum-protect/8.1.8?topic=tuning-tcp-flow ...Und du stellst auf der Syno LUNs bereit, auf die Veeam zugreift? Oder SMB-Shares? NFS? SHR oder "natives" RAID6?
Hat der TO noch nicht geschafft zu beantworten... 
1
Sorry dafür, dass sich ein Fehler durch meine gesamte Frage bzgl. MB/MBits gezogen hat, ist nun korrigiert.
Angebunden ist das NAS via SMB.
Der dedizierte Backupserver ist tatsächlich ein weiterer physischer Host, Intel Bronze 3204, 16GB RAM, 2TB HDD, und erfüllt damit die Mindestvoraussetzungen von Veeam.
Angeschafft wurde das Backupsystem leider ohne mein Zutun, deshalb kann ich das nicht beantworten. Ich war zu diesem Zeitpunkt nicht für das Backupsystem/die Backups verantwortlich.
VLANs sind nicht vorhanden, getrennt sind die einzelnen Subnetze des Unternehmens über eine Firewall, sprich, hier wird mit physischen Netzen getrennt (nicht meine Entscheidung, wäre auch ein Fan von VLANs...)
Die Hosts und der Backuphost + NAS hängen aber im gleichen Subnetz, somit läuft kein Traffic über eine Firewall/Router, tatsächlich nur über einen (dummen/unkonfigurierten) Gigabit-Switch.
Die VMs sind nicht Terrabyte groß, die gesamte Umgebung hat diese Größe. Restore-Tests wurden bereits durchgeführt, hier gab es keine Geschwindigkeitsprobleme.
Leider läuft das tägliche Backup aber wie beschrieben nicht mit 70MB/s, sondern mit 2-10MB/s.
"Nativ".
Du hast Recht, es wird mit NBD gesichert. Dies muss dann aber bereits seit Beginn der Fall sein.
Ich werde mir das aber mal genauer ansehen, DANKE!
Generell möchte ich aber folgenden Themen auf die Ursache gehen:
Deshalb klingt das für mich soweit nach einer plausiblen Erklärung:
Ich werde im Laufe der Woche nochmal mit neuen Repositorys herum spielen, wenn eine VM in ein neues Repository schnell ist, interessiert es mich, ob es auch für die ganze Umgebung gilt. Ich werde mal die gesamte Umgebung in ein neues Repository sichern, und dann nochmal übers Ergebnis berichten.
Wenn das auch langsam ist, dann sind wir mit den Platten glaube ich auf einer guten Spur.
Danke schon mal an alle, die sich bisher konstruktiv beteiligt haben!
Gruß
Angebunden ist das NAS via SMB.
Zitat von @WoenK0:
Dedizierter Backupserver ist auch schön und gut, aber wie ist der ausgestattet ?
Wenn er schon dediziert ist, warum wird auf ein NAS gesichert ?
Oder ist das nur eine dedizierte VM ?
Erfüllt der Server die Mindestvorgaben von Veeam ?
Dedizierter Backupserver ist auch schön und gut, aber wie ist der ausgestattet ?
Wenn er schon dediziert ist, warum wird auf ein NAS gesichert ?
Oder ist das nur eine dedizierte VM ?
Erfüllt der Server die Mindestvorgaben von Veeam ?
Der dedizierte Backupserver ist tatsächlich ein weiterer physischer Host, Intel Bronze 3204, 16GB RAM, 2TB HDD, und erfüllt damit die Mindestvoraussetzungen von Veeam.
Angeschafft wurde das Backupsystem leider ohne mein Zutun, deshalb kann ich das nicht beantworten. Ich war zu diesem Zeitpunkt nicht für das Backupsystem/die Backups verantwortlich.
Zitat von @WoenK0:
Wie ist das Netzwerk aufgebaut ?
Irgendwelche VLANS vorhanden ?
Wie werden die verarbeitet ?
War jemand faul und hats über die Firewall gemacht ?
Wie ist das Netzwerk aufgebaut ?
Irgendwelche VLANS vorhanden ?
Wie werden die verarbeitet ?
War jemand faul und hats über die Firewall gemacht ?
VLANs sind nicht vorhanden, getrennt sind die einzelnen Subnetze des Unternehmens über eine Firewall, sprich, hier wird mit physischen Netzen getrennt (nicht meine Entscheidung, wäre auch ein Fan von VLANs...)
Die Hosts und der Backuphost + NAS hängen aber im gleichen Subnetz, somit läuft kein Traffic über eine Firewall/Router, tatsächlich nur über einen (dummen/unkonfigurierten) Gigabit-Switch.
Zitat von @WoenK0:
Und Terrabyte grosse VMs und nur 1GBit ?
Schon mal an Restoretest oder Desaster Recovery gedacht ?
Bringt Dir ein Backup was wenn du nicht weisst ob du es nutzen kannst ?
Wie teuer ist es wenn das Recovery von einer einzigen VM mehrere Stunden dauert ?
Und Terrabyte grosse VMs und nur 1GBit ?
Schon mal an Restoretest oder Desaster Recovery gedacht ?
Bringt Dir ein Backup was wenn du nicht weisst ob du es nutzen kannst ?
Wie teuer ist es wenn das Recovery von einer einzigen VM mehrere Stunden dauert ?
Die VMs sind nicht Terrabyte groß, die gesamte Umgebung hat diese Größe. Restore-Tests wurden bereits durchgeführt, hier gab es keine Geschwindigkeitsprobleme.
Zitat von @WoenK0:
70MegaBytes pro Sekunde Verarbeitungsgeschwindigkeit halte ich bei einen Gigabit Netzwerk für absolut akzeptabel, da würde ich keine Sekunde Zeit mit Optimierung verschwenden, weil jedes Stellschräubchen wo man da dreht etwas anderes kaputt macht. Veeam B&R mag in den Standard Einstellungen nicht optimal für alle Einsatzbereiche sein, aber was Optimierung angeht kann man nicht pauschal Empfehlungen geben.
70MegaBytes pro Sekunde Verarbeitungsgeschwindigkeit halte ich bei einen Gigabit Netzwerk für absolut akzeptabel, da würde ich keine Sekunde Zeit mit Optimierung verschwenden, weil jedes Stellschräubchen wo man da dreht etwas anderes kaputt macht. Veeam B&R mag in den Standard Einstellungen nicht optimal für alle Einsatzbereiche sein, aber was Optimierung angeht kann man nicht pauschal Empfehlungen geben.
Leider läuft das tägliche Backup aber wie beschrieben nicht mit 70MB/s, sondern mit 2-10MB/s.
"Nativ".
Zitat von @ElmerAcmeee:
Servus,
schau mal ins Log mit welcher Methode gesichert wird. Hot-Add oder NBD?
Ich tippe auf NBD.
Hier gab es mal ein paar Anpassungen und Restriktionen von Veeam und VMWare die dazu führen, dass über das MNGT Interface der Traffic beschnitten wird.
Mit einem virtuellen Veeam Proxy wird das umgangen und per Hot-Add gesichert. Dann auch wieder schnell.
Hört sich alles zumindest genau danach an... Wir sind auch darüber gestolpert.
Gruß und viel Erfolg
Servus,
schau mal ins Log mit welcher Methode gesichert wird. Hot-Add oder NBD?
Ich tippe auf NBD.
Hier gab es mal ein paar Anpassungen und Restriktionen von Veeam und VMWare die dazu führen, dass über das MNGT Interface der Traffic beschnitten wird.
Mit einem virtuellen Veeam Proxy wird das umgangen und per Hot-Add gesichert. Dann auch wieder schnell.
Hört sich alles zumindest genau danach an... Wir sind auch darüber gestolpert.
Gruß und viel Erfolg
Du hast Recht, es wird mit NBD gesichert. Dies muss dann aber bereits seit Beginn der Fall sein.
Ich werde mir das aber mal genauer ansehen, DANKE!
Generell möchte ich aber folgenden Themen auf die Ursache gehen:
Zitat von @IntelOutside:
Abgesehen davon hat der TO hauptsächlich gefragt , warum es am Anfang so schnell geht, und es plötzlich so langsam wurde.
Abgesehen davon hat der TO hauptsächlich gefragt , warum es am Anfang so schnell geht, und es plötzlich so langsam wurde.
Deshalb klingt das für mich soweit nach einer plausiblen Erklärung:
Zitat von @IntelOutside:
Die 12 SMR Platten im Raid6 sind hier m.E. der größte Flaschenhals. Solange nicht Spuren überschrieben werden lief das Ganze warhrscheinlich relativ gut. Werden jetzt aber Spuren überschrieben dann werden die Platten unter der Belastung den Raid Controller die meiste Zeit warten lassen. Da hilft auch eine 10 Gbit Anbindung nicht viel.
Hier müssen "passende" Platten rein ( auf der Synology Webseite gibts eine HCL)
Die 12 SMR Platten im Raid6 sind hier m.E. der größte Flaschenhals. Solange nicht Spuren überschrieben werden lief das Ganze warhrscheinlich relativ gut. Werden jetzt aber Spuren überschrieben dann werden die Platten unter der Belastung den Raid Controller die meiste Zeit warten lassen. Da hilft auch eine 10 Gbit Anbindung nicht viel.
Hier müssen "passende" Platten rein ( auf der Synology Webseite gibts eine HCL)
Ich werde im Laufe der Woche nochmal mit neuen Repositorys herum spielen, wenn eine VM in ein neues Repository schnell ist, interessiert es mich, ob es auch für die ganze Umgebung gilt. Ich werde mal die gesamte Umgebung in ein neues Repository sichern, und dann nochmal übers Ergebnis berichten.
Wenn das auch langsam ist, dann sind wir mit den Platten glaube ich auf einer guten Spur.
Danke schon mal an alle, die sich bisher konstruktiv beteiligt haben!
Gruß
Angebunden ist das NAS via SMB.
Keine gute Idee! SMB/CIFS ist durch die Verwendung sehr kleiner Pakete generell eine schlechte Wahl wenn es um Performance bei der Übertragung geht. NFS wäre da deutlich sinnvoller.
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
Die Lösung des Problems war -> neues Repository in Veeam erstellen.
Anbindung identisch, Quelle/Ziel identisch, aber das Backup ist wieder schnell.
Lediglich ein neues Repository (mit gleichen Settings!!) hat die Lösung gebracht.
Technischer Hintergrund ist mir ehrlich gesagt unbekannt.
Anbindung identisch, Quelle/Ziel identisch, aber das Backup ist wieder schnell.
Lediglich ein neues Repository (mit gleichen Settings!!) hat die Lösung gebracht.
Technischer Hintergrund ist mir ehrlich gesagt unbekannt.
1
