12
Backupplanung mit VEEAM und FC Tape Library
Hallo zusammen,
ich habe hier eine MSL2024 FC, ein Backup Storage von Synology (nicht FC fähig) und einen dedizierten Veeam Server.
Das momentane Netzwerk ist nicht in VLANs unterteilt und es besteht leider nur ein großes Netz, später soll alles über Core, Access- Layer und VLAN-Aufteilung laufen.
Das SAN besteht aus 3 ESX (zusammen 60VMs) und einer MSA, sowie 2 FC Switche + FC Tape Library. Insgesamt würde ich am liebsten den VEEAM-Server virtualisieren und die Tape Library an die VM hänger, wenn das möglich ist?
Wo würdet Ihr das Backup Storage platzieren? Leider bringt die Synology nur 10G Ethernet.
Besten Dank schon mal!
ich habe hier eine MSL2024 FC, ein Backup Storage von Synology (nicht FC fähig) und einen dedizierten Veeam Server.
Das momentane Netzwerk ist nicht in VLANs unterteilt und es besteht leider nur ein großes Netz, später soll alles über Core, Access- Layer und VLAN-Aufteilung laufen.
Das SAN besteht aus 3 ESX (zusammen 60VMs) und einer MSA, sowie 2 FC Switche + FC Tape Library. Insgesamt würde ich am liebsten den VEEAM-Server virtualisieren und die Tape Library an die VM hänger, wenn das möglich ist?
Wo würdet Ihr das Backup Storage platzieren? Leider bringt die Synology nur 10G Ethernet.
Besten Dank schon mal!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 347482
Url: https://administrator.de/forum/backupplanung-mit-veeam-und-fc-tape-library-347482.html
Ausgedruckt am: 31.03.2025 um 17:03 Uhr
12 Kommentare
Neuester Kommentar
Moin,
eine Möglichkeit wäre:
dedizierten Backupserver, welcher mit einer FC- sowie 10GBit Karte ausgestattet ist. Das würde ich in jedem Fall machen, denn wenn dir dein Cluster crasht, ist der VEEAM noch im Zugriff und mich nicht neu aufgesetzt werden. Mal abgesehen vom Import der DB mit den Inventory-Files der Library
Dann:
Die 10GBit sind ja nur "zu langsam", wenn du eine 16GBit FC-Infrastruktur betreibst und deine Bänder/ Drives die Daten schneller wie 10GBit verarbeiten können...
Gruß
em-pie
eine Möglichkeit wäre:
dedizierten Backupserver, welcher mit einer FC- sowie 10GBit Karte ausgestattet ist. Das würde ich in jedem Fall machen, denn wenn dir dein Cluster crasht, ist der VEEAM noch im Zugriff und mich nicht neu aufgesetzt werden. Mal abgesehen vom Import der DB mit den Inventory-Files der Library
Dann:
- Backup-Server und NAS via 10G miteinander verbinden
- Backup-Server und Library via FC miteinander verbinden
- Backup-Server per FC und der normalen NIC mit an die Infrastruktur.
- Backup-Server, NAS und Library sofern möglich an drei verschiedenen (Brand-)Abschnitten platzieren und fertig.
Die 10GBit sind ja nur "zu langsam", wenn du eine 16GBit FC-Infrastruktur betreibst und deine Bänder/ Drives die Daten schneller wie 10GBit verarbeiten können...
Gruß
em-pie
Okay perfekt, also kann ich problemlos den Server, bis ich 10G karten bekomme, per FC an die Library und per 1G an den Access Switch gehen.
Gern würde ich aber dennoch den Server Virtualisieren, natürlich unabhängig von der produktiv ESX Umgebung. So richtig bekomme ich aber das Tape Laufwerk dort nicht eingebunden. Hast du Erfahrung, wie ich FC in solch eine VM einbinde?
Gern würde ich aber dennoch den Server Virtualisieren, natürlich unabhängig von der produktiv ESX Umgebung. So richtig bekomme ich aber das Tape Laufwerk dort nicht eingebunden. Hast du Erfahrung, wie ich FC in solch eine VM einbinde?
Du kannst einen dedizierten FC Port (nicht die SAN Ports!) per Device Pass-Through an eine VM statisch anbinden.
Allerdings wird seitens VMware ein Tapedrive nicht supportet. Es ist also "Glückssache" ob diese Konstruktion funktioniert.
Ich empfehle Dir dringend, wie mein Vorschreiber em-pie, einen physikalischen Backup Server mit eigener FC Karte!
Ein "einfaches Gerät" reicht zumeist bereits aus...
Allerdings wird seitens VMware ein Tapedrive nicht supportet. Es ist also "Glückssache" ob diese Konstruktion funktioniert.
Ich empfehle Dir dringend, wie mein Vorschreiber em-pie, einen physikalischen Backup Server mit eigener FC Karte!
Ein "einfaches Gerät" reicht zumeist bereits aus...
Zitat von @Dr.EVIL:
Du kannst einen dedizierten FC Port (nicht die SAN Ports!) per Device Pass-Through an eine VM statisch anbinden.
Allerdings wird seitens VMware ein Tapedrive nicht supportet. Es ist also "Glückssache" ob diese Konstruktion funktioniert.
Okay, ich las nur, dass FC Tape bei ESX 5.0 nicht supportet ist.Du kannst einen dedizierten FC Port (nicht die SAN Ports!) per Device Pass-Through an eine VM statisch anbinden.
Allerdings wird seitens VMware ein Tapedrive nicht supportet. Es ist also "Glückssache" ob diese Konstruktion funktioniert.
Dann ist das alles in Ordnung, rum basteln werde ich nicht, dann kommt VEEAM eben auf einen DL 380 G7 mit FC karte. ( Ist eben bloß ein bissel schade um den G7)
Ich empfehle Dir dringend, wie mein Vorschreiber em-pie, einen physikalischen Backup Server mit eigener FC Karte!
Ein "einfaches Gerät" reicht zumeist bereits aus...
Hi
Du kannst aber einen oder mehrere Veeam Proxy(s) in deine VM Umgebung virtuell packen.
Der nimmt dir dann beim Backup die Last vom Hauptserver.
Würde bei so vielen VMs schon fast Sinn machen da ich davon ausgehe das du nur ein begrenztes Fenster zum sichern hast.
mit freundlichen Grüßen Nemesis
Du kannst aber einen oder mehrere Veeam Proxy(s) in deine VM Umgebung virtuell packen.
Der nimmt dir dann beim Backup die Last vom Hauptserver.
Würde bei so vielen VMs schon fast Sinn machen da ich davon ausgehe das du nur ein begrenztes Fenster zum sichern hast.
mit freundlichen Grüßen Nemesis
So viel haben wir dann doch nicht zu sichern, mir ist eigentlich bloß der DL 380 G7 als alleiniger VEEAM-Server zu schade. Vielleicht wäre es auch denkbar die MSL mit 10G Modulen auszustatten?
Theoretisch...
Allerdings können FC Ports nicht gemeinsam mit iSCSI Ports auf das gleiche Volume zugreifen.
Ausserdem wird die MSA nicht wie die StoreVirtual, StoreServ oder Nimble direkt von Veeam unterstützt.
Mit diesen Storages kannst Du direkt an der VSphere vorbei auf dem Storage einen Snapshot auslösen und diesen vom Storage über das SAN zum BackupStorage transportieren.
Bei der MSA wird der Snapshot Request "klassisch" von der Veeam Software an die Vsphere weitergeleitet, welche dann den Snapshot auf der MSA initiiert.
Der Snapshot wird dann über das ESX Server LAN zum Backup Server weitergeleitet.
Der Backupserver benötigt daher keinen SAN Anschluss. Ein möglichst performanter LAN Link zu den ESX Server muss hier ausreichen.
(Leider beherrscht Veeam m.W. immer noch kein Multistreaming über mehrer NIC Ports...)
Ich habe auf dem "physischen Backup Server" im übrigen alles installiert welches ich nicht virtualisieren kann, oder will (Z.B. den Vsphere Server)
Allerdings können FC Ports nicht gemeinsam mit iSCSI Ports auf das gleiche Volume zugreifen.
Ausserdem wird die MSA nicht wie die StoreVirtual, StoreServ oder Nimble direkt von Veeam unterstützt.
Mit diesen Storages kannst Du direkt an der VSphere vorbei auf dem Storage einen Snapshot auslösen und diesen vom Storage über das SAN zum BackupStorage transportieren.
Bei der MSA wird der Snapshot Request "klassisch" von der Veeam Software an die Vsphere weitergeleitet, welche dann den Snapshot auf der MSA initiiert.
Der Snapshot wird dann über das ESX Server LAN zum Backup Server weitergeleitet.
Der Backupserver benötigt daher keinen SAN Anschluss. Ein möglichst performanter LAN Link zu den ESX Server muss hier ausreichen.
(Leider beherrscht Veeam m.W. immer noch kein Multistreaming über mehrer NIC Ports...)
Ich habe auf dem "physischen Backup Server" im übrigen alles installiert welches ich nicht virtualisieren kann, oder will (Z.B. den Vsphere Server)
Zitat von @Dr.EVIL:
Theoretisch...
Allerdings können FC Ports nicht gemeinsam mit iSCSI Ports auf das gleiche Volume zugreifen.
Ausserdem wird die MSA nicht wie die StoreVirtual, StoreServ oder Nimble direkt von Veeam unterstützt.
Mit diesen Storages kannst Du direkt an der VSphere vorbei auf dem Storage einen Snapshot auslösen und diesen vom Storage über das SAN zum BackupStorage transportieren.
Bei der MSA wird der Snapshot Request "klassisch" von der Veeam Software an die Vsphere weitergeleitet, welche dann den Snapshot auf der MSA initiiert.
Der Snapshot wird dann über das ESX Server LAN zum Backup Server weitergeleitet.
Der Backupserver benötigt daher keinen SAN Anschluss. Ein möglichst performanter LAN Link zu den ESX Server muss hier ausreichen.
(Leider beherrscht Veeam m.W. immer noch kein Multistreaming über mehrer NIC Ports...)
Okay, die Idee war eigentlich alles in das SAN aufzunehmen.( Synology NAS als Backup Storage, VEEAM Backup Server + MSA und die Hosts)Theoretisch...
Allerdings können FC Ports nicht gemeinsam mit iSCSI Ports auf das gleiche Volume zugreifen.
Ausserdem wird die MSA nicht wie die StoreVirtual, StoreServ oder Nimble direkt von Veeam unterstützt.
Mit diesen Storages kannst Du direkt an der VSphere vorbei auf dem Storage einen Snapshot auslösen und diesen vom Storage über das SAN zum BackupStorage transportieren.
Bei der MSA wird der Snapshot Request "klassisch" von der Veeam Software an die Vsphere weitergeleitet, welche dann den Snapshot auf der MSA initiiert.
Der Snapshot wird dann über das ESX Server LAN zum Backup Server weitergeleitet.
Der Backupserver benötigt daher keinen SAN Anschluss. Ein möglichst performanter LAN Link zu den ESX Server muss hier ausreichen.
(Leider beherrscht Veeam m.W. immer noch kein Multistreaming über mehrer NIC Ports...)
Letztendlich habe ich nun das Problem, dass ich die Synology nicht ins SAN mit aufnehmen kann, könnte aber Link Aggregation auf der Synology betreiben.( Oder später zusätzlich per 10G) Meine momentane Testsicherung auf Band LTO6 beträgt konstante 106Mb/s, mehr geht nicht im 1G LAN. Hast du eine Idee, wie ich hier mehr performance rein bekomme? Die HBA kann ich am VEEAM Server wieder ausbauen. Es werden nämlich immer die Backups erst to disk gesichert und von Disk to Tape. Die Disk (Synology) ist ja momemtane nur mit 1G angeschlossen. ( 4 1G Ports +2 10GPorts hätte dieses Gerät)
Ich habe auf dem "physischen Backup Server" im übrigen alles installiert welches ich nicht virtualisieren kann, oder will (Z.B. den Vsphere Server)
Veeam ist zweifellos ein tolles Backup Programm - Allerdings sehr "spezialisiert" auf VSphere Umgebungen!
Sehr viel Funktionen die ein "konventionelles" Backup Programm üblicherweise (gegen den Einwurf kleiner Münzen
) beherrscht, kann Veeam (noch?) nicht.
Hierzu gehören neben dem "LAN- oder "Server- less" Backup über das (FC) SAN, welches nur bei einigen Storage Umgebungen von HPE, DellEMC und Netapp) unterstützt werden, das parallele Multistreaming von mehreren Datenquellen über unterschiedliche MAC-Adressen im LAN.
Daher sind die Möglichkeiten Veeam signifikant zu beschleunigen relativ gering.
Neben der Kompression der zu übertragenden Daten, einer möglichst breitbandigen und latenzarmen Verbindung zwischen den VSphere Hosts und dem Backup Storage, sowie der Anpassung der Stripesizegröße an das Backup Medium, bleibt nur die Geschwindigkeit des Sicherungsziels (Target) zu erhöhen.
Wenn dort allerdings nur ein paar SATA Drives mit 7.200 im RAID5/6 werkeln, ist hier natürlich wenig machbar...
Sehr viel Funktionen die ein "konventionelles" Backup Programm üblicherweise (gegen den Einwurf kleiner Münzen
) beherrscht, kann Veeam (noch?) nicht.Hierzu gehören neben dem "LAN- oder "Server- less" Backup über das (FC) SAN, welches nur bei einigen Storage Umgebungen von HPE, DellEMC und Netapp) unterstützt werden, das parallele Multistreaming von mehreren Datenquellen über unterschiedliche MAC-Adressen im LAN.
Daher sind die Möglichkeiten Veeam signifikant zu beschleunigen relativ gering.
Neben der Kompression der zu übertragenden Daten, einer möglichst breitbandigen und latenzarmen Verbindung zwischen den VSphere Hosts und dem Backup Storage, sowie der Anpassung der Stripesizegröße an das Backup Medium, bleibt nur die Geschwindigkeit des Sicherungsziels (Target) zu erhöhen.
Wenn dort allerdings nur ein paar SATA Drives mit 7.200 im RAID5/6 werkeln, ist hier natürlich wenig machbar...
Direct San komme ich nun auf 129mb/s beim Restore vom Tape raus und das ist glaube echt gut für lto6? Backup auf den Veeam Server kommt mit 500mb/s und auf die Synology rs3617xs+ mit 106mb/s konstant. später soll Veeam Server und Synology per 10g an den Core Switch und dann sollte die Geschwindigkeit noch etwas höher gehen. was sagst du dazu ?
Besten Dank!
Besten Dank!
Zitat von @Leo-le:
Direct San komme ich nun auf 129mb/s beim Restore vom Tape raus und das ist glaube echt gut für lto6?
Wenn man bedenkt, das LTO6 bis zu 400MB/s beherrscht: "Nicht wirklich" Direct San komme ich nun auf 129mb/s beim Restore vom Tape raus und das ist glaube echt gut für lto6?
Über eine 1Gbit/s TCP verbindung kann man etwa diesen Datenrate übertragen..
Backup auf den Veeam Server kommt mit 500mb/s und auf die Synology rs3617xs+ mit 106mb/s konstant. später soll Veeam Server und Synology per 10g an den Core Switch und dann sollte die Geschwindigkeit noch etwas höher gehen. was sagst du dazu ?
500MB/s ist für ein Storage mit 12 SATA Platten, das mit 10Gbit angeschlossen nicht schlecht!
Um die hier maximale zu transportierende Geschwindigkeit zu ermitteln arbeite ich gern mit einem "Null Devise" (/dev/null) oder, da bei Windows u.U. schwer zu mappen, mit einer RAM-Disk auf welche ich die Testdaden kopiere um die maximale Übetragungsgeschwindigkeit zu ermitteln.
Fällt die Übertragungsrate auf die tatsächlichen Medien geringer aus, ist der Fehler dort zu suchen (Z.B. zu schwache CPU, zu langsamer RAID Controller, falsch gewählter RAID Level, Konfigurationsfehler usw.usw.)
Zitat von @Dr.EVIL:
Über eine 1Gbit/s TCP verbindung kann man etwa diesen Datenrate übertragen..
160MB/s ohne Kompression dachte ichZitat von @Leo-le:
Direct San komme ich nun auf 129mb/s beim Restore vom Tape raus und das ist glaube echt gut für lto6?
Wenn man bedenkt, das LTO6 bis zu 400MB/s beherrscht: "Nicht wirklich" Direct San komme ich nun auf 129mb/s beim Restore vom Tape raus und das ist glaube echt gut für lto6?
Über eine 1Gbit/s TCP verbindung kann man etwa diesen Datenrate übertragen..
Backup auf den Veeam Server kommt mit 500mb/s und auf die Synology rs3617xs+ mit 106mb/s konstant. später soll Veeam Server und Synology per 10g an den Core Switch und dann sollte die Geschwindigkeit noch etwas höher gehen. was sagst du dazu ?
500MB/s ist für ein Storage mit 12 SATA Platten, das mit 10Gbit angeschlossen nicht schlecht!
Um die hier maximale zu transportierende Geschwindigkeit zu ermitteln arbeite ich gern mit einem "Null Devise" (/dev/null) oder, da bei Windows u.U. schwer zu mappen, mit einer RAM-Disk auf welche ich die Testdaden kopiere um die maximale Übetragungsgeschwindigkeit zu ermitteln.
Fällt die Übertragungsrate auf die tatsächlichen Medien geringer aus, ist der Fehler dort zu suchen (Z.B. zu schwache CPU, zu langsamer RAID Controller, falsch gewählter RAID Level, Konfigurationsfehler usw.usw.)
die 500MB sind nur auf den VEEAM Server gegangen, um probeweise direct SAN mal auszutesten. Momentan haben wir keine 10G Switche im Core Bereich, geschweige überhaupt einen Corebereich. Der wird erst 1QT kommen.
Zwecks der Messung mit zum Beispiel IOMETER frage ich mich immer, welche Daten ich dort eintrage. Momentane config ist dort 20mio max disk size, 16 outstanding io, 4K 100% read; 0% random, 20sex run time und 10sek ramp up time; Vielleicht kannst du mir hier noch einen Tipp geben?
Besten Dank vorab!
