yellowcake
Goto Top

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 face-smile
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 ... face-confused 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 ?

Content-Key: 93901513574

Url: https://administrator.de/contentid/93901513574

Printed on: July 24, 2024 at 22:07 o'clock

Member: kreuzberger
kreuzberger Jan 09, 2024 at 08:59:03 (UTC)
Goto Top
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
Member: radiogugu
radiogugu Jan 09, 2024 at 09:08:56 (UTC)
Goto Top
Zitat von @Yellowcake:
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 face-smile

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 ... face-confused 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
Member: DerMaddin
DerMaddin Jan 09, 2024 at 09:14:54 (UTC)
Goto Top
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.
Member: Penny.Cilin
Penny.Cilin Jan 09, 2024 at 09:24:43 (UTC)
Goto Top
Zitat von @Yellowcake:

Hallo zusammen
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.
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 face-smile
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?
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 ... face-confused 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.

Gruss Penny.
Member: DerMaddin
DerMaddin Jan 09, 2024 at 09:47:13 (UTC)
Goto Top
@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.
Member: gravelking
gravelking Jan 09, 2024 updated at 10:13:17 (UTC)
Goto Top
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
Member: DerMaddin
DerMaddin Jan 09, 2024 at 10:36:45 (UTC)
Goto Top
@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.
Member: ElmerAcmeee
ElmerAcmeee Jan 09, 2024 at 11:34:08 (UTC)
Goto Top
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
Member: em-pie
em-pie Jan 09, 2024 updated at 12:32:42 (UTC)
Goto Top
Moin,

Jetzt habe ich demnächst hier eine TapeLibrary mit 12x LTO9 Laufwerken stehen face-smile
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:
screenshot 2024-01-09 132028
screenshot 2024-01-09 132206---02

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
Member: Yellowcake
Yellowcake Jan 09, 2024 at 19:53:54 (UTC)
Goto Top
wow erst mal cool für so viel feedback face-smile

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 face-smile 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 ^^
Member: Yellowcake
Yellowcake Jan 09, 2024 at 19:56:55 (UTC)
Goto Top
Zitat von @Penny.Cilin:

Zitat von @Yellowcake:

Hallo zusammen
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.
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 face-confused

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 face-smile
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?

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 ... face-confused 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.

Gruss Penny.
Member: Yellowcake
Yellowcake Jan 09, 2024 at 19:57:43 (UTC)
Goto Top
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.

Danke, ja genau , aktuell greifen wir das so ab
Member: Yellowcake
Yellowcake Jan 09, 2024 updated at 20:00:17 (UTC)
Goto Top
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

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
fehlen dann nicht Daten im Backup, also ob man im großen sicher oder in vielen keinen, macht doch keinen unterschied , hmmm
Member: Yellowcake
Yellowcake Jan 09, 2024 at 20:06:13 (UTC)
Goto Top
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.

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.
Member: Yellowcake
Yellowcake Jan 09, 2024 at 20:14:26 (UTC)
Goto Top
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 ...?

habe ic oben schon was beschrieben face-smile

Ansonsten haben unsere Filer auch in Summe knapp 70 TB. Aufgeteilt in 8 Stück, wobei der größte davon 18TB hat.
dann hast du ja eine VBK mit 18 TB die dann nur über ein Laufwerk geschrieben wird... also genau den flaschenhals den ich gerade versuche zu verbessern face-smile

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 :p

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.
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


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
Member: Yellowcake
Yellowcake Jan 09, 2024 at 20:18:34 (UTC)
Goto Top
Zitat von @em-pie:

Moin,

Jetzt habe ich demnächst hier eine TapeLibrary mit 12x LTO9 Laufwerken stehen face-smile
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:
screenshot 2024-01-09 132028
screenshot 2024-01-09 132206---02
Die Option gibts meine ich aber nur im normalen Job , im File to Tape Job gibts das nicht, oder ich irre mich


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

so ähnlich sichern wir auch alles, bis auf so sonderlocken wie den Fileserver, den man leider so nicht wirklich sichern wenn es ein Cluster ist face-confused

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 face-smile
Member: Yellowcake
Yellowcake Jan 10, 2024 at 07:33:45 (UTC)
Goto Top
aktuell habe ich das cluster auf zwei Jobs aufgeteilt:
neues projekt
und hier die Laufwerke aufgeteilt:
neues projekt
das sieht dann auf der Fileebene in Veeam so aus:
neues projekt (1)

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 face-smile
wird nur ein albtraum bei einer totalen Wiederherstellung, weil man x Job zusammen popeln muss :p
neues projekt (2)
Member: ElmerAcmeee
ElmerAcmeee Jan 11, 2024 at 08:21:17 (UTC)
Goto Top
Moin,

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

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
Member: Dani
Dani Jan 11, 2024 updated at 16:49:14 (UTC)
Goto Top
Moin,
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
Member: Yellowcake
Yellowcake Jan 12, 2024 at 05:43:10 (UTC)
Goto Top
Zitat von @ElmerAcmeee:

Moin,

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

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... üüüübel
danke! ändere gerade den Aufbau und die Bestellung der SFP Module ab



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).

leider keine Chance, der Server muss 24/7 immer laufen.

Gruß und viel Erfolg
danke face-smile
Member: em-pie
em-pie Jan 12, 2024, updated at Jan 13, 2024 at 00:03:27 (UTC)
Goto Top
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 ...
Member: ElmerAcmeee
ElmerAcmeee Jan 12, 2024 at 07:57:32 (UTC)
Goto Top
Moin,
Quote from @Dani:

Moin,
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.

Ja, das stimmt. Ist ein anderer Ansatz
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 face-smile

Gruß und viel Erfolg