22
Veeam 11-12 - FileServerCluster - Tape
Hallo zusammen
ich habe eine frage an alle die mit Veeam einen FileServer sichern.
wie geht Ihr hier vor ?
Mir fällt es sehr schwer hier den richtigen weg zu finden.
ich habe hier einen Filserver-Cluster von 4 VMs mit schlappen 80TB Daten stehen. Diesen würde ich gerne sichern.
Aktuell greife ich den dem dem Windows Agent ab über zwei Jobs ab, um hier in den einzelnen Jobs die Laufwerke auszuwählen. Das Klappt ganz gut auf Disk zu sichern.
Wenn ich nun das auf Band runter schreiben will, kann ich das nur auf zwei Laufwerke aufteilen und die zwei Laufwerke brauchen gute 3-4 Wochen um den Spass runterzuschreiben.
Jetzt habe ich demnächst hier eine TapeLibrary mit 12x LTO9 Laufwerken stehen
Jetzt war meine Überlegung die File To Disk Funktion von Veeam zu nutzen um gleich über SMB/NFS die Daten aus dem Cluster abzugreifen. Diesen Job kann ich dann aber nicht anhängen an einen Tape job... Warum auch immer. Ich kann hier nur dann einen extra File To Tape Job erstellen und diesen dann auf Band schreiben lassen.
In den Optionen von File to Tape, sehe ich aber nichts mit Multi Laufwerken ...
gehe jetzt davon erst mal aus das er dann nur ein Laufwerk nutzten wird. Das wäre minimal schlecht würde ich behaupten.
daher die Frage, wie sichert ihr größere Fileserver mit Veeam ?
ich habe eine frage an alle die mit Veeam einen FileServer sichern.
wie geht Ihr hier vor ?
Mir fällt es sehr schwer hier den richtigen weg zu finden.
ich habe hier einen Filserver-Cluster von 4 VMs mit schlappen 80TB Daten stehen. Diesen würde ich gerne sichern.
Aktuell greife ich den dem dem Windows Agent ab über zwei Jobs ab, um hier in den einzelnen Jobs die Laufwerke auszuwählen. Das Klappt ganz gut auf Disk zu sichern.
Wenn ich nun das auf Band runter schreiben will, kann ich das nur auf zwei Laufwerke aufteilen und die zwei Laufwerke brauchen gute 3-4 Wochen um den Spass runterzuschreiben.
Jetzt habe ich demnächst hier eine TapeLibrary mit 12x LTO9 Laufwerken stehen
Jetzt war meine Überlegung die File To Disk Funktion von Veeam zu nutzen um gleich über SMB/NFS die Daten aus dem Cluster abzugreifen. Diesen Job kann ich dann aber nicht anhängen an einen Tape job... Warum auch immer. Ich kann hier nur dann einen extra File To Tape Job erstellen und diesen dann auf Band schreiben lassen.
In den Optionen von File to Tape, sehe ich aber nichts mit Multi Laufwerken ...
gehe jetzt davon erst mal aus das er dann nur ein Laufwerk nutzten wird. Das wäre minimal schlecht würde ich behaupten.daher die Frage, wie sichert ihr größere Fileserver mit Veeam ?
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: 93901513574
Url: https://administrator.de/forum/veeam-11-12-fileservercluster-tape-93901513574.html
Ausgedruckt am: 22.12.2024 um 18:12 Uhr
22 Kommentare
Neuester Kommentar
Hallo @Yellowcake
um die Performance der LTO-9 Laufwerke wirklich ausnutzen zu können solltest du auf jeden Fall zusehen, dass du eine sehr gute Netzwerkanbindung aller betreffenden Server hast, also LWL 10GBit.
Dann teile die die 80TB in sinnvolle kleinere Jobs auf und macht eben ToTape Jobs. Das läuft dann auch flott.
Kreuzberger
um die Performance der LTO-9 Laufwerke wirklich ausnutzen zu können solltest du auf jeden Fall zusehen, dass du eine sehr gute Netzwerkanbindung aller betreffenden Server hast, also LWL 10GBit.
Dann teile die die 80TB in sinnvolle kleinere Jobs auf und macht eben ToTape Jobs. Das läuft dann auch flott.
Kreuzberger
Zitat von @Yellowcake:
wie geht Ihr hier vor ?
Mir fällt es sehr schwer hier den richtigen weg zu finden.
wie geht Ihr hier vor ?
Mir fällt es sehr schwer hier den richtigen weg zu finden.
Morschen.
So wie du ihn einschlägst, klingt das erst einmal nicht verkehrt.
Wenn ich nun das auf Band runter schreiben will, kann ich das nur auf zwei Laufwerke aufteilen und die zwei Laufwerke brauchen gute 3-4 Wochen um den Spass runterzuschreiben.
Der Durchsatz ist nun mal schwer abhängig von Anbindung und der eingesetzten LTO Version in Band und Laufwerk.
Jetzt habe ich demnächst hier eine TapeLibrary mit 12x LTO9 Laufwerken stehen
Klingt gut.
Jetzt war meine Überlegung die File To Disk Funktion von Veeam zu nutzen um gleich über SMB/NFS die Daten aus dem Cluster abzugreifen.
Wie ist der VM Host, der Backup Server und eventuelles Storage angebunden? 1G, 10G, 25G?
Diesen Job kann ich dann aber nicht anhängen an einen Tape job... Warum auch immer. Ich kann hier nur dann einen extra File To Tape Job erstellen und diesen dann auf Band schreiben lassen.
In den Optionen von File to Tape, sehe ich aber nichts mit Multi Laufwerken ... gehe jetzt davon erst mal aus das er dann nur ein Laufwerk nutzten wird. Das wäre minimal schlecht würde ich behaupten.
In den Optionen von File to Tape, sehe ich aber nichts mit Multi Laufwerken ...
gehe jetzt davon erst mal aus das er dann nur ein Laufwerk nutzten wird. Das wäre minimal schlecht würde ich behaupten.Veeam weiß ja, wie viele Laufwerke vorhanden sind und ist eines gerade beschäftigt, wird das andere verwendet.
Gruß
Marc
Meinst du wirklich ein redundantes File Server Cluster oder einfach nur vier File Server, die für dich ein "Cluster" darstellen?
Bei dieser Datenmenge ist es empfehlenswert erst einen Backup Job auf ein Repository zu machen und dann einen Copy-to-Tape Job. Je nach Netzwerkbandbreite und I/O der Disks kann es sonst ein Flaschenhals werden direkt aufs Tape zu schreiben.
Unser File Server (ist nur eine VM, Daten liegen auf dem SAN) wird über einen normalen Backup Job gesichert. Hier sind nur die entsprechenden virtuellen Disks gewählt. Wenn möglich ist auch ein Snapshot-basiertes Backup von Vorteil, wenn dein Storage von Veeam unterstützt wird.
Bei dieser Datenmenge ist es empfehlenswert erst einen Backup Job auf ein Repository zu machen und dann einen Copy-to-Tape Job. Je nach Netzwerkbandbreite und I/O der Disks kann es sonst ein Flaschenhals werden direkt aufs Tape zu schreiben.
Unser File Server (ist nur eine VM, Daten liegen auf dem SAN) wird über einen normalen Backup Job gesichert. Hier sind nur die entsprechenden virtuellen Disks gewählt. Wenn möglich ist auch ein Snapshot-basiertes Backup von Vorteil, wenn dein Storage von Veeam unterstützt wird.
Hallo,
ich habe eine frage an alle die mit Veeam einen FileServer sichern.
Okay.
wie geht Ihr hier vor ?
Mir fällt es sehr schwer hier den richtigen weg zu finden.
ich habe hier einen Filserver-Cluster von 4 VMs mit schlappen 80TB Daten stehen. Diesen würde ich gerne sichern.
Hat jede VM 80 TB Daten? ist das die tägliche Sicherungsmenge zusammen, oder jedes einzelnen Servers?
Welches Sicherungsverfahren nutzt Du? Soweit ich weiß kann VEAAM inkrementelle Backups. So wie IBM TSM.
bei IBM TSM sichert man nur noch inkrementell. Somit ist die Sicherungsmenge / -zeit absehbar.
Alternative nutzt man blockbasierte Sicherung. Dann ist auch die Sicherung auf Band recht schnell.
Jetzt habe ich demnächst hier eine TapeLibrary mit 12x LTO9 Laufwerken stehen
Ist doch schon mal was. Allerdings hast Du Dir mal Gedanken gemacht, wie die Backupsoftware die Datensicherungen parallel auf mehreren Laufwerken verwaltet? Ich kenne unter IBM TSM Collocation. Ob es so etwas unter VEAAM gibt?
Gruss Penny.
ich habe eine frage an alle die mit Veeam einen FileServer sichern.
wie geht Ihr hier vor ?
Mir fällt es sehr schwer hier den richtigen weg zu finden.
ich habe hier einen Filserver-Cluster von 4 VMs mit schlappen 80TB Daten stehen. Diesen würde ich gerne sichern.
Welches Sicherungsverfahren nutzt Du? Soweit ich weiß kann VEAAM inkrementelle Backups. So wie IBM TSM.
bei IBM TSM sichert man nur noch inkrementell. Somit ist die Sicherungsmenge / -zeit absehbar.
Alternative nutzt man blockbasierte Sicherung. Dann ist auch die Sicherung auf Band recht schnell.
Aktuell greife ich den dem dem Windows Agent ab über zwei Jobs ab, um hier in den einzelnen Jobs die Laufwerke auszuwählen. Das Klappt ganz gut auf Disk zu sichern.
Backup-to-Disk-To-Tape ist das Stichwort. Wenn Du das mit blockbasierter Sicherung durchführst kommst Du in äquadenter zeit zum Ziel.Wenn ich nun das auf Band runter schreiben will, kann ich das nur auf zwei Laufwerke aufteilen und die zwei Laufwerke brauchen gute 3-4 Wochen um den Spass runterzuschreiben.
Wie gesagt solche Datenmengen nicht per File (Datei) sichern, sondern blockbasiert.Jetzt habe ich demnächst hier eine TapeLibrary mit 12x LTO9 Laufwerken stehen
Jetzt war meine Überlegung die File To Disk Funktion von Veeam zu nutzen um gleich über SMB/NFS die Daten aus dem Cluster abzugreifen. Diesen Job kann ich dann aber nicht anhängen an einen Tape job... Warum auch immer. Ich kann hier nur dann einen extra File To Tape Job erstellen und diesen dann auf Band schreiben lassen.
In den Optionen von File to Tape, sehe ich aber nichts mit Multi Laufwerken ... gehe jetzt davon erst mal aus das er dann nur ein Laufwerk nutzten wird. Das wäre minimal schlecht würde ich behaupten.
daher die Frage, wie sichert ihr größere Fileserver mit Veeam ?
Wie schon geschrieben nicht Dateibasiert, sondern blockbasiert.In den Optionen von File to Tape, sehe ich aber nichts mit Multi Laufwerken ...
gehe jetzt davon erst mal aus das er dann nur ein Laufwerk nutzten wird. Das wäre minimal schlecht würde ich behaupten.daher die Frage, wie sichert ihr größere Fileserver mit Veeam ?
Gruss Penny.
@penny.cillin jedes "bessere" Backup-Lösung kann VMs blockbasiert sichern. In Veeam heißt das CBT, dass aber, soweit mir bekannt, nur in VMware und Hyper-V funktioniert und die VM darf keine Snapshots besitzen.
Aber wenn der TO tatsächlich über den Windows Agent sichert, dann ist das zu 100% File Level.
Aber wenn der TO tatsächlich über den Windows Agent sichert, dann ist das zu 100% File Level.
Servus,
dir ist bewusst, das sich die Lizenzierung von Veeam in der Version 12 geändert hat?
Du benötigst jetzt pro 500GB an Daten (FileToTape) eine Lizenz für eine Instanz. Im Standard sind meines Wissens nach 4
Lizenzen erhalten.
Für deine 80TB wären also zusätzlich 156 Instanzen notwendig.
Wir sind auch darüber gestolpert. Hier der Link von Veeam zum Thema:
Veeam Instance Consumption
Da uns die Kosten zu hoch waren, haben wir jetzt unsere FileToTape Jobs geändert so das wir abteilungsbezogen das Backup machen. So haben wir nur 20 zusätzliche Lizenzen benötigt.
Grüße
dir ist bewusst, das sich die Lizenzierung von Veeam in der Version 12 geändert hat?
Du benötigst jetzt pro 500GB an Daten (FileToTape) eine Lizenz für eine Instanz. Im Standard sind meines Wissens nach 4
Lizenzen erhalten.
Für deine 80TB wären also zusätzlich 156 Instanzen notwendig.
Wir sind auch darüber gestolpert. Hier der Link von Veeam zum Thema:
Veeam Instance Consumption
Da uns die Kosten zu hoch waren, haben wir jetzt unsere FileToTape Jobs geändert so das wir abteilungsbezogen das Backup machen. So haben wir nur 20 zusätzliche Lizenzen benötigt.
Grüße
@gravelking: in welchen Fällen lohnt sich ein FileToTape Job noch? Ich meine Sicherung auf Band ist oft nur für längere Zeiträume (GFS-Prinzip oder Archiv) sinnvoll aber nicht für Szenarien wenn mal eine Datei/Ordner wiederhergestellt werden müssen. Vor allem nicht bei riesigen Datenmengen.
Wir sichern gar nicht auf Tape, da wir ein 3-2-1-0-0 System etabliert haben. Also Backup des ganzen Clusters (alle VMs) zu einem Linux-Repo mit Kopie zur zweiten Repo in einem anderen Gebäude (~300m entfernt). Die kritischen VMs werden darüber hinaus noch zu Wasbi S3 kopiert mit 30 Tagen Retention Policy. Dazu erfolgt noch GFS-Archivierung monatlich und jährlich.
Wir sichern gar nicht auf Tape, da wir ein 3-2-1-0-0 System etabliert haben. Also Backup des ganzen Clusters (alle VMs) zu einem Linux-Repo mit Kopie zur zweiten Repo in einem anderen Gebäude (~300m entfernt). Die kritischen VMs werden darüber hinaus noch zu Wasbi S3 kopiert mit 30 Tagen Retention Policy. Dazu erfolgt noch GFS-Archivierung monatlich und jährlich.
Moin,
kannst du das "File-Server Cluster" Konstrukt genauer beschreiben?
Beim Windows Cluster spricht man doch sonst von Shares oder Ressourcen (schon was länger her bei mir) und nicht von VMs...
Oder meinst du 4 Knoten?
Das ist dann wohl auch der Grund für den File-Copy Job ...?
Ansonsten haben unsere Filer auch in Summe knapp 70 TB. Aufgeteilt in 8 Stück, wobei der größte davon 18TB hat.
Flaschenhals beim Tape-Out ist das Backup-Repository. Das Tape LW / Library selber ist ja spezifiziert für die Geschwindigkeit. LTO9 = 400MB/s. Daran sollte es nicht scheitern.
12x LTO9 ist ja schon ne Nummer. Da muss das Repository auch entsprechend schnell sein.
Offtopic:
wir sind vor langer Zeit von dem Windows Cluster (DC, DHCP, File, SQL, Exchange) zu normalen / separaten VMs übergegangen. Nun über ein Jahrzehnt keinerlei Ausfälle. Die Verfügbarkeit gewährleisten wir über VMWare.
Gruß und viel Erfolg
kannst du das "File-Server Cluster" Konstrukt genauer beschreiben?
Beim Windows Cluster spricht man doch sonst von Shares oder Ressourcen (schon was länger her bei mir) und nicht von VMs...
Oder meinst du 4 Knoten?
Das ist dann wohl auch der Grund für den File-Copy Job ...?
Ansonsten haben unsere Filer auch in Summe knapp 70 TB. Aufgeteilt in 8 Stück, wobei der größte davon 18TB hat.
Flaschenhals beim Tape-Out ist das Backup-Repository. Das Tape LW / Library selber ist ja spezifiziert für die Geschwindigkeit. LTO9 = 400MB/s. Daran sollte es nicht scheitern.
12x LTO9 ist ja schon ne Nummer. Da muss das Repository auch entsprechend schnell sein.
Offtopic:
wir sind vor langer Zeit von dem Windows Cluster (DC, DHCP, File, SQL, Exchange) zu normalen / separaten VMs übergegangen. Nun über ein Jahrzehnt keinerlei Ausfälle. Die Verfügbarkeit gewährleisten wir über VMWare.
Gruß und viel Erfolg
Moin,
Wenn du/ ihr wirklich bald 12 Drives habt - da muss der TapeProxy aber auch ausreichend "Doppelwumms" haben, um alle Drives bedienen zu können sowie die Daten (von Disk) einzusammeln
Jetzt habe ich demnächst hier eine TapeLibrary mit 12x LTO9 Laufwerken stehen
Jetzt war meine Überlegung die File To Disk Funktion von Veeam zu nutzen um gleich über SMB/NFS die Daten aus dem Cluster abzugreifen. Diesen Job kann ich dann aber nicht anhängen an einen Tape job... Warum auch immer. Ich kann hier nur dann einen extra File To Tape Job erstellen und diesen dann auf Band schreiben lassen.
Du musst im MediaPool definieren, dass du mehrere Drives n utzen kannst/ willst. Im Tape-Job greifst du dann auf diesen MediaPool zu:Jetzt war meine Überlegung die File To Disk Funktion von Veeam zu nutzen um gleich über SMB/NFS die Daten aus dem Cluster abzugreifen. Diesen Job kann ich dann aber nicht anhängen an einen Tape job... Warum auch immer. Ich kann hier nur dann einen extra File To Tape Job erstellen und diesen dann auf Band schreiben lassen.
daher die Frage, wie sichert ihr größere Fileserver mit Veeam ?
unser Filer ist zwar mit seinen 1,5TB (inkl. Systempartition) überschaubar, aber grundsätzlich sichern wir alle virtuellen Server wie folgt:t- VMware-VMs liegen alle im SAN (FibreChannel)
- VEEAM sieht die LUNs des SANs ebenfalls (per FibreChannel)
- VEEAM holt sich die Daten per FC und CBT (inkrementell) und schiebt diese auf eine eigenen BackupStorage (ebenfalls FC)
- Veeam legt eine Kopie der BackupDaten im ImmutableBackup Repo ab.
- Veeam schiebt die Daten ebenso aufs Tape (letzer Job in der gesamten Kette).
- Tapes (LTO8) sind in einer IBM-Library (TS4300 / 3 Drives) untergebracht
- Flaschenhals beim 2Tape ist immer das Drive/ Tape (~ 50%) könnte aber auch sein, weil VEEAM mit 16GBit am FC hängt und die Drives zu je 8GBit
Wenn du/ ihr wirklich bald 12 Drives habt - da muss der TapeProxy aber auch ausreichend "Doppelwumms" haben, um alle Drives bedienen zu können sowie die Daten (von Disk) einzusammeln
wow erst mal cool für so viel feedback
um auf ein paar Fragen und Details noch ein zu gehen
Ja es ist ein Windows Cluster mit eingehangen LUNs über ein Multi Pfard 32G SAN
Die ESX Server haben aktuell 2x4 10G LAN Verbindungen.
Der Hardware Backupproxy greift über 2x25G LAN auf die ESX zu und hier haben wir noch mal zwei Virtuelle Proxy laufen, damit wir nicht über die Managment verbindung von VMware zugreifen.
Dieses Jahr wird aber alles auf 2x4 25G im LAN geupdatet :D
also da habe ich keinen flaschen hals. Generell habe ich keinen Flaschenhals
Das Problem besteht ja bei einem Cluster, das er sich die LUN abgreift und dann je nach zustand des klasters die in die VM umhängt.
Das führt dazu wenn ich peer Veeam ganz normal die VMs abgreife, ich die Lun mal in der VM sicher und mal wo anders irgend wann. Führt dazu das die Daten mehrmals im Job gesichert sind und das bei 80TB kommt doof. Auch wenn man was wiederherstellen will darf man suchen , ist irgendwie nicht ideal... ich weiß nicht ob sich hier bei Veeam 12 was mit Cluster sicherung geändert hat ...
Und die lösung die ich gerade mache, nur die Laufwerke in Jobs abgreife, geht, problem wenn ein Laufwerk relativ groß ist, erstellt er hier eine riesen VBK Datei. und da komme ich wieder auf das grund Problem:
Wenn Veeam was auf Tape schreiben will von einem Backupjob, dann kann er hier Multi Laufwerke nutzten, schreibt aber dann die einzelne VBK Datei auf jeweils ein Laufwerk. Veeam kann keine VBK Datei auf zwei laufwerke aufteilen. Macht ja auch eigl sinn.
Wenn man jetzt viele VMs hat, die alle so 500GB groß sind, dann macht das spass weil jede VM eine VBK Datei ist und die schön auf x LAufwerke verteilt werden können Jetzt kommt man aber mit einer 20TB VBK Datei um die ecke und dann sieht der spass leider doof auf, weil die prübelt er dann über ein Laufwerk. Da das Laufwerk 300MB/s macht dauert das was :p
daher die idee mit dem File to Disk und dann das auf Tape.
ABER...
Wenn man File to Disk macht, kann man hier keinen Tape Job anknüpfen der das dann auf Tape schreibt.
Hier ist nur die möglichkeit, File to Tape von SMB oder File to Tape und man schaut auf dem Repro Server nach wie der File to Disk job hingeschrieben hat und greift das wieder ab.
Hier ist aber das Problem, wenn sich was ändert, muss man das immer im Hinterkopf haben.
und da wir ein Scalout Repro nutzen mit ein paar mehr speicherplätzen wandert das hier auch wieder wie wild automatisch rum und man kann das gleich vergessen hier den Pfard hart zu hinterlegen.
Problem ist, ich kann schwer mal eben 80TB mal so zum spass sichern ^^
um auf ein paar Fragen und Details noch ein zu gehen
Ja es ist ein Windows Cluster mit eingehangen LUNs über ein Multi Pfard 32G SAN
Die ESX Server haben aktuell 2x4 10G LAN Verbindungen.
Der Hardware Backupproxy greift über 2x25G LAN auf die ESX zu und hier haben wir noch mal zwei Virtuelle Proxy laufen, damit wir nicht über die Managment verbindung von VMware zugreifen.
Dieses Jahr wird aber alles auf 2x4 25G im LAN geupdatet :D
also da habe ich keinen flaschen hals. Generell habe ich keinen Flaschenhals
Das Problem besteht ja bei einem Cluster, das er sich die LUN abgreift und dann je nach zustand des klasters die in die VM umhängt.
Das führt dazu wenn ich peer Veeam ganz normal die VMs abgreife, ich die Lun mal in der VM sicher und mal wo anders irgend wann. Führt dazu das die Daten mehrmals im Job gesichert sind und das bei 80TB kommt doof. Auch wenn man was wiederherstellen will darf man suchen , ist irgendwie nicht ideal... ich weiß nicht ob sich hier bei Veeam 12 was mit Cluster sicherung geändert hat ...
Und die lösung die ich gerade mache, nur die Laufwerke in Jobs abgreife, geht, problem wenn ein Laufwerk relativ groß ist, erstellt er hier eine riesen VBK Datei. und da komme ich wieder auf das grund Problem:
Wenn Veeam was auf Tape schreiben will von einem Backupjob, dann kann er hier Multi Laufwerke nutzten, schreibt aber dann die einzelne VBK Datei auf jeweils ein Laufwerk. Veeam kann keine VBK Datei auf zwei laufwerke aufteilen. Macht ja auch eigl sinn.
Wenn man jetzt viele VMs hat, die alle so 500GB groß sind, dann macht das spass weil jede VM eine VBK Datei ist und die schön auf x LAufwerke verteilt werden können
Jetzt kommt man aber mit einer 20TB VBK Datei um die ecke und dann sieht der spass leider doof auf, weil die prübelt er dann über ein Laufwerk. Da das Laufwerk 300MB/s macht dauert das was :pdaher die idee mit dem File to Disk und dann das auf Tape.
ABER...
Wenn man File to Disk macht, kann man hier keinen Tape Job anknüpfen der das dann auf Tape schreibt.
Hier ist nur die möglichkeit, File to Tape von SMB oder File to Tape und man schaut auf dem Repro Server nach wie der File to Disk job hingeschrieben hat und greift das wieder ab.
Hier ist aber das Problem, wenn sich was ändert, muss man das immer im Hinterkopf haben.
und da wir ein Scalout Repro nutzen mit ein paar mehr speicherplätzen wandert das hier auch wieder wie wild automatisch rum und man kann das gleich vergessen hier den Pfard hart zu hinterlegen.
Problem ist, ich kann schwer mal eben 80TB mal so zum spass sichern ^^
Zitat von @Penny.Cilin:
Hallo,
ich habe eine frage an alle die mit Veeam einen FileServer sichern.
Okay.
wie geht Ihr hier vor ?
Mir fällt es sehr schwer hier den richtigen weg zu finden.
ich habe hier einen Filserver-Cluster von 4 VMs mit schlappen 80TB Daten stehen. Diesen würde ich gerne sichern.
Hat jede VM 80 TB Daten? ist das die tägliche Sicherungsmenge zusammen, oder jedes einzelnen Servers?
Welches Sicherungsverfahren nutzt Du? Soweit ich weiß kann VEAAM inkrementelle Backups. So wie IBM TSM.
bei IBM TSM sichert man nur noch inkrementell. Somit ist die Sicherungsmenge / -zeit absehbar.
Alternative nutzt man blockbasierte Sicherung. Dann ist auch die Sicherung auf Band recht schnell.
Hallo,
ich habe eine frage an alle die mit Veeam einen FileServer sichern.
wie geht Ihr hier vor ?
Mir fällt es sehr schwer hier den richtigen weg zu finden.
ich habe hier einen Filserver-Cluster von 4 VMs mit schlappen 80TB Daten stehen. Diesen würde ich gerne sichern.
Welches Sicherungsverfahren nutzt Du? Soweit ich weiß kann VEAAM inkrementelle Backups. So wie IBM TSM.
bei IBM TSM sichert man nur noch inkrementell. Somit ist die Sicherungsmenge / -zeit absehbar.
Alternative nutzt man blockbasierte Sicherung. Dann ist auch die Sicherung auf Band recht schnell.
Aktuell greife ich den dem dem Windows Agent ab über zwei Jobs ab, um hier in den einzelnen Jobs die Laufwerke auszuwählen. Das Klappt ganz gut auf Disk zu sichern.
Backup-to-Disk-To-Tape ist das Stichwort. Wenn Du das mit blockbasierter Sicherung durchführst kommst Du in äquadenter zeit zum Ziel.Ja frage ist wie setzte ich das in Veeam um und gibts vorraussetzungen an die LUN
Wenn ich nun das auf Band runter schreiben will, kann ich das nur auf zwei Laufwerke aufteilen und die zwei Laufwerke brauchen gute 3-4 Wochen um den Spass runterzuschreiben.
Wie gesagt solche Datenmengen nicht per File (Datei) sichern, sondern blockbasiert.Jetzt habe ich demnächst hier eine TapeLibrary mit 12x LTO9 Laufwerken stehen
schaue ich mir auf jeden fall mal an * danke*
Jetzt war meine Überlegung die File To Disk Funktion von Veeam zu nutzen um gleich über SMB/NFS die Daten aus dem Cluster abzugreifen. Diesen Job kann ich dann aber nicht anhängen an einen Tape job... Warum auch immer. Ich kann hier nur dann einen extra File To Tape Job erstellen und diesen dann auf Band schreiben lassen.
In den Optionen von File to Tape, sehe ich aber nichts mit Multi Laufwerken ... gehe jetzt davon erst mal aus das er dann nur ein Laufwerk nutzten wird. Das wäre minimal schlecht würde ich behaupten.
daher die Frage, wie sichert ihr größere Fileserver mit Veeam ?
Wie schon geschrieben nicht Dateibasiert, sondern blockbasiert.In den Optionen von File to Tape, sehe ich aber nichts mit Multi Laufwerken ...
gehe jetzt davon erst mal aus das er dann nur ein Laufwerk nutzten wird. Das wäre minimal schlecht würde ich behaupten.daher die Frage, wie sichert ihr größere Fileserver mit Veeam ?
Gruss Penny.
Zitat von @DerMaddin:
@penny.cillin jedes "bessere" Backup-Lösung kann VMs blockbasiert sichern. In Veeam heißt das CBT, dass aber, soweit mir bekannt, nur in VMware und Hyper-V funktioniert und die VM darf keine Snapshots besitzen.
Aber wenn der TO tatsächlich über den Windows Agent sichert, dann ist das zu 100% File Level.
@penny.cillin jedes "bessere" Backup-Lösung kann VMs blockbasiert sichern. In Veeam heißt das CBT, dass aber, soweit mir bekannt, nur in VMware und Hyper-V funktioniert und die VM darf keine Snapshots besitzen.
Aber wenn der TO tatsächlich über den Windows Agent sichert, dann ist das zu 100% File Level.
Danke, ja genau , aktuell greifen wir das so ab
Zitat von @gravelking:
Servus,
dir ist bewusst, das sich die Lizenzierung von Veeam in der Version 12 geändert hat?
Du benötigst jetzt pro 500GB an Daten (FileToTape) eine Lizenz für eine Instanz. Im Standard sind meines Wissens nach 4
Lizenzen erhalten.
Für deine 80TB wären also zusätzlich 156 Instanzen notwendig.
Wir sind auch darüber gestolpert. Hier der Link von Veeam zum Thema:
Veeam Instance Consumption
Servus,
dir ist bewusst, das sich die Lizenzierung von Veeam in der Version 12 geändert hat?
Du benötigst jetzt pro 500GB an Daten (FileToTape) eine Lizenz für eine Instanz. Im Standard sind meines Wissens nach 4
Lizenzen erhalten.
Für deine 80TB wären also zusätzlich 156 Instanzen notwendig.
Wir sind auch darüber gestolpert. Hier der Link von Veeam zum Thema:
Veeam Instance Consumption
Ja ich weiß die nehmen es von den lebenden :p aber beim Thema backup heißt es : geld spielt keine Rolex (fast)
Da uns die Kosten zu hoch waren, haben wir jetzt unsere FileToTape Jobs geändert so das wir abteilungsbezogen das Backup machen. So haben wir nur 20 zusätzliche Lizenzen benötigt.
Grüße
Zitat von @DerMaddin:
@gravelking: in welchen Fällen lohnt sich ein FileToTape Job noch? Ich meine Sicherung auf Band ist oft nur für längere Zeiträume (GFS-Prinzip oder Archiv) sinnvoll aber nicht für Szenarien wenn mal eine Datei/Ordner wiederhergestellt werden müssen. Vor allem nicht bei riesigen Datenmengen.
Wir sichern gar nicht auf Tape, da wir ein 3-2-1-0-0 System etabliert haben. Also Backup des ganzen Clusters (alle VMs) zu einem Linux-Repo mit Kopie zur zweiten Repo in einem anderen Gebäude (~300m entfernt). Die kritischen VMs werden darüber hinaus noch zu Wasbi S3 kopiert mit 30 Tagen Retention Policy. Dazu erfolgt noch GFS-Archivierung monatlich und jährlich.
@gravelking: in welchen Fällen lohnt sich ein FileToTape Job noch? Ich meine Sicherung auf Band ist oft nur für längere Zeiträume (GFS-Prinzip oder Archiv) sinnvoll aber nicht für Szenarien wenn mal eine Datei/Ordner wiederhergestellt werden müssen. Vor allem nicht bei riesigen Datenmengen.
Wir sichern gar nicht auf Tape, da wir ein 3-2-1-0-0 System etabliert haben. Also Backup des ganzen Clusters (alle VMs) zu einem Linux-Repo mit Kopie zur zweiten Repo in einem anderen Gebäude (~300m entfernt). Die kritischen VMs werden darüber hinaus noch zu Wasbi S3 kopiert mit 30 Tagen Retention Policy. Dazu erfolgt noch GFS-Archivierung monatlich und jährlich.
nicht mehr auf Tape sichern kommt nicht in frage, wir sichern auf zwei Ebenen (Repro & immutable Repro) auf Disk, und dann noch einmal auf Tape. Hintergrund ist der, alles was Online ist, kann auch angegriffen werden. Nur was Offline ist, ist sicher von veränderung.
Zitat von @ElmerAcmeee:
Moin,
kannst du das "File-Server Cluster" Konstrukt genauer beschreiben?
Beim Windows Cluster spricht man doch sonst von Shares oder Ressourcen (schon was länger her bei mir) und nicht von VMs...
Oder meinst du 4 Knoten?
Das ist dann wohl auch der Grund für den File-Copy Job ...?
Moin,
kannst du das "File-Server Cluster" Konstrukt genauer beschreiben?
Beim Windows Cluster spricht man doch sonst von Shares oder Ressourcen (schon was länger her bei mir) und nicht von VMs...
Oder meinst du 4 Knoten?
Das ist dann wohl auch der Grund für den File-Copy Job ...?
habe ic oben schon was beschrieben
Ansonsten haben unsere Filer auch in Summe knapp 70 TB. Aufgeteilt in 8 Stück, wobei der größte davon 18TB hat.
Flaschenhals beim Tape-Out ist das Backup-Repository.
ja, wenn die Hardware vom Repro eine Qnap ist, dann stimmt das, da wir hier aber nicht gerade eine Qnap nutzt haben wir hier keine Probleme, das Repro langweilt sich bei dem Taps :pDas Tape LW / Library selber ist ja spezifiziert für die Geschwindigkeit. LTO9 = 400MB/s. Daran sollte es nicht scheitern.
12x LTO9 ist ja schon ne Nummer. Da muss das Repository auch entsprechend schnell sein.
*brum Brum* :D
Offtopic:
wir sind vor langer Zeit von dem Windows Cluster (DC, DHCP, File, SQL, Exchange) zu normalen / separaten VMs übergegangen. Nun über ein Jahrzehnt keinerlei Ausfälle. Die Verfügbarkeit gewährleisten wir über VMWare.
bekomme ich die Windows Admin nie im leben von überzeugt :D
Gruß und viel Erfolg
danke :D
Zitat von @em-pie:
Moin,
Die Option gibts meine ich aber nur im normalen Job , im File to Tape Job gibts das nicht, oder ich irre michMoin,
Jetzt habe ich demnächst hier eine TapeLibrary mit 12x LTO9 Laufwerken stehen
Jetzt war meine Überlegung die File To Disk Funktion von Veeam zu nutzen um gleich über SMB/NFS die Daten aus dem Cluster abzugreifen. Diesen Job kann ich dann aber nicht anhängen an einen Tape job... Warum auch immer. Ich kann hier nur dann einen extra File To Tape Job erstellen und diesen dann auf Band schreiben lassen.
Du musst im MediaPool definieren, dass du mehrere Drives n utzen kannst/ willst. Im Tape-Job greifst du dann auf diesen MediaPool zu:Jetzt war meine Überlegung die File To Disk Funktion von Veeam zu nutzen um gleich über SMB/NFS die Daten aus dem Cluster abzugreifen. Diesen Job kann ich dann aber nicht anhängen an einen Tape job... Warum auch immer. Ich kann hier nur dann einen extra File To Tape Job erstellen und diesen dann auf Band schreiben lassen.
daher die Frage, wie sichert ihr größere Fileserver mit Veeam ?
unser Filer ist zwar mit seinen 1,5TB (inkl. Systempartition) überschaubar, aber grundsätzlich sichern wir alle virtuellen Server wie folgt:t- VMware-VMs liegen alle im SAN (FibreChannel)
- VEEAM sieht die LUNs des SANs ebenfalls (per FibreChannel)
- VEEAM holt sich die Daten per FC und CBT (inkrementell) und schiebt diese auf eine eigenen BackupStorage (ebenfalls FC)
- Veeam legt eine Kopie der BackupDaten im ImmutableBackup Repo ab.
- Veeam schiebt die Daten ebenso aufs Tape (letzer Job in der gesamten Kette).
- Tapes (LTO8) sind in einer IBM-Library (TS4300 / 3 Drives) untergebracht
- Flaschenhals beim 2Tape ist immer das Drive/ Tape (~ 50%) könnte aber auch sein, weil VEEAM mit 16GBit am FC hängt und die Drives zu je 8GBit
Wenn du/ ihr wirklich bald 12 Drives habt - da muss der TapeProxy aber auch ausreichend "Doppelwumms" haben, um alle Drives bedienen zu können sowie die Daten (von Disk) einzusammeln
Wumms haben wir
aktuell habe ich das cluster auf zwei Jobs aufgeteilt:
und hier die Laufwerke aufgeteilt:
das sieht dann auf der Fileebene in Veeam so aus:
und da sieht man auch die VBK Dateil :p
meine lösung ist jetzt, noch mehr Jobs zu erstellen und jedes Laufwerk zu einen Job machen um so mehrere kleinere VBK Datein zu bekommen. Diese kann man dann besser weg schreiben
wird nur ein albtraum bei einer totalen Wiederherstellung, weil man x Job zusammen popeln muss :p
und da sieht man auch die VBK Dateil :p
meine lösung ist jetzt, noch mehr Jobs zu erstellen und jedes Laufwerk zu einen Job machen um so mehrere kleinere VBK Datein zu bekommen. Diese kann man dann besser weg schreiben
wird nur ein albtraum bei einer totalen Wiederherstellung, weil man x Job zusammen popeln muss :p
Moin,
Trägt zwar nichts zur eigentlichen Lösung bei, aber ich glaube du verwechselst hier MByte/s mit Mbit/s
Mit theoretisch 12x 400MByte/s machst du nen 32Gbit/s FC dicht
bekomme ich die Windows Admin nie im leben von überzeugt :D
ein Versuch wäre es Wert. Aus meiner persönlichen Erfahrung mit Win 2008 und 2012 Cluster, war der Grund für eine Downtime immer das Cluster selber (Evtl ist es ja aber auch mittlerweile besser geworden).
Gruß und viel Erfolg
Quote from @Yellowcake:
naja, ist doch nix, sagen wir mal 400MB/s pro Laufwerk, wobei das schon echt die theorie ist. dann sind das 4,8G . kann man über ein 8G SAN prügeln. Wir haben aber ein 32G SAN und je Repro mit 2 verbindungen
*brum Brum* :D
naja, ist doch nix, sagen wir mal 400MB/s pro Laufwerk, wobei das schon echt die theorie ist. dann sind das 4,8G . kann man über ein 8G SAN prügeln. Wir haben aber ein 32G SAN und je Repro mit 2 verbindungen
*brum Brum* :D
Trägt zwar nichts zur eigentlichen Lösung bei, aber ich glaube du verwechselst hier MByte/s mit Mbit/s
Mit theoretisch 12x 400MByte/s machst du nen 32Gbit/s FC dicht
bekomme ich die Windows Admin nie im leben von überzeugt :D
Gruß und viel Erfolg
Moin,
Gruß,
Dani
wir sind vor langer Zeit von dem Windows Cluster (DC, DHCP, File, SQL, Exchange) zu normalen / separaten VMs übergegangen. Nun über ein Jahrzehnt keinerlei Ausfälle. Die Verfügbarkeit gewährleisten wir über VMWare.
das hängt von den Anforderungen ab. VMware kann keine Verfügbarkeit auf Applikationsebene abbilden. Ist auch nicht dessen Aufgabe.Gruß,
Dani
Zitat von @ElmerAcmeee:
Moin,
Trägt zwar nichts zur eigentlichen Lösung bei, aber ich glaube du verwechselst hier MByte/s mit Mbit/s
Mit theoretisch 12x 400MByte/s machst du nen 32Gbit/s FC dicht
Uh ha, du hast vollkommen recht, da hat sich hier bei uns ein Fehler eingeschlichen... üüüübelMoin,
Quote from @Yellowcake:
naja, ist doch nix, sagen wir mal 400MB/s pro Laufwerk, wobei das schon echt die theorie ist. dann sind das 4,8G . kann man über ein 8G SAN prügeln. Wir haben aber ein 32G SAN und je Repro mit 2 verbindungen
*brum Brum* :D
naja, ist doch nix, sagen wir mal 400MB/s pro Laufwerk, wobei das schon echt die theorie ist. dann sind das 4,8G . kann man über ein 8G SAN prügeln. Wir haben aber ein 32G SAN und je Repro mit 2 verbindungen
*brum Brum* :D
Trägt zwar nichts zur eigentlichen Lösung bei, aber ich glaube du verwechselst hier MByte/s mit Mbit/s
Mit theoretisch 12x 400MByte/s machst du nen 32Gbit/s FC dicht
danke! ändere gerade den Aufbau und die Bestellung der SFP Module ab
bekomme ich die Windows Admin nie im leben von überzeugt :D
leider keine Chance, der Server muss 24/7 immer laufen.
Gruß und viel Erfolg
Warum stellt ihr nicht auf DFS um und verteilt die Nutzdaten dann auf 2x2 oder 3x2 Server?
https://learn.microsoft.com/de-de/windows-server/storage/dfs-replication ...
Dann ist jeder Server etwas kleiner in der Sicherung und ihr müsst nicht solche Handstände machen.
Unter Veeam dann einen Job „Fileserver“, der in VMware tagbasiert die VMs holt und gut…
Edit: OK, DFS inkl. Relikation bietet kein echtes HA ggü. einem FileServer-Cluster...
https://www.reddit.com/r/sysadmin/comments/xa241g/dfs_vs_file_clustering ...
https://learn.microsoft.com/de-de/windows-server/storage/dfs-replication ...
Dann ist jeder Server etwas kleiner in der Sicherung und ihr müsst nicht solche Handstände machen.
Unter Veeam dann einen Job „Fileserver“, der in VMware tagbasiert die VMs holt und gut…
Edit: OK, DFS inkl. Relikation bietet kein echtes HA ggü. einem FileServer-Cluster...
https://www.reddit.com/r/sysadmin/comments/xa241g/dfs_vs_file_clustering ...
Moin,
In meinem Beispiel hieß das: 2 separate DCs, ab win 2016 DHCP Failover, Exchange DAG.
Und für Filer könnte man noch DFS-R nutzen. Wobei ich in den letzten 10 Jahre noch nie nen reinen Windows Filer habe crashen gesehen.
Und mit nem redundanten / gespiegelten SAN und VMWare Cluster hätte ich da auch keine Bedenken.
Aber, da müssen halt auch alle Beteiligten mitspielen. Der Teufel steckt im Detail
Gruß und viel Erfolg
Quote from @Dani:
Moin,
Ja, das stimmt. Ist ein anderer AnsatzMoin,
wir sind vor langer Zeit von dem Windows Cluster (DC, DHCP, File, SQL, Exchange) zu normalen / separaten VMs übergegangen. Nun über ein Jahrzehnt keinerlei Ausfälle. Die Verfügbarkeit gewährleisten wir über VMWare.
das hängt von den Anforderungen ab. VMware kann keine Verfügbarkeit auf Applikationsebene abbilden. Ist auch nicht dessen Aufgabe.In meinem Beispiel hieß das: 2 separate DCs, ab win 2016 DHCP Failover, Exchange DAG.
Und für Filer könnte man noch DFS-R nutzen. Wobei ich in den letzten 10 Jahre noch nie nen reinen Windows Filer habe crashen gesehen.
Und mit nem redundanten / gespiegelten SAN und VMWare Cluster hätte ich da auch keine Bedenken.
Aber, da müssen halt auch alle Beteiligten mitspielen. Der Teufel steckt im Detail
Gruß und viel Erfolg
