2
ISCSI Targets - Bandlaufwerkersatz?
Unsicherheit über Machbarkeit - ist es überhaupt sinnvoll?
Hallo,
Zur Konsolidierung der Backups mehrerer Server möchte ich ein zentrales Storage System einführen.
Leider bin ich noch unsicher über die grundsätzliche Machbarkeit bzw. das Vorgehen.
Ziel ist es, wie immer ;), Backups vollständig, versioniert und zeitnah wieder einspielen zu können plus ausser Haus Lagerung.
Es gibt diverse Anbieter am Markt die tolle iSCSI Targets anbieten.
Im Grunde möchte ich das Storage System als eine Art von Bandlaufwerkersatz einsetzen und dachte an folgenden Weg:
Ich gehe der Einfachheithalber mal von Servern aus auf denen Server 2008 läuft und die per WinImage bzw. der Windows-Serversicherung derzeit lokal sichern.
Das Storage bekommt also min. 1 Target das jeweils dem entsprechenden Server als lokales Laufwerk untergeschoben wird.
Im einfachsten Fall also eine einzige Platte die komplett als Target zur Verfügung gestellt wird.
Nun würde ich gern wöchentlich/mtl/jährl. eine Platte entnehmen und wie althergebracht ausser Haus lagern.
Das heißt Freitags wird die Platte die im Storage System klemmt herausgezogen und gegen die Platte der kommenden Woche ersetzt.
So wie man es von Bandlaufwerken kennt.
Kann ich auf dem iSCSI Host eine Art Pool angeben der dann letztendlich den Servern zur Verfügung steht?
Wie hoch ist der Aufwand der da betrieben werden müsste?
Ich dachte an ein zentrales System wie es QNap,Synology oder Buffalo anbieten.
Testweise habe ich die Grundfunktion von iSCSI (minimal) getestet.
iSCSI Softwaretarget für 2008 R2. Target im zu sichernden Server eingefügt (per iSCSI Initiator) und darauf gesichert.
Rücksicherung: Sicherung auf Host-Target per Netzlaufwerk freigegeben und entsprechend mit BootDVD darauf zugegriffen und System zurück gespielt.
Das funktioniert soweit wie ich es mir vorstellte.
Aber als automatischen Pool anlegen wie in obigen Szenario wäre toll. ;)
Ist die Überlegung grundsätzlich sinnvoll oder gibt es bessere Alternativen?
Der Serverpool ist gemischt. Fileserver, Exchange aber auch SQL.
Clienten werden derzeit noch nicht eingefasst. Durch zentrales speichern der "Nutzdaten" derzeit auch nicht relevant.
Anmerkung:
Ich bin ein paar Jahre aus der IT-Verwaltung und habe vielleicht nicht mehr den aktuellen Stand der Technik bzw. Überblick über "heutige" Art und Weisen der Backuperstellung.
Alles was ich zum Thema lese ist entweder auf "altem" Stand oder nicht praxisnah genug und sehr oberflächlich.
Falls jemand ein paar Lesetipps hat würde ich mich sehr freuen. Ich bemühe mich nach Kräften alles zu erarbeiten aber manchmal ist es einfacher jemanden zu fragen. ;)
Hallo,
Zur Konsolidierung der Backups mehrerer Server möchte ich ein zentrales Storage System einführen.
Leider bin ich noch unsicher über die grundsätzliche Machbarkeit bzw. das Vorgehen.
Ziel ist es, wie immer ;), Backups vollständig, versioniert und zeitnah wieder einspielen zu können plus ausser Haus Lagerung.
Es gibt diverse Anbieter am Markt die tolle iSCSI Targets anbieten.
Im Grunde möchte ich das Storage System als eine Art von Bandlaufwerkersatz einsetzen und dachte an folgenden Weg:
Ich gehe der Einfachheithalber mal von Servern aus auf denen Server 2008 läuft und die per WinImage bzw. der Windows-Serversicherung derzeit lokal sichern.
Das Storage bekommt also min. 1 Target das jeweils dem entsprechenden Server als lokales Laufwerk untergeschoben wird.
Im einfachsten Fall also eine einzige Platte die komplett als Target zur Verfügung gestellt wird.
Nun würde ich gern wöchentlich/mtl/jährl. eine Platte entnehmen und wie althergebracht ausser Haus lagern.
Das heißt Freitags wird die Platte die im Storage System klemmt herausgezogen und gegen die Platte der kommenden Woche ersetzt.
So wie man es von Bandlaufwerken kennt.
Kann ich auf dem iSCSI Host eine Art Pool angeben der dann letztendlich den Servern zur Verfügung steht?
Wie hoch ist der Aufwand der da betrieben werden müsste?
Ich dachte an ein zentrales System wie es QNap,Synology oder Buffalo anbieten.
Testweise habe ich die Grundfunktion von iSCSI (minimal) getestet.
iSCSI Softwaretarget für 2008 R2. Target im zu sichernden Server eingefügt (per iSCSI Initiator) und darauf gesichert.
Rücksicherung: Sicherung auf Host-Target per Netzlaufwerk freigegeben und entsprechend mit BootDVD darauf zugegriffen und System zurück gespielt.
Das funktioniert soweit wie ich es mir vorstellte.
Aber als automatischen Pool anlegen wie in obigen Szenario wäre toll. ;)
Ist die Überlegung grundsätzlich sinnvoll oder gibt es bessere Alternativen?
Der Serverpool ist gemischt. Fileserver, Exchange aber auch SQL.
Clienten werden derzeit noch nicht eingefasst. Durch zentrales speichern der "Nutzdaten" derzeit auch nicht relevant.
Anmerkung:
Ich bin ein paar Jahre aus der IT-Verwaltung und habe vielleicht nicht mehr den aktuellen Stand der Technik bzw. Überblick über "heutige" Art und Weisen der Backuperstellung.
Alles was ich zum Thema lese ist entweder auf "altem" Stand oder nicht praxisnah genug und sehr oberflächlich.
Falls jemand ein paar Lesetipps hat würde ich mich sehr freuen. Ich bemühe mich nach Kräften alles zu erarbeiten aber manchmal ist es einfacher jemanden zu fragen. ;)
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: 174771
Url: https://administrator.de/contentid/174771
Ausgedruckt am: 05.11.2024 um 16:11 Uhr
2 Kommentare
Neuester Kommentar
Hi,
also ein iSCSI Target verhält sich gegenüber dem initierenden Server wie eine lokal angeschlossene Festplatte. Wenn das Storage (= iSCSI Target) ein richtiges SAN ist, dann kannst du da nicht einfach irgendwelche Platten rausziehen. Ich würde nach dem Prinzip D2D2T (Disk to Disk to Tape) verfahren. D.h ein größeres Storagedevice nimmt das oder die Backups auf und von dort wird es auf Band oder ein anders Wechselmedium (z.B. Tandberg RDX) kopiert. Das Band (oder RDX) kannst du dann mit nach Hause nehmen.
Backupsoftware u. -produkte gibt es von verschiedenen Herstellern (Acronis, Symantec, etc.)
Hoffe geholfen zu haben,
Gruß D.
also ein iSCSI Target verhält sich gegenüber dem initierenden Server wie eine lokal angeschlossene Festplatte. Wenn das Storage (= iSCSI Target) ein richtiges SAN ist, dann kannst du da nicht einfach irgendwelche Platten rausziehen. Ich würde nach dem Prinzip D2D2T (Disk to Disk to Tape) verfahren. D.h ein größeres Storagedevice nimmt das oder die Backups auf und von dort wird es auf Band oder ein anders Wechselmedium (z.B. Tandberg RDX) kopiert. Das Band (oder RDX) kannst du dann mit nach Hause nehmen.
Backupsoftware u. -produkte gibt es von verschiedenen Herstellern (Acronis, Symantec, etc.)
Hoffe geholfen zu haben,
Gruß D.
Hallo dh,
Jeder Einwand hilft... ;)
@ Disk2Disk2Tape
Ich denke das ist auch am sinnvollsten.
Wie du angemerkt hast, sind Storage Systeme nicht unbedingt dafür geeignet.
Meldungen über fehlerhafte HDDs dürften allein schon ein Grund sein... ;)
Ich werde wohl vorerst mit WBAdmin tgl. sichern und speziellere Tasks per Scheduler auf der Kommandozeile anschubsen und entsprechend ein Vollbackup auf externe Geräte schieben.
Dann habe ich erstmal etwas Luft und arbeite mich an weitere Lösungen heran.
Im Moment kann ich mangels Daten keine Prognose Abzeichen wo die Reise von den Kapazitäten dauerhaft hingeht. Dazu fehlen mir einfach zuviel Kenngrößen. ;)
Jeder Einwand hilft... ;)
@ Disk2Disk2Tape
Ich denke das ist auch am sinnvollsten.
Wie du angemerkt hast, sind Storage Systeme nicht unbedingt dafür geeignet.
Meldungen über fehlerhafte HDDs dürften allein schon ein Grund sein... ;)
Ich werde wohl vorerst mit WBAdmin tgl. sichern und speziellere Tasks per Scheduler auf der Kommandozeile anschubsen und entsprechend ein Vollbackup auf externe Geräte schieben.
Dann habe ich erstmal etwas Luft und arbeite mich an weitere Lösungen heran.
Im Moment kann ich mangels Daten keine Prognose Abzeichen wo die Reise von den Kapazitäten dauerhaft hingeht. Dazu fehlen mir einfach zuviel Kenngrößen. ;)
