Bei einem unserer Kunden war der Wartungsvertrag für die NetApp VTL abgelaufen. Eine Verlängerung wäre unverhältnismäßig teuer gewesen. Außerdem war die Kapazität des Systems auch schon an seine Grenzen gestoßen. Da der Großteil der Daten des Kunden auf NetApp Primary Systemen lag oder darauf umgezogen werden sollte, viel die Entscheidung für eine Ablösung auf eine Kombination von 2 NetApp Nearstore Systemen und Advanced File Devices mit einer Bandsicherung für Langzeitsicherungen.

Auf die beiden Nearstore Systeme, die sich an 2 unterschiedlichen Standorten befinden, werden die Sicherungen der Oracle und VMware ESX Backups, sowie die auf den NetApp befindlichen Nutzerdaten mittels des NetApp Produktes SnapVault auf die erste NetApp gesichert. Diese Backup Volumes werden zyklisch mit dem Produkt SnapMirror auf die 2'te Nearstore in einen entfernten Standort gespiegelt. Da der Kunde schon seit einiger Zeit unsere Backup-Lösungen SBint-O und SBint-VM einsetzt, konnte die Sicherung der Oracle Datenbanken und der VMware-ESX-Datastores weiterhin mit NetWorker gestartet und überwacht werden. Die anfallenden Oracle-Archivelog Dateien werden mit SBint-O vom Primary Storage auf die erste Nearstore verdrängt. Jetzt fehlte nur noch eine entsprechende Integration der auf NetApp gehosteten Benutzerdaten. Hierfür gab es jedoch auch bereits eine Lösung unserer SBint-Backup-Tools. Denn auch hierfür kann man mit Hilfe eines NetWorker-Clients und einer zugehörigen NetWorker-Gruppe die Sicherung eines NetApp Volumes von einem Storage-System zum zweiten starten und überwachen. Selbstverständlich werden auch diese Sicherungen in unserer SBint-WWW-Oberfläche visualisiert (siehe auch hier).

Was jetzt noch fehlte, waren eine integrierte Sicherungslösung ganzer virtueller Filer-Umgebungen, sowie eine einfache Möglichkeit die benötigten Volumes und SnapVault- bzw. SnapMirror-Beziehungen automatisiert anzulegen. Jeder virtuelle Filer besitzt mehrere NetApp-Volumes. Diese sollten auf den sekundären Systemen alle die gleiche Aufbewahrungsfristen erhalten. Hierfür wurde unsere SBint-Backup-Lösung kurzerhand um eine entsprechende Funktion erweitert. Ein neuer Parameter in der Konfigurationsdatei definiert welche primären NetApp-Volumes auf einem gemeinsamen sekundären Ziel-Volume gesichert werden sollen. Das Sicherungskommando startet entsprechend bei einer durch NetWorker getriggerten Sicherung den SnapVault-Abgleich aller definierten Volumes auf ein gemeinsames Ziel-Volume. Nach der erfolgreichen Übertragung aller Volumes wird auf dem Nearstore-Volume ein gemeinsamer Snapshot erzeugt, der von unserer Backup-Integration nach der definierten Retentionzeit auch wieder entfernt wird. Jetzt fehlte nur noch ein komfortables Tool, dass die auf den Nearstores benötigten Volumes automatisiert anlegt und die für die Sicherung benötigten Snapshot-Beziehungen konfiguriert. Entstanden ist ein kleines Programm, dass im nächsten Blog beschrieben wird.

Ende 2011 konnten wir die von uns betreuten Backup-Tools bei ihrem Einsatz für Microsoft-Produkte im direkten Vergleich bewerten: EMC NetWorker NMM 2.3, NetApp SnapManager in jeweils aktueller Version und Microsoft DPM 2010. Als eine erste Erkenntnis läßt sich festhalten, dass keines der Tools sich dergestalt hervorhebt, dass es uneingeschränkt zu empfehlen oder abzuraten wäre. Je nach zu sichernden Daten (MS Exchange, MS SQL, Sharepoint, MS DPM, Hyper-V, Systembackup) hat jedes Tool eigene Stärken und Schwächen.

Hier eine kurze Übersicht:
Beginnen wir bei beim Backup von Betriebssystemen: MS DPM und EMC Networker bieten hier gleichermassen bequeme und zuverlässige Unterstützung (siehe auch Blogbeitrag "Networker SaveSet ALL mit NMM 2.3"). NetApp bietet die Option, Betriebssysteme mittels "Open Systems SnapVault Agents" zu sichern, unterstützt im Gegensatz zu Microsoft und EMC jedoch kein Bare Metal Recovery.

Microsoft Exchange kann mit allen drei Tools gesichert und wiederhergestellt werden. Hier ist NetApp Snapmanager for Exchange in Kombination mit dem von Kroll Ontrack lizensierten "Single Item Restore" die leistungsfähigste - jedoch auch die kostenintensivste und in der Einrichtung aufwendigste - Lösung. Die auf NetApp-Storage abgelegten Backups können sehr schnell zugänglich gemacht und mit Single Item Restore Elemente wiederhergestellt werden. Bei Microsoft DPM und Networker EMC erfolgt der Restore einzelner Elemente unter Nutzung einer Wiederherstellungsdatenbank - diese muss jedoch erst einmal mit den Daten aus dem Backup gefüllt und anschließend gemountet werden; der notwendige Reparaturvorgang der Datenbank ist in beiden Tools integriert. NetApp und EMC bieten ein graphisches Interface zur Suche nach wiederherzustellenden Einzelelementen - Microsoft nutzt hier die Powershell, was die Daten besser vor unberechtigter Einsichtnahme schützt.

MS SQL: auch für die Sicherung, die Wiederherstellung und das (temporäre) Clonen von MS SQL-Datenbanken liefert NetApp das leistungsfähigste (und teuerste) Tool. Für die Wiederherstellung stehen die Optionen des Restores der Originaldatenbank ebenso wie Restore auf eine neue Datenbank zur Verfügung. Auch MS DPM bietet diese Möglichkeiten - problemlos auch auf andere MS-SQL-Server. NetApp verfügt darüber hinaus über die Möglichkeit des (temporären) Clonens von SQL-Datanbanken in sehr kurzer Zeit. Networker NMM kann derzeit nur die Originaldatenbank wiederherstellen; diese jedoch ebenfalls auf andere MS-SQL-Server (directed recover).

Sharepoint-Backups stellen allgemein hohe Anforderungen. Mit allen drei Tools können solche Backups ausgeführt werden. MS DPM zeichnet sich hierbei dadurch aus, dass die Konfiguration der Backups am Schnellsten ausgeführt werden konnte und darüber hinaus ein Restore einzelner Elemente möglich ist; jedoch nicht einzelner Versionen. Networker bedarf einer etwas aufwendigeren Einrichtung des Backups und verfügt in der Version 2.3 leider nicht mehr über die Möglichkeit des Sicherns und Restores einzelner Elemente wie die NMM-Versionen vor 2.3. NetApp verfügt mit dem SnapManager for Sharepoint (SMSP) auch auf diesem Bereich über die leistungsfähigste Software - leider kann sie nicht uneingeschränkt empfohlen werden. SMSP ist eine Lizenz der entsprechenden AvePoint-Software, was für hohe Qualität des Produktes spricht. Die NetApp-Version dieser Software ist jedoch stark limitiert und erscheint teilweise unbeherrschbar - wenn Fehler auftauchen, sind diese nicht immer zu lokalisieren und abzustellen. Seit einigen Monaten ist die Version 6.1 des SMSP angekündigt, die dann bis zum SMSP per Powershell bedient werden kann und eine bessere Fehlerdiagnose ermöglichen sollte. Die SMSP-Konfiguration ist vergleichsweise aufwendig (es werden dedizierte Backup-Server empfohlen), bietet jedoch neben einem single Item Restore auf Versionsebene auch integrierte Optionen für die Nutzung von SQL-BLOB-Storage sowie die manuelle und automatische Archivierung von Daten auf NetApp-Storage; auch auf über Jahre blockierten SnapLock-Bereichen.

Die weiteren möglichen Backups wurden von uns nicht ausführlich getestet, daher hier nur eine kurze Einschätzung:
MS DPM kann gesichert werden: durch einen zweiten MS DPM oder mittels Networker NMM. Beide Tools bieten diese Unterstützung explizit an. NetApp kann als Storage für den Betrieb des MS DPM mit SAN-Devices Verwendung finden, die dann natürlich auch durch NetApp-Snapshots gesichert werden können. Eine integrierte Unterstützung fehlt jedoch; auch gelang es uns nicht, auf den SnapShot einer als DPM-Disk-Storage genutzten LUN zuzugreifen: diese Datenträger wurden stets als nicht formatiert gemeldet.

Hyper-V-Umgebungen mit ihren VMs können durch alle drei Produkte gesichert und wiederhergestellt werden; NetApp bietet dafür den Snapmanager for Hyper-V seit zwei Jahren in der Version 1.0 an, d.h im Vergleich zum Snapmanager VI mit geringerem Leistungsumfang.
ESX-Umgebungen werden in den Backup-Konzepten sowohl von NetApp als auch von EMC Networker umfassend unterstützt: NetApp liefert den SMVI (SnapManager for Virtual Infrastructure) inzwischen voll integriert als "Virtual Storage Console for VMware vSphere";  Networker bietet die Konfiguration von Clients als VMWare-VM an.

Preisgestaltung und Fazit: Wer NetApp-Storage einsetzt, sollte auch für das Backup der Applikationsdaten auf NetApp-Produkte setzen, deren Preis in diesem Fall kein Hindernis darstellen darf. Networker NMM ist relativ teuer, bietet sich jedoch für heterogene Umgebungen, in denen Networker als zentrales Backup-Tool eingesetzt wird, an und lieferte gut implementierte Features. Microsoft DPM eignet sich nur zur Sicherung von Microsoft-Systemen: die Software beherrscht deren Backups und Restores perfekt, ist relativ preiswert, schnell  konfiguriert und übersichtlich. Sie ist auch als Ergänzung für "teure" Backup-Umgebungen zu empfehlen. MS DPM geht äußerst sparsam mit den Ressourcen um (Backup-Medien; Netzwerk). Microsofts DPM und besonders EMCs NMM zeichnen sich durch ein eindeutiges, einheitliches und "gut in der Hand liegendes" User-Interface aus.

Wer kennt das nicht.

Alle paar Tage gibt es Updates und Bugfixes. Mal kommt es über die Community (Ubuntu), mal vom Softwarehersteller (Java und AcrobatReader) oder auch vom Hersteller des OS (Windows).

Problematisch an diesen Updates ist zuweilen, dass man vorher nicht weiss, ob anschließend noch alles funktioniert.

Was hat das jetzt mit der NMC zu tun? Die NMC-Clientsoftware ist ein Java-Programm. Genauer: Java WebStart. Hier nun liegt das Problem. Da Java hauptsächlich plattformunabhängig ist und nicht so sehr auf- und abwärtskompatibel, gibt es bei Java-Updates häufiger Probleme mit den Anwendungen.

Aktuell folgendes:

Die NMC-Version 7.5 ff. funktioniert mit Java "1.6.0_26".

Sollte ein Update auf Java 1.6.0_29 oder _30 erfolgt sein:
Nur noch die neueste NMC von EMC lässt sich damit erfolgreich betreiben. Bei den anderen Versionen muss man mit Fehlern bei der Authentifizierung (Login) rechnen.

Für FTS-Kunden bedeutet das: Auf keinen Fall die Java-Version 1.6.0_29 oder _30 installieren!!

Erst mit dem nächsten Servicepack von FTS können wir mit einer Kompatibilität zur aktuellen Javaversion rechnen.

Sollte es dennoch passiert sein, gibt es aber auch noch Hoffnung.
Bis Java5 wurden die älteren Versionen nicht weggeworfen, sondern blieben auf dem Rechner liegen. So konnte man mit der beim Aufruf des Kommandos javaws durch die Angabe des Pfades auch ältere Versionen starten. Unter Java6 ersetzen die Update jetzt die älteren Versionen, so dass diese Optione nicht mehr besteht.

Allerdings besteht immer noch die Möglichkeit eine passende Version herunterzuladen. Man braucht dazu aber einen Oracle-Account.

Für den FTS-NetWorker Version 7.5 und 7.6 benötigt man Java6 Update 26 (1.6.0_26). Neuere Versionen funktionieren aktuell nicht.

Unser DemoLab versetzt uns in die Situation, verschiedene Backup-Tools im Betrieb direkt zu vergleichen. Eine Übersicht dazu wird noch 2011 an dieser Stelle veröffentlicht - zum Thema Networker NMM 2.3 vorab schon einige Anmerkungen:

• Derzeit ändern sich mit jeder neuen NetWorker-Version die Regeln zum Einrichten von Backups am Server, wobei die Qualität der Anleitungen nicht immer mithalten kann.
• Es ist dringend anzuraten, spätestens vor dem ersten Backup und nach Installation der Networker Software (Client oder Storage Node) den EMC Config Checker for NMM zu installieren und auszuführen.
  Dabei gilt:
  • Die Version des Config Checkers sollte die jeweils aktuelle sein: Version 1.1.2 kann beispielsweise Sharepoint-Informationen auslesen; die Version 1.1.0 hat noch nicht einmal die SharePoint-Version erkannt.
  • Der Config Checker kennt bei der Verwendung aktueller Virtualisierungslösungen die dort genutzten Netzwerkkarten nicht; betreffende Meldungen können ignorieren werden.
  • Alle anderen Fehler müssen abgestellt werden, um erfolgreich sichern zu können.

Mit Networker Server 7.6.2 und NMM auf der Clientseite lassen sich recht bequem und zuverlässig die Savesets in der NMC konfigurieren, wobei derzeit Applications (MS Exchange, MS SQL, MS Sharepoint ...) prinzipiell nicht erkannt werden. Immerhin wird ein Disaster Recovery Backup für den Client als Backup des Filesystems angeboten. Wählt man dieses aus, so erhält man: den Saveset ALL! Er umfasst alle lokalen Laufwerke sowie SYSTEM COMPONENTS:\ und DISASTER_RECOVERY:\. Natürlich soll als Systembackup in erster Linie das Betriebssystem und nicht der Dateibestand der Anwendungen (als Bestandteil eines File-Backups ohnehin inkonsistent) gesichert werden.
Startet man nun per NMC den Saveset ALL, dann schlagen die Backups fehl mit dem Hinweis, dass der Saveset DISASTER_RECOVERY:\ für NMM nicht gültig ist und dafür das einfache save-Kommando der Networker Client-Software infrage kommt. Dieses Backup wiederum schlägt fehl mit dem Hinweis, dass NMM installiert ist und daher save.exe für den Saveset ALL nicht genutzt werden kann.

Für einen MS Application Server ergibt sich somit die Notwendigkeit der Erstellung dreier verschiedener Savesets: 1) NMM-Sicherung der Applikations-Daten, 2) Saveset DISASTER_RECOVERY:\, mit save.exe zu sichern und 3) Saveset ALL - mit NMM zu sichern.
Der DISASTER_RECOVERY:\ - Saveset erstellt dabei ein den Datensatz für ein Bare-Metal-Recovery, mit dem das komplette System wiederhergestellt werden kann. Dazu eignet sich die EMC Networker Recovery CD hervorragend und dafür ist sie auch vorgesehen.
Sollte die CD in virtualisierten Umgebungen scheinbar nicht einsetzbar sein, so bitte daran denken, dass es um das Wiederherstellen eines komplett ausgefallenen Betriebssystems geht - also am Besten dem Ersatz für das ausgefallene System erst einmal eine neue, leere Festplatte spendieren!

Der Saveset ALL umfasst ebenfalls das komplette Betriebssystem mit allen angeschlossenen Laufwerken, klammern jedoch die Applikationsdaten explizit aus und sichert DISASTER_RECOVERY:\ nicht mt. Damit eignet sich Saveset ALL nicht zum Einsatz für die sofortige Wiederherstellung eines ausgefallenen Systems, sondern für das Wiederherstellen älterer Zustände des Systems oder einzelner Komponenten. Auch der Umweg über einen "zwischengeschalteten" Wiederherstellungserver, der mit dem wiederherzustellenden System "überschrieben" wird, ist realisierbar.