How to install, configure and integrate NetApp SnapManager Exchange in OnCommand and do restores with SME and SMBR

In diesem Artikel möchte ich euch die Einrichtung von NetApp SnapManager Exchange näher bringen. Ebenso wird in diesem Artikel die Integration in NetApp OnCommand erläutert, damit automatisiert über eine Protection Policy nach einem erfolgreichen lokalen Backup automatisiert ein SnapVault auf eine Secondary NetApp getriggert wird. Wer bereits meinen Artikel über die Integration von Microsoft SMSQL in NetApp OnCommand gelesen hat, wird erstaunlich viele Parallelen in der Vorgehensweise finden 😉

Folgende Konfigurationsschritte werden beschrieben:

1. Anbinden des Exchange Servers an OnCommand
2. Anlegen einer Protection Policy in OnCommand
3. Initial Wizard SnapManager Exchange
4. Einrichtung eines Backupjobs für die Exchange Datenbanken
5. Konfiguration des OnCommand Datasets für SME
6. Beispiel: Restoreablauf einer SME Datenbank
7. Beispiel: Restoreablauf eines einzelnen Objekts per Single Mailbox Recovery (SMBR)

Folgende Voraussetzungen müssen erfüllt sein:

1. SnapDrive ist bereits installiert und mit einem AD Serviceuser konfiguriert (z.B. svcsnapdrive)
2. LUNs sind nach Best Practice konfiguriert und in einer passenden Volume/Qtree Struktur, die von SME / OnCommand supportet wird
3. Exchange ist installiert und die Datenbanken vorhanden (kein DAG o.ä. konfiguriert)
4. AD User, der für SME dienen soll ist vorhanden (z.B. svcsme)
5. im OnCommand Core sind bereits die Storages integriert, eine Secondary Provisioning Policy, sowie Secondary Ressource Pools konfiguriert

Verwendete Umgebung:

1. virtualisierter Microsoft Exchange Server mit allen Rollen, geschützt durch VMware HA
2. Anbindung der LUNs per SnapDrive 7.0.x per ISCSI
3. OnCommand Core 5.x auf separatem Server
4. SnapManager SME soll auf dem gleichen Server installiert und konfiguriert werden
5. SMBR wird auf einer separaten „Restore“-VM installiert (Admin-PC)

Here we goooo 😉

 

 

1. Anbinden des Exchange Servers an OnCommand

 

 

• in der OnCommand Weboberfläche unter „Administration“ – „User and Roles“ den Serviceusern für SnapDrive und SnapManager Exchange entsprechende OnCommand Rechte geben (im Beispiel bekommen die User „FullControl“ Rechte)

• da SnapDrive bereits auf dem Exchange Server installiert ist und die LUNs verbunden sind, muss SnapDrive noch an OnCommand angebunden werden
• auf der CLI des Servers „sdcli oncommand_config set -host ONCOMMANDNAME -user SNAPDRIVESERVICEUSERNAME“ ausführen
• mit „sdcli oncommand_config list“ prüfen, dass erfolgreich

• SnapDrive Dienst muss neu gestartet werden -> SnapDrive sauber an OnCommand angebunden

• danach die Installation des SnapManager Exchange durchführen (in der Regel – next next next – den SME im Wizard mit dem entsprechenden vorgesehenen Diensteuser konfigurieren z.B: svcsme) -> Snap Manager Exchange erfolgreich installiert, Dienst läuft unter dem vorgesehenen Diensteuser

 

 

2. Anlegen einer Protection Policy in OnCommand

 

 

• bevor der NetApp SnapManager for Exchange das erste Mal gestartet wird, sollten wir im OnCommand eine Protection Policy anlegen, da beim Initial Wizard des SME danach verlangt wird
• HINWEIS: Die primären Snapshots, sowie eine darauf folgende Replikation mir SnapVault wird vom SME getriggert. In der Protection Poliy muss somit nur eine Vorhaltezeit auf der Sekundärseite definiert werden.
• in der OnCommand Management Console eine neue „Remote-Backup-Only“ Protection Policy anlegen

• keine Einstellungen für Primärretention und Transport vornehmen (macht ja der SME)

• auf der Backupseite festlegen, wie viele Snapshots vorgehalten werden sollen (in unserem Fall übertragen wir jeden Tag Snapshots der Klassifizierung „daily“ und wollen auf der SnapVault Destination für 2 Wochen Snapshots vorhalten

 

 

3. Initial Wizard SnapManager Exchange

 

 

• nachdem die Protection Policy im OnCommand vorhanden ist, starten wir den SME auf dem Exchange Server und führen den Initial Wizard durch – Next

• Angabe des Servers, der die Exchange Datenbank verifizieren soll (in unserem Fall, soll unser Exchange Server, der auch die Backups ausführt im Anschluss an das Backup den Snapshot mounten und die gebackupte Datenbank verifizieren)

• Angabe des Exchange Server, der konfiguriert werden soll (per default, der Server auf dem der SME installiert ist) – Next

• im nächsten Schritt können die Exchange Datenbanken auf entsprechende NetApp LUNs umgezogen werden, falls die Struktur nicht bereits passend angelegt wurde. In unserem Beispiel haben wir alles entsprechend Best Practice platziert – Next

• im Testsetup haben wir eine Datenbank des Exchange Servers auf lokalen Disks und erhalten deshalb eine Warning. Da wir diese nicht sichern wollen, ignorieren wir die Warning mit „Ja“

• Angabe, wo das / die Snapinfo Folder liegen sollen – wir belassen den default

• Auswahl der zu beachtenden Datenbanken (die System und Testdatenbank lassen wir „außen vor“, da diese in unserem Testsystem auf lokalen Platten liegen)

• bei der Abfrage nach der passenden Protection Policy geben wir die Policy an, die wir im Schritt 2. Anlegen einer Protection Policy in OnCommand für den SME angegeben haben

• wir konfigurieren die Abhängigkeit zwischen MSiSCSI und MSExchangeSA Service

• Konfiguration der Mailbenachrichtigung (Mailserver, Absendeadresse, Empfängeradresse) für Backup-/Configuration-/Restore-Reports

• im Advanced stellen wir ein, dass der ausführliche Report als Attachment oer Mail mitversendet wird

•  wir aktivieren das Monitoring und Reporting und bestätigen die Zusammenfassung mit „Finish“

• die geforderten Tasks, führen wir mit „Start Now“ aus (da die Datenbanken, Logs etc. bereits korrekt in den LUNs liegen, wird im Beispiel bei den Tasks 2-11 nichts ausgeführt) -> Initiale Einrichtung des NetApp SnapManager Exchange erfolgreich

 

 

4. Einrichtung eines Backupjobs für die Exchange Datenbanken

 

 

• nach erfolgreicher Grundeinrichtung richten wir einen Backupjob für alle unsere Datenbanken über den „Backup Wizard“ ein

• Next 😉

 

• Auswahl der zu sichernden Datenbanken

• wir wollen Datenbanken, sowie Transaction Logs backupen

• Full Backup

• die Backups dieses Backupjobs sollen in die Backup Management Group „Daily Backup“ laufen. In diesem Beispiel führen wir nur Backups der Gruppe „Daily“ aus.

• da wir den SnapManager Exchange in OnCommand integrieren, müssen wir die „time stamp naming convention“ verwenden

• Angabe wie lange wir Backups auf der Primärseite vorhalten möchten (SME kümmert sich um die Rotation)

• Angabe, wie lange wir die Möglichkeit haben möchten „Up-to-the-minute“ Restores durchführen zu können (i.d.R. stellt man hier unter „backups generated in the last (days)“ den gleichen Wert ein wie im vorherigen Fenster ein – wie lange die Backups aufgehoben werden sollen)

• Logfiles werden als Kopie im SnapInfo Folder abgelegt für die im vorherigen Schritt angegebene „up-to-the-minute“ Retention

• wir konfigurieren, dass nach erfolgreichem Backup automatisiert die LUNs / DBs aus dem Snapshot an den Server gemountet werden und das Backup verifiziert wird

• Nach erfolgreichem primären Snapshot soll der SME diesen Snapshot direkt per SnapVault auf eine Secondary NetApp übertragen mit dem Retention-Tag „daily“. Die Rotation auf der Backupseite übernimmt die Einstellungen, die wir in der OnCommand Protection Policy unter „daily“ definiert haben

• keine weiteren Kommandos benötigt

• Einstellungen im Summary prüfen und über „Schedule“ einen entsprechenden Windows Task mit der entsprechend „geklickten“ Scriptzeile anlegen

• im Popupfenster dem Task einen Namen geben und den Task mit dem NetApp SME Serviceuser (z.B. svcsme) konfigurieren

• Zeiten angeben, wann der SME Task laufen soll bzw. das konfigurierte Backup (in unserem Beispiel läuft das Backup 2x am Tag. Wir haben somit 14 Stände bei einer eingestellten Retention von 7 Tagen auf der Primärseite – SME – und 28 Stände bei einer eingestellten Retetion von 2 Wochen – Protection Policy OnCommand)

• Scriptzeile bei Bedarf prüfen / analysieren, was welcher Wert darstellt

• Task evtl. nach einer gewissen Laufzeit ohne Erfolg beenden lassen

• Backupjob für den SME mit automatisierter Übertragung im Rahmen eines Scheduled Tasks konfiguriert -> Noch nicht starten oder ausführen!

 

5. Konfiguration des OnCommand Datasets für SME

 

 

•  in der OnCommand Management Console hat der NetApp SnapManager Exchange automatisch ein Dataset für den Exchange Server angelegt

• im Dataset fehlt noch die Zuweisung, auf welches Aggregat bzw. auf welchen Ressourcepool mit welcher Provisioning Policy gebackupt werden soll
• Auswahl des vom SME angelegten Datasets – Edit

• unter „Backup“ – „Provisioning / Ressource Pools“ eine entsprechende Provisioning Policy (auf welcher Klasse von RAID geschütztem Storage und mit welchen Eigenschaften sollen die Zielvolumes automatisiert angelegt werden), sowie einen Ressourcepool (auf welchen Aggregaten) zuweisen

• im Hintergrund legt OnCommand automatisiert die Zielvolumes an, baut die SnapVault Beziehungen automatisch auf und startet die initiale Übertragung -> nach erfolgreicher initialer Übertragung steht die Beziehung und das Dataset ist „Conformant“

• nun kann das Konstrukt getestet werden. Einfach den angelegten „Scheduled Task“ auf dem Exchange Server ausführen

• im SnapManager for Echange kann unter „Reports“ der Verlauf des Jobs eingesehen werden, im NetApp OnCommand unter „Jobs“ die Übertragung und was auf der Secondary Site passiert

 

 

6. Beispiel: Restoreablauf einer SME Datenbank

 

 

• Let’s do a sample restore… Wie, das ist doch nur eine Backupsoftware.. 😉
• In diesem Beispiel findet ihr die Vorgehensweise für einen up-to-the-minute Restore einer Exchange Datenbank
• „Restore“ auswählen

• „Restore Wizard“ starten

• Restore von einem Backup, das auf diesem Server erstellt wurde

• Auswahl des gewünschten Backupstandes (Local Backups -> Primärstorage, Archived Backups -> Backupstorage)

• wohin soll gerestored werden?

• Auswahl der Datenbank, die gerestored werden soll

„Up-to-the-minute“ Restore

• entsprechenden Recovery Point auswählen

• „No, this is an actual restore“

• weitere Einstellungen für den Restore

ACHTUNG: wenn dieser beispielhafte Wizard am Ende bestätigt wird, dann führt er wirklich einen Restore auf der Original-DB durch!

 

 

 7. Beispiel: Restoreablauf eines einzelnen Objekts per Single Mailbox Recovery (SMBR)

 

 

• im Gegensatz zum Restore von der kompletten Datenbank können per NetApp Single Mailbox Recovery (SMBR) einzelne Mails, Kalendereinträge, Aufgaben usw. aus einem Snapshot gerestored werden
• hierfür gehen wir auf einen Adminserver und melden uns mit dem SME Serviceuser an (z.B. svcsme)

• unter diesem User installieren wir NetApp SnapDrive (im Optimalfall die gleiche Version wie auf dem Exchange Server auf dem SME die Backups triggert), eine passende Microsoft Office Version und eine kompatible NetApp Single Mailbox Recovery Version (i.d.R. Next – Next – Next – Finish)

• Konfiguration von Outlook für den SnapManager Exchange User (kann zum Testen des Zugriffes auf den Exchange Servers verwendet werden oder z.B. als Zielpostfach für den Restore von einzelnen Objekten)

• per SnapDrive die Datenbank-LUN aus dem entsprechenden Snapshot an den Admin-Server connecten

• per SnapDrive die passende Log-LUN aus dem entsprechenden Snapshot an den Admin-Server connecten

• das Datenbankfile, sowie die entsprechenden Logfiles sind in den gemounteten Laufwerken sichtbar
• Anstarten von Single Mailbox Recovery
• „Open Source“

• Auswahl der *.edb aus dem gemounteten Snapshotlaufwerk, sowie Angabe des Logfilepfades aus dem 2. gemounteten Snapshotlaufwerk

• „Open Target Exchange Server“ (Alternativ kann auch in ein PST-File ge“restore“d werden, das man dann klassisch über Microsoft Outlook Bordmittel importiert)

• verbinden zu einer aktiven Mailbox auf dem produktiven Exchange, in die der Restore eines Objektes stattfinden soll (der SnapManager Exchange Service User braucht im Exchange Zugriffsrechte auf das entsprechende Zielpostfach. In unserem Beispiel wollen wir uns auf das svcsme Postfach verbinden und dorthin restoren)

• Auswahl des Quellpostfachs, Auswahl der Mail, Kalendereintrages oder ähnlichem

• das gewünschte Objekt per Drag-and-Drop ind das „Live“-Postfach ziehen -> taucht wieder im Live-System auf -> Restore erfolgreich durchgeführt

• zum Abschluss die gemapten Datenbank- und Logfile-LUNs aus dem Snapshot per SnapDrive wieder disconnecten

 

 

– I wish I could be a Virtual Machine –

 

 

Benjamin Ulsamer

Senior Consultant & Trainer

teamix GmbH