13
Veeam Backup mit immutable Backups auf einen gemounteten iscsi LUN
Moin,
oh man, irgendwie ist selbst jetzt der Topic noch zu kurz.
Es geht um folgendes:
Ich würde gerne immutable Backups bauen. Nun habe ich heute einen alten DL380 gen 6 reaktiviert und dabei festgestellt, dass ich nicht mehr für schmales Geld große 2,5 Zoll HDDs bekomme.
Ok, dann habe ich etwas rumgespielt, da ich die immutable Backups testen wollte. Maßnahme: Ich habe auf einem NAS ein ISCSI LUN gebaut, den gemountet, xfs mit Fastclone konfiguriert und das war es.
Dann habe ich länger drüber nachgedacht. Immutable ist mir relativ wichtig, dazu brauche ich ja irgendein Ubuntu o.ä. dazwischen.
Spricht etwas dagegen, ein ISCSI LUN zu mounten, das dem Backupserver als Repository zur Verfügung zu stellen?
Ich würde den DL380 auch rausschmeißen und eine kleine VM bauen.
oh man, irgendwie ist selbst jetzt der Topic noch zu kurz.
Es geht um folgendes:
Ich würde gerne immutable Backups bauen. Nun habe ich heute einen alten DL380 gen 6 reaktiviert und dabei festgestellt, dass ich nicht mehr für schmales Geld große 2,5 Zoll HDDs bekomme.
Ok, dann habe ich etwas rumgespielt, da ich die immutable Backups testen wollte. Maßnahme: Ich habe auf einem NAS ein ISCSI LUN gebaut, den gemountet, xfs mit Fastclone konfiguriert und das war es.
Dann habe ich länger drüber nachgedacht. Immutable ist mir relativ wichtig, dazu brauche ich ja irgendein Ubuntu o.ä. dazwischen.
Spricht etwas dagegen, ein ISCSI LUN zu mounten, das dem Backupserver als Repository zur Verfügung zu stellen?
Ich würde den DL380 auch rausschmeißen und eine kleine VM bauen.
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: 3010773319
Url: https://administrator.de/contentid/3010773319
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
13 Kommentare
Neuester Kommentar
Servus
Wir handehaben das ähnlich, jedoch wird ein LUN via FC gemountet.
Du musst nur sicherstellen, dass niemand Zugriff auf das VLAN hat. Dementsprechend hat man ein Management VLAN auf welches nur das "IT VLAN" oder ein Jump Host Zugriff hat.
Ich würde den DL380 auch rausschmeißen und eine kleine VM bauen.
Würde ich persönlich mit machen. Was machst du, wenn dein VM System gehackt wird und die VM verschlüsselt oder gelöscht wird? Klar...du kannst das ISCSI LUN wieder mounten, doch Zeit ist Geld
Lieber ein Blech rein als Immutable Storage Mount Server, auf diesen Root Login verbieten ( sollte ja Standard sein) und im Best Practise nach Veeam sogar den SSH Zugang sperren!.
Zugriff auf die Shell erfolgt dann nur via IPMI oder KVM Konsole. Für den "normal" Betrieb ist ein Zugriff via SSH nicht notwendig, da Veeam über einen seperaten Dienst + Port kommuniziert.
Ok, dann habe ich etwas rumgespielt, da ich die immutable Backups testen wollte. Maßnahme: Ich habe auf einem NAS ein ISCSI LUN gebaut, den gemountet, xfs mit Fastclone konfiguriert und das war es.
ok. Also das Standardverfahren für Immutable BackupsDann habe ich länger drüber nachgedacht. Immutable ist mir relativ wichtig, dazu brauche ich ja irgendein Ubuntu o.ä. dazwischen.
Das hast du doch jetzt schon oder? RedHat, CentOS, AlmaLinux (offziell nicht supportet), Ubuntu etc...auf jedenfall ein System, welches xfs supported.Spricht etwas dagegen, ein ISCSI LUN zu mounten, das dem Backupserver als Repository zur Verfügung zu stellen?
Nein.Wir handehaben das ähnlich, jedoch wird ein LUN via FC gemountet.
Du musst nur sicherstellen, dass niemand Zugriff auf das VLAN hat. Dementsprechend hat man ein Management VLAN auf welches nur das "IT VLAN" oder ein Jump Host Zugriff hat.
Ich würde den DL380 auch rausschmeißen und eine kleine VM bauen.
Lieber ein Blech rein als Immutable Storage Mount Server, auf diesen Root Login verbieten ( sollte ja Standard sein) und im Best Practise nach Veeam sogar den SSH Zugang sperren!.
Zugriff auf die Shell erfolgt dann nur via IPMI oder KVM Konsole. Für den "normal" Betrieb ist ein Zugriff via SSH nicht notwendig, da Veeam über einen seperaten Dienst + Port kommuniziert.
Moin,
perfekt, dann würde ich das ganze evtl. noch etwas umbauen.
Entweder baue ich mir ein separates VLAN oder nehme evtl. sogar einen einfachen Switch, NAS und separate Maschine für xfs dran. Würde dann aber vermutlich sogar eine kleine Hardware kaufen anstatt den DL380 Gen 6 angeschaltet zu lassen.
perfekt, dann würde ich das ganze evtl. noch etwas umbauen.
Entweder baue ich mir ein separates VLAN oder nehme evtl. sogar einen einfachen Switch, NAS und separate Maschine für xfs dran. Würde dann aber vermutlich sogar eine kleine Hardware kaufen anstatt den DL380 Gen 6 angeschaltet zu lassen.
Zitat von @matze81:
Moin,
perfekt, dann würde ich das ganze evtl. noch etwas umbauen.
Entweder baue ich mir ein separates VLAN oder nehme evtl. sogar einen einfachen Switch, NAS und separate Maschine für xfs dran.
Wenn du genügend Ports hast, dann kannst du das NAS auch direkt an das Blech anschließen und auf 1 oder 2 ausgewählten Ports legst du nur das Management vom NAS.Moin,
perfekt, dann würde ich das ganze evtl. noch etwas umbauen.
Entweder baue ich mir ein separates VLAN oder nehme evtl. sogar einen einfachen Switch, NAS und separate Maschine für xfs dran.
ISCSI erlaubst du dann nur an den 1 oder 2 Ports, welche direkt an das Blech gehen.
Würde dann aber vermutlich sogar eine kleine Hardware kaufen anstatt den DL380 Gen 6 angeschaltet zu lassen.
Ist das im Privaten oder Produktiven umfeld?
Hallo,
ein NAS sehe ich aber als Fehler an.
Beim Immutable geht es darum das nichts gelöscht werden kann, egal wie.
Wenn dir vom NAS aus das Volume gelöscht wird, hilft es auch nichts.
Wir haben extra Server dafür gekauft und die haben nur eine Verbindung zum Backup-Proxy, sonst nichts.
Keine Management Konsole, kein SSH auf dem Server, nichts.
Nachteil, fällt eine Platte aus, dann merkst du das nur am akustischen Alarm des RAID-Controllers.
Viele Grüße
Deepsys
ein NAS sehe ich aber als Fehler an.
Beim Immutable geht es darum das nichts gelöscht werden kann, egal wie.
Wenn dir vom NAS aus das Volume gelöscht wird, hilft es auch nichts.
Wir haben extra Server dafür gekauft und die haben nur eine Verbindung zum Backup-Proxy, sonst nichts.
Keine Management Konsole, kein SSH auf dem Server, nichts.
Nachteil, fällt eine Platte aus, dann merkst du das nur am akustischen Alarm des RAID-Controllers.
Viele Grüße
Deepsys
Zitat von @Deepsys:
Hallo,
ein NAS sehe ich aber als Fehler an.
Beim Immutable geht es darum das nichts gelöscht werden kann, egal wie.
Wenn dir vom NAS aus das Volume gelöscht wird, hilft es auch nichts.
Daher legt man das Management auf auf ein VLAN, welches max. aus dem IT VLAN oder von einem Jump Host erreicht werden kann. Anmeldung nach 3 Versuchen sperren usw.Hallo,
ein NAS sehe ich aber als Fehler an.
Beim Immutable geht es darum das nichts gelöscht werden kann, egal wie.
Wenn dir vom NAS aus das Volume gelöscht wird, hilft es auch nichts.
Ich benötige z.B. 150 TB für Immutable. Da wirds mit einem Server dann auch kritisch.
Wir haben extra Server dafür gekauft und die haben nur eine Verbindung zum Backup-Proxy, sonst nichts.
Keine Management Konsole, kein SSH auf dem Server, nichts.
So soll es ja auch sein.Keine Management Konsole, kein SSH auf dem Server, nichts.
Nachteil, fällt eine Platte aus, dann merkst du das nur am akustischen Alarm des RAID-Controllers.
Zitat von @matze81:
Nachteil, fällt eine Platte aus, dann merkst du das nur am akustischen Alarm des RAID-Controllers.
Raid Controller könnte man aber SNMP auf dem IPMI Interface überwachen. Dann natürlich wiederrum nur den SNMP Zugriff via Firewall von bestimmten Ports erlauben. Sonst nichts.Das ist eine gute Idee
Also verstehe ich das richtig du willst das Storage(gerät) per iSCSI an das OS hängen was das immutable Backup sicherstellt und das wiederum als Backup Target verwenden? Das würde ich nicht machen. Erstens ist das Storage ein weitere Angriffsvektor wie schon geschrieben.
Ich weiß auch nicht was passiert wenn andere Initiatoren das Target dann mouten, eventuell können die einfach die Dateien überschrieben weil das eigentliche Initiator-OS das zwar verhindert, ein "alternativer" Initiator sich aber nicht darum schert.
Und zu guter Letzt verstehe ich den Nutzen nicht. Ich habe mir eine eigene Hardware zusammen gebaut und einfach ein Ubuntu drauf getan und das rennt. Die eigentliche "Arbeit" erbringt der Backup Server, das Target scheint mir kaum Last zu haben.
Ich weiß auch nicht was passiert wenn andere Initiatoren das Target dann mouten, eventuell können die einfach die Dateien überschrieben weil das eigentliche Initiator-OS das zwar verhindert, ein "alternativer" Initiator sich aber nicht darum schert.
Und zu guter Letzt verstehe ich den Nutzen nicht. Ich habe mir eine eigene Hardware zusammen gebaut und einfach ein Ubuntu drauf getan und das rennt. Die eigentliche "Arbeit" erbringt der Backup Server, das Target scheint mir kaum Last zu haben.
Moin,
ich frage mich ja, warum man "solch ein gebastel" in Kauf nehmen will..
Einen Backup-Server hinstellen, der ein LTO-Drive mitbringt und gut. Dort dann mit WORM-Medien arbeiten und fertig. Zudem kann man Bänder hervorragend auslagern. Ein NAS, welches einmal täglich als Backupziel dient, dürfte unhandlicher sein.
Zudem: ein NAS als Backup-Target zu verwenden finde ich, für meinen persönlichen Geschmack, nicht sinnvoll. Da laufen viel zu viele Dienste nebenher mit, die man als Dateiablage nicht benötigt. Wozu muss auf einem Datengrab ein Webserver laufen? Da reicht es ja, wenn das der Backup-server schon mitbringt...
Und je weniger Systeme involviert sind, desto weniger Angriffsvektoren existieren.
IMHO also:
den DL380 mit VEEAM ausstatten, ausreichend INTERNE Platten da hineinschieben und - falls man die noch für die Kiste bekommt, ein LTO-Drive rein mit ein paar WORM-Medien und gut.
Gruß
em-pie
ich frage mich ja, warum man "solch ein gebastel" in Kauf nehmen will..
Einen Backup-Server hinstellen, der ein LTO-Drive mitbringt und gut. Dort dann mit WORM-Medien arbeiten und fertig. Zudem kann man Bänder hervorragend auslagern. Ein NAS, welches einmal täglich als Backupziel dient, dürfte unhandlicher sein.
Zudem: ein NAS als Backup-Target zu verwenden finde ich, für meinen persönlichen Geschmack, nicht sinnvoll. Da laufen viel zu viele Dienste nebenher mit, die man als Dateiablage nicht benötigt. Wozu muss auf einem Datengrab ein Webserver laufen? Da reicht es ja, wenn das der Backup-server schon mitbringt...
Und je weniger Systeme involviert sind, desto weniger Angriffsvektoren existieren.
IMHO also:
den DL380 mit VEEAM ausstatten, ausreichend INTERNE Platten da hineinschieben und - falls man die noch für die Kiste bekommt, ein LTO-Drive rein mit ein paar WORM-Medien und gut.
Gruß
em-pie
Nun, die NAS sollte natürlich nichts anderes machen als immutable Backup, wie auch, sie ist ja idealerweise nicht im Produktivnetz. Die NAS kann dann in einem anderen Brandabschnitt oder an einem anderen Standort stehen. Sinnvolle Anwendungen gibt's da schon.
Zitat von @ukulele-7:
Also verstehe ich das richtig du willst das Storage(gerät) per iSCSI an das OS hängen was das immutable Backup sicherstellt und das wiederum als Backup Target verwenden? Das würde ich nicht machen. Erstens ist das Storage ein weitere Angriffsvektor wie schon geschrieben.
Das hat bei einem NAS ebenso bei einem „richtigen“ StorageAlso verstehe ich das richtig du willst das Storage(gerät) per iSCSI an das OS hängen was das immutable Backup sicherstellt und das wiederum als Backup Target verwenden? Das würde ich nicht machen. Erstens ist das Storage ein weitere Angriffsvektor wie schon geschrieben.
Ich weiß auch nicht was passiert wenn andere Initiatoren das Target dann mouten, eventuell können die einfach die Dateien überschrieben weil das eigentliche Initiator-OS das zwar verhindert, ein "alternativer" Initiator sich aber nicht darum schert.
Genau aus diesem Grund erlaubt man eben nur authentifizierten Initiatoren das mounten. Siehe CHAP
Oder lässt du jedes Gerät an deine iscsi Targets? Davon abgesehen… wie soll jemand an den iscsi Port, wenn dieser direkt ohne Switch verbunden ist?
Und zu guter Letzt verstehe ich den Nutzen nicht. Ich habe mir eine eigene Hardware zusammen gebaut und einfach ein Ubuntu drauf getan und das rennt.
Prima. Kannst du damit auch 150 oder 250 TB im Raid 60 zur Verfügung stellen?IMHO also:
den DL380 mit VEEAM ausstatten, ausreichend INTERNE Platten da hineinschieben und - falls man die noch für die Kiste bekommt, ein LTO-Drive rein mit ein paar WORM-Medien und gut.
Gruß
em-pie
den DL380 mit VEEAM ausstatten, ausreichend INTERNE Platten da hineinschieben und - falls man die noch für die Kiste bekommt, ein LTO-Drive rein mit ein paar WORM-Medien und gut.
Gruß
em-pie
Das ist aber nicht wirklich nach VEEAM Best Practice - alles in ein Blech zu stopfen.
Bedenke das eine Tape Wiederherstellung viel langsamer ist, als von Disk. Noch dazu fehlt dir dann Instant Recovery.
Davon abgesehen sollte natürlich das NAS nicht das einzige Backup sein.
Auch wir sichern auf ein Primär Storage, dann Copy Jobs auf Immutable und auf eine LTO8 Tape Library mit 40 Bändern, jedoch ziehe ich die Disk bei der Widerherstellung den Bändern immer vor, wenn ich darüber 2GB/s oder mehr lesen und schreiben kann.
@tech-flare
Naja, wir haben bei uns auch Veeam-Server, Storage (FC-SAN) und TS4300 auf drei Standorte verteilt installiert.
Aber wer einen DL380 Gen6 einsetzt, hat vermutlich nur ein begrenztes Budget
Naja, wir haben bei uns auch Veeam-Server, Storage (FC-SAN) und TS4300 auf drei Standorte verteilt installiert.
Aber wer einen DL380 Gen6 einsetzt, hat vermutlich nur ein begrenztes Budget
@tech-flare
mein Beitrag richtete sich an den TO. Ich glaube nicht das ein Konstrukt:
<Backupserver> => <immutable Backup Repository> =iSCSI=> <Storage>
sinnvoll ist sondern es viel leichter mit
<Backupserver> => <immutable Backup Repository inkl. eigenem Storage>
umzusetzen ist. Natürlich hat alles seine physikalischen grenzen aber es ging hier nicht um deine 250 TB, ich denke mal es geht um sehr viel weniger.
mein Beitrag richtete sich an den TO. Ich glaube nicht das ein Konstrukt:
<Backupserver> => <immutable Backup Repository> =iSCSI=> <Storage>
sinnvoll ist sondern es viel leichter mit
<Backupserver> => <immutable Backup Repository inkl. eigenem Storage>
umzusetzen ist. Natürlich hat alles seine physikalischen grenzen aber es ging hier nicht um deine 250 TB, ich denke mal es geht um sehr viel weniger.
