26
Veeam Immutable Repository
Guten Morgen,
ich plane zurzeit die Erneuerung unserer Veeam Backup-Infrastruktur, diese soll zukünftig folgendermaßen aussehen:
1. Lokales Backup auf den physikalischen Backup-Server im RZ
2. Backup Copy auf ein Immutable Storage an einem ca. 50 km entfernten Standort, angebunden über 400 MBit/s
3. Langzeit-Archivierung wöchentlich auf LTO9-Tapes
Die Datenmenge ist mit 7 TB Vollbackup überschaubar, die Änderungsrate ist ca. 150 GB pro Tag und benötigt so ca. eine Stunde für den Transfer auf das Immutable, wobei die Bandbreite jederzeit auf Gigabit anpassbar wäre.
Nun meine konzeptionelle Frage zu dem Immutable Storage:
Ich habe mir hierzu zwei Lösungen anbieten lassen:
1. Physikalischer Server mit ausreichend internen Festplatten
2. Physikalischer Server mit iSCSI-Storage
Die erste Variante nimmt die Komplexität aus der Infrastruktur und macht es auf den ersten Blick übersichtlicher.
Die zweite Variante scheint flexibler was die Dimensionierung des Speicherplatzes betrifft, jedoch wird eine iSCSI-Infrastruktur benötigt, also weitere Switche mit erhöhtem Ausfallrisiko und Management. Dazu kommt, dass die Infrastruktur komplett aus dem Netz gehalten werden soll, so dass ein Monitoring nur schwer möglich ist. Andererseits besteht die Möglichkeit an dem Standort einen DR-Host zu implementieren und diesen auch an das Storage anzubinden.
So, viel geschrieben und wenig entschieden… wie seht ihr das so?
ich plane zurzeit die Erneuerung unserer Veeam Backup-Infrastruktur, diese soll zukünftig folgendermaßen aussehen:
1. Lokales Backup auf den physikalischen Backup-Server im RZ
2. Backup Copy auf ein Immutable Storage an einem ca. 50 km entfernten Standort, angebunden über 400 MBit/s
3. Langzeit-Archivierung wöchentlich auf LTO9-Tapes
Die Datenmenge ist mit 7 TB Vollbackup überschaubar, die Änderungsrate ist ca. 150 GB pro Tag und benötigt so ca. eine Stunde für den Transfer auf das Immutable, wobei die Bandbreite jederzeit auf Gigabit anpassbar wäre.
Nun meine konzeptionelle Frage zu dem Immutable Storage:
Ich habe mir hierzu zwei Lösungen anbieten lassen:
1. Physikalischer Server mit ausreichend internen Festplatten
2. Physikalischer Server mit iSCSI-Storage
Die erste Variante nimmt die Komplexität aus der Infrastruktur und macht es auf den ersten Blick übersichtlicher.
Die zweite Variante scheint flexibler was die Dimensionierung des Speicherplatzes betrifft, jedoch wird eine iSCSI-Infrastruktur benötigt, also weitere Switche mit erhöhtem Ausfallrisiko und Management. Dazu kommt, dass die Infrastruktur komplett aus dem Netz gehalten werden soll, so dass ein Monitoring nur schwer möglich ist. Andererseits besteht die Möglichkeit an dem Standort einen DR-Host zu implementieren und diesen auch an das Storage anzubinden.
So, viel geschrieben und wenig entschieden… wie seht ihr das so?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator Dani am 02.01.2024 um 09:31:31 Uhr
Schicht im Schacht.
Content-ID: 7194842971
Url: https://administrator.de/forum/veeam-immutable-repository-7194842971.html
Ausgedruckt am: 25.12.2024 um 16:12 Uhr
26 Kommentare
Neuester Kommentar
In 2U passen über 24 Laufwerke. 1,8 oder 2,4TB Laufwerke und gut ist.
Reicht das nicht, hängst Du ein SAS Enclosure dran.
Eine 2,5" SAS HDD bringt im Schnitt 100IOPs und mehr.
Wie werden die Daten jetzt in der Produktivumgebung gespeichert?
SAN Copy ist keine Möglichkeit?
Reicht das nicht, hängst Du ein SAS Enclosure dran.
Eine 2,5" SAS HDD bringt im Schnitt 100IOPs und mehr.
Wie werden die Daten jetzt in der Produktivumgebung gespeichert?
SAN Copy ist keine Möglichkeit?
Moin,
Was genau wäre denn das iSCSI-Target? Ein Storage, welches auch anderen Systemen zur Verfügung steht?
Falls nein: das Storage direkt (ohne Switche) an den Immutable Repository Server hängen (10Gbit) und gut.
Dadurch, dass das Storage dann auch nur von dort erreichbar ist, ist es auch „sicher“.
Ansonsten: viele bzw. Große Platten in den Server und los geht's.
Edit:
Aber prinzipiell hast du natürlich recht.
Was genau wäre denn das iSCSI-Target? Ein Storage, welches auch anderen Systemen zur Verfügung steht?
Falls nein: das Storage direkt (ohne Switche) an den Immutable Repository Server hängen (10Gbit) und gut.
Dadurch, dass das Storage dann auch nur von dort erreichbar ist, ist es auch „sicher“.
Ansonsten: viele bzw. Große Platten in den Server und los geht's.
Edit:
In 2U passen über 24 Laufwerke. 1,8 oder 2,4TB Laufwerke und gut ist.
Setzt aber nen Passendem Controller und entsprechende Backplane voraus.Aber prinzipiell hast du natürlich recht.
Zitat von @8585324113:
Wie werden die Daten jetzt in der Produktivumgebung gespeichert?
SAN Copy ist keine Möglichkeit?
Wie werden die Daten jetzt in der Produktivumgebung gespeichert?
SAN Copy ist keine Möglichkeit?
Die Daten werden auf lokale Festplatten im Backupserver gesichert, insofern ist natürlich auch zu überlegen, ob das nicht dann auch für das Backup Copy ausreicht. Dieses soll nur für den DR-Fall genutzt werden, die Langzeitarchivierung erfolgt ja auf Tapes.
Zitat von @em-pie:
Was genau wäre denn das iSCSI-Target? Ein Storage, welches auch anderen Systemen zur Verfügung steht?
Falls nein: das Storage direkt (ohne Switche) an den Immutable Repository Server hängen (10Gbit) und gut.
Was genau wäre denn das iSCSI-Target? Ein Storage, welches auch anderen Systemen zur Verfügung steht?
Falls nein: das Storage direkt (ohne Switche) an den Immutable Repository Server hängen (10Gbit) und gut.
Zunächst würde es dediziert für das Immutable genutzt werden, ggf. später noch für einen DR-Host, aber dann kann man das neu überdenken. Mir war nicht klar, dass iSCSI bei einer 1:1-Verbindung auch ohne dazwischenliegenden Switchen supported ist. Ich könnte also zwei 10G-Ports des Servers mit den beiden Controllern des Storages direkt verbinden?
Zitat von @JoeDevlin:
Die Daten werden auf lokale Festplatten im Backupserver gesichert, insofern ist natürlich auch zu überlegen, ob das nicht dann auch für das Backup Copy ausreicht. Dieses soll nur für den DR-Fall genutzt werden, die Langzeitarchivierung erfolgt ja auf Tapes.
Zitat von @8585324113:
Wie werden die Daten jetzt in der Produktivumgebung gespeichert?
SAN Copy ist keine Möglichkeit?
Wie werden die Daten jetzt in der Produktivumgebung gespeichert?
SAN Copy ist keine Möglichkeit?
Die Daten werden auf lokale Festplatten im Backupserver gesichert, insofern ist natürlich auch zu überlegen, ob das nicht dann auch für das Backup Copy ausreicht. Dieses soll nur für den DR-Fall genutzt werden, die Langzeitarchivierung erfolgt ja auf Tapes.
Nein, wie werden jetzt die Daten gespeichert, bevor sie im Backup landen?
Zitat von @JoeDevlin:
Zunächst würde es dediziert für das Immutable genutzt werden, ggf. später noch für einen DR-Host, aber dann kann man das neu überdenken. Mir war nicht klar, dass iSCSI bei einer 1:1-Verbindung auch ohne dazwischenliegenden Switchen supported ist. Ich könnte also zwei 10G-Ports des Servers mit den beiden Controllern des Storages direkt verbinden?
Zitat von @em-pie:
Was genau wäre denn das iSCSI-Target? Ein Storage, welches auch anderen Systemen zur Verfügung steht?
Falls nein: das Storage direkt (ohne Switche) an den Immutable Repository Server hängen (10Gbit) und gut.
Was genau wäre denn das iSCSI-Target? Ein Storage, welches auch anderen Systemen zur Verfügung steht?
Falls nein: das Storage direkt (ohne Switche) an den Immutable Repository Server hängen (10Gbit) und gut.
Zunächst würde es dediziert für das Immutable genutzt werden, ggf. später noch für einen DR-Host, aber dann kann man das neu überdenken. Mir war nicht klar, dass iSCSI bei einer 1:1-Verbindung auch ohne dazwischenliegenden Switchen supported ist. Ich könnte also zwei 10G-Ports des Servers mit den beiden Controllern des Storages direkt verbinden?
Ja. Aber das Geld kann man besser anlegen.
Zitat von @8585324113:
Nein, wie werden jetzt die Daten gespeichert, bevor sie im Backup landen?
Nein, wie werden jetzt die Daten gespeichert, bevor sie im Backup landen?
Zurzeit auf einer Compellent, der per SAS an die ESXi- und an den Backup-Server angeschlossen ist. Das Backup erfolgt via DirectSAN aus Veeam.
Nun hast du mein Herz gewonnen.
Wie heißt die Compellent?
Wechsel auf Dell Data Domain ist warum aussortiert?
Du kannst dich beim Backupen massiv verbessern.
Wie heißt die Compellent?
Wechsel auf Dell Data Domain ist warum aussortiert?
Du kannst dich beim Backupen massiv verbessern.
Ich habe bisher nichts ausgeschlossen 🙂 Kannst du das etwas erläutern?
Gucke dir bitte mal die DD an, dann beantworte ich Fragen.
Nur so viel, sie ist dem Veeam haushoch überlegen.
Nur so viel, sie ist dem Veeam haushoch überlegen.
Hallo,
für was soll denn das Immutable nun sein? "Nur" Copy, oder auch für das 1. Backup?
Bei uns sind mittlerweile alle Backups auf Immutable Repos gespeichert. Egal ob Primary Backup oder Backupy Copy.
Bis letztes Jahr waren die Immutales Repos ISCSI Storages angebunden an einen Physischen Server. Mittlerweile und aufgrund der möglichen Angriffsfläche bestehen unsere Backup Repos aus mehrere phyischen Server mit 24 oder 36 3,5" HDD Platten ( >= 16 TB pro HDD) mit entsprechenden RAID Controllern.
Gesichert wird vom Proxy via FC.
Die Backupgeschwindigkeit ist ausreichend.
Welche Geschwindigkeit benötigst du denn beim Primary Backup? Das Copy Backup ist ja bei dir sowieso auf 400 MBit limitiert.
für was soll denn das Immutable nun sein? "Nur" Copy, oder auch für das 1. Backup?
Bei uns sind mittlerweile alle Backups auf Immutable Repos gespeichert. Egal ob Primary Backup oder Backupy Copy.
Bis letztes Jahr waren die Immutales Repos ISCSI Storages angebunden an einen Physischen Server. Mittlerweile und aufgrund der möglichen Angriffsfläche bestehen unsere Backup Repos aus mehrere phyischen Server mit 24 oder 36 3,5" HDD Platten ( >= 16 TB pro HDD) mit entsprechenden RAID Controllern.
Gesichert wird vom Proxy via FC.
Die Backupgeschwindigkeit ist ausreichend.
Welche Geschwindigkeit benötigst du denn beim Primary Backup? Das Copy Backup ist ja bei dir sowieso auf 400 MBit limitiert.
Man kann zwar ein Hardened Repository mit einem externen Storage aufbauen, aber empfohlen ist das nicht. Das liegt aber eher an der Angriffsfläche, da ein Angreifer über das Management die Backups, bzw das komplette Storage löschen könnte. Eine 1:1 Verbindung zum Repository Server würde das ganze zwar sicherer gestalten, aber warum den Aufwand machen? Bei eurer Backupgröße reicht ein kleiner physischer Server vollkommen aus.
Der Festplattentyp hängt von eurer gewünschten Performance im Restorefall ab. Wollt ihr nur die 400Mbit/1Gbit auslasten oder ggf. den Server vom zweiten Standort holen?
Was mich noch interessieren würde. Was plant ihr als primäres Backup Ziel und wo bindet ihr das LTO Drive ab?
Der Festplattentyp hängt von eurer gewünschten Performance im Restorefall ab. Wollt ihr nur die 400Mbit/1Gbit auslasten oder ggf. den Server vom zweiten Standort holen?
Was mich noch interessieren würde. Was plant ihr als primäres Backup Ziel und wo bindet ihr das LTO Drive ab?
Zitat von @tech-flare:
für was soll denn das Immutable nun sein? "Nur" Copy, oder auch für das 1. Backup?
für was soll denn das Immutable nun sein? "Nur" Copy, oder auch für das 1. Backup?
Das Immutable soll „nur“ für den Copy-Job sein, da wir den Veeam-Server physikalisch betreiben und dann die internen Festplatten für der erste Backup verwenden.
Welche Geschwindigkeit benötigst du denn beim Primary Backup? Das Copy Backup ist ja bei dir sowieso auf 400 MBit limitiert.
Das erste Backup sollte ist von der Geschwindigkeit ausreichend, hier haben wir ja aktuell den direkten Zugriff auf das Storage und das ist bei den Datenmengen völlig unproblematisch.
Zitat von @regnor:
Man kann zwar ein Hardened Repository mit einem externen Storage aufbauen, aber empfohlen ist das nicht. Das liegt aber eher an der Angriffsfläche, da ein Angreifer über das Management die Backups, bzw das komplette Storage löschen könnte. Eine 1:1 Verbindung zum Repository Server würde das ganze zwar sicherer gestalten, aber warum den Aufwand machen? Bei eurer Backupgröße reicht ein kleiner physischer Server vollkommen aus.
Man kann zwar ein Hardened Repository mit einem externen Storage aufbauen, aber empfohlen ist das nicht. Das liegt aber eher an der Angriffsfläche, da ein Angreifer über das Management die Backups, bzw das komplette Storage löschen könnte. Eine 1:1 Verbindung zum Repository Server würde das ganze zwar sicherer gestalten, aber warum den Aufwand machen? Bei eurer Backupgröße reicht ein kleiner physischer Server vollkommen aus.
Ist sehe das grundsätzlich auch so, das Management ist eher ein Risiko. Ein involvierter Dienstleister hat dieses Konzept ins Spiel gebracht um das Storage auch für ein DR-Szenario nutzen zu können.
Der Festplattentyp hängt von eurer gewünschten Performance im Restorefall ab. Wollt ihr nur die 400Mbit/1Gbit auslasten oder ggf. den Server vom zweiten Standort holen?
Im Restore-Fall würden wir den Server vom zweiten Standort holen um schneller wiederherstellen zu können. Ich würde daher sagen, dass wir die Festplatten/Controller bei internen Festplatten daran orientieren und nicht an den verhältnismäßig langsamen 400 MBit/s, daran kann sich die Schreibrate höchstens richten.
Was mich noch interessieren würde. Was plant ihr als primäres Backup Ziel und wo bindet ihr das LTO Drive ab?
Das primäre Backupziel ist ein Dell-Server mit ausreichend internen Festplatten, da steht aktuell noch die konkrete Konfiguration aus. Dort wird das LTO-Laufwerk angebunden, so ist es derzeit auch, nur soll der Server noch ausgetauscht werden.
Zitat von @8585324113:
Gucke dir bitte mal die DD an, dann beantworte ich Fragen.
Nur so viel, sie ist dem Veeam haushoch überlegen.
Gucke dir bitte mal die DD an, dann beantworte ich Fragen.
Nur so viel, sie ist dem Veeam haushoch überlegen.
Ich habe mir mal einen kurzen Überblick verschafft, es sieht auf alle Fälle nach mehr Komplexität aus, die ich gerne möglichst vermeiden möchte. Zu mehr fehlt mir gerade das Verständnis, inwieweit uns das gegenüber einem einfachen Server weiterhelfen wird.
Moin,
Gruß,
Dani
Im Restore-Fall würden wir den Server vom zweiten Standort holen um schneller wiederherstellen zu können.
an der Stelle seit erwähnt, dass evtl. das Netzwerk am Standort 1 vorbereitet werden muss. Gerade auf Hinblick, dass Standorte über Layer 3 verbunden sind und damit unterschiedliche IP Subnetze vorhanden sind. Ich würde daher sagen, dass wir die Festplatten/Controller bei internen Festplatten daran orientieren und nicht an den verhältnismäßig langsamen 400 MBit/s, daran kann sich die Schreibrate höchstens richten.
Eigentlich definiert man RPO und RTO und an Hand dessen erfolgt das Sizing der notwendigen Komponenten.Gruß,
Dani
Zitat von @JoeDevlin:
Ich habe mir mal einen kurzen Überblick verschafft, es sieht auf alle Fälle nach mehr Komplexität aus, die ich gerne möglichst vermeiden möchte. Zu mehr fehlt mir gerade das Verständnis, inwieweit uns das gegenüber einem einfachen Server weiterhelfen wird.
Zitat von @8585324113:
Gucke dir bitte mal die DD an, dann beantworte ich Fragen.
Nur so viel, sie ist dem Veeam haushoch überlegen.
Gucke dir bitte mal die DD an, dann beantworte ich Fragen.
Nur so viel, sie ist dem Veeam haushoch überlegen.
Ich habe mir mal einen kurzen Überblick verschafft, es sieht auf alle Fälle nach mehr Komplexität aus, die ich gerne möglichst vermeiden möchte. Zu mehr fehlt mir gerade das Verständnis, inwieweit uns das gegenüber einem einfachen Server weiterhelfen wird.
Warum Komplexität?
Du bekommst eine virtuelle oder physische Appliance, die in wenigen Stunden eingerichtet ist und dann mit unzähligen Backups eine lange Zeit lang immer effizienter wird.
Da steckt auch viel Compellent-EMC Know-How drin, über Kreuz drin.
Ich kenne beide Konzepte und kann sagen, dass die DD "günstiger" ist und einfacher. Günstiger in Bezug auf die Leistungsfähigkeit.
Außerdem ist es in Summe EIN Produkt mit entsprechenden Support.
Vielleicht reicht die Zeit für eine Leihstellung oder Demo.
Zitat von @JoeDevlin:
Ist sehe das grundsätzlich auch so, das Management ist eher ein Risiko. Ein involvierter Dienstleister hat dieses Konzept ins Spiel gebracht um das Storage auch für ein DR-Szenario nutzen zu können.
Das würde ich dann aber eher trennen, da es zwei unterschiedliche use Cases sind. Ein sicheres Backup Storage, und getrennt davon eine DR-Umgebung/Hardware. Nachdem ihr auch einen DR Host benötigen würdet, könntet ihr diesen auch gleich mit internen Disks ausstatten, auf welchen wiederhergestellt werden soll.Ist sehe das grundsätzlich auch so, das Management ist eher ein Risiko. Ein involvierter Dienstleister hat dieses Konzept ins Spiel gebracht um das Storage auch für ein DR-Szenario nutzen zu können.
Im Restore-Fall würden wir den Server vom zweiten Standort holen um schneller wiederherstellen zu können. Ich würde daher sagen, dass wir die Festplatten/Controller bei internen Festplatten daran orientieren und nicht an den verhältnismäßig langsamen 400 MBit/s, daran kann sich die Schreibrate höchstens richten.
Dann könnt ihr die Hardware so wählen, dass sie eure Anforderungen erfüllt.Das primäre Backupziel ist ein Dell-Server mit ausreichend internen Festplatten, da steht aktuell noch die konkrete Konfiguration aus. Dort wird das LTO-Laufwerk angebunden, so ist es derzeit auch, nur soll der Server noch ausgetauscht werden.
Alles klar. Ich wollte nur sicher gehen, dass das Laufwerk nicht am Hardened Repository hängen soll; das wäre Veeam seitig nämlich nicht möglich.
Ob ihr eine Deduplication Appliance benötigt, solltet ihr euch gut überlegen. Zwar sind diese als Appliance Lösung einfacher zu verwalten und können höhere Aufbewahrungszeiten erreichen, aber können auf der anderen Seite auch Nachteile mit sich bringen (Kosten, Performance, Erweiterbarkeit).
Zitat von @Dani:
an der Stelle seit erwähnt, dass evtl. das Netzwerk am Standort 1 vorbereitet werden muss. Gerade auf Hinblick, dass Standorte über Layer 3 verbunden sind und damit unterschiedliche IP Subnetze vorhanden sind.
an der Stelle seit erwähnt, dass evtl. das Netzwerk am Standort 1 vorbereitet werden muss. Gerade auf Hinblick, dass Standorte über Layer 3 verbunden sind und damit unterschiedliche IP Subnetze vorhanden sind.
Danke für den Hinweis, das muss mir ins Notfallkonzept, das ein entsprechendes VLAN vorbereitet ist und das Routing angepasst werden muss.
Eigentlich definiert man RPO und RTO und an Hand dessen erfolgt das Sizing der notwendigen Komponenten.
Ja, irgendeine auch wahr 🙂
Zitat von @regnor:
Das würde ich dann aber eher trennen, da es zwei unterschiedliche use Cases sind. Ein sicheres Backup Storage, und getrennt davon eine DR-Umgebung/Hardware. Nachdem ihr auch einen DR Host benötigen würdet, könntet ihr diesen auch gleich mit internen Disks ausstatten, auf welchen wiederhergestellt werden soll.
Das würde ich dann aber eher trennen, da es zwei unterschiedliche use Cases sind. Ein sicheres Backup Storage, und getrennt davon eine DR-Umgebung/Hardware. Nachdem ihr auch einen DR Host benötigen würdet, könntet ihr diesen auch gleich mit internen Disks ausstatten, auf welchen wiederhergestellt werden soll.
Genau zu der Meinung bin ich inzwischen, dank eures Feedbacks, auch gekommen! Das Konzept wäre dann recht simpel mit jeweils dedizierter Hardware für primäres und sekundäres Backup, falls ein DR-Host hinzukommt, dann ebenfalls dediziert. Die RTO und RPO werde ich intern diskutieren und dann entsprechend mit dem Dienstleister sizen.
Zitat von @8585324113:
Du bekommst eine virtuelle oder physische Appliance, die in wenigen Stunden eingerichtet ist und dann mit unzähligen Backups eine lange Zeit lang immer effizienter wird.
Da steckt auch viel Compellent-EMC Know-How drin, über Kreuz drin.
Du bekommst eine virtuelle oder physische Appliance, die in wenigen Stunden eingerichtet ist und dann mit unzähligen Backups eine lange Zeit lang immer effizienter wird.
Da steckt auch viel Compellent-EMC Know-How drin, über Kreuz drin.
Ich werde das mal mit betrachten, es muss letztendlich in unserer Umgebung und unser internes Know-how bzw. auch zu unseren Partnern passen. Es klingt interessant und ich lasse mich dazu mal beraten.
Ich danke euch allen für euer Feedback, das hat mir sehr geholfen!
Ich wünsche nun allen einen guten Rutsch in das neue Jahr!
Der Blick über den Tellerrand schadet nicht. Es skaliert auch wunderbar. Bzw ist die Skalierung schon fast verrückt. Wirklich endlos geiles Zeug.
Zitat von @8585324113:
Der Blick über den Tellerrand schadet nicht. Es skaliert auch wunderbar. Bzw ist die Skalierung schon fast verrückt. Wirklich endlos geiles Zeug.
Der Blick über den Tellerrand schadet nicht. Es skaliert auch wunderbar. Bzw ist die Skalierung schon fast verrückt. Wirklich endlos geiles Zeug.
Es klingt fast so, als würdest du die Teile vertreiben.
Ps.: Ich denke das ist für den Ersteller doch etwas too much.
Pps.: frohes Neues
Gruß
Lass mich raten: Du hast noch eine DD gesehen oder benutzt? du denkst Veeam ist toll und "günstig"
Wir hatten zu Spitzenzeiten 17 Compellent-Paare und Off-Site noch zwei große SC8000er als Backup mit angeschlossenen VEEAM Backup. Das war in erster Linie teuer, kompliziert, zeitaufwändig und personalaufwändig.
Mit dem Ende der CMP kamen die PowerMax und PowerScales und sind durch die DD ergänzt am Off-Site-Standort.
Und nein, ich vertreibe die Kisten nicht, ich kenne Sie nur und bei meiner Anordnung im Dezember zu einem IT-Dienstleister, der seine öffentlichen Kunden nicht bedienen konnte, habe ich wieder VEEAM-Konstrukte gesehen, die nicht funktioniert haben. Backup für über eine halbe Million Euro zzgl. Software und dennoch Zusammenbruch.
Von daher, Veeam richtig einsetzen oder Alternativen wie DD oder Commvault ernsthaft mal ansehen.
Wir hatten zu Spitzenzeiten 17 Compellent-Paare und Off-Site noch zwei große SC8000er als Backup mit angeschlossenen VEEAM Backup. Das war in erster Linie teuer, kompliziert, zeitaufwändig und personalaufwändig.
Mit dem Ende der CMP kamen die PowerMax und PowerScales und sind durch die DD ergänzt am Off-Site-Standort.
Und nein, ich vertreibe die Kisten nicht, ich kenne Sie nur und bei meiner Anordnung im Dezember zu einem IT-Dienstleister, der seine öffentlichen Kunden nicht bedienen konnte, habe ich wieder VEEAM-Konstrukte gesehen, die nicht funktioniert haben. Backup für über eine halbe Million Euro zzgl. Software und dennoch Zusammenbruch.
Von daher, Veeam richtig einsetzen oder Alternativen wie DD oder Commvault ernsthaft mal ansehen.
Zitat von @8585324113:
Lass mich raten: Du hast noch eine DD gesehen oder benutzt? du denkst Veeam ist toll und "günstig"
Ich kenne die Teile sehr wohl....nur das ganze muss auch im Verhältnis steheLass mich raten: Du hast noch eine DD gesehen oder benutzt? du denkst Veeam ist toll und "günstig"
Von daher, Veeam richtig einsetzen oder Alternativen wie DD oder Commvault ernsthaft mal ansehen.
Eben...und der Fragesteller hat explizit nach einem Veeam Immutable Storage gefragt. Und dafür benötigt man keine halbe Million.
Nur als Beispiel:
Er bekommt für ca 15k ein pyhischen Server als Immutable Storage mit 24 x 18 TB inkl. NBD. Das ganze läuft dann als Raid 60 mit einem Broadcom 9580.
Bei Bedarf auch mit 36 Platten.
Und das ist bei weitem keine Raketenwissenschaft.
Raid einrichten, Linux OS installieren und konfigurieren und an Veeam anbinden.
Er hat ja bereits mehrfach betont, dass es zu seiner Umbegung passen muss und jeder Beitrag dazu von dir bezieht sich auf die DD
Ich werde das mal mit betrachten, es muss letztendlich in unserer Umgebung und unser internes Know-how bzw. auch zu unseren Partnern passen.
Was für ein Verhältnis passt denn nicht? Es die günstigere und effizientere Lösung, die eine ganze Reihe von Features abrufen kann, die die CMP ermöglicht, was eine Selbst-Bastel-Spielekind-Veeam-Kiste nicht kann oder können wird. Also Kreisliga gegen Bundesliga.
Und ja, man kann einen Server basteln, mit 24x 18TB Spindeln. Aber wenn man schon mal eine CMP gekauft hatte, warum soll man dann 2023 sowas tun? Natürlich kann man auch 36 Spindeln auf 6U unterbringen im Bastelwahn, wenn die DD das auf 2U günstiger und besser kann.
Die DD würde den ROI der CMP noch mal steigern, weil horizontale und vertikale Integration. Du kennst offenkundig die CMP nicht.
Und bevor du jetzt etwas mit dem Preis und erzählen willst, Dell wird sich immer dem Wettbewerb stellen und gute Preise machen.
Und ja, man kann einen Server basteln, mit 24x 18TB Spindeln. Aber wenn man schon mal eine CMP gekauft hatte, warum soll man dann 2023 sowas tun? Natürlich kann man auch 36 Spindeln auf 6U unterbringen im Bastelwahn, wenn die DD das auf 2U günstiger und besser kann.
Die DD würde den ROI der CMP noch mal steigern, weil horizontale und vertikale Integration. Du kennst offenkundig die CMP nicht.
Und bevor du jetzt etwas mit dem Preis und erzählen willst, Dell wird sich immer dem Wettbewerb stellen und gute Preise machen.
Es ist ja erfreulich, dass du mit einer Lösung auf Data Domain Basis zufrieden bist. Aber ich denke, dass es hier nicht um die Suche nach alternativen Lösungen ging und du immer mehr vom Thema abkommst.
Zitat von @regnor:
Es ist ja erfreulich, dass du mit einer Lösung auf Data Domain Basis zufrieden bist. Aber ich denke, dass es hier nicht um die Suche nach alternativen Lösungen ging und du immer mehr vom Thema abkommst.
Es ist ja erfreulich, dass du mit einer Lösung auf Data Domain Basis zufrieden bist. Aber ich denke, dass es hier nicht um die Suche nach alternativen Lösungen ging und du immer mehr vom Thema abkommst.
Ja, wem sagts du das?
Es ging um 7TB und und 150Gb aktive daten am Tag.
Dann ging es um einen physischen Server mit iSCSI und SAN usw... zzgl Veeam Software usw...
...und dann kommst Du um die Ecke und behauptest es weicht vom Thema ab, dass eine DD für weniger Invest und Unterhaltung mehr Leistung bringt? Oder meinst du auch, dass 24 bis 36 18TB Spindeln nicht vom Thema abweichen? :facepalm:
