Projektantrag Vorbereitung zur Einführung einer neuen Backuplösung

[Kalmar]

1. Problembeschreibung

Projektumfeld

XYZ ist ein mittelständisches Gebäudetechnikunternehmen mit über 100 Jahren Erfahrung und mehr als 450 Beschäftigten. Es stellt Dienstleistungen aus Elektrotechnik, Stahlbau, Versorgungstechnik und Gebäudemanagement zur Verfügung.

Das Computersystem besteht aus 19 virtuellen Servern, die auf drei Hardwarehosts laufen. Die virtuellen Maschinen lagern auf einem SAN-System mit iSCSI-Anbindung.

Bisher wurden alle Server über Acronis Backup & Recovery 10 gesichert, welches aber auch durch den Support nicht lösbare Probleme verursacht. Aus diesem Grund wurde vorübergehend auf eine Backupnotlösung (vSphere Data Recovery) ausgewichen, die aber für die gestellten Ansprüche ungenügend ist.

Projektziel

Ziel ist, eine Backuplösung auf Basis von Windows Server 2008 R2 (x64) zu finden, die das vorhandene virtuelle System besser ausnutzen kann, weniger Zeit und Ressourcen verbraucht und im Notfall eine geringe Ausfallzeit gewährleistet. Dabei ist die Erfüllung der technischen Anforderungen vorrangig vor den Kosten.

Erwartetes Ergebnis:

- Zuverlässiges Backup

- Geringer Speicherbedarf (Deduplizierung und Komprimierung der Backups)

- Schnelle Wiederherstellungsmöglichkeit, geringe Ausfallzeiten

- Verringerung der benötigten Backupzeit

- Einfache Administration

Eigene Tätigkeit

Prüfung verschiedener Lösungen auf Eignung (wirtschaftlich und technisch), Evaluierung der geeignetsten Lösung um eine fundierte Entscheidungsgrundlage liefern zu können.

2. Projektplanung

IST-Analyse 2 Std.

Entwicklung SOLL-Konzept, Pflichtenheft 2 Std.

Einholung und technischer Vergleich verschiedener Lösungen 6,5 Std.

Kosten- Nutzen-Analyse 5 Std.

Einrichten einer Testumgebung 3 Std.

Installation, Konfiguration und Test 5 Std.

Auswertung der Ergebnisse, Empfehlungsschreiben 4,5 Std.

Ausarbeitung d. Projektdokumentation 7 Std.

Geplanter Zeitaufwand in Stunden: Summe: 35 Std.

Der Deal dabei ist, ich weiß ums Verrecken nicht, ob ich jetzt in das Ding schon die Angaben zur geplanten Projektdoku dazupacken muss. Muss ich? Ist die Planung genau genug, oder soll da mehr rein? Ich will den Antrag ASAP wegschicken um anfangen zu können.

PS: Müssen die Anzahl der Client PCs in die Projektumgebung? Die Zahl der User könnte in der Wirtschaftlichkeitsbetrachtung auftauchen und wichtig sein.

Bearbeitet 25. Januar 2012 von Kalmar
Vergessen

[Kalmar]

Hat keiner nen Kommentar dazu? Hm....

[Servior]

Ansich finde ich den Antrag nicht schlecht, mir fehlt jetzt persönlich nur die Erwähnung der Testumgebung.

Das eine Testumgebung aufgebaut wird war mir erst beim lesen des Zeitplans aufgefallen.

Weiterhin:

Ich will den Antrag ASAP wegschicken um anfangen zu können.

Sofern dein Projekt genehmigt wird, musst du dich wie alle anderen Auszubildenden auch an den vorgeschriebenen Zeitraum für die Durchführung halten.

[Kalmar]

Okay, danke so weit schon mal.

Dann sollte ich den 4. ESX-Host vielleicht mit angeben, als Testumgebung.

Wegen des Zeitraums: schnell wegschicken, bewilligen lassen und DANN anfangen

[Kalmar]

Zur Info: wurde unbeanstandet genehmigt

[metux]

Kurze Zwischenfrage: warum nicht einfach das SAN snaphots machen lassen ?

[DocInfra]

Weil Snapshots kein Backup sind, sondern nur ein Teil eines Backupkonzeptes sein können.

[metux]

Weil Snapshots kein Backup sind, sondern nur ein Teil eines Backupkonzeptes sein können.

Klar, trifft aber auf die da genannte Backup-Software genauso zu - die eigentliche Backuplösung muß man ja ohnehin im konkreten Falle selbst entwickeln.

Insofern halte ich das schon für eine gute Option, das Backup auf VM-Layer zu lösen.

Möglicherweise bietet VMWare da sogar eine Möglichkeit, VM-Snapshots mit den Storage-Snapshots zu konsistent zu koordinieren (sollte evtl. via barriers möglich sein) - dann bräuchte man nach einem fail die VM's nichtmal neu booten.

[Kalmar]

Der Grund, warum wir nicht einfach Snapshots machen wollen ist, dass wir die Maschinen schnell, auch aus dem Backup raus, starten können. Und eine File Level Recovery ist auch nicht übel. Hab mich am Ende für veeam Backup & Replication 6 entschlossen.

[metux]

Der Grund, warum wir nicht einfach Snapshots machen wollen ist, dass wir die Maschinen schnell, auch aus dem Backup raus, starten können.

Genau das geht ja mit blockdevice-level snapshots besonders gut.

Ich setze mal vorraus, daß die snapshots auf dem SAN atomisch sind. Dann hast Du stets einen hinreichend konsistenten Zustand (abgesehen von dem Umstand, daß zu dem Zeitpunkt evtl. nicht alle Puffer konsistent geschrieben sind - aber dagegen gibts ja schließlich barriers + FUA).

Und eine File Level Recovery ist auch nicht übel. Hab mich am Ende für veeam Backup & Replication 6 entschlossen.

Deren Datasheets zufolge machen die auch blockdevice-snapshots. Das klingt erstmal vernünftig.

Mir ist allerdings noch nicht ganz klar, wer genau die Snapshots hier macht. Damit es konsistent wird, benötigt es eine entsprechende

Synchronisation mit dem VMM oder dem Storage. (die schreiben allerdings, daß es unabhängig vom Storage sei, ergo muß es sich

mit dem VMM absprechen).

Hast Du schonmal ausgemessen, welche Storage-Last das Teils produziert ?