DELL/EMC hat mit seinem neuen Datensicherungsprodukt „PowerProtect Data Manager“ (PPDM) ein unschlagbares Sicherungsprogramm für VMware Image Sicherungen im Portfolio. Dieses auf Transparent Snapshots basierende Sicherungsverfahren benötigt keine virtuellen Maschinen als Backup-Proxies mehr, sondern lagert die Sicherungsarbeit auf die physikalischen ESXi Maschinen aus. Die Sicherungen der virtuellen Maschinen werden so schneller, benötigen weniger System-Ressourcen und die sonst nötige Pflege der Proxy-Server entfällt auch noch.

Leider fehlt dem Produkt PPDM jedoch die Möglichkeit die PPDM-Sicherungen auf Bänder zu duplizieren. Genau diese Tape-Auslagerung wird aber durch die immer häufiger vorkommenden Ransomeware Attacken und/oder gesetzlichen Vorgaben von einigen Kunden gewünscht.

Im vorliegenden Projekt hat der Kunde parallel zur neuen PPDM Umgebung eine bestehende NetWorker-Backup-Umgebung mit StorageNodes und einer Tape-Library. Der Wunsch war die PPDM-Sicherungen einmal pro Monat mit Hilfe von NetWorker auf Band zu sichern und diese Sicherungen dort für 1 Jahr aufzuheben. Hierbei sollten für alle mit PPDM gesicherten virtuellen Maschinen, die erste Sicherung des jeweiligen Monats auf Band dupliziert werden.

Sowohl NetWorker, als auch PPDM sichern bei dem Kunden auf das DELL/EMC Backup-Storage-System DataDomain. Was lag also näher, als die von PPDM erzeugten DataDomain Sicherungen mit Hilfe von NetWorker-StorageNodes von dem DataDomain System zu lesen und auf Tape zu sichern.

Bei der PPDM Sicherung werden die Sicherungen der virtuellen Maschinen auf dem DataDomain-Filesystem als jeweils eigenes Verzeichnis mit allen VMware spezifischen Dateien abgelegt. Sichert man ein solches Verzeichnis, hat man demzufolge einen kompletten Stand der virtuellen Maschine, der im Recover-Fall vom Band in einen VMware-Datastore eingespielt werden kann.

Die Idee war geboren; was fehlte, war „lediglich“ noch die Umsetzung einiger Voraussetzungen und die Erstellung von Python Modulen und Skripten.

Basierend auf den REST-API Schnittstellen des PPDM-Servers und des NetWorker-Servers wurden 3 Programme erstellt, die die PPDM Sicherungen analysieren, die PPDM Sicherung auf Band befördern und eine NetWorker-Band-Sicherung für Recovery Zwecke auf einer DataDomain wiederherstellen.

• ppdm_find_backup.py

  • Python-Skript, das:

    • für alle VMware Sicherungen des PPDM-Servers in einem definierten MTREE, die zugehörigen Sicherungen eines definierbaren Tages sammelt und die gewonnenen Informationen für die zukünftigen Sicherungen in einer Python-Pickle Datei ablegt.

    • alle gefundenen virtuellen Maschinen als SaveSet Namen in definierten NetWorker Clients hinterlegt. Die Clients sind in dem Falle die NetWorker StorageNodes.

Dieses Skript läuft einmal monatlich vor den NetWorker Sicherungen und wird mit Hilfe eines definierten Cron-Jobs auf dem NetWorker-Server gestartet.

• nsr_ppdm2tape.py <vm-name>

  • Python-Skript, das als NetWorker Backup-Command für die Sicherung einer übergebenen virtuellen Maschine sorgt. Das Vorgehen ist wie folgt:

    • Eventuelles mounten des DataDomain Filesystems.

    • Auslesen der backup Information aus der oben definierten Pickle-Datei.

    • Starten einer NetWorker Band-Sicherung einer virtuellen Maschine.

    • Eventuelles unmounten des DataDomain Mtrees.

• ppdm_recover.py <vm-name>

  • Python-Skript, das eine NetWorker Sicherung auf einen definierten DataDomain Mtree wiederherstellt. Der gesicherte Stand der Maschine wird in einem eigenen Unterverzeichnis im Recover-Mtree abgelegt. Folgende Schritte werden hierbei durchgeführt:

    • Interaktive Auswahl des gewünschten Sicherungsstandes

    • Mount des DataDomain Recover-Mtrees

    • Wiederherstellung der virtuellen Maschine mit Hilfe des NetWorker „recover“ Kommandos.

    • Unmount des DD-Mtrees

Das hier beschriebene Konzept ist natürlich nur eine grobe Beschreibung der Funktionalität. Es fehlen die Konfigurationsschritte und Voraussetzungen auf der DataDomain und im NetWorker. Außerdem fehlt die Installationsbeschreibung der Python-Skripte auf den beteiligten Maschinen. Natürlich fehlt auch das weitere Vorgehen beim Verlauf eines Recover von Tape in eine laufende virtuelle Maschine. Aber all das würde über das Ziel dieses Blogs hinausgehen. Ich wollte Ihnen nur eine Idee für das in der Einleitung beschriebene Problem aufzeigen. Sollten Sie an diesem Projekt näher interessiert sein, so melden Sie sich bitte per E-Mail an den Autor.

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.

Viel zu lange her, dass ich hier etwas veröffentlicht habe.
Das hat aber nichts damit zu tun, dass es nichts zu berichten gäbe, sondern dass es einfach zu viel zu tun gibt und ich daher keine Zeit gefunden habe, dies hier zu berichten. Nun sitze ich am Flughafen und warte auf den wegen Nebel verschobenen Flug zur NetApp Insight und habe endlich mal Zeit und Luft diese Zeilen zu schreiben ;-)

Wo fangen wir an?
Unser Snapshot-Backup Entwicklung für Oracle und VMware ist an vielen Ecken vorangetrieben worden.

Folgende Erweiterungen wurden für die Oracle-Sicherung auf NetApp implementiert und sind bereits beim Kunden im Einsatz:

• vollautomatische Recover Funktionalität
  • Recover Until Time
  • Vollständiges Recover (Crash Recover)

Durch diese Erweiterung können NSR-ORA-NDMP Kunden auf unser Produkt wechseln ohne Funktionalität zu verlieren. Im Gegenteil: Sie erhalten zusätzliche Funktionalität (SnapVault Support).

Folgende Erweiterungen wurden für die VMware-Sicherungen auf NetApp implemetiert:

• Parallelisierung einiger Funktionen: Dadurch wurde die Sicherungsdauer zum Teil auf ein Viertel der Zeit reduziert!
• Unterstützung von orignären NetApp Snapshots für das Recovery von Einzeldateien. Hierdurch können mehrere Sicherungsstände pro Tag durch den normale NetApp Snapshot Scheduler generiert werden. Diese Snapshot Sicherungen sind zwar nur Crash-Consistent, können aber für das Recovery einzelner Dateien verwendet werden.

Migrationsunterstützung :

Unterstützung von mehreren gleichzeitigen SnapVault Beziehungen.
Sowohl die Oracle-  als auch die VMware- Lösung erkennen und "updaten" jetzt auch mehrere gleichzeitige SnapVault Beziehungen. Hierdurch kann z.B. der secondary Storage auf einem neuen System angelegt werden und sobald beide Nearstore Systeme den gleichen Snapshot-Stand haben (beide haben Snapshots über "n" Wochen), kann die "alte" Nearstore Verbindung aufgelöst werden.

Volume Backup:

Unterstützung von Volume Sicherungen über unsere Snapshot Integration.
Dieses Feature unsere Snapshot-Backup Integration ermöglicht z.B. die Sicherung eines Multistore-Filers (VFiler) auf eine gemeinsames Nearstore Volume zu sichern und dieses für Langzeitsicherungen anschließend auf Band-Medien zu sichern.