EMC® AppSync™ 2.2.2 Benutzer- und

Transcription

EMC® AppSync™
Version 2.2.2
Benutzer- und Administratorhandbuch
302-002-307
01
Copyright © 2012-2015 EMC Deutschland GmbH. Alle Rechte vorbehalten. Veröffentlicht in Deutschland.
EMC ist der Ansicht, dass die Informationen in dieser Veröffentlichung zum Zeitpunkt der Veröffentlichung korrekt sind. Die
Informationen können jederzeit ohne vorherige Ankündigung geändert werden.
Die Informationen in dieser Veröffentlichung werden ohne Gewähr zur Verfügung gestellt.Die EMC Corporation macht keine
Zusicherungen und übernimmt keine Haftung jedweder Art im Hinblick auf die in diesem Dokument enthaltenen Informationen
und schließt insbesondere jedwede implizite Haftung für die Handelsüblichkeit und die Eignung für einen bestimmten Zweck
aus.Für die Nutzung, das Kopieren und die Verteilung der in dieser Veröffentlichung beschriebenen EMC Software ist eine
entsprechende Softwarelizenz erforderlich.
EMC², EMC und das EMC Logo sind eingetragene Marken oder Marken der EMC Corporation in den USA und anderen Ländern.
Alle anderen in diesem Dokument erwähnten Marken sind das Eigentum ihrer jeweiligen Rechtsinhaber.
Die aktuellen behördlichen Vorschriften für Ihre Produktserie können unter EMC Online-Support (https://support.emc.com)
abgerufen werden.
EMC Deutschland GmbH
Am Kronberger Hang 2a 65824 Schwalbach/Taunus
Tel.: +49 6196 4728-0
http://germany.emc.com
2
EMC AppSync 2.2.2 Benutzer- und Administratorhandbuch
INHALT
Kapitel 1
Einführung
9
AppSync-Überblick ....................................................................................... 10
Servicepläne – Überblick................................................................. 10
Rollenbasiertes Management...........................................................11
Berichte zeigen den bewährten Schutz ............................................ 12
AppSync-Architektur......................................................................................12
AppSync-Server ...............................................................................12
AppSync-Agent (Host-Plug-in) – Übersicht........................................12
AppSync-Konsole (Benutzeroberfläche)........................................... 15
REST-Schnittstelle............................................................................ 15
Unterschiede zwischenAppSync und Replication Manager............................ 16
Interoperabilität von AppSync und Replication Manager ..................16
Kapitel 2
AppSync-Konsole
17
Übersicht über die Konsole........................................................................... 18
Ausführen von Aktionen................................................................... 18
In der Konsole angezeigte Zeiten......................................................18
Troubleshooting von Konsolenproblemen........................................ 18
Troubleshooting von Problemen der Browser-Anzeige ..................... 19
Behebung von Browseraktualisierungsproblemen............................19
Festlegen von Einstellungen.......................................................................... 19
Starten der AppSync-Konsole........................................................................ 19
Kapitel 3
Servicepläne
21
Servicepläne – Überblick...............................................................................22
Erstellen eines Serviceplans.............................................................24
Zusammenfassung der Exchange-Serviceplaneinstellungen.......................... 26
Zusammenfassung der SQL Server-Serviceplaneinstellungen........................ 28
Zusammenfassung der Oracle-Serviceplaneinstellungen...............................30
Zusammenfassung der Serviceplaneinstellungen für Dateisysteme............... 33
Zusammenfassung der VMware-Serviceplaneinstellungen............................ 35
Kapitel 4
AppSync-CLI-Dienstprogramm
39
AppSync CLI-Dienstprogramm – Lernprogramm.............................................40
Kapitel 5
Schutz von Microsoft Exchange
45
Übersicht über die Exchange-Unterstützung ................................................. 46
Bereitstellung von AppSync für den Exchange-Schutz: Zusammenfassung der
Schritte......................................................................................................... 48
Erkennen von Exchange-Datenbanken .............................................48
Entfernen eines Exchange-Postfachservers ......................................49
Schützen von DAG-Datenbanken in einem Serviceplan.....................49
Schutz einer Exchange-Datenbank ............................................................... 49
Sofortiges Schützen einer Exchange-Datenbank...............................50
Abonnieren eines Serviceplans für eine Exchange-Datenbank.......... 50
Beenden des Serviceplan-Abonnements für eine Datenbank ........... 50
3
INHALT
Eine Kopie nach Bedarf ablaufen lassen...........................................51
Erstellen einer Datenbankkopie auf der Seite Copies........................51
Serviceplandetails........................................................................................ 52
Servicezeitplan................................................................................ 52
Anwendungserkennung................................................................... 53
Anwendungszuordnung................................................................... 53
Pre-copy script ................................................................................ 53
Create copy...................................................................................... 54
Post-copy script............................................................................... 56
Unmounten einer früheren Kopie......................................................57
Kopie mounten................................................................................ 57
Kopie validieren............................................................................... 60
Post-mount script.............................................................................61
Unmount copy..................................................................................61
Mounten von Exchange-Kopien..................................................................... 61
Mounten und Wiederherstellen von Einschränkungen...................... 62
Mounten einer Exchange-Kopie nach Bedarf.................................... 62
Unmounten einer Exchange-Kopie ...................................................65
Übersicht über das Wiederherstellen einer Exchange-Kopie...........................66
Von der Wiederherstellung betroffene Einheiten...............................66
Wiederherstellen aus einer Exchange-Kopie..................................... 67
Manuelles Wiederherstellen einer Exchange-Datenbank.................. 68
Wiederherstellen einer eigenständigen Exchange-Datenbank auf
XtremIO............................................................................................69
Wiederherstellen einer Exchange-Datenbank-DAG auf XtremIO.........70
Teilwiederherstellung.......................................................................71
Wiederherstellen von Protokollen aus absturzkonsistenten (APiT)
Kopien............................................................................................. 72
Wiederherstellen einer gelöschten Exchange-Datenbank................. 73
Wiederherstellung auf Elementebene .............................................. 73
Troubleshooting des EMCAppSync Exchange Interface-Service......................75
Kapitel 6
Schutz von SQL Server
77
Übersicht über die SQL Server-Unterstützung................................................ 78
SQL Server-Voraussetzungen........................................................... 78
SQL Server-unterstützte Konfigurationen..........................................79
Unterstützung für SQL Server auf virtuellen Laufwerken....................79
Erforderliche Berechtigungen und Rechte.........................................79
Aktualisieren von Anmeldedaten für eine SQL Server-Instanz........... 81
Unterstützung für AlwaysOn-Verfügbarkeitsgruppen......................................81
SQL Server-Transaktionsprotokollbackup...................................................... 82
Konfigurieren der Backups von Transaktionsprotokollen für SQL Server
........................................................................................................ 83
Konfigurieren von Protokollbackup-Skripten.................................... 85
Ausführen eines Protokollbackups nach Bedarf............................... 85
Anzeigen von Protokollbackups für einen Serviceplan......................86
Anzeigen von SQL-Datenbankkopien................................................86
Ablauf von Protokollbackups............................................................89
Überlegungen für die Arbeit mit SQL Server in einem Cluster......................... 91
SQL Server-Benutzerdatenbank-Ordner......................................................... 93
Erkennen von SQL Server-Instanzen................................................. 93
Schützen einer SQL-Datenbank..................................................................... 94
Konfigurieren von Schutz für SQL Server-Datenbanken.....................94
Beenden des Serviceplan-Abonnements für eine Datenbank............95
Erkennen von SQL Server-Datenbanken ...........................................95
4
INHALT
Erstellen einer Datenbankkopie auf der Seite Copies........................95
Ablaufen lassen einer SQL-Datenbankkopie nach Bedarf................. 96
Zusammenfassung und Einzelheiten von Serviceplänen.................. 96
Mount-Überlegungen für SQL Server............................................................107
Mounten von SQL Server-Datenbankkopien nach Bedarf................108
Unmounten eine SQL Server-Kopie ................................................ 113
Wiederherstellung von SQL Server-Datenbanken – Übersicht...................... 114
Wiederherstellungsüberlegungen für Datenbanken in einer
Verfügbarkeitsgruppe.................................................................... 114
Betroffene Entitäten während der Wiederherstellung......................115
Wiederherstellen einer primären Datenbank oder einer sekundären
Datenbank mit Failover.................................................................. 115
Wiederherstellen einer sekundären Datenbank ohne Failover........ 116
Wiederherstellen einer SQL Server-Kopie....................................... 117
Wiederherstellen einer SQL Server-Kopie auf XtremIO.................... 119
SQL Server-Wiederherstellungsdienstprogramm (Assqlrestore)...... 123
Neuverwendung von SQL Server-Datenbankkopien..................................... 127
Arbeiten mit dem Assistenten zum Festlegen einer neuen Verwendung
...................................................................................................... 129
Kapitel 7
Schutz von Oracle
133
Überblick über die Oracle-Unterstützung..................................................... 134
Oracle-Berechtigungen...................................................................134
Integration von Red Hat Cluster Services mit AppSync.................... 134
Unterstützung für Oracle Data Guard.............................................. 135
Integration von Veritas Cluster Services......................................... 138
HACMP-Clusterintegration.............................................................. 139
Voraussetzungen und unterstützte Konfigurationen....................... 141
Schutz einer Datenbank.............................................................................. 144
Erkennen von Datenbanken........................................................... 145
Abonnieren eines Serviceplans für eine Datenbank........................145
Oracle-Kopien-Seite....................................................................... 146
Zusammenfassung von Serviceplan und -details......................................... 148
Servicezeitplan.............................................................................. 148
Außer Kraft setzen von Planungen für Servicepläne........................ 149
Anwendungserkennung................................................................. 150
Anwendungszuordnung................................................................. 150
Speichereinstellungen................................................................... 150
Präkopieskript............................................................................... 150
Kopie erstellen...............................................................................151
Automatischer Ablauf von Kopien.................................................. 152
Postkopieskript..............................................................................153
Unmount previous copy................................................................. 153
Pre-Mount script............................................................................ 153
Kopien mounten ............................................................................154
Außer Kraft setzen von Mount-Einstellungen in einem Serviceplan. 155
Post mount script...........................................................................155
Unmount copy................................................................................156
Mounten einer Oracle-Kopie........................................................................ 156
Mounten einer Kopie mit dem Assistenten zum Mounten von Oracle
...................................................................................................... 157
RMAN-Katalogisierungsfunktion .................................................... 159
Auf eigenständigem Server mounten und Skripte für eine manuelle
Recovery vorbereiten......................................................................160
Auf Cluster mounten und wiederherstellen.....................................162
5
INHALT
Mounten und Unmounten von VMAX 3-Kopien............................... 162
Wiederherstellen einer Oracle-Kopie........................................................... 163
Von der Wiederherstellung betroffene Einheiten.............................164
Vdisk-Wiederherstellung mit betroffenen Entitäten........................ 165
Wiederherstellen einer RAC-Kopie.................................................. 165
Wiederherstellen einer RAC-Kopie für betroffene Entitäten............. 166
Wiederherstellen einer Kopie aus XtremIO......................................168
Übersicht über die Neuverwendung.............................................................172
...................................................................................................... 175
Mounten und Wiederherstellen des Oracle-Clone eines Clone für ein
RecoverPoint-Lesezeichen .............................................................176
Mounten und Wiederherstellen des Oracle-Snap eines CloneRecoverPoint-Lesezeichens ........................................................... 177
Kapitel 8
Schutz von Dateisystemen
179
Übersicht über die Unterstützung für das Dateisystem................................ 180
Schutz von NFS-Dateisystemen auf VNX-Speicher.......................... 180
Zusammenfassung der Serviceplaneinstellungen für Dateisysteme.............182
Abonnieren eines Serviceplans für ein Dateisystem....................... 184
Außer Kraft setzen von Planungen für Servicepläne ....................... 184
Servicezeitplan.............................................................................. 185
Anwendungserkennung................................................................. 185
Anwendungszuordnung................................................................. 185
Phase Pre-copy script.....................................................................185
Phase Create Copy mit den Callout-Skripten Einfrieren und
Wiederaufnehmen......................................................................... 186
Phase Post-copy script................................................................... 187
Unmounten einer früheren Kopie....................................................188
Kopie mounten.............................................................................. 188
Post-mount script...........................................................................190
Mounten einer Kopie mit dem Assistenten für das Mounten von Dateisystemen
................................................................................................................... 191
Ändern des Mount-Punkts für ein betroffenes Dateisystem.............192
Unmounten einer Dateisystemkopie ..............................................192
Mount-Einstellungen in einem Serviceplan außer Kraft setzen........193
Wiederherstellen eines Dateisystems..........................................................193
Manuelles Wiederherstellen einer Kopie des Dateisystems auf XtremIO
...................................................................................................... 194
Kapitel 9
Schutz von VMware-Rechenzentren
197
Konfigurationsvoraussetzungen ................................................................. 198
VMware vStorage VMFS-Anforderungen .........................................198
Erkennen von Rechenzentren ..................................................................... 201
Liste der Rechenzentren ................................................................ 201
Hinzufügen eines VMware vCenter Servers .................................... 202
Liste der VMware-Datenspeicher ................................................... 202
Schutz eines VMware-Datenspeichers............................................202
Überlegungen zum Mounten einer VMFS-Kopie .......................................... 211
Mounten einen Datenspeicherkopie nach Bedarf........................... 211
Unmounten einer VMware-Datastore-Kopie ................................... 213
Wiederherstellen eines Datenspeichers aus einer Kopie..............................214
VM-Vorgänge während der Wiederherstellung................................ 215
6
INHALT
Betroffene Datenspeicherentitäten während der Wiederherstellung
...................................................................................................... 215
Wiederherstellen einer VMware-Datastore-Kopie aus XtremIO........ 216
Wiederherstellen einer virtuellen Maschine aus einer Kopie........................ 218
Wiederherstellungsoptionen für virtuelle Maschinen......................220
Wiederherstellung von Dateien und Ordnern mit VMFS- oder NFSDatenspeichern...........................................................................................222
Wiederherstellen einer Datei oder eines Ordners aus einem virtuellen
Laufwerk........................................................................................ 222
Kapitel 10
Überwachen von AppSync
225
Konzepte und Best Practices für RPO...........................................................226
Bericht zur Recovery Point-Compliance.......................................... 226
Exportieren eines RPO-Compliance-Berichts in CSV-Datei...............226
Überblick über die RPO-Compliance............................................... 227
Warnmeldungen und zugehörige Ereignisse................................................ 227
Bestätigen von Warnmeldungen.....................................................228
Senden von Warnmeldungen per E-Mail...................................................... 229
Konfigurieren der Servereinstellungen für E-Mail-Benachrichtigungen
...................................................................................................... 229
Festlegen der Empfänger von E-Mail-Warnmeldungen.................... 229
Repurpose Monitor......................................................................................230
7
INHALT
8
KAPITEL 1
Einführung
In diesem Kapitel werden folgende Themen behandelt:
l
l
l
AppSync-Überblick ............................................................................................... 10
AppSync-Architektur..............................................................................................12
Unterschiede zwischenAppSync und Replication Manager.................................... 16
Einführung
9
Einführung
AppSync-Überblick
EMC AppSync bietet einen einfachen, SLA-orientierten Ansatz nach dem
Selfserviceprinzip zum Schutz, zur Wiederherstellung und zum Klonen von kritischen
Microsoft- und Oracle-Anwendungen und VMware-Umgebungen. Nach der Definition von
Serviceplänen (z. B. Gold, Silber und Bronze), können Anwendungseigentümer
Produktionsdaten schnell mit Granularität auf Elementebene durch die Verwendung der
zugrunde liegenden EMC Replikationstechnologien schützen, wiederherstellen und
klonen. AppSync bietet auch einen Überwachungsservice für den Anwendungsschutz, der
Warnmeldungen ausgibt, wenn die SLAs nicht eingehalten werden.
AppSync unterstützt die folgenden Anwendungen und Speicherarrays:
l
Anwendungen: Oracle, Microsoft SQL Server, Microsoft Exchange und VMware-VMFS
und NFS-Datenspeicher und Dateisysteme.
l
Speicher: VMAX, VMAX 3, VNX (Block und File), VNXe, XtremIO und ViPR Controller
l
Replikationstechnologien: VNX Advanced Snapshots, VNXe Unified Snapshots, SRDF,
TimeFinder, SnapVX, RecoverPoint, XtremIO-Snapshot und ViPR-Snapshot.
Servicepläne – Überblick
AppSync schützt eine Anwendung durch die Erstellung von Kopien von
Anwendungsdaten.
Sie geben für AppSync an, was Sie schützen möchten, indem Sie ein Anwendungsobjekt
zu einem Serviceplan abonnieren. Wenn der Serviceplan ausgeführt wird, wird eine Kopie
erstellt. Der Serviceplan kann die Kopie auch mounten, unmounten und validieren und
benutzererstellte Skripte ausführen. Diese Aktionen heißen Phasen des Serviceplans und
unterscheiden sich zwischen Anwendungen.
AppSync schließt mehrere anwendungsbezogene Pläne ein, die ohne Änderungen
übernommen werden können. Mit dem Befehl Subscribe to Plan and Run wenden Sie die
Einstellungen eines Serviceplans auf die Daten an und schützen diese sofort.
Hinweis
Diese Servicepläne werden standardmäßig bereitgestellt. Sie sind allerdings nicht auf die
Einstellungen in diesen Plänen beschränkt. Sie können diese Pläne anpassen und eigene
benutzerdefinierte Pläne erstellen.
Es gibt drei Arten von Kopiervorgängen (abhängig vom verwendeten Plan):
l
Create local copy: Erstellt bei Serviceplänen des Typs Bronze eine lokale Kopie (VNX
Advanced Snapshots, VMAX TimeFinder Clone, VMAX VP Snap, VMAX 3 SnapVX,
Lesezeichen für RecoverPoint, XtremIO-Snapshot, VNX2e Unified Snapshot, VNXDatei-Snapshots, ViPR-Snapshot) auf dem Server.
l
Create remote copy: Erstellt bei Serviceplänen des Typs Silber auf dem Ziel eine
Remotekopie, wie beispielsweise ein RecoverPoint-Lesezeichen, eine VMAX-Kopie
des SRDF-Ziels (R2) oder einen VNX Snap eines ReplicatorV2-Remote-Clone.
l
Create local and remote copy: Erstellt bei Serviceplänen des Typs Gold lokale und
Remote-Kopien (RecoverPoint-Lesezeichen) auf dem Ziel.
Servicepläne legen auch die bevorzugte Reihenfolge der Speichertechnologie fest, die
während der Erstellung von Kopien wie beispielsweise VNX-Snapshot oder VMAX-Clone/
Snap oder RecoverPoint-Lesezeichen zu verwenden sind.
Alle-Servicepläne können den Zeitraum für den automatischen Ablauf der Kopien
festlegen. Wenn Sie ein Objekt für einen Serviceplan abonnieren, bildet es eine Gruppe
10
Einführung
mit anderen Objekten, die bereits im Plan enthalten sind. Für alle Objekte im Serviceplan
gelten die Workflows und Einstellungen, die im Serviceplan definiert sind. (Die
Ausnahmen sind die spezifischen Außerkraftsetzungen für den Start oder das Mounten
einer Kopie.)
Die Servicepläne bieten außerdem ein paar anwendungsbezogene Kopieoptionen. Der
Oracle-Serviceplan hat beispielsweise die folgenden Kopieoptionen:
l
Place database in hot backup mode (standardmäßig aktiviert)
l
Copy the Fast Recovery Area (standardmäßig deaktiviert)
l
Index and copy the block change tracking (BCT) file (standardmäßig deaktiviert)
l
Create backup control file (standardmäßig deaktiviert)
Die Standardservicepläne bieten Schutzstufen mit Tiering. Wenn Sie einen Serviceplan
ändern wollen, passen Sie dessen Einstellungen an Ihre Anforderungen an oder erstellen
einen neuen Plan.
Mounten und Unmounten von VMAX 3-Kopien
Mount-/Unmount-Vorgänge auf VMAX 3 umfassen das Masking/Unmasking von LUNs
oder einer Gruppe von LUNs für einen Host. AppSync stützt sich auf die AutoProvisioning-Funktion von VMAX 3.
Der Mount-Host muss dem VMAX 3-Array per Zoning zugewiesen werden. Als Nächstes
können Sie eine Masking-Ansicht mit der entsprechenden Initiatorgruppe, Portgruppe
und Speichergruppe erstellen.
Wenn AppSync einen Mount-Vorgang auf VMAX 3 ausführt, erkennt es zuerst den
Hostinitiator für den Mount-Host und ordnet dann basierend auf diesem Hostinitiator
AppSync der Masking-Ansicht zu (oder entfernt die Zuordnung). Dieser Vorgang
bestimmt, in welcher Speichergruppe die Ziel-LUNs maskiert/demaskiert werden. Beim
Mounten/Unmounten von RDM oder Vdisk identifiziert AppSync die Masking-Ansicht, die
auf dem Hostinitiator für den ESX-Server basiert.
Sie können das erwünschte Service-Level-Ziel (SLO) für die Ziel-LUN in der Mount-Phase
des Serviceplans auswählen. Wenn eine Speichergruppe für den Mount-Host mit der
gewünschten SLO vorhanden ist, fügt AppSync die LUN zur Speichergruppe hinzu. Wenn
diese Speichergruppe nicht vorhanden ist, fügt AppSync die LUN einer Speichergruppe
hinzu, die für den Host maskiert ist.
Wenn eine Speichergruppe zur Auswahl von Zielgeräten konfiguriert ist, entfernt AppSync
die Geräte aus der Speichergruppe zum Zeitpunkt des Mount-Vorgangs und fügt sie der
Speichergruppe für den Mount-Host hinzu. Die Geräte werden der ursprünglichen
Speichergruppe hinzugefügt, wenn die Kopie abgelaufen ist.
Rollenbasiertes Management
AppSync unterstützt den rollenbasierten Zugriff auf Ressourcen und Funktionen.
Sie können AppSync für mehrere Benutzer einrichten. Jedem Benutzer können eine oder
mehrere Rollen zugewiesen werden, die seinen Verantwortlichkeiten und Anforderungen
entsprechen. Sie können lokale AppSync-Benutzer erstellen und optional Benutzer über
einen LDAP-Server (Lightweight DirectoryAccess Protocol) hinzufügen, der die
Autorisierung übernimmt.
Bestimmte Benutzerrollen und deren Berechtigungen finden Sie im EMC AppSyncSicherheitskonfigurationsleitfaden auf der EMC Support-Website.
Rollenbasiertes Management
11
Einführung
Berichte zeigen den bewährten Schutz
AppSync erzeugt Berichte, die Ihnen mitteilen, ob die Daten geschützt, wiederherstellbar
und mit den Service-Level-Agreements vorgabenkonform sind.
Die Berichte in AppSync müssen nicht bearbeitet werden. Warnmeldungen und Berichte
können problemlos auf der obersten Ebene des AppSync-Dashboard angezeigt werden.
Warnmeldungen können in E-Mail gesendet werden. AppSync-Berichte können im CSVFormat (Comma-separated Value) exportiert werden.
AppSync-Architektur
AppSync-Komponenten umfassen den AppSync-Server, den Agent (Host-Plug-inSoftware) und die Benutzerschnittstellen (Benutzeroberfläche oder Konsole).
Abbildung 1 AppSync-Architekturschema
AppSync-Server
Die AppSync-Serversoftware befindet sich auf einem unterstützten Windows-System. Sie
steuert die Servicepläne und speichert Daten zu jeder von ihr erstellten Kopie.
Das Repository ist in einer PostgreSQL-Datenbank auf dem AppSync-Server gespeichert.
AppSync-Agent (Host-Plug-in) – Übersicht
AppSync installiert Lightweight-Agent-Plug-in-Software auf den Produktions- und MountHosts.
AppSync verlagert die Plug-in-Software vom AppSync-Server auf den Host, wenn Sie den
Host als Ressource hinzufügen. In einer Umgebung, die verhindert, dass der AppSyncServer auf einen Host zugreift, können Sie das Agent-Plug-in manuell installieren.
12
Einführung
Hinweis
Bei einer Push-Installation bleibt das Agent-Host-Plug-in in derselben Version wie
derAppSync-Server. Wenn Sie das Agent-Host-Plug-in aktualisieren möchten, wählen Sie
Update-Plug-in mit Settings > Server aus.
Für UNIX werden Tar-Bündel für AIX und Linux übertragen und während der
Hostregistrierung auf dem Host extrahiert.
Beispiele für Hosts, auf denen sich das Plug-in befindet, sind Exchange-Postfachserver
oder Exchange-Validierung oder Mount-Hosts. Das Agent-Plug-in wird nicht für den
Schutz von VMware-Datenspeichern verwendet.
Bereitstellungsanforderungen für Linux
Die aktuellen Supportversionen finden Sie in der EMC AppSync Support Matrix. Die
Anforderungen für die Bereitstellung unter Linux umfassen:
l
Red Hat Linux
l
Oracle® Linux
l
CentOS
l
SuSE Linux
l
Kompatibles Linux sg3_utils-Paket
l
Unterstützter Linux-Host mit aktiviertem Root-SSH oder ein anderer BS-Benutzer mit
aktivierter SUDO-Funktion
l
Unterstützte Oracle-Datenbanksoftware, die für die Datenbank-Recovery auf MountHosts installiert ist.
l
Unterstützte Oracle-Datenbank, die mit /etc/oratab-Einträgen auf Produktionshosts
erstellt wird
l
Gültige Oracle-Datenbankkonfiguration
AIX-Bereitstellungsanforderungen
l
OpenSSH- und OpenSSL-Pakete. OpenSSL ist eine Voraussetzung für die OpenSSHInstallation.
l
Die folgenden Pakete sind obligatorisch, damit AppSync mit AIX-Hosts funktioniert.
n
BZip2 Paket. Dieses Paket ist auch obligatorisch, damit AppSync mit AIX-Hosts
funktioniert. Das Zlib-Paket ist eine Voraussetzung für die Bzip2-Installation.
n
SUDO-Paket (nur wenn die SUDO-Funktion gewünscht wird) oder für OpenSSH und
OpenSSL. Zlib ist eine Voraussetzung zum Aktivieren der SUDO-Funktion.
l
Unterstützte Oracle-Datenbanksoftware, die für die Datenbank-Recovery auf MountHosts installiert ist.
l
Unterstützte Oracle-Datenbank, die mit /etc/oratab-Einträgen auf
Produktionshosts erstellt wird
l
Gültige Oracle-Datenbankkonfigurationen wie zuvor in diesem Abschnitt
beschrieben.
Paketstandorte:
l
OpenSSH und OpenSSL-Pakete befinden sich auf der Betriebssystem-CD.
l
Bzip2, Zlib und Sudo befinden sich auf der Website für IBM AIX Toolbox.
Linux/AIX mit Sudo-Benutzeranforderungen
Sie können den Root-Benutzer auf AppSync-Produktions- und Mount- oder ProduktionsHosts verwenden. Wenn Sie den Root-Benutzer nicht verwenden möchten, kann in
AppSync-Agent (Host-Plug-in) – Übersicht
13
Einführung
AppSync ein anderer Benutzer mit Sudo-Zugriff verwendet werden. Erstellen Sie dazu
einen Betriebssystem-Benutzer auf Oracle-Produktions- und -Mount-Servern und nehmen
Sie dann die folgenden Änderungen vor:
l
Bearbeiten Sie die Datei sudousers mit visudo und fügen Sie diese Zeilen am
Ende der Datei hinzu. (Sie müssen die Datei als Root-Benutzer bearbeiten.)
n
Defaults:appsync !requiretty
n
Defaults:appsync !env_reset
n
{user} ALL = (root) NOPASSWD: /{install path}/acp
Dabei ist {user} der Benutzername, den Sie soeben erstellt haben, und {install
path} der Ort, an dem die AppSync-Agent-Software installiert werden soll. Stellen Sie
sicher, dass der Benutzer in das Verzeichnis schreiben kann, z. B.:
appsync ALL = (root) NOPASSWD:
/opt/emc/appsync/acp
Installation
Wenn Sie alle vor der Bereitstellung erforderlichen Aufgaben abgeschlossen haben,
installieren Sie AppSync. Informationen hierzu finden Sie im EMC AppSync Installation and
Configuration Guide.
Unterstützte Gerätekonfigurationen
Die neuesten Versionen finden Sie in der EMC AppSync Support Matrix.
Gerätezuordnung mit:
Tabelle 1 Unterstützte Gerätekonfigurationen
AIX
LINUX
Multipathing: Das MultipathingPaket ist für Plattformen
erforderlich, auf denen VNX, VMAX
oder RecoverPoint auf VNX in nicht
virtualisierten Umgebungen
ausgeführt wird.
Multipathing: Das Multipathing-Paket ist für Plattformen
erforderlich, auf denen VNX, VMAX oder RecoverPoint auf
VNX in nicht virtualisierten Umgebungen ausgeführt wird.
l
Natives MPIO
l
PowerPath
Natives MPIO
l
PowerPath
l
Veritas DMP
n
Unterstützt, wenn auf dem Produktions- und dem
Mount-Host DMP installiert ist und die DMP-Geräte
keine Partition haben.
n
Unterstützt mit anderen als ASM-Datenbanken auf
VXDMP-Geräten mit oder ohne VXVM VolumeManager
l
Symbolische Links
l
Linux-ASMLib (nur ASM)
l
mknod-Geräte
l
UDEV-Bindungen
l
Block-Geräte
l
Dev-mapper-Geräte
l
Block-Geräte mit O_DIRECT
l
Symbolische Links
Dateisysteme:
14
l
Einführung
Tabelle 1 Unterstützte Gerätekonfigurationen (Fortsetzung)
AIX
l
LINUX
jfs und jfs2
AppSync-Konsole (Benutzeroberfläche)
DieAppSync-Konsole ist webbasiert. Zu den unterstützten Browsern gehören Chrome,
Internet Explorer und Firefox. Weitere Informationen zu den unterstützten Versionen
finden Sie in der AppSync-Supportmatrix.
Es gibt ein Problem beim Ausführen von Flash auf Windows Server 2012 R2. Adobe Flash
ist nur installiert und aktiviert, wenn Sie die Desktop-Erfahrung aktivieren. Es ist nicht
erforderlich, Flash Player auf Windows 2008 R2 zu aktivieren. Rufen Sie für Windows
2008 R2 die Adobe-Website auf und installieren Sie die neueste Version von Flash Player.
Für Windows Server 2008 R2 oder Windows Server 2012 R2 müssen Sie die verstärkte
Sicherheitskonfiguration in Internet Explorer deaktivieren. Schließen Sie alle geöffneten
Internet Explorer-Fenster. Überprüfen Sie diese Szenarien:
1.
l
Wenn Sie Windows Server 2008 R2 ausführen, navigieren Sie in der
Serverübersicht zum Abschnitt „Sicherheitsinformationen“ und klicken Sie dann
auf Verstärkte Sicherheitskonfiguration für IE konfigurieren. Das Dialogfeld
Verstärkte Sicherheitskonfiguration für Internet Explorer wird geöffnet.
l
Wenn Sie Windows Server 2012 ausführen, klicken Sie auf Diesen lokalen Server
konfigurieren, um die Konfigurationsseite Lokaler Server zu öffnen. Navigieren
Sie neben „Verstärkte Sicherheitskonfiguration für IE“ zu „Einstellungen“ und
klicken Sie dann auf Ein um das Dialogfeld „Verstärkte Sicherheitskonfiguration
für Internet Explorer“ zu öffnen.
2. Um die verstärkte Sicherheitskonfiguration für Internet Explorer zu bearbeiten, wenn
Mitglieder der lokalen Administratorgruppe angemeldet sind, navigieren Sie zu
Administratoren und klicken Sie dann auf Aus.
3. Um die verstärkte Sicherheitskonfiguration für Internet Explorer zu bearbeiten, wenn
alle anderen Benutzer angemeldet sind, navigieren Sie zu Benutzer und klicken Sie
dann auf Aus (Empfohlen).
4. Klicken Sie auf OK, um die Änderungen zu übernehmen.
Aktivieren Sie auch die Desktopdarstellung auf Windows Server 2012. Führen Sie die
folgenden Schritte aus:
1. Öffnen Sie den Server-Manager und klicken Sie auf Rollen und Features hinzufügen.
2. Wenn der Assistent „Rollen und Features hinzufügen“ angezeigt wird, geben Sie
Werte auf den Seiten für Installationstyp, Serverauswahl und Serverrollen ein.
3. Erweitern Sie auf der Seite „Features“ die Option „Benutzeroberflächen und
Infrastruktur“ und wählen Sie Desktopdarstellung aus.
4. Wählen Sie auf der Bestätigungsseite die Option Zielserver bei Bedarf automatisch
neu starten aus und klicken Sie auf Installieren.
REST-Schnittstelle
AppSync verfügt über eine Rest-Schnittstelle, die Anwendungsprogrammierern den
Zugriff auf Informationen ermöglicht, die durchAppSync gesteuert werden.
AppSync-Konsole (Benutzeroberfläche)
15
Einführung
Die API wird im AppSync-REST API Reference Guide beschrieben
Unterschiede zwischenAppSync und Replication Manager
Obwohl es sich um verwandte Produkte handelt, gibt es wichtige Unterschiede
zwischenAppSync und Replication Manager.
AppSync unterscheidet sich hauptsächlich dadurch von Replication Manager, dass das
Konzept der Servicepläne (Schutz-Policies) verwendet wird, die darauf ausgelegt sind,
bestimmte Servicelevelanforderungen zu erfüllen. Die Servicepläne können umfassend
angepasst und mit einem Klick auf die Anwendung angewendet werden. AppSync ist für
Anwendungsadministratoren und Speicheradministratoren einfach zu verwenden, da
keine Vorkenntnisse im Bereich Datenreplikationstechnologie erforderlich sind.
Interoperabilität von AppSync und Replication Manager
Replication Manager und AppSync-Server können nicht auf demselben Host vorhanden
sein.
Der Replication Manager-Client und das AppSync-Agent-Plug-in können auf demselben
Host installiert sein und koexistieren.
16
KAPITEL 2
AppSync-Konsole
l
l
l
Übersicht über die Konsole................................................................................... 18
Festlegen von Einstellungen.................................................................................. 19
Starten der AppSync-Konsole................................................................................ 19
AppSync-Konsole
17
AppSync-Konsole
Übersicht über die Konsole
Die AppSync-Konsole ist in Abschnitte für Management, Reporting und Administration
angeordnet.
l
Das Dashboard ist eine anpassbare Ansicht der Berichte und Warnmeldungen. In der
Dashboard-Standardansicht werden der RPO-Status (Recovery Point Objective) der
geschützten Anwendungen, der Abschlussstatus von Serviceplänen, die neuesten
Warnmeldungen und die gerade ausgeführten Aktivitäten angezeigt.
l
Copy Management enthält eine Auflistung erkannter Anwendungen wie Microsoft
Exchange und Microsoft SQL Server, und bietet den anwendungsorientierte
Einstiegspunkt für Schutz, Mounten, Wiederherstellen, Serviceplanabonnement und
andere Vorgänge.
l
Über die Registerkarte Service Plans können Sie Einstellungen für Servicepläne
anzeigen und ändern und Listen mit Objekten, die einen Serviceplan abonnieren, die
Kopien, die von diesen Objekten erstellt wurden, und die Ereignisse, die bei der
Ausführung des Serviceplans erzeugt wurden, anzeigen.
l
Monitoring zeigt Warnmeldungen, Recovery-Punkt-Complianceberichte und
Abschlussberichte für Servicepläne an.
l
Settings ist für das Hinzufügen von Servern, VMware vCenter-Servern und
Speicherressourcen zu AppSync. Unter „Settings“ finden Sie außerdem das
Management von Lizenzen, die Benutzeradministration und Servereinstellungen.
l
Support bietet Zugriff auf Anleitungsvideos und auf die Supportseite von AppSync
auf der EMC Supportwebsite.
Benutzerrollen steuern, welche Bereiche der Konsole angezeigt werden und welche
Vorgänge in den Menüs aufgeführt sind. Die Konsole zeigt beispielsweise keine der
Registerkarten Copy Management und Service Plans für einen Benutzer an, der nur über
die Rolle „Sicherheitsadministrator“ verfügt.
Ausführen von Aktionen
Wählen Sie ein Objekt aus und klicken Sie auf die Aktionsschaltflächen unten auf der
Seite, um eine Aktion für dieses Objekt auszuführen. Verwenden Sie die Umschalttaste,
um mehrere Objekte auszuwählen. Verwenden Sie die Strg-Taste, um nicht
zusammenhängenden Objekte auswählen. Klicken Sie auf die Aktionsschaltfläche am
Ende der Auswahl, um eine Aktion für mehrere Objekte auszuführen.
Beispiele für Objekte sind Anwendungshosts, Speichersysteme, Postfachserver,
Datenbanken, Kopien und Benutzer.
In der Konsole angezeigte Zeiten
In der AppSync-Konsole angezeigte Zeiten spiegeln die lokale Uhrzeit des AppSyncServers, nicht der Konsole wieder.
Troubleshooting von Konsolenproblemen
Unerwartetes Verhalten der AppSync-Konsole kann mit dem Browser und seinen
unterstützenden Add-Ons and Extensions verbunden sein.
Prüfen Sie die aktuelle Supportmatrix auf unterstützte Browserversionen.
18
AppSync-Konsole
Troubleshooting von Problemen der Browser-Anzeige
Erfahren Sie, wie Probleme mit der Datenanzeige in der AppSync-Konsole gelöst werden.
Symptom: AppSync zeigt veraltete oder beschädigte Daten an.
Lösung:
1. Löschen Sie den Browsercache. Weitere Informationen finden Sie in der
browserspezifischen Dokumentation.
2. Löschen des Java-Cache:
a. Wählen Sie Start > Control Panel (Windows 7) oder Start > Control Panel >
Programs (Windows 2008/2012).
b. Doppelklicken Sie auf das Java-Symbol.
c. Wählen Sie Settings unter Temporary Internet Files.
d. Wählen Sie Delete Files.
e. Wählen Sie alle verfügbaren Optionen und dann OK.
Behebung von Browseraktualisierungsproblemen
Symptom: Einige Inhalte in der AppSync-Konsole werden nicht angezeigt.
Ursache: Sie haben den Browser mithilfe des Browsersymbols Refresh oder durch
Drücken von F5 auf Ihrer Tastatur aktualisiert.
Lösung: Aktualisieren Sie die Inhalte in der AppSync-Konsole, indem Sie das Symbol
Refresh oben rechts in der Konsole verwenden.
Festlegen von Einstellungen
Sie können die Sprache festlegen, die in der Benutzeroberfläche angezeigt wird, und die
Konsole zur Verwendung über Remoteverbindungen optimieren.
Vorgehensweise
1. Wählen Sie die Sprache aus der Liste der installierten Sprachen aus.
Wenn Sie die Sprache ändern, müssen Sie den Browser schließen und AppSync
erneut starten, damit die Einstellungen wirksam werden.
2. Aktivieren Sie die Option Optimize for Remote Connection, um die
Benutzeroberfläche zur Verwendung über Remoteverbindungen zu optimieren.
Beispielsweise können bestimmte visuelle Effekte zu einem langsamen
Bildschirmaufbau führen, wenn Sie remote auf die Konsole zugreifen. Mit dieser
Option wird die Reaktionszeit beim Remotezugriff verbessert. Die
Managementoptionen oder -funktionen werden dadurch nicht beeinträchtigt.
Starten der AppSync-Konsole
Sie können die AppSync-Konsole auf einem unterstützten Webbrowser von einem
beliebigen System aus ausführen, das über Konnektivität zum AppSync-Server verfügt.
Verwenden Sie http://appsync_server:8085/Appsync, um die Konsole zu starten.
Troubleshooting von Problemen der Browser-Anzeige
19
AppSync-Konsole
Wenn die Konsole auf dem AppSync-Server ausgeführt wird, können Sie die Konsole
starten, indem Sie auf die AppSync-Verknüpfung auf dem Installationsprogramm-Desktop
klicken. appsync_server muss ein Hostname und darf keine IP-Adresse sein.
20
KAPITEL 3
Servicepläne
l
l
l
l
l
l
Servicepläne – Überblick.......................................................................................22
Zusammenfassung der Exchange-Serviceplaneinstellungen.................................. 26
Zusammenfassung der SQL Server-Serviceplaneinstellungen................................ 28
Zusammenfassung der Oracle-Serviceplaneinstellungen.......................................30
Zusammenfassung der Serviceplaneinstellungen für Dateisysteme....................... 33
Zusammenfassung der VMware-Serviceplaneinstellungen.................................... 35
Servicepläne
21
Servicepläne
Weitere Informationen zu Standard-Serviceplantypen, Objekt- und Kopie-Abonnements,
Serviceplaneinstellungen, Zeitplänen und Außerkraftsetzungen.
Informationen darüber, wie jeder Arraytyp Servicepläne unterstützt, finden Sie im
Abschnitt über Voraussetzungen im EMC AppSync Installations- und
Konfigurationsleitfaden.
AppSync erstellt und verwaltet Kopien von Anwendungsdaten. Ein Serviceplan definiert
die Attribute für diese Kopien. Sie können einen Serviceplan für
Anwendungsdatenobjekte abonnieren. Dann führt AppSync den Serviceplan aus und
erstellt Kopien der Daten von Attributen, die Sie im Plan angegeben haben. Kopien, die
von einem Serviceplan erzeugt wurden, werden in der Registerkarte Copies des
Serviceplans aufgeführt.
Es gibt keine Begrenzung der Anzahl der Objekte, für die Sie einen Serviceplan
abonnieren können. AppSync teilt die Arbeit automatisch für eine optimale Performance
auf. Wenn Sie genaue Kontrolle darüber benötigen, welche Objekte für das Mounten,
Skripting und Validieren gruppiert werden, überlegen Sie sich, mehrere Servicepläne zu
erstellen und die Objekte zwischen den Plänen zu verteilen. Diese Methode funktioniert,
wenn die Objekte, für die ein Serviceplan abonniert wird, vom gleichen Server sind.
Abonnieren Sie für nicht mehr als 12 Objekte einen Serviceplan, wenn Sie diese Methode
verwenden.
Serviceplantypen
AppSync bietet die folgenden anwendungsspezifischen Tiered-Pläne. Es gibt drei Arten
von Kopieoptionen (abhängig vom verwendeten Plan):
l
Create local copy: Bei Bronze-Serviceplänen erstellt AppSync eine lokale Kopie auf
dem Server mit VNX Advanced Snapshot, VMAX TimefinderClone, VMAX VP Snap,
VMAX 3 SnapVX, Lesezeichen für RecoverPoint, XtremIO-Snapshot, VNX2e Unified
Snapshots, VNX File-Snapshots, ViPR-Snapshot.
AppSync unterstützt außerdem Snapshots für ViPR als Kopietechnologie für
Anwendungen, die über ViPR Controller bereitgestellt werden. AppSync unterstützt
nur Anwendungen, die von ViPR mit virtuellen Blockpools bereitgestellt werden, die
nur von VMAX/VPLEX (mit VMAX2 und XtremIO)/XtremIO-Speichersystemen gesichert
werden. Derzeit werden nur VMware-Datenspeicher, Oracle und Dateisysteme auf
Linux und AIX unterstützt.
l
Create remote copy: Bei Silber-Serviceplänen erstellt AppSync eine Remotekopie
(RecoverPoint-Lesezeichen VMAX2-Kopie auf dem SRDF-Ziel (R2), VMAX V3 SnapVX
oder einen VNX File-Snap eines Remoteclone von ReplicatorV2) auf dem Ziel.
l
Create local and remote copy: Bei Gold-Serviceplänen erstellt AppSync lokale und
Remote-Kopien (z. B. RecoverPoint-Lesezeichen) auf dem Ziel.
Hinweis
Stellen Sie sicher, dass Sie die Speicherfähigkeiten verstehen, wenn Sie einen
Serviceplantyp auswählen. Nicht alle Speichertechnologien unterstützen RemoteReplikation, sodass Silber- oder Gold-Servicepläne möglicherweise für die
Anwendungsdaten nicht erfolgreich sind.
Bronze-, Silber- und Gold-Servicepläne werden standardmäßig bereitgestellt, Sie können
diese jedoch anpassen oder eigene Pläne erstellen.
22
Servicepläne
Serviceplaneinstellungen
Wenn Sie für ein Objekt einen Serviceplan abonnieren, bildet es eine Gruppe mit den
anderen Objekten, die bereits Teil des Plans sind. Für alle Objekte im Serviceplan gelten
die Workflows und Einstellungen, die im Serviceplan definiert sind.
Servicepläne legen eine Speicherreihenfolgenvoreinstellung fest, die die bevorzugte
Reihenfolge der Speichertechnologie darstellt, die der Serviceplan bei der Erstellung von
Kopien verwendet. Wenn AppSync eine Voreinstellung nicht erfüllen kann, versucht es,
die nächste Voreinstellung in der Liste der Speicherreihenfolgenvoreinstellungen zu
verwenden. Sie können die Voreinstellungen anpassen, um Servicepläne zu erstellen, die
die von Ihnen gewünschte Replikationstechnologie verwenden.
Die Standard-Servicepläne bieten Schutzstufen mit Tiering. Wenn Sie Einstellungen
ändern müssen, ändern Sie den Serviceplan.
In jedem Serviceplan kann der automatischen Ablauf von Kopien festgelegt werden, der
die Anzahl der Kopien beschränkt, die AppSync behält, und automatisch ältere Kopien
ablaufen lässt, die die Anzahl übersteigen, die für den Serviceplan definiert ist.
Servicepläne bieten außerdem einige anwendungsspezifische Kopieoptionen, die
bearbeitet werden können. Der Oracle-Serviceplan hat beispielsweise die folgenden
Kopieoptionen:
l
Place the database in hot backup mode (standardmäßig aktiviert).
l
Copy the Fast Recovery Area (standardmäßig deaktiviert).
l
Index and copy BCT (block change tracking) file (standardmäßig deaktiviert).
l
Create backup control file (standardmäßig deaktiviert)
Damit der Replikationsspeicher nicht überbelastet oder zu schnell verbraucht wird, legen
Sie bei der Einrichtung des Serviceplans die Werte in den folgenden Feldern fest:
l
RPO in der Phase Startup des Serviceplans
l
Always keep n Copies in der Phase Create copy
Überwachen Sie außerdem das Speichersystem mit der Benutzeroberfläche des
Speichersystems auf der AppSync-Konsole.
Außerkraftsetzen der Planungen eines Serviceplans
Sie können die Planungseinstellungen eines Serviceplans außer Kraft setzen und
separate Planungen für einzelne Objekte angeben, für die der Plan abonniert wird.
In der Phase Plan Startup des Serviceplans wählen Sie einen Wiederholungstyp, der
darauf basiert, welcher Serviceplan ausgelöst wird. Diese Wiederholungstyp gilt für alle
Anwendungsobjekte, für die ein Serviceplan abonniert wird. Sie können die Einstellungen
jedoch außer Kraft setzen und separate Einstellungen für ausgewählte Objekte angeben.
Sie können nur die Einstellungen für den Recurrence Type außer Kraft setzen, der für den
Plan bereits ausgewählt wurde. Beispielsweise soll der gewählte Wiederholungstyp On
selected days... ausgeführt werden und die Einstellungen lauten Run at 12:00 AM on
days Fri, Sat. Wenn Sie diese Einstellungen für ein Objekt außer Kraft setzen, können Sie
nur die Zeit und die Wochentage ändern. Sie können als Teil des Außerkraftsetzens
keinen anderen Wiederholungstyp wählen.
Wenn Sie als Serviceplanadministrator die allgemeinen Wiederholungseinstellungen (z.
B. die Ausführungszeit oder die Minuten nach der vollen Stunde) ändern, wirkt sich dies
nicht auf die Einstellungen der Außerkraftsetzungen aus. Wenn Sie den
Wiederholungstyp selbst ändern, sind die Außerkraftsetzungen nicht mehr gültig. Der
neue Wiederholungstyp wird jetzt für alle Objekte angewendet, bis Sie einzelne
Einstellungen angeben, die auf dem neuen Wiederholungstyp basieren.
23
Servicepläne
Hinweis
Wenn mehrere Pläne für ein Anwendungsobjekt abonniert werden, dürfen die Pläne nicht
so geplant werden, dass sie gleichzeitig ausgeführt werden.
Serviceplanereignisse
Ereignisse zeigen den Fortschritt eines Vorgangs an. Sie werden erzeugt, wenn ein
Serviceplan ausgeführt und eine Kopie gemountet oder wiederhergestellt wird.
Die Ereignisinformationen enthalten Folgendes:
l
Typ (Fehler, Warnung oder Information)
l
Datum und Uhrzeit des Ereignisses
l
Beschreibung
l
Server
Sie können Ereignisse anzeigen unter:
l
Registerkarte Events des Serviceplans. In der AppSync-Konsole zeigt Ihnen
beispielsweise die Registerkarte Events unter Service Plans > Microsoft Exchange >
Bronze die Ereignisse an, die für die Exchange-Kopie unter dem Plan relevant sind.
l
Anwendungsseite Copies Gehen Sie beispielsweise zu Copy Management > VMware
Datacenters, wählen Sie ein Rechenzentrum und dann einen Datenspeicher, um die
Seite Copies anzuzeigen. Wählen Sie eine Kopie, um dessen zugehörigen Ereignisse
in der Seite Events anzuzeigen.
l
Ereignisse werden auch zum Zeitpunkt angezeigt, an dem sie in den Assistenten zum
Mounten und Wiederherstellen erzeugt werden, und wenn ein Objekt einen Plan
abonniert und dieser sofort ausgeführt wird.
Standardmäßig werden nur die Ereignisse der obersten Ebene, die als
Meilensteinereignisse bekannt sind, angezeigt. Ein Meilensteinereignis wird nach
Abschluss jeder Phase in einem Serviceplanzyklus erzeugt. Sie können ein
Meilensteinereignis zum Anzeigen der anderen Ereignisse, die in der Phase erzeugt
wurden, erweitern.
Erstellen eines Serviceplans
Sie können einen neuen Serviceplan durch Verwenden eines vorhandenen Plans als
Vorlage erstellen.
Bevor Sie beginnen
Dieser Vorgang erfordert die Serviceplan-Administratorrolle in AppSync
Vorgehensweise
1. Wählen Sie Service Plans aus.
2. Klicken Sie auf Create.
3. Wählen Sie im Dialogfeld Create New Plan einen vorhandenen Plan aus, den Sie als
Vorlage verwenden möchten. Geben Sie einen Namen und eine Beschreibung für den
neuen Serviceplan ein.
Hinweis
Der neue Serviceplan umfasst dieselbe Planung und andere Einstellungen wie die
Vorlage. Es gibt jedoch keine Objekte, für die der neue Serviceplan abonniert wurde.
24
Servicepläne
Ausführen eines Serviceplans nach Bedarf
Servicepläne werden anhand einer Planung ausgeführt. Sie können jedoch einen
Serviceplan auch nach Bedarf ausführen lassen.
Bevor Sie beginnen
Dieser Vorgang erfordert die Datenadministratorrolle in AppSync
Vorgehensweise
2. Wählen Sie die zu schützende Anwendung aus.
3. Wählen Sie einen Plan aus der Liste aus und klicken Sie auf OK.
Die Ausführung dieses Serviceplans gilt für alle Anwendungsobjekte, für die derzeit
der Plan abonniert ist.
Der Serviceplan wird sofort ausgeführt. Das Dialogfeld Run Service Plan zeigt den
Fortschritt beim Erkennen und Zuordnen des Anwendungsspeichers an und der
Anwendungsschutz beginnt gemäß den Serviceplaneinstellungen.
4. Klicken Sie auf Details, um weitere Events anzuzeigen, die in jeder Phase aufgetreten
sind.
Deaktivieren und erneutes Aktivieren eines Serviceplans
Standardmäßig sind alle Servicepläne aktiviert. Sie können einen Serviceplan
deaktivieren und erneut aktivieren.
Bevor Sie beginnen
Vorgehensweise
2. Wählen Sie die Anwendung aus.
3. Wählen Sie den Plan aus und klicken Sie auf Disable oder Enable.
Löschen eines Serviceplans
Sie können einen benutzererstellten Serviceplan löschen.
Bevor Sie beginnen
l
l
Sie können keinen integrierten Serviceplan (z. B. Bronze, Silver, Gold) löschen.
l
Ein Serviceplan kann nicht gelöscht werden, wenn der Plan über Abonnements
verfügt oder wenn für den Plan zugeordnete, gültige Kopien vorhanden sind.
Vorgehensweise
2. Wählen Sie die Anwendung aus.
3. Wählen Sie einen benutzererstellten Plan aus und klicken Sie auf Delete.
4. Klicken Sie zur Bestätigung auf Yes.
Erstellen eines Serviceplans
25
Servicepläne
Zusammenfassung der Exchange-Serviceplaneinstellungen
Mit den Standardeinstellungen für Servicepläne wird eine anwendungskonsistente Kopie
alle 24 Stunden erstellt. Nur die Replikationstechnologie, die durch Copy type in der
Kopieerstellungsphase angegeben wird, unterscheidet sich von Plan zu Plan.
Tabelle 2 Serviceplan für Exchange - Standardeinstellungen
Einstellung
Aktiviert/
Standardeinstellungen
nicht aktiviert
Zeitplan
Plan Startup
Aktiviert
Automatische Planung
Typ der
Wiederholung:
Erstellt eine
Kopie alle 24
Stunden, mit der
ersten
Ausführung um
Mitternacht
(00:00).
Recovery Point
Objective (RPO):
Eine Kopie sollte
alle 24 Stunden
erstellt werden.
(Warnmeldung
wird
ausgegeben,
wenn das Ziel
nicht erreicht
wird.)
Application
discovery
Aktiviert
Keine
Bestimmt durch
die Phase Plan
Startup
Application
mapping
Aktiviert
Keine
Beginnt nach
Abschluss der
Phase
Application
discovery
Pre-copy script
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Phase
Application
mapping
Create copy
26
Aktiviert
l
n
Bronze: Lokale Kopie erstellen
Beginnt nach
Abschluss der
Phase Pre-copy
n
Silber: Remotekopie erstellen
script
n
Gold: Lokale und Remotekopie erstellen (einschließlich VNX FileSnapshots).
Kopietyp:
Servicepläne
Tabelle 2 Serviceplan für Exchange - Standardeinstellungen (Fortsetzung)
Einstellung
Aktiviert/
nicht aktiviert
Zeitplan
l
Exchange-Backuptyp: Komplett, Kopie oder differenziell
l
Voreinstellung der Speicherreihenfolge: Snapshots, Lesezeichen
Hinweis
Bei Silber- und Gold-Serviceplänen stehen Lesezeichen und VNX FileSnapshots zur Verfügung. VMAX SRDF wird für Silber-Servicepläne
(Remote-Kopie) unterstützt.
l
Speichereinstellungen:
n
Include RecoverPoint copies in expiration rotation policy: Aktivieren
Sie diese Option, um RecoverPoint-Kopien beim Berechnen von
Rotationen einzubeziehen.
Hinweis
Wenn diese Option nicht aktiviert ist, sammeln sich RecoverPointKopien an und werden beibehalten, bis die Lesezeichen aus dieser
RecoverPoint-Appliance „herausfallen“.
l
Post-copy
script
Nicht aktiviert
Scannen von Ereignisprotokollen:
n
Fehlschlagen bei Fehler -1018
n
n
n
Fehlschlagen bei Ereignis-ID 447
n
Fehlschlagen bei Ereignis-ID 448
n
Nicht zulassen, dass sich Datenbanken und Protokolle auf
demselben Volume befinden
Keine
Beginnt nach
Abschluss der
Phase Create
copy
Unmount
previous copy
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Phase
Postkopieskrip
t
Mount copy
Nicht aktiviert
l
Mount on server: Ursprünglicher Host
l
Mount with access: Schreibgeschützt
l
Mount Path: Standardpfad
Beginnt nach
Abschluss der
Phase Unmount
previous copy
Hinweis
Das Laufwerk, das für das Mounten angegeben ist, darf keine geclusterte
Festplatte sein.
l
Copy metadata files to: Standardpfad
Zusammenfassung der Exchange-Serviceplaneinstellungen
27
Servicepläne
Tabelle 2 Serviceplan für Exchange - Standardeinstellungen (Fortsetzung)
Einstellung
Validate copy
Post-mount
script
Aktiviert/
nicht aktiviert
Nicht aktiviert
Nicht aktiviert
l
Image access mode: Protokollierter Zugriff
l
Parallele Überprüfung von Datenbanken und Protokollen
l
Protokollüberprüfung nicht minimieren
l
Drosselung der Überprüfung nicht durchführen
Keine
Zeitplan
Beginnt nach
Abschluss der
Phase Mount
copy
Beginnt nach
Abschluss der
Phase Validate
copy
Unmount copy
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Phase Post-
Mount-Skript
Zusammenfassung der SQL Server-Serviceplaneinstellungen
Tabelle 3 Serviceplan für SQL Server - Standardeinstellungen
Einstellung
Aktiviert/
nicht aktiviert
Zeitplan
Plan Startup
Aktiviert
Typ der
Wiederholung:
Erstellt eine
Kopie alle 24
Stunden, mit der
ersten
Ausführung um
Mitternacht
(00:00).
Recovery Point
Objective (RPO):
Eine Kopie sollte
alle 24 Stunden
erstellt werden.
(Warnmeldung
wird
ausgegeben,
wenn das Ziel
nicht erreicht
wird).
28
Servicepläne
Tabelle 3 Serviceplan für SQL Server - Standardeinstellungen (Fortsetzung)
Einstellung
Aktiviert/
nicht aktiviert
Zeitplan
Application
discovery
Aktiviert
Keine
Durch
Planstartphase
bestimmt
Application
mapping
Aktiviert
Keine
Beginnt nach
Abschluss der
Anwendungserk
ennungsphase
Pre-copy script
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Anwendungszuo
rdnungsphase
Create copy
Aktiviert
l
l
Kopietyp:
n
Bronze: Lokale Kopie erstellen
n
n
Gold: Lokale und Remotekopie erstellen
Beginnt nach
Abschluss der
Phase „Pre-copy
script“
SQL Server-Backuptyp: Full oder Copy
n
Auto Switch to Copy
n
Enable Log Backup
Hinweis
Diese Option muss ausgewählt werden, um Ausführungen von
Protokollbackups nach Bedarf zu ermöglichen.
l
Storage Ordered Preference: Snapshot, Clone, Lesezeichen
l
Ablauf der Datenbankkopien:
n
Include RecoverPoint copies in expiration rotation policy: Aktivieren
Sie diese Option, um RecoverPoint-Kopien beim Berechnen von
Rotationen einzubeziehen.
Hinweis
Wenn diese Option nicht aktiviert ist, sammeln sich RecoverPointKopien an und werden beibehalten, bis die Lesezeichen für diese
aus der RecoverPoint-Appliance „herausfallen“.
l
Backupoptionen für Transaktionsprotokolle:
n
Schedule immediately after database backup = Standardwert.
n
Alle 30 oder 15 Minuten oder alle 1 bis 24 Stunden sind andere
verfügbare Optionen.
Hinweis
Geplante Protokollbackups werden in Zeiten zwischen DatenbankBackups durchgeführt.
n
Backuppfad: Standardpfad
n
Freier Speicherplatz auf dem Volume: 5GB
29
Servicepläne
Tabelle 3 Serviceplan für SQL Server - Standardeinstellungen (Fortsetzung)
Einstellung
Aktiviert/
nicht aktiviert
n
Backupgruppengröße: 5
n
Kürzen von Protokollen: Ausgewählt
n
Prüfsumme Backup: Nicht ausgewählt
n
Komprimierung: Ausgewählt
n
Ablauf von Protokollbackups: Minimale Aufbewahrung 24 Stunden
Zeitplan
Post-copy
script
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Kopieerstellungs
phase
Unmount
previous copy
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Phase „Postcopy script“
Mount copy
Nicht aktiviert
l
Kopie mounten
n
Mount on Server: Ursprünglicher Host
n
Mount with access: Schreibgeschützt
n
Mount Path: Standardpfad
Beginnt nach
Abschluss der
Phase „Unmount
previous copy“
Hinweis
Das für das Mounten angegebene Laufwerk darf keine
Clusterfestplatte sein.
n
Metadatendateien kopieren auf: Standardpfad
n
Image Access mode: Protokollierter Zugriff
Post-mount
script
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Phase „Mount
copy“
Unmount copy
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Phase „Postmount script“
Pre-log backup
script
Nicht aktiviert
Keine
Beginnt nach
Protokollbackup
Post-log
backup script
Nicht aktiviert
Keine
Beginnt nach
Protokollbackup
Zusammenfassung der Oracle-Serviceplaneinstellungen
Verwenden Sie diese Liste der Standardeinstellungen für Servicepläne für OracleDatenbanken in AppSync.
30
Servicepläne
Tabelle 4 Serviceplan für Oracle-Server - Standardeinstellungen
Einstellung
Aktiviert/
nicht aktiviert
Zeitplan
Plan Startup
Aktiviert
Wiederholungstyp
: AppSync erstellt
eine Kopie alle 24
Stunden, mit der
ersten
Ausführung um
Mitternacht
(00:00). Recovery
Point Objective
(RPO): Erstellt
eine Kopie alle
24 Stunden.
Application
discovery
Aktiviert
Keine
Bestimmt durch
die
Planstartphase
Application
mapping
Aktiviert
Keine
Beginnt nach
Abschluss der
Anwendungserke
nnungsphase.
Pre-copy script
Aktiviert
Keine
Beginnt nach
Abschluss der
Anwendungszuor
dnungsphase
Create copy
Aktiviert
Die Kopieerstellungsoptionen in den Serviceplaneinstellungen bieten
verschiedene Steuerelemente, die beeinflussen, wie die Oracle-Kopie
erstellt wird. Gültige Kopietypen:
Beginnt nach
Abschluss der
Phase „Pre-copy
script“.
l
Bronze: Lokale Kopie erstellen.
l
l
Gold: Lokale und Remote-Kopie erstellen.
Einstellungsoptionen für das Erstellen einer Kopie umfassen:
l
Place the database in hot backup mode (standardmäßig aktiviert).
Wenn diese Option aktiviert ist, wird die Datenbank in dieser
Schutzphase in einen Hot-Backupmodus versetzt und es werden
Kopien der Archivprotokolle sofort erstellt. Wenn Sie diese Option
deaktivieren, wird die Datenbank nicht in den Hot-Backupmodus
versetzt, und die Kopie wird aus den nicht stillgelegten Livedaten ohne
jegliche Instrumentierung der Datenbank erstellt.
l
Copy the Fast Recovery Area (standardmäßig deaktiviert)
Wenn diese Option aktiviert ist, informiert dieses Feld AppSync, eine
Kopie des zugrunde liegenden Speichers zu erstellen, der durch die
FRA beim Schutz der Archivprotokolldateien der Datenbank verwendet
wird.
l
Index and copy the BCT (block change tracking) file (standardmäßig
deaktiviert)
Wenn diese Option aktiviert ist, erstellt AppSync einen Eintrag in der
Oracle-BCT-Datei (Block Change Tracking) und kopiert die Datei im
Zusammenfassung der Oracle-Serviceplaneinstellungen
31
Servicepläne
Tabelle 4 Serviceplan für Oracle-Server - Standardeinstellungen (Fortsetzung)
Einstellung
Aktiviert/
nicht aktiviert
Zeitplan
Rahmen des Schutzes erneut. Diese Datei kann dann in einem
Anwendungsbeispiel (Mounten und Backup) verwendet werden, um
ein beschleunigtes inkrementelles Backup bereitzustellen. Diese
Option erfordert den Hot-Backupmodus.
l
Create backup control file for RMAN cataloging (standardmäßig
deaktiviert)
Wenn diese Option aktiviert ist, erstellt AppSync eine binäre
Backupsteuerdatei mit einer Anforderung zur Katalogisierung der
Datenbankinhalte in einem Remote-RMAN-Katalog. Diese Option
erfordert den Hot-Backupmodus.
l
Expiration: Include RecoverPoint copies in expiration rotation policy:
Wählen Sie diese Option aus, um RecoverPoint-Kopien beim
Berechnen von Rotationen einzubeziehen. Wenn Sie diese Option nicht
auswählen, sammeln sich RecoverPoint-Kopien an und werden
beibehalten, bis ihre Lesezeichen aus der RecoverPoint-Appliance
rotiert werden.
Hinweis
Wenn RecoverPoint-Kopien in der Rotationsrichtlinie berücksichtigt
werden, werden mit der Policy ALWAYS_CONSOLIDATE Lesezeichen
erstellt. Andernfalls werden mit der Policy NEVER_CONSOLIDATE
Lesezeichen erstellt. Eine Definition dieser Konsolidierungsrichtlinien
finden Sie in der RecoverPoint-Dokumentation.
Post-copy
script
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Kopieerstellungsp
hase
Unmount
previous copy
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Postkopiephase.
Pre-mount
script
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Appliance durch
die Phase
„Unmount
previous copy“.
Mount and
Recovery
Nicht aktiviert
Optionen für Mounten und Recovery:
Beginnt nach
Abschluss der
Phase „Pre-mount
script“.
32
l
Mount on standalone server (RM-Äquivalent: No recover)
l
Mount on standalone server and create RMAN catalog entry (RMÄquivalent : Catalog with RMAN )
l
Mount on standalone server and recover database (RM-Äquivalent:
Recover)
l
Mount on standalone server and prepare scripts for manual database
recovery (RM-Äquivalent: Prepare-only/generate scripts for manual
recovery)
Servicepläne
Tabelle 4 Serviceplan für Oracle-Server - Standardeinstellungen (Fortsetzung)
Einstellung
Aktiviert/
nicht aktiviert
l
Zeitplan
Mount on grid cluster and recover as RAC database (RM-Äquivalent:
Mount as RAC database)
Post-mount
script
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Mount-Phase.
Unmount copy
Nicht aktiviert
Keine
Beginnt nach
Abschluss der
Phase „Postmount script“.
Zusammenfassung der Serviceplaneinstellungen für
Dateisysteme
Verwenden Sie diese Tabelle, um die Standardeinstellungen für Dateisysteme für die
Serviceplanphasen einschließlich Start, Erkennung, Zuordnung, Prä- und
Postkopyskripting, Mounten/Unmounten und Kopieren kennenzulernen.
alle 24 Stunden erstellt. Nur die Replikationstechnologie, die durch den Kopietyp in der
Phase zur Erstellung der Kopie vorgegeben wird, unterscheidet sich bei den einzelnen
Plänen. In der folgenden Tabelle werden die Standardeinstellungen zusammengefasst:
Tabelle 5 Standardeinstellungen für Servicepläne für
Dateisysteme
Einstellung
Aktiviert/ Standardeinstellungen
nicht
aktiviert
Zeitplan
Plan Startup
Aktiviert
Typ des Wiederholung: Erstellt
eine Kopie alle 24 Stunden, mit
der ersten Ausführung um
Mitternacht (00:00).
Recovery Point Objective (RPO):
Eine Kopie sollte alle 24 Stunden
erstellt werden. (Warnmeldung
wird ausgegeben, wenn das Ziel
nicht erreicht wird.)
Application
discovery
Aktiviert
Keine
Durch die Planstartphase
bestimmt.
Application
mapping
Aktiviert
Keine
Beginnt nach Abschluss der
Anwendungserkennungsphase.
Pre-copy script
Nicht
aktiviert
Keine
Anwendungszuordnungsphase
Zusammenfassung der Serviceplaneinstellungen für Dateisysteme
33
Servicepläne
Dateisysteme (Fortsetzung)
Einstellung
nicht
aktiviert
Zeitplan
Create copy
Aktiviert
Präkopieskript-Phase
Kopietyp:
l
Bronze: Lokale Kopie
erstellen
l
Silber: Remote-Kopie
erstellen (VMAX v2, v3
VMAX, RecoverPoint und
VNX File).
l
Gold: Lokale und
Remotekopie erstellen
(RecoverPoint und VNX
File).
Auch:
34
l
Storage Ordered
Preference: Snapshot,
Clone und Lesezeichen
l
Include RecoverPoint
copies in expiration
rotation policy – Wählen
Sie diese Option aus, um
RecoverPoint-Kopien
beim Berechnen von
Rotationen
einzubeziehen. Wenn Sie
diese Option nicht
auswählen, sammeln sich
RecoverPoint-Kopien an
und werden beibehalten,
bis ihre Lesezeichen aus
der RecoverPointAppliance „herausfallen“.
Post-copy script
Nicht
aktiviert
Keine
Kopieerstellungsphase
Unmount
previous copy
Nicht
aktiviert
Keine
Postkopieskript-Phase
Mount copy
(Eine
PrämountskriptPhase ist
verfügbar für
Servicepläne für
Dateisysteme)
Nicht
aktiviert
Mount Copy
Phase zum Unmounten der
vorherigen Kopie
l
Mount on Server:
Ursprünglicher Host
l
Mount with access:
Lesen/Schreiben
l
Mount Path:
Standardpfadimage
Servicepläne
Einstellung
nicht
aktiviert
l
Access mode:
Protokollierter Zugriff
l
Copy to Mount: Lokal (nur
für Gold-Pläne)
l
Use Dedicated Storage
Group: Standardmäßig
ausgewählt
Zeitplan
Post-mount
script
Nicht
aktiviert
Keine
Phase zum Mounten der Kopie
Unmount copy
Nicht
aktiviert
Keine
Postmountskript-Phase
Zusammenfassung der VMware-Serviceplaneinstellungen
alle 24 Stunden erstellt. Lediglich die Replikationstechnologie, die durch den Kopietyp in
der Phase zur Erstellung der Kopie vorgegeben wird, unterscheidet sich bei den einzelnen
Plänen.
Tabelle 6 VMware-Serviceplan - Standardeinstellungen
Einstellung
Aktiviert/
nicht aktiviert
Schedule
Plan Startup
Aktiviert
Typ der
Wiederholung:
Erstellt eine
Kopie alle 24
Stunden, mit der
ersten
Ausführung um
Mitternacht
(00:00).
Recovery Point
Objective (RPO):
Alle 24 Stunden
sollte eine Kopie
erstellt werden.
(Warnmeldung
wird
ausgegeben,
wenn das Ziel
Automatic schedule
35
Servicepläne
Tabelle 6 VMware-Serviceplan - Standardeinstellungen (Fortsetzung)
Einstellung
Aktiviert/
nicht aktiviert
Schedule
nicht erreicht
wird.)
Application
discovery
Aktiviert
Keine
Durch die Phase
des Planstarts
bestimmt
Application
mapping
Aktiviert
Keine
Beginnt nach
Abschluss der
Phase der
Anwendungserk
ennung
Kopie erstellen
Aktiviert
l
l
l
Kopietyp:
n
Bronze: Create Local copy
n
Silver: Create Remote copy
n
Gold: Create Local and Remote copy
Beginnt nach
Abschluss der
Anwendungszuo
rdnungsphase
Konsistenz der Kopien:
n
Virtual machine Consistent with a maximum of 4 simultaneous VM
snapshots
n
Ignore VM Snapshots for VMs: Link zur Auswahl einzelner virtueller
Maschinen, die zu ignorieren sind, während VMware-Snapshots bei
der Ausführung des Serviceplans erstellt werden.
n
Include Virtual Machine Disk: Aktivieren Sie dieses
Kontrollkästchen, um virtuelle Maschinenlaufwerke zu schützen, die
mehrere Datenspeicher umfassen. Diese Option ist standardmäßig
nicht ausgewählt.
Storage Ordered Preference: Snapshot, Clone, Bookmark
Hinweis
Bei Silber- und Gold-Serviceplänen stehen Lesezeichen und VNX-Datei
sowie VMAX SRDF(Remotekopie) zur Verfügung.
l
Ablaufdatum: Include RecoverPoint copies in expiration rotation policy:
Aktivieren Sie diese Option, um RecoverPoint-Kopien beim Berechnen
von Rotationen einzubeziehen.
Hinweis
Wenn diese Option nicht aktiviert ist, sammeln sich RecoverPoint-Kopien
an und werden beibehalten, bis ihre Lesezeichen aus der RecoverPointAppliance „herausfallen“.
Unmounten
einer früheren
Kopie
Nicht aktiviert
Keine
Kopie mounten
Nicht aktiviert
l
36
No default mount host
Beginnt nach
Abschluss der
Kopieerstellungs
phase
Beginnt nach
Abschluss der
Servicepläne
Tabelle 6 VMware-Serviceplan - Standardeinstellungen (Fortsetzung)
Einstellung
Kopie
unmounten
Aktiviert/
nicht aktiviert
Nicht aktiviert
Schedule
l
Mount using new signature
l
Bei RecoverPoint: mount with logged access und mount local copy (im
Fall eines Plans für lokale und Remotekopien)
l
Bei VNX-Datei: mount copy with read-only or read/write access for local
or remote copies
Keine
Phase zum
Umounten der
vorherigen Kopie
Beginnt nach
Abschluss der
Phase zum
Mounten der
Kopie
37
Servicepläne
38
KAPITEL 4
l
AppSync CLI-Dienstprogramm – Lernprogramm..................................................... 40
39
AppSync CLI-Dienstprogramm – Lernprogramm
Die AppSync-CLI ist ein Dienstprogramm, das mit AppSync ausgeliefert wird und zum
Scripting oder zur Ausführung von Aufgaben über eine Befehlszeilenoberfläche
verwendet wird.
Die AppSync-CLI wird im Verzeichnis EMC\AppSync\appsync-cli installiert. Sie
können sie unter Windows mit der Datei appsync-cli.bat ausführen und in UNIX mit
appsync-cli.sh.
Voraussetzungen
l
Java Runtime Environment (JRE) Version 7 Update 6 (jre1.7) und höher - muss
installiert und im Pfad verfügbar sein.
l
Konfigurierte AppSync-Installation mit registrierten Ressourcen
l
Erkannte Anwendungen auf registrierten Hosts
l
Konfigurierte Servicepläne
l
Achten Sie für I18N-Unterstützung unter Windows darauf, dass Sie vor der
Ausführung die richtige Codeseite festgelegt haben.
Verwenden der Befehlszeilenoberfläche
Sie können die AppSync-CLI auf dem Server ausführen, auf dem AppSync installiert ist.
Sie können außerdem das \EMC\Appsync\appsync-cli-Verzeichnis an einen
anderen Speicherort/Host verschieben. Alle durchgeführten Aktionen geben zu ScriptingZwecken Code 0 für Erfolg und den lokalen Systemausfallcode zurück (-1 unter Windows
oder 255 unter Linux). Die Syntax zur Verwendung der AppSync-CLI lautet:
appsync-cli.bat -action options=value
Geben Sie als Präfix für die Aktion, die Sie durchführen möchten, ein mit Bindestrich
angeschlossenes-argument ein. Alle Optionen speziell für diese Aktion sind key=valuePaare. Wenn Sie einen Wert verwenden, der Leerzeichen enthält, z. B. ein Dateisystem
oder einen Pfad, müssen Sie den Text nicht in doppelte Anführungszeichen setzen.
Setzen Sie einen Wert, der mit einem nachgestellten Schrägstrich endet, nicht in
doppelte Anführungszeichen. Java ignoriert dieses Konstrukt.
Die AppSync-CLI besitzt zudem zwei optionale Argumente für die Verarbeitung von
Meldungen. Sie können jederzeit das Argument verbose=true verwenden, um eine
detailliertere Meldungsausgabe abzurufen, und das Argument silent=true, um alle
Meldungen zu unterdrücken.
Die AppSync-CLI unterstützt die folgenden Aktionen:
40
l
Anmelden/Abmelden
l
Serviceplan ausführen
l
Serviceplan aktivieren/deaktivieren
l
Alle für einen Serviceplan oder ein Anwendungsobjekt erstellten Kopien auflisten
l
Alle Details eines Anwendungsobjekts auflisten
l
Anwendungsobjekts für einen Serviceplan abonnieren/Abonnement aufheben
l
Kopie mounten/unmounten
l
Ablaufen lassen einer Kopie
l
AppSync-Berichte ausführen und exportieren
Verwenden des Hilfe-Arguments „/?“ Argument
Um ein detailliertes Hilfemenü für einen Befehl aufzurufen, fügen Sie das Argument /?
hinzu. Dieses Argument zeigt alle verfügbaren CLI-Befehle an. Aufgrund der Komplexität
und der riesigen Anzahl von Argumenten verwendet die CLI-Hilfe die folgenden
Partitionen für das Hilfemenü:
l
appsync-cli.bat /? Gibt Informationen zu allen von der Befehlszeilenoberfläche
unterstützten Aktionen zurück.
l
appsync-cli.bat -action /? Gibt für die ausgewählte Aktion verfügbare nicht
spezifische Anwendungsoptionen zurück.
l
appsync-cli.bat -action app=<value> /? Gibt für die ausgewählte Aktion
verfügbare anwendungsspezifische Optionen zurück.
l
appsync-cli.bat -mount app=<value> option=<value> /? Gibt
Mount-spezifische Optionen für die angegebene Mount-Option zurück.
Hinweis
Beim Verwenden des Hilfearguments auf nichtenglischen Systemgebietsschemas
müssen Sie das Hilfe-Argument „/?“ in doppelte Anführungszeichen einschließen.
CLI-Aktionen
Anmelden/Abmelden
Nehmen Sie vor dem Ausführen von CLI-Aktionen eine Authentifizierung mit einem
AppSync-Server vor. Der Anmeldebefehl erfordert einen Servernamen, einen HTTPSKommunikationsport, einen AppSync-Benutzer und das zugehörige Passwort. Beispiel:
appsync-cli.bat -login server=<server> port=8445 user=admin
password=<admin_pass>
Nach der Anmeldung wird eine Datei mit dem Namen LOCAL_TOKEN, die die
erforderlichen Authentifizierungsinformationen enthält, im aktuellen Verzeichnis
gespeichert. Wenn diese Datei gelöscht wird oder die aktuelle Sitzung abläuft, muss
durch erneutes Ausführen des Anmeldebefehls eine neue Sitzung erstellt werden.
Wenn Sie Aktionen mit der AppSync-CLI abgeschlossen haben, stellen Sie sicher, dass
Sie sich abmelden. Der Befehl zum Abmelden schließt nicht nur die aktuelle Sitzung,
sondern macht sie auch ungültig. Beispiel:
appsync-cli.bat -logout
Ausführen/Aktivieren/Deaktivieren eines Serviceplans
Sie können einen Serviceplan durch Angabe des Anwendungsnamens und des
Serviceplans aktivieren, deaktivieren und ausführen. Beispiel:
appsync-cli.bat -runSP app=sql service_plan=Bronzee
appsync-cli.bat -enableSP app=sql service_plan=Bronze
appsync-cli.bat -disableSP app=sql service_plan=Bronze
Abonnieren/Abonnement beenden
Sie können ein Anwendungsobjekt über die CLI für einen Serviceplan abonnieren. Die
Optionen sind für jede Anwendung unterschiedlich. Führen Sie den Hilfebefehl „/?“ für
die Anwendung aus, die Sie für eine vollständige Liste der erforderlichen Argumente
abonnieren bzw. deren Abonnement Sie beenden möchten. Beispiel:
appsync-cli.bat -subscribe app=oracle service_plan=<sp1>
oracle_server=<server> db_name=<db1>
41
appsync-cli.bat -unsubscribe app=sql service_plan=<sp1>
sql_server=<server> instance_name=<instance> db_name=<db1>
Auflisten von Kopien und Details zu Kopien
Vor dem Mounten einer Kopie ist die UUID der Kopie erforderlich. Um diese Informationen
zu erhalten, führen Sie den Befehl -listCopies entweder für einen Serviceplan oder
für ein Anwendungsobjekt aus. Auch hier sind die Argumente anwendungsspezifisch.
Verwenden Sie also unbedingt den Hilfebefehl „/?“, um weitere Informationen zu
erhalten.
Mit dem Argument „age“ können Sie auf der Konsole anzeigbare Kopien nach Alter
filtern. Beispiel:
appsync-cli.bat -listCopies app=sql service_plan=Bronze age=month
appsync-cli.bat -listCopies app=sql instance_name=<value>
db_name=<value> age=all
Um weitere Informationen zu einer Anwendungskopie anzuzeigen, führen Sie den Befehl
-copyDetails aus und geben Sie die UUID der Kopie an. Beispiel:
appsync-cli.bat -copyDetails app=<app> copy_ID=<value>
Mounten/Unmounten
Die AppSync-CLI unterstützt alle Mount-Optionen, die über die grafische
Benutzeroberfläche verfügbar sind. Die Optionen sind für jede Anwendung
unterschiedlich. Führen Sie den Hilfebefehl „/?“ für die Anwendung aus, die gemountet
werden soll, um die Mount-Optionen zu bestimmen. Beispiel:
appsync-cli.bat -login server=<server> port=8445 user=admin
password=<admin_pass>
appsync-cli.bat -mount app=sql copy_ID=<value> option=recover
recovery_instance=<value> point_in_time=<value>
appsync-cli.bat -mount app=datastore copy_ID=<value>
mount_host=<value> cluster_mount=yes image_access_mode=virtual_roll
appsync-cli.bat -mount app=oracle copy_ID=<value> option=rac
mount_cluster=<value> mount_servers=<server1,server2>
Um eine Kopie zu unmounten, benötigen Sie den Anwendungsnamen und die uuid der
Kopie. Beispiel:
appsync-cli.bat -unmount app=<app> copy_ID=<value>
Verwenden Sie zum Unmounten der neuesten oder ältesten gemounteten Kopie speziell
für Datenbank\Dateisystem\Datenspeicher die folgenden Befehle:
l
Für Datenspeicher: appsync-cli.bat -unmount app=datastore
datastore=<value> datacenter=<value> vcenter=<value>
option=latestMountedCopy/oldestMountedCopy
l
Für die SQL-Anwendung: appsync-cli.bat -unmount app=sql
instance_name=<value> db_name=<value> option=latestMountedCopy/
oldestMountedCopy
l
Für die Oracle-Anwendung: appsync-cli.bat -unmount app=oracle
oracle_server=<value> db_name=<value> option=latestMountedCopy/
oldestMountedCopy
l
Für Dateisysteme: appsync-cli.bat -unmount app=filesystem
fs_server=<value> fs_name=<value> fs_type=<value>
option=latestMountedCopy/oldestMountedCopy
42
Auf der Ebene des Serviceplans kann die Kopie von jeder beliebigen Datenbank
stammen, die für diesen Service abonniert ist. Zum Unmounten einer Kopie benötigen Sie
den Anwendungsnamen und den Serviceplan. Beispiel:
Die Kopie kann aus jeder beliebigen Datenbank stammen, die für diesen Serviceplan
abonniert ist
Um eine Kopie zu unmounten, benötigen Sie den Anwendungsnamen und den
Serviceplan. Beispiel:
appsync-cli.bat -unmount app=<app> service_plan=<value> option=latestMountedCopy/
oldestMountedCopyy
X
Ablaufen lassen einer Kopie
Um eine Kopie ablaufen zu lassen, benötigen Sie den Anwendungsnamen und die UUID
der Kopie. Geben Sie -listCopies ein. Beispiel: appsync-cli.bat -expire
app=datastore copy_ID=<value>
Ausführen eines Berichts
Es gibt vier verfügbare Berichte, die Sie über die AppSync-CLI ausführen und exportieren
können. Dazu gehören:
l
Recovery Point Objective (RPO)
l
Bericht zum Abschluss des Serviceplans (SPC)
l
Warnmeldungen
l
Aktivitäten
Führen Sie Berichte entweder als Zusammenfassungsberichte oder als detaillierte
Ansicht aus. Verwenden Sie dazu das Argument detailed=true/false. Die Ausnahme
zu dieser Regel ist ein Aktivitätsbericht, der die aktuell ausgeführte Aktivität druckt.
Alle Berichte werden im aktuellen Verzeichnis in eine .csv-Datei exportiert und weisen
einen durch den Berichtstyp bestimmten eindeutigen Namen sowie die lokale Uhrzeit
auf. Über den Hilfebefehl (/?) erhalten Sie weitere Unterstützung zu Berichten. Beispiel:
appsync-cli.bat -report report_type=rpo detailed=true
43
44
KAPITEL 5
l
l
l
l
l
l
l
Übersicht über die Exchange-Unterstützung ......................................................... 46
Bereitstellung von AppSync für den Exchange-Schutz: Zusammenfassung der
Schritte................................................................................................................. 48
Schutz einer Exchange-Datenbank ....................................................................... 49
Serviceplandetails................................................................................................ 52
Mounten von Exchange-Kopien............................................................................. 61
Übersicht über das Wiederherstellen einer Exchange-Kopie...................................66
Troubleshooting des EMCAppSync Exchange Interface-Service..............................75
45
Übersicht über die Exchange-Unterstützung
Mit AppSync können Sie anwendungskonsistente Kopien von Exchange-Daten erstellen.
Die AppSync-Unterstützung für die Microsoft Exchange-Anwendung umfasst Folgendes:
l
Schutz und Verwaltung von Microsoft Exchange in eigenständigen und DAGUmgebungen (aktive und passive Datenbanken).
l
Mounten von Kopien auf einem Windows 2008- oder Windows 2012-Host zum
Ausführen von Konsistenzprüfungen oder zur langfristigen Speicherung.
l
Wiederherstellen von Kopien auf Exchange-Produktionsdatenbanken, falls die
Produktionsdatenbanken zurück auf einen Point-in-Time gebracht werden müssen.
l
Wiederherstellen einzelner Postfächer und Postfachelemente mithilfe von Kroll
Ontrack®. Diese Aktion kann auch mithilfe von EMC ItemPoint™ für Microsoft
Exchange erfolgen, bis dieses Produkt das Ende seiner Nutzungsdauer (EOSL)
erreicht.
l
Unterstützung für Datenbanken auf physischen Hosts, RDMs und virtuellen
Festplatten auf virtuellen Hosts.
Hinweis
AppSync unterstützt nur RDMs im physischen Kompatibilitätsmodus. RDMs im virtuellen
Modus werden nicht unterstützt.
Voraussetzungen für Exchange Server
Überprüfen Sie, ob die Exchange-Konfiguration den Anforderungen für die unterstützte
Version von AppSync entspricht, einschließlich der Anforderungen für das WindowsBetriebssystem sowie der unterstützten Servicepacks für ExchangeUmgebungen.DieAppSync Support Matrix unter https://elabnavigator.emc.com/eln/
extendedSupport ist die maßgebliche Informationsquelle zu unterstützten
Softwareprogrammen und Plattformen.
AppSync unterstützt den Schutz und die betriebliche Recovery von ExchangeDatenbanken in eigenständigen und in DAG-Konfigurationen, darunter:
l
Exchange 2010-Postfachserver auf Windows Server 2008 SP2 und Windows Server
2008 R2 oder höher.
l
Exchange 2013-Postfachserver auf Windows 2008 R2 SP1 oder höher.
l
Microsoft Exchange 2010 und 2013 Database Availability Groups (DAGs),
einschließlich aktiver und passiver Kopien.
Unterstützung für Exchange auf virtuellen Laufwerken
Sie können Exchange-Datenbanken schützen, mounten und wiederherstellen, die sich
auf VMware RDMs im physischen Kompatibilitätsmodus und auf virtuellen Laufwerken
befinden. AppSync unterstützt vollständige Backups, Kopien und differenzielle Backups.
Während des Schutzes gilt Folgendes:
46
l
Für eine erfolgreiche Zuordnung muss Virtual Center dem AppSync-Server hinzugefügt
und eine Erkennung durchgeführt werden.
l
Für einen erfolgreichen Schutz müssen sich die Protokolldateien und die
Datenbankdateien auf virtuellen Laufwerken befinden. Eine Kombination aus
physischem und virtuellem Speicher ist nicht zulässig.
l
Der Schutz von Exchange-Datenbanken auf virtuellen Maschinen, die denselben
Datenspeicher gemeinsam nutzen, wird nicht unterstützt.
l
Virtuelle Laufwerke werden für Exchange ESX 5.0 und höher unterstützt.
l
AppSync-Versionen 1.6.0.1 und höher unterstützen die zirkuläre Protokollierung für
Exchange-Datenbanken.
AppSync-Interaktion mit Microsoft VSS
Microsoft Volume Shadow Copy Service (VSS) ist die Infrastruktur, mit der AppSync
anwendungsbezogene Kopien erstellt.
Wenn AppSync eine Kopie erstellt, wird in Koordination mit VSS und Exchange eine
Schattenkopie erstellt. Die Kopie ist eine Point-in-Time-Kopie der Volumes, die die Daten,
Protokolle und Systemdateien für Exchange-Datenbanken enthalten.
AppSync legt beim Erstellen der Kopie in Koordination mit VSS und Exchange die
Eingabe-Ausgabe zu den Datenbanken still und setzt den Datenfluss nach Erstellung der
Kopie fort. Während einer Wiederherstellung stellt AppSync in Koordination mit VSS und
Exchange die Point-in-Time-Schattenkopie wieder her.
Für Exchange erforderliche Berechtigungen
Für Konten, die von AppSync für die Zusammenarbeit mit Exchange verwendet werden,
sind spezielle Berechtigungen erforderlich.
l
Bei eigenständigen Exchange-Servern muss es sich bei dem Konto um ein
Domainbenutzerkonto mit der Rolle „Databases“ handeln.
l
Bei DAG-Servern muss es sich bei dem Konto um ein Domainbenutzerkonto mit den
Rollen „Database“ und „Database Copies“ handeln.
l
Bei einem Mount-Host muss es sich bei dem Benutzerkonto um ein Domainkonto
handeln, das Mitglied der lokalen Administratorgruppe ist.
l
Das Konto muss über die Benutzerrechte Log on as a batch job und Log on as a
service verfügen.
l
Das Konto kann die Rolle View-only Organization haben. Dies ist eine optionale Rolle
nur für Microsoft Exchange 2013, wenn Sie Postfächer mit öffentlichen Ordnern in der
Umgebung haben. AppSync nutzt diese Rolle zur Bestimmung der Datenbank, die
den öffentlichen Mailbox-Ordner der primären Hierarchie enthält.
Beim ersten Zugriff auf den Exchange-Server sind die Anmeldedaten für den AppSync
Exchange Interface-Service erforderlich. Sie werden aufgefordert, zwei Sätze von
Anmeldedaten für die Konfiguration des AppSync Exchange Interface-Service einzugeben.
AppSync verwendet den ersten Satz von Anmeldedaten zur Installation und Konfiguration
des AppSync Exchange Interface-Service auf dem Exchange-Produktions- oder MountHost. Das Konto muss über lokale Administratorrechte verfügen. AppSync verwendet den
zweiten Satz von Anmeldedaten, um den Service auszuführen. Ein Benutzer muss ein
Domainbenutzer mit den folgenden Exchange-Rollen sein:
l
Datenbankrolle für eigenständigen Server
l
Datenbank- und Datenbankkopie-Rollen in DAG-Umgebung
Änderungen an Serviceplänen nach dem Upgrade
Nach einem AppSync-Upgrade treten Änderungen an der Ausführung der Servicepläne
auf.
Beachten Sie die folgenden Änderungen:
l
Speicherreihenfolge – nach einem Upgrade wird die Speicherreihenfolge in allen
Serviceplänen durch die neue Reihenfolge ersetzt. Prüfen Sie nach einem Upgrade
die Anweisungen unter Create Copy für die einzelnen Servicepläne, um
sicherzustellen, dass die Speicherreihenfolge richtig ist.
l
Rotation von RecoverPoint-Kopien – nach einem Upgrade wird in keinem der
Servicepläne eine Replikatrotation für RecoverPoint-Kopien mehr durchgeführt. Wenn
Übersicht über die Exchange-Unterstützung
47
Sie die Replikatrotation für einen Serviceplan aktivieren möchten, der RecoverPointKopien erstellt, überprüfen Sie die Anweisungen unter Create Copy für den
Serviceplan und aktivieren Sie das Kontrollkästchen, um RecoverPoint-Kopien beim
Ablauf zu berücksichtigen.
Bereitstellung von AppSync für den Exchange-Schutz:
Zusammenfassung der Schritte
Dies ist eine Zusammenfassung der Schritte von der Bereitstellung von AppSync bis zur
Einrichtung des Exchange-Schutzes.
Vorgehensweise
1. Installieren Sie den AppSync Server.
2. Navigieren Sie in der AppSync-Konsole zu Settings > Storage Infrastructure und
klicken Sie auf Add.
Dies fügt das Speichersystem dort hinzu, wo sich die Exchange-Postfachdatenbank
befindet.
3. Navigieren Sie zu Settings > Servers und klicken Sie auf Add.
Dadurch werden die eigenständigen Exchange-Postfachserver oder Server, die
Mitglied der DAG sind, als Hosts hinzugefügt.
4. Navigieren Sie zu Copy Management > Microsoft Exchange und klicken Sie auf einen
Servernamen in der Liste der eigenständigen Exchange- und DAG-Server.
5. Geben Sie die Anmeldedaten ein, um den Service AppSyncExchange Interface zu
konfigurieren und auszuführen.
Die Exchange-Datenbanken werden erkannt.
6. Abonnieren Sie Schutz für eine Exchange-Datenbank durch Auswahl einer der
folgenden Optionen:
l
Sofortiger Schutz mit der Option Subscribe to Plan and Run, durch die ein
Serviceplan für die Datenbank abonniert und der Schutz sofort nur für die
ausgewählte Datenbank ausgeführt wird. Bei den Datenbanken in einer DAG wird
eine der passiven Datenbanken standardmäßig geschützt.
l
Mit der Option Subscribe to Plan wird ein Serviceplan für die Datenbank abonniert,
jedoch nicht ausgeführt. Der Schutz erfolgt gemäß dem Zeitplan des Serviceplans.
Erkennen von Exchange-Datenbanken
Beim Erstellen, Löschen oder Umbenennen von Datenbanken müssen Sie eine Erkennung
von Datenbanken auf dem Exchange Server ausführen, um AppSync auf dem aktuellen
Stand zu halten.
Bevor Sie beginnen
48
l
l
Der Service AppSync Exchange Interface muss ausgeführt werden.
l
Wenn Sie einen eigenständigen Exchange-Server, der Teil von AppSync ist, zu einem
Teil einer DAG machen möchten, sollten Sie vor der Ausführung einer Erkennung
zunächst den eigenständigen Server (gemeinsam mit seinen Kopien, sofern
vorhanden) aus AppSync entfernen. Während der Erkennung wird der ursprüngliche
eigenständige Server identifiziert, um ihn zu einem Teil der DAG zu machen.
Vorgehensweise
1. Navigieren Sie zu Copy Management > Microsoft Exchange.
2. Klicken Sie auf einen Exchange-Server, um dessen Datenbanken anzuzeigen.
3. Klicken Sie auf Discover Databases, um Datenbanken für diesen Server zu erkennen.
Entfernen eines Exchange-Postfachservers
Entfernen Sie einen Exchange-Postfachserver, wenn es nicht mehr erforderlich ist, seinen
Schutz auf dem AppSync-Server zu verwalten.
Bevor Sie beginnen
Dieser Vorgang erfordert die Ressourcenadministratorrolle in AppSync
Es dürfen keine Kopien des Postfachservers vorhanden sein, den Sie entfernen möchten.
Vorgehensweise
1. Wählen Sie Settings > Servers aus.
2. Wählen Sie den zu entfernenden Server aus.
3. Wählen Sie Remove > Remove servers only aus.
Es wird ein Dialogfeld angezeigt, über das Sie zur Bestätigung aufgefordert werden.
4. Klicken Sie auf OK, um den Vorgang zu bestätigen.
Schützen von DAG-Datenbanken in einem Serviceplan
AppSync unterstützt den Schutz von Exchange-Datenbanken, die Teil einer
Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG) sind.
Wenn für einen DAG-Server ein AppSync-Serviceplan abonniert wird, ist er standardmäßig
eines der passiven Mitglieder der DAG, das für den Datenschutz ausgewählt wird.
Vorgehensweise
l
Wählen Sie Active in der Spalte Copy to Protect aus der Registerkarte Subscriptions
für Pläne aus, um ein aktives Mitglied der DAG-Datenbank zu schützen.
Schutz einer Exchange-Datenbank
Sie können eine Exchange-Datenbank durch Abonnieren eines AppSync-Serviceplans
schützen.
In AppSync werden Servicepläne als Schutzmechanismus für Datenbanken verwendet.
Sie können einen Serviceplan für eine Datenbank abonnieren und den Serviceplan sofort
ausführen lassen oder die Ausführung des Serviceplans für einen späteren Zeitpunkt
festlegen.
l
Wählen Sie Subscribe to Plan and Run aus, wenn Sie eine ausgewählte Datenbank
sofort schützen möchten. Der Serviceplan wird nur für die Datenbank ausgeführt. Bei
einer DAG wird eine der passiven Datenbanken standardmäßig geschützt.
l
Wählen Sie Subscribe to Plan aus, wenn Sie den Schutz für einen späteren Zeitpunkt
planen möchten. Der Schutz für Datenbanken, die Teil des Serviceplans sind, wird zur
geplanten Zeit ausgeführt.
l
Wählen Sie auf der Serviceplan-Seite die Option Run aus, um den gesamten Plan
sofort auszuführen. Alle für den Plan abonnierten Datenbanken werden geschützt.
Entfernen eines Exchange-Postfachservers
49
Sofortiges Schützen einer Exchange-Datenbank
Klicken Sie auf Subscribe to Plan and Run, um eine Datenbank zu einem bestehenden
Serviceplan hinzuzufügen und den Serviceplan nur für die ausgewählte Datenbank sofort
auszuführen.
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Copy Management > Microsoft Exchange
2. Klicken Sie auf einen Exchange-Postfachserver oder eine DAG aus der Liste, um deren
Datenbanken anzuzeigen.
3. Wählen Sie aus dieser Liste die zu schützende Datenbank aus.
Achten Sie beim Ausführen eines Vorgangs bei mehreren Elementen darauf, dass Sie
die Umschalt- oder Strg-Taste gedrückt halten.
4. Wählen Sie aus der Liste Protect den entsprechenden Serviceplan unter Subscribe to
Plan and Run aus.
In der DAG wird eine passive Datenbank standardmäßig geschützt.
Das Dialogfeld Subscribe to Plan and Run wird angezeigt, in dem der Fortschritt über
die verschiedenen Phasen anzeigt wird.
Abonnieren eines Serviceplans für eine Exchange-Datenbank
planen möchten. Der Schutz für alle Datenbanken, die Teil des Serviceplans sind, wird
zur geplanten Zeit ausgeführt.
Bevor Sie beginnen
Vorgehensweise
2. Klicken Sie auf einen Exchange-Postfachserver oder eine DAG aus der Liste, um deren
3. Wählen Sie aus dieser Liste die zu schützende Datenbank aus.
Halten Sie zur Auswahl mehrerer Datenbanken die Umschalt- oder Strg-Taste auf Ihrer
Tastatur gedrückt.
Plan aus.
In der DAG wird eine passive Datenbank standardmäßig geschützt. Zum Wechseln des
Schutztyps auf eine andere Option legen Sie diesen unter der Registerkarte
Subscriptions des Serviceplans fest.
Der Plan wird in der Spalte Plans für die Datenbank hinzugefügt.
Beenden des Serviceplan-Abonnements für eine Datenbank
Sie können ein Serviceplan-Abonnement für eine einzelne Datenbank beenden.
50
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Copy Management > Microsoft Exchange
2. Wählen Sie einen Postfachserver aus, um die Liste der Exchange-Datenbanken
anzuzeigen.
3. Wählen Sie die Datenbank aus, die aus einem Plan entfernt werden soll.
l
Wählen Sie den Plan aus, für den Sie das Abonnement beenden möchten: Protect >
Unsubscribe from Plan.
In der Pop-up-Liste werden nur die Pläne angezeigt, zu denen ein Abonnement für
die Datenbank vorliegt.
l
Wählen Sie zum Beenden des Abonnements aller Servicepläne Unsubscribe from
Plan > All aus.
Eine Kopie nach Bedarf ablaufen lassen
Beim Ablaufen lassen einer Kopie wird diese aus der AppSync-Datenbank entfernt und
dadurch kann je nach Replikationstechnologie und Kopiestatus Speicherplatz freigesetzt
werden.
Bevor Sie beginnen
Durch das Ablaufen lassen einer Kopie, die mit RecoverPoint erstellt wurde, wird das
entsprechende Lesezeichen nicht aus RecoverPoint selbst entfernt.
Vorgehensweise
1. Wählen Sie Copy Management > Microsoft Exchange aus.
2. Klicken Sie auf einen Exchange-Postfachserver, um dessen Datenbanken anzuzeigen.
3. Klicken Sie auf eine Exchange-Datenbank, um deren Kopien anzuzeigen.
4. Wählen Sie eine oder mehrere zu löschende Kopien aus.
Darüber hinaus können Sie diese Aktion in der Serviceplan-Registerkarte Copies
ausführen.
5. Wählen Sie Expire aus.
Überprüfen Sie, ob Sie die Kopie, die Sie ausgewählt haben, und alle zugehörigen
aufgeführten Kopien ablaufen lassen möchten und bestätigen Sie dies.
Erstellen einer Datenbankkopie auf der Seite Copies
Abonnieren Sie einen AppSync-Exchange-Serviceplan auf der Seite Copies, um eine
Kopie einer Datenbank zu erstellen.
Bevor Sie beginnen
Vorgehensweise
2. Klicken Sie auf eine Postfachserverinstanz.
3. Klicken Sie in der Liste der Exchange-Datenbanken auf die Datenbank, um ihre Kopien
anzuzeigen.
Eine Kopie nach Bedarf ablaufen lassen
51
4. Wählen Sie aus der Liste Create a copy using plan den entsprechenden Serviceplan
aus.
Der Serviceplan wird sofort für die Datenbank ausgeführt.
Serviceplandetails
Ein Serviceplan hat die folgenden Registerkarten: „Settings“, „Subscriptions“, „Copies“,
„Events“, und für SQL Server-Pläne „Log Backups“.
Die Registerkarte Settings zeigt den Namen, die Beschreibung und den Status (ob
aktiviert oder deaktiviert) des Serviceplans an. Abgesehen davon sind die verschiedenen
Phasen des Plans auch Teil dieser Registerkarte. Klicken Sie auf die entsprechenden
Registerkarten, um Informationen bezüglich Abonnements, vom Plan erstellte Kopien,
während des Ausführens des Serviceplans erzeugte Ereignisse und für SQL Server
bezüglich vom Plan erstellte Protokollbackups anzuzeigen.
Servicezeitplan
Die Planung eines Serviceplans wird in der Phase Plan Startup festgelegt.
Der Startup Type (geplant oder nach Bedarf) bestimmt, ob der Plan so konfiguriert ist,
dass er nach einem Zeitplan ausgeführt wird, oder ob er manuell ausgeführt wird.
Optionen für die Planung, wann ein Serviceplan beginnt:
l
l
l
l
Angeben eines Recovery Point Objective (RPO)
n
Legen Sie ein RPO von 30 Minuten oder 1, 2, 3, 4, 6, 8, 12 oder 24 Stunden fest
n
Minuten nach der vollen Stunde werden in 5-Minuten-Intervallen festgelegt
n
Standard-RPO beträgt 24 Stunden
Ausführen zu bestimmten Zeiten an jedem Tag
n
Wählen Sie bis zu zwei verschiedene Zeitpunkte am Tag
n
n
Eine Standardvorgabe ist nicht ausgewählt
Ausführen zu einem bestimmten Zeitpunkt an ausgewählten Tagen der Woche
n
Ein oder mehrere Tage der Woche (bis zu alle sieben Tage) können ausgewählt
werden
n
Ein Standard-Tag der Woche ist nicht ausgewählt. Die standardmäßige Tageszeit
ist Mitternacht.
Ausführen zu einem bestimmten Zeitpunkt an ausgewählten Tagen des Monats
n
Wählen Sie eine oder mehrere Tage des Monats (bis zu alle Tage) aus
n
Wählen Sie eine Uhrzeit aus. Verfügbare Zeiten sind in 15-Minuten-Intervallen.
n
Der Standardwert ist der erste Tag des Monats
Steuern der Speicherauslastung bei der Replikation
Wenn Sie einen Serviceplan einrichten, legen Sie Werte in den folgenden Feldern fest,
damit der Replikationsspeicher nicht überbelastet oder zu schnell verbraucht wird:
52
l
RPO-Wert in der Phase „Plan Startup“
l
Bewahren Sie immer n Kopien in der Phase „Create copy“ auf
Sie sollten auch Ihr Speichersystem anhand der Benutzeroberfläche für das
Speichersystem überwachen.
Außer Kraft setzen von Planungen für Servicepläne
Sie können einzelne Planungen für Datenbanken, für die ein Serviceplan abonniert
wurde, durch außer Kraft setzen der allgemeinen Wiederholungseinstellungen festlegen.
Bevor Sie beginnen
Sie können nur die Einstellungen des Wiederholungstyps außer Kraft setzen, der bereits
für den Serviceplan ausgewählt wurde.
Vorgehensweise
1. Navigieren Sie zu Service Plans > Microsoft Exchange und wählen Sie einen der Pläne
aus der Liste aus.
2. Wählen Sie unter der Registerkarte Settings die Phase Plan Startup aus.
3. Notieren Sie sich im Bereich Plan Startup Defaults auf der rechten Seite den
Recurrence Type, der für den Plan ausgewählt wurde.
Ein Wiederholungstyp kann nur dann festgelegt werden, wenn Scheduled als Startup
Type ausgewählt wurde.
4. Klicken Sie auf die Registerkarte Plan Startup Overrides.
5. Legen Sie einzelne Planungen für ausgewählte Datenbanken auf Grundlage Ihrer
Anforderungen fest.
Wenn Sie beispielsweise den Wiederholungstyp On specified days of the month
ausgewählt haben und die Regeleinstellung Run at 12:00 AM am 1st day of every
month festgelegt wurde, können Sie die Uhrzeit und den Tag für die einzelnen
Datenbanken außer Kraft setzen.
Anwendungserkennung
Vor der Erstellung der Kopie, prüft AppSync den Exchange-Postfachserver auf Änderungen
wie beispielsweise das Hinzufügen, Löschen, Umbenennen oder Verschieben von
Datenbanken.
Es sind keine Benutzereinstellungen mit dieser Phase verknüpft und diese Phase kann
nicht deaktiviert werden.
Anwendungszuordnung
Nach dem Erkennen der Anwendung, ordnet AppSync sie Arrayspeichern und
Schutzservices wie RecoverPoint zu.
Es sind keine Benutzereinstellungen mit dieser Phase verknüpft und sie kann nicht
deaktiviert werden.
Pre-copy script
Um vorbereitende Schritte vor dem Erstellen einer Kopie auszuführen, geben Sie ein
Präkopieskript und Parameter in der Registerkarte Settings eines Serviceplans an.
Das Präkopieskript wird gemäß dem Zeitplan ausgeführt, der in der Phase Plan Startup
eingestellt wurde. Gültige Skriptformate sind .bat, .exe und .ps1 (PowerShell-Skripte). Sie
können optional Anmeldedaten eingeben, um das Skript unter einem bestimmten
Benutzer auszuführen. Das Skript wird standardmäßig unter dem lokalen System
ausgeführt.
Anwendungserkennung
53
AppSync unterstützt die Ausführung von PowerShell-Skripten nicht direkt. Sie müssen
diese in der Regel in eine .bat-Datei einschließen. Die andere Option besteht darin, den
Standardwert für ps1-Dateien C:\WINDOWS\system32\WindowsPowerShell
\v1.0\powershell.exe als „Offen“ festzulegen. Wenn das PS-Skript ausgeführt
wird, erhalten Sie möglicherweise einen Fehler und müssen eine entsprechende
Ausführungsrichtlinien festlegen.
So führen Sie PowerShell-Befehle über Skripte aus:
1. Geben Sie den vollständigen Pfadnamen zur PowerShell-Befehlsdatei in der .batDatei an: powershell -command C:\PshellCommands.ps1 <nul
2. Legen Sie die PowerShell-Ausführungsrichtlinie so fest, dass Sie das Skript ausführen
können. Beispielsweise sollte die erste Zeile in der .bat-Datei für eine nicht
eingeschränkte Richtlinie wie folgt aussehen: powershell -command setexecutionpolicy unrestricted <nul
3. Fügen Sie für eine korrekte Beendigung der PowerShell-Sitzung <nul am Ende der
Zeile ein, die das PowerShell-Skript aufruft. Der standardmäßige Speicherort des
Skripts ist %ProgramData%\EMC\AppSync\scripts\ auf dem
Anwendungshost.
Die genauen Parameter hängen vom Skript ab. Parameter mit Leerzeichen müssen in
doppelte Anführungszeichen gesetzt sein.
Diese Phase kann aktiviert oder deaktiviert werden. Dieser Vorgang erfordert die
Serviceplan-Administratorrolle in AppSync
Create copy
Die Kopieerstellungsphase erstellt eine Kopie basierend auf der Replikationstechnologie,
die im Serviceplan angegeben ist.
Diese Phase gibt den Typ der zu erstellenden Exchange-Kopie an, d. h. ob ExchangeFehler im Anwendungsereignisprotokoll ignoriert werden und ob sich die Datenbank und
die Protokolle auf demselben Volume befinden können.
Weitere Informationen zur Serviceplankopie finden Sie unter Übersicht: Serviceplan auf
Seite 10.
Exchange-Backuptyp
AppSync nutzt VSS zur Erstellung einer konsistenten Online-Kopie auf Volume-Ebene.
54
l
Full erstellt eine Kopie der Datenbanken im Serviceplan unter Verwendung von VSS
(Volume Shadow Copy Service). Dies schließt die Datenbankdateien,
Transaktionsprotokolle und Kontrollpunktdateien ein. Wird das Backup erfolgreich
abgeschlossen, werden die Protokolle gekürzt.
l
Copy erstellt eine Kopie der Datenbanken im Serviceplan unter Verwendung von VSS
(Volume Shadow Copy Service). Dies schließt ebenso wie bei Verwendung der Option
Full die Datenbankdateien, Transaktionsprotokolle und Kontrollpunktdateien ein.
Allerdings werden dabei die Protokolle nicht gekürzt.
l
Differential kopiert das gesamte Transaktionsprotokoll-Volume. Ein komplettes
Backup der ausgewählten Datenbank muss vorhanden sein oder das Backup schlägt
fehl. Die Transaktionsprotokolle werden nach Abschluss des Backups nicht gekürzt.
Automatischer Ablauf von Kopien
Der automatische Ablaufwert in der Kopieerstellungsphase eines Serviceplans gibt die
maximale gewünschte Anzahl von Snap-, Clone- oder Lesezeichen-Kopien an, die
gleichzeitig vorhanden sein können.
Wenn der Wert "Always keep x copies" erreicht ist, laufen ältere Kopien ab, um freien
Speicherplatz für die nächste Kopie in der Rotation zu gewinnen. Fehlgeschlagene Kopien
werden nicht gezählt. AppSync lässt die älteste Kopie erst ablaufen, wenn dessen Ersatz
erfolgreich erstellt wurde. Wenn beispielsweise die Anzahl der aufzubewahrenden Kopien
7 beträgt, lässt AppSync die älteste Kopie nicht ablaufen, bis die 8. Kopie erstellt wurde.
AppSync lässt Kopien unter folgenden Umständen nicht ablaufen:
l
Gemountete Kopien laufen nicht ab.
l
Eine Kopie, die das einzige Replikat einer Datenbank enthält, läuft nicht ab.
Diese Einstellung ist unabhängig von den VNX-Pool Policy-Einstellungen in Unisphere
zum automatischen Löschen von ältesten Snapshots. Die Serviceplanadministrator sollte
mit dem Speicheradministrator zusammenarbeiten, um sicherzustellen, dass die VNXPool Policy-Einstellungen die Unterstützung der angegebenen Anzahl von SnapshotKopien für die Anwendung ermöglicht, die sich in diesem Pool befindet.
Include RecoverPoint copies in expiration rotation policy: Aktivieren Sie diese Option,
um RecoverPoint-Kopien beim Berechnen von Rotationen einzubeziehen.
Hinweis
Wenn diese Option nicht ausgewählt ist, sammeln sich RecoverPoint-Kopien an und
werden beibehalten, bis die Lesezeichen aus der RecoverPoint-Appliance „herausfallen“.
Exchange-Ereignisprotokollfehler
Exchange protokolliert bestimmte Fehler in das Anwendungsereignisprotokoll, wenn sie
auftreten. Diese Fehler weisen auf eine mögliche Beschädigung der Daten in den EDBoder Protokolldateien hin. Sie können dazu führen, dass die Erstellung von Kopien
fehlschlägt, es sei denn, Sie weisen AppSync ausdrücklich an, diese zu ignorieren.
AppSync sucht im Anwendungsereignisprotokoll nach diesen Fehlern jedes Mal, wenn
eine Kopie erstellt wird. Wenn AppSync das erste Mal ausgeführt wird, wird das gesamte
Protokoll durchsucht. Nachfolgende Ausführungen suchen seit der letzten erfolgreichen
Ausführung. Wenn es keine vorhandenen Kopien gibt, durchsucht AppSync das gesamte
Protokoll, wenn die nächste Kopie erstellt wird.
In der Phase „Create copy“ eines Serviceplans können Sie AppSync so konfigurieren,
dass alle diese Fehler ignoriert werden.
Tabelle 7 Microsoft Exchange-Ereignisfehler
Fehler Bedeutung
-1018
Der Versuch der Datenbank, die Informationen zu einer bestimmten Seite in der
Datenbank zu überprüfen, ist fehlgeschlagen.
-1019
Dieser Fehler ist einem Fehler -1018 ähnlich, bedeutet jedoch, dass die abgerufene Seite
eine ungültige Seitennummer (in der Regel nur Nullen) anstatt einer ungültigen
Prüfsumme zurückgegeben hat.
Create copy
55
Tabelle 7 Microsoft Exchange-Ereignisfehler (Fortsetzung)
Fehler Bedeutung
-1022
Zeigt wesentliche Hardwareprobleme, insbesondere Festplatten-Subsystemprobleme,
an. Wenn die Datenbank-Engine eine Seite von der Festplatte fordert, aber stattdessen
aus dem I/O-Subsystem eine Fehlermeldung erhält, führt dies zu einem Fehler -1022.
447
Zeigt eine Beschädigung der logischen Datenbankstruktur an. Dies wird von einer
Meldung begleitet, dass der Informationsspeicher anormal beendet wurde.
448
Gibt eine Inkonsistenz oder Beschädigung in einer Tabelle in der Microsoft-JetDatenbank an. Dies wird von einer Meldung begleitet, dass eine
Speicherdateninkonsistenz in einer Tabelle erkannt wurde.
Datenbank- und Protokolllayout
Exchange unterstützt Umgebungen, in denen sich die Datenbank und die Protokolle auf
demselben Volume befinden, wenn mehr als eine Kopie der Datenbank in einer DAGUmgebung vorhanden ist. Servicepläne können konfiguriert werden, die Beschränkung
zu ignorieren, die verhindert, dass sich Datenbanken und Protokolle auf demselben
Volume befinden.
Bei der Erstellung von Kopien von Exchange-Datenbanken ist eine empfohlene
Vorgehensweise, einen Serviceplan so zu beschränken, dass diese Konfiguration nicht
zulässig ist, da das Vorhandensein von Datenbanken und Protokollen auf dem gleichen
Volume Ihre Optionen für die Wiederherstellung einschränkt. Allerdings können Sie
auswählen, ob Servicepläne mit dieser Konfiguration erfolgreich sein sollen.
Diese Option wird in der Kopieerstellungsphase eines Serviceplans festgelegt.
Wenn Sie diese Option auswählen, können Sie die Datenbanken und die Protokolle nur
zusammen wiederherstellen. Die Wiederherstellung überschreibt neuere
Protokolldateien. Um neuere Protokolldateien zur Verwendung während der Recovery zu
bewahren, kopieren Sie sie vor der Wiederherstellung zu einem anderen Volume.
Post-copy script
Geben Sie ein Postkopieskript und Parameter in der Registerkarte Settings des
Serviceplans an, um eine Bereinigung oder andere Schritte nach dem Erstellen einer
Kopie durchzuführen.
Das Skript wird nach dem erfolgreichen Abschluss der Phase Create copy ausgeführt.
Gültige Skriptformate sind .bat, .exe und .ps1 (PowerShell-Skripte). Sie können optional
Anmeldedaten eingeben, um das Skript unter einem bestimmten Benutzer auszuführen.
Das Skript wird standardmäßig unter dem lokalen System ausgeführt.
Wenn AppSync Kopien von Anwendungselementen in einem Serviceplan erstellt, kann es
die Anwendungselemente zum Schutz teilen und in separate Gruppen platzieren. Diese
Aktion kann aus Performance-Gründen (z. B. VSS für Exchange und SQL) durchgeführt
werden oder weil die Elemente in einem Serviceplan durch verschiedene
Replikationstechnologien geschützt werden. Beispielsweise kann ein Serviceplan einige
Anwendungselemente enthalten, die teilweise von VNX Snapshots und teilweise durch
RecoverPoint-Lesezeichen geschützt sind. Daher werden Anwendungselemente in diesen
Gruppen unabhängig voneinander geschützt.
56
Wenn AppSync ein Postkopieskript aufruft, übermittelt AppSync die Kopien, die in der
Gruppe erstellt wurden, durch Aufrufen des Skripts mit -appCopies <ANW1> <ANW2>,
wobei ANW1 und ANW2 die Namen der Anwendungselemente in dieser Gruppierung sind.
Ausführungsrichtlinie festlegen
2. Legen Sie die PowerShell-Ausführungrichtlinie so fest, dass Sie das Skript ausführen
Zeile ein, die das PowerShell-Skript aufruft.
Wenn AppSync das Postkopieskript ausführt, wird es für die Anwendungselemente
ausgeführt, die Teil einer Gruppe sind. Wenn mehrere Gruppen vorhanden sind, wird das
Postkopieskript mehrfach ausgeführt. Wenn AppSync das Postkopieskript ausführt,
übermittelt AppSync die Liste der Anwendungselemente in der Replikationsgruppe als
Argumente an das Skript direkt nach den Benutzer-Argumenten. Die Syntax lautet:
-applicationCopies <ITEM1> <ITEM2> <ITEM3>
wobei <ITEMx> der Name des Anwendungselements ist, das geschützt wird.
Der standardmäßige Speicherort des Skripts ist %ProgramData%\EMC\AppSync
\scripts\ auf dem Anwendungshost.
doppelte Anführungszeichen gesetzt werden.
Unmounten einer früheren Kopie
Der Serviceplan führt nach dem Erstellen der neuen Kopie einen Unmount-Vorgang für
eine zuvor gemountete Kopie durch. Eine Ausnahme bildet eine Kopie, die nach Bedarf
statt durch den Serviceplan gemountet wurde. In diesem Fall wird der Unmount-Vorgang
für die nach Bedarf gemountete Kopie nicht durchgeführt.
Mit dieser Phase sind keine Benutzereinstellungen verknüpft und die Phase kann
aktiviert oder deaktiviert werden.
Kopie mounten
Die Phase „Mount copy“ mountet die Kopie. Diese Phase kann aktiviert oder deaktiviert
werden.
Die Einstellungen Mount Copy Defaults für den Wert für die Attribute (schreibgeschützt
oder Lesen / Schreiben) für den Mount-Host, Mount-Pfad und Mount-Zugriff sind vom
Serviceplan abhängig. Andere Mount-Einstellungen bestimmen, wohin die ExchangeMetadatendateien kopiert werden, den Typ der Kopie, die gemountet werden soll, und
den RecoverPoint-Imagezugriffstyp.
57
l
Mount on Server
Hiermit können Sie zwischen Windows-Hosts, auf die Sie Zugriff haben, und
ursprünglichen Servern auswählen. Wenn Sie das Validieren der Kopien ausgewählt
haben, werden nur Server, auf denen die Exchange-Verwaltungstools installiert sind,
in der Drop-down-Liste angezeigt. Diese Server werden auf der Seite Microsoft
Exchange Protection als Utility Host angezeigt.
l
Mount with Access
Wählen Sie den Zugriffstyp aus, mit dem die Kopie gemountet werden soll - Lese-/
Schreib- oder nur Lesezugriff
l
Mount Path
n
Alternate mount path
Der standardmäßige Mount-Pfad, wenn der Mount-Host mit dem Produktionshost
identisch ist, lautet SystemDrive: \AppSyncMounts\Production_Server_Name.
Der Pfad wird in der Konsole als % SystemDrive%\AppSyncMounts\%
%ProdServerName%% dargestellt.
Begrenzen Sie zum Festlegen des Werts einer Windows-Umgebungsvariablen im
Mount-Pfad den Variablennamen mit einzelnen Prozentzeichen (%). Der
Standardpfad enthält auch eine AppSync-Variable (ProdServerName), die mit zwei
Prozentzeichen (%) begrenzt ist.
Die folgenden Zeichen sind im Pfad nicht zulässig:
<>:"/|?*
n
Same as original path Dies ist eine weitere Option für den Mount-Pfad. Sie
können eine der Optionen auswählen.
Hinweis
Wählen Sie bei der Durchführung eines DAG-Mounts den Mount-Pfad nicht als
Same as original path aus, wenn der Mount-Host gleichzeitig auch ein DAG-Node
ist, der eine Kopie der von Ihnen gemounteten Datenbank aufweist.
l
Copy metadata files to
Standardmäßig ist der Speicherort zum Kopieren von VSS-Metadatendateien der
Standardpfad - SystemDrive: \AppSyncMounts\Production_Server_Name.
<>:"/|?*
Wenn Sie die Datenbank auf einem anderen Medium sichern, müssen Sie diese
Metadatendateien ebenfalls sichern.
l
58
Image-Zugriffsoptionen während des RecoverPoint-Mount-Vorgangs
RecoverPoint bietet bei einer zielseitigen Hostanwendung die Möglichkeit, Daten auf
den Replikations-Volumes der Zielseite zu schreiben, und dabei weiterhin die
Änderungen in der Quelle nachzuverfolgen.
n
Slow access time, fast image I/O performance (RecoverPoint access mode:
Logged Access)
Verwenden Sie diese Mount-Option, wenn die Integritätsprüfung das Scannen von
großen Bereichen der replizierten Volumes umfasst. Dies ist die einzige
verfügbare Option, wenn Sie auf den Produktionshost mounten.
n
Fast access time, Fast after roll image I/O performance (RecoverPoint access
mode: Virtual Access with Roll)
Bietet nahezu sofortigen Zugriff auf die Kopie, aktualisiert jedoch auch das
replizierte Volume im Hintergrund. Wenn die replizierten Volumes am
angeforderten Point-in-Time liegen, wechselt die RPA transparent zum direkten
Replikat-Volume-Zugriff, wodurch die Verarbeitung von Prozessen mit hoher
Auslastung ermöglicht wird.
n
Fast access time, Slow image I/O performance (RecoverPoint access mode:
Virtual Access)
Bietet nahezu sofortigen Zugriff auf das Image. Diese Option ist nicht für die
Verarbeitung von Prozessen mit hoher Auslastung vorgesehen.
n
Desired Service Level Objective (SLO)
Wenn Sie ein VMAX 3 Array verwenden, ist außerdem die Einstellung Desired
Service Level Objective (SLO) verfügbar. Die Option wird im Mount-Assistenten
angezeigt und gibt die erforderlichen VMAX 3 Service-Level-Ziele an. SLO definiert
den Servicezeit-Betriebsbereich einer Speichergruppe.
l
Kopie, die gemountet werden soll
Wird für Servicepläne angezeigt, die sowohl eine lokale als auch eine Remote-Kopie
erstellen. Sie können den Typ der Kopie, die gemountet werden soll, auswählen.
l
Wenn Sie ein VMAX 3-Array verwenden, ist außerdem eine Einstellung mit der
Bezeichnung „Desired Service Level Objective (SLO)“ verfügbar. Die Option wird im
Mount-Assistenten angezeigt und gibt die erforderlichen VMAX 3-Service-Level-Ziele
an. SLO definiert den Betriebsbereich der Servicezeit einer Speichergruppe.
Mount-Host-Außerkraftsetzungen im Serviceplan
Wählen Sie verschiedene Mount-Hosts für mehrere Exchange-Server, die einen
Serviceplan abonnieren, aus.
In der Phase „Mount Copy“ eines Serviceplans können Sie den Host, auf den die Kopie
gemountet werden soll, sowie zugehörige Mount-Optionen festlegen. Wenn Sie mehrere
Server als Teil eines Serviceplans haben, möchten Sie möglicherweise deren Kopien auf
verschiedenen Hosts hosten. Sie können verschiedene Mount-Hosts und andere
Optionen in der Registerkarte Mount Copy Overrides der Phase Mount copy im
Serviceplan angeben.
Außer Kraft setzen von Mount-Hosts in einem Serviceplan
Wenn es mehrere registrierte Hosts gibt und für sie der gleiche Plan abonniert wurde,
können Sie für jeden Server einen anderen Mount-Host auswählen und damit die
allgemeinen Mount-Host-Einstellungen außer Kraft setzen.
Bevor Sie beginnen
Gehen Sie folgendermaßen vor, wenn für mehrere Hosts ein Plan abonniert wurde und
Sie verschiedene Mount-Hosts für ihre Datenbankkopien verwenden möchten.
Vorgehensweise
1. Navigieren Sie zu Service Plans und wählen Sie einen der Pläne aus der Liste aus.
2. Wählen Sie unter der Registerkarte Settings die Phase Mount copy aus.
In der Registerkarte Mount Copy Defaultsumfasst die Liste der Server alle ExchangeServer, für deren Datenbanken dieser Plan abonniert wurde. In den MountEinstellungen werden die Standardeinstellungen angezeigt.
3. Klicken Sie auf Mount Copy Overrides, um die Standardeinstellungen außer Kraft zu
setzen.
4. Wählen Sie den Server aus, dessen Mount-Einstellungen Sie außer Kraft setzen
möchten, und klicken Sie auf Set Overrides.
5. Wählen Sie im Dialogfeld Override Default Mount Settings die Optionen lediglich für
jene Einstellungen aus, die Sie außer Kraft setzen möchten.
Kopie mounten
59
Wenn Sie beispielsweise eine Kopie auf einem anderen Pfad mounten möchten,
müssen Sie den Pfad aus der Liste Mount Path auswählen. Felder, die kein
Auswahlfeld aufweisen, behalten ihre Standardeinstellungen bei.
6. Wählen Sie OK aus, um Ihre Änderungen zu speichern.
In der ersten Spalte der Zeile des Servers, dessen Standard-Mount-Einstellungen Sie
geändert haben, wird ein Bleistiftsymbol angezeigt.
7. Wählen Sie zum Zurücksetzen eines Servers auf die Standardeinstellungen den Server
aus und klicken Sie auf Use Default Settings.
Kopie validieren
Exchange-Verwaltungstools führen in dieser Phase eine Konsistenzprüfung aus.
Standardmäßig werden die Datenbanken und Protokolle sequenziell geprüft. Wenn die
Datenbanken nicht dieselbe LUN verwenden und der Mount-Host über genügend
Ressourcen zur Unterstützung von parallelen Konsistenzprüfungen verfügt, verwenden
Sie die Option Parallel. Beachten Sie, dass Exchange maximal 16 parallele Prüfungen
verarbeiten kann.
Wenn die Konsistenzprüfung erfolgreich abgeschlossen wird, weist AppSync Exchange
an, die Protokolle zu kürzen, damit nur die Änderungen bleiben, die in der Datenbank
nicht übernommen sind.
Diese Phase kann aktiviert oder deaktiviert werden.
Erweiterte Optionen für die Konsistenzprüfung
AppSync bietet erweiterte Optionen, die ändern, wie Konsistenzprüfungen in Exchange
ausgeführt werden. Das Aktivieren dieser Funktionen kann die Performance
beeinträchtigen.
l
Minimize log checking
Durch Auswahl dieser Option wird die Protokollüberprüfung beschleunigt, da die
Software zur Konsistenzprüfung angewiesen wird, nur die Protokolle zu prüfen, die
für eine Wiederherstellung der Datenbank erforderlich sind. Bei Auswahl dieser
Option verbessert sich die Performance der Konsistenzprüfung. Wenn Sie diese
Option deaktivieren, wird für alle Datenbankprotokolle eine Konsistenzprüfung
durchgeführt.
Dieser Befehl weist AppSync an, nur eine Teilmenge der Exchange-Protokolle zu
prüfen, die in der Kopie enthalten sind. Die Teilmenge der Protokolle sind genau die
Protokolle, die zur Wiederherstellung der Datenbank erforderlich sind. Wenn Ihr
Backupzeitfenster kurz ist, ist diese Option wahrscheinlich nützlich. Die Kopie enthält
jedoch Protokolle, die nicht auf Konsistenz überprüft wurden. Wenn Sie versuchen,
das Protokollvolume wiederherzustellen, stellt sich möglicherweise heraus, dass
einige Protokolldateien beschädigt sind oder die Protokollreihenfolge nicht
vollständig ist. Vor der Wiederherstellung des Protokollvolume sollten Sie das
Replikat mounten und für den Protokollpfad den Befehl eseutil /k Enn
ausführen.
Deaktivieren Sie für maximalen Schutz Minimize log checking. Wenn es Ihnen um
maximale Performance geht, aktivieren Sie diese Option.
Sie müssen auch ein Arbeitsverzeichnis festlegen, in das die erforderlichen
Protokolldateien zum Prüfen kopiert werden.
Die Option Minimize log checking ist nicht verfügbar, wenn die Consistency-Methode
die differenzielle Methode ist.
60
l
Throttle-Prüfung
Konsistenzprüfungen können pausiert werden, um die Ein-/Ausgabe während der
Überprüfung der verlangsamen. Sie können die Anzahl der Ein-/Ausgaben, nach
denen pausiert werden soll, sowie die Dauer der Pause festlegen.
Post-mount script
Geben Sie ein Post-Mount-Skript und Parameter in der Option „Post-mount script“ in der
Registerkarte Settings eines Serviceplans an.
Das Skript wird nach dem erfolgreichen Abschluss der Phase „Mount copy“ oder „Mount
with Recovery“ ausgeführt. Dieses Skript wird normalerweise für Backups verwendet.
Wählen Sie von der Liste Server den Server, auf dem Sie das Skript ausführen wollen. Sie
können es optional auf einem anderen registrierten Host als dem Mount-Host ausführen
und Anmeldedaten eingeben, um das Skript unter einem bestimmten Benutzer
auszuführen.
Die genauen Parameter hängen von Ihrem Skript ab. Parameter mit Leerzeichen müssen
in doppelte Anführungszeichen gesetzt werden.
Unmount copy
Die finale Phase im Serviceplan führt einen Unmount-Vorgang für die Kopie durch. Alle
gemounteten Datenbanken werden im Rahmen dieser Phase heruntergefahren.
Diese Phase wird deaktiviert, wenn die Phase Unmount previous copy aktiviert ist. Keine
Benutzereinstellungen sind mit dieser Phase verknüpft.
Mounten von Exchange-Kopien
AppSync kann eine Kopie nach Bedarf oder als Teil eines Plans mounten.
Auf einem eigenständigen Exchange-Produktionsserver erstellte Kopien können wie folgt
gemountet werden:
l
auf einem alternativen Host im selben Speicherort wie der Produktionshost.
l
auf einem alternativen Host an einem neuen Speicherort. Sie geben die MountOption durch Hinzufügen eines alternativen Pfads zu Beginn des Pfads an.
l
auf dem Produktionshost an einem anderen Speicherort.
In einer DAG erstellte Kopien können wie folgt gemountet werden:
l
auf einem alternativen Host
l
auf einem Server in einer anderen DAG
l
auf einem anderen Server in derselben DAG
Hinweis
Kopien können nicht auf demselben DAG-Server gemountet werden, auf dem die Kopie
erstellt wurde.
Post-mount script
61
Mounten und Wiederherstellen von Einschränkungen
Einschränkungen zum Mounten und Wiederherstellen von Exchange-Kopien sind in der
folgenden Liste aufgeführt:
l
Wenn der Root-Laufwerkbuchstabe über Mount-Punkte verfügt, die alle im selben
Plan enthalten sind, werden Mount- und Wiederherstellungsvorgänge wahrscheinlich
fehlschlagen. Wenn beispielsweise die Protokoll- und die Systemdateien auf L:\ und
die Postfachdateien auf L:\SG1DBMP gespeichert sind (wobei SG1DBMP ein MountPunkt ist), schlagen Mounts und Wiederherstellungen fehl.
l
Wenn in Umgebungen mit Windows 2012 und höher eine Wiederherstellung
durchgeführt wird, werden die Daten auf LUNs selbst dann überschrieben, wenn das
Volume verwendet wird. Diese Aktion unterscheidet sich von anderen WindowsPlattformen, die in denen AppSync eine Warnung anzeigt, wenn die LUN verwendet
wird. Da bei Wiederherstellungen alles überschrieben wird, achten Sie darauf, dass
es keine anderen Daten auf diesem Volume gibt und das Volume nicht verwendet
wird.
Mounten einer Exchange-Kopie nach Bedarf
Sie können nach Bedarf den Mount-Vorgang einer Exchange-Kopie von einer Kopie oder
Datenbank initiieren.
Bevor Sie beginnen
Vorgehensweise
1. Wählen Sie Recover > Mount a Copy auf der Seite Exchange Databases aus.
Alternativ dazu können Sie auf der Seite Copies oder unter der Registerkarte Copies
des Serviceplans eine Kopie auswählen und dann auf Mount klicken.
2. Verwenden Sie die Filter Copies oder Service Plan, um die entsprechende Kopie zum
Mounten auszuwählen.
Die Liste der Kopien wird basierend auf den ausgewählten Filtern aktualisiert.
3. Wählen Sie die Kopie aus, die Sie mounten möchten.
Bei einer RecoverPoint-Kopie haben Sie auch die Möglichkeit, eine Kopie basierend
auf einem bestimmten Zeitpunkt auszuwählen. Klicken Sie auf Select a point in time,
um eine Kopie mit einem bestimmten Zeitstempel auszuwählen. Bei der angezeigten
Zeit handelt es sich um die Uhrzeit der Konsole. Wenn sich die Konsole in einer
anderen Zeitzone als der Server befindet, geben Sie die Uhrzeit gemäß der
Serverzeitzone ein, um die Kopie zu mounten.
4. Wählen Sie auf der Seite Mount Additional Copies eine oder mehrere zusätzliche
Kopien aus, die Sie mounten möchten.
Die hier aufgeführten Kopien gehören zu anderen Datenbanken, die zur selben Zeit
geschützt waren und sich auf demselben Host wie die von Ihnen im vorherigen Schritt
ausgewählte Kopie befinden.
5. Wählen Sie auf der Seite Validate Copy Yes aus, um die Kopien zu validieren und die
Validierungsoptionen festzulegen. Näheres finden Sie unter den Mount- und
Validierungsoptionen.
6. Wählen Sie auf der Seite Mount Options die Mount-Optionen aus.
l
62
Bei VMAX 3-Arrays (nur bei diesen Arrays) wird ein SLO-Drop-down-Menü
angezeigt. Sie können das gewünschte Service-Level-Ziel (Service Level Objective,
SLO) für die Mount-Kopie auswählen. Falls eine Speichergruppe für den MountHost mit der gewünschten SLO vorhanden ist, fügt AppSync die LUN zur
Speichergruppe hinzu. Wenn diese Speichergruppe nicht vorhanden ist, fügt
AppSync die LUN zu einer Speichergruppe hinzu, die gegenüber dem Host
maskiert ist. Wenn eine Speichergruppe zur Auswahl von Zielgeräten konfiguriert
ist, entfernt AppSync die Geräte aus der Speichergruppe zum Zeitpunkt des
Mountens und fügt sie der Speichergruppe für den Mount-Host hinzu. Die Geräte
werden der ursprünglichen Speichergruppe hinzugefügt, wenn die Kopie
abgelaufen ist. Nachfolgend finden Sie ein Beispiel für das Menü Desired SLO:
Abbildung 2 Für VMAX 3 das gewünschte SLO auswählen
l
Mount on Server
Hiermit können Sie zwischen Windows-Hosts, auf die Sie Zugriff haben, und
ursprünglichen Servern auswählen. Wenn Sie das Validieren der Kopien
ausgewählt haben, werden nur Server, auf denen die Exchange-Verwaltungstools
installiert sind, in der Drop-down-Liste angezeigt. Diese Server werden auf der
Seite Microsoft Exchange Protection als „Utility Host“ angezeigt.
l
Mount with Access
Wählen Sie den Zugriffstyp aus, mit dem die Kopie gemountet werden soll - Lese-/
Schreib- oder nur Lesezugriff
l
Mount Path
n
Wenn Sie einen nicht standardmäßigen Mount-Pfad angeben, darf das für das
Mounten angegebene Laufwerk kein Clusterlaufwerk sein.
n
Alternate mount path
Der standardmäßige Mount-Pfad, wenn der Mount-Host mit dem
Produktionshost identisch ist, lautet SystemDrive: \AppSyncMounts
\Production_Server_Name.
Der Pfad wird in der Konsole als % SystemDrive%\AppSyncMounts\%
%ProdServerName%% dargestellt.
Begrenzen Sie zum Festlegen des Werts einer Windows-Umgebungsvariablen
im Mount-Pfad den Variablennamen mit einzelnen Prozentzeichen (%). Der
Mounten einer Exchange-Kopie nach Bedarf
63
Standardpfad enthält auch eine AppSync-Variable (ProdServerName), die mit
zwei Prozentzeichen (%) begrenzt ist.
<>:"/|?*
n
Identisch mit dem ursprünglichen Pfad
Dies ist eine weitere Option für den Mount-Pfad. Sie können eine der Optionen
auswählen.
Hinweis
Wählen Sie bei der Durchführung eines DAG-Mounts den Mount-Pfad nicht als
Same as original path aus, wenn der Mount-Host gleichzeitig auch ein DAGNode ist, der eine Kopie der von Ihnen gemounteten Datenbank aufweist.
l
Copy metadata files to
Standardmäßig ist der Speicherort zum Kopieren von VSS-Metadatendateien der
Standardpfad - SystemDrive: \AppSyncMounts\Production_Server_Name.
<>:"/|?*
Wenn Sie die Datenbank auf einem anderen Medium sichern, müssen Sie diese
Metadatendateien ebenfalls sichern.
l
Image-Zugriffsoptionen während des RecoverPoint-Mount-Vorgangs
RecoverPoint bietet bei einer zielseitigen Hostanwendung die Möglichkeit, Daten
auf die Replikations-Volumes der Zielseite zu schreiben und dabei weiterhin die
Änderungen in der Quelle nachzuverfolgen.
n
Slow access time, fast image I/O performance (RecoverPoint access mode:
Logged Access)
Verwenden Sie diese Mount-Option, wenn die Integritätsprüfung das Scannen
von großen Bereichen der replizierten Volumes umfasst. Dies ist die einzige
n
Fast access time, Fast after roll image I/O performance (RecoverPoint access
mode: Virtual Access with Roll)
Bietet nahezu sofortigen Zugriff auf die Kopie, aktualisiert jedoch auch das
replizierte Volume im Hintergrund. Wenn die replizierten Volumes am
angeforderten Point-in-Time liegen, wechselt die RPA transparent zum direkten
Replikat-Volume-Zugriff, wodurch die Verarbeitung von Prozessen mit hoher
Auslastung ermöglicht wird.
n
Fast access time, Slow image I/O performance (RecoverPoint access mode:
Virtual Access)
7. Geben Sie auf der Seite Configure AppSync Exchange Interface Service die
Anmeldedaten ein, um den Service auf dem Mount-Server zu konfigurieren.
Diese Seite wird nur angezeigt, wenn Sie ausgewählt haben, die Kopie zu validieren,
und wenn der Service nicht konfiguriert ist.
8. Überprüfen Sie die Angaben unter Summary und klicken Sie auf Finish, um die Kopie
zu mounten.
9. Wählen Sie auf der Seite Results die Option View Details aus, um den Fortschritt der
verschiedenen Phasen anzuzeigen, die zum Mounten einer Kopie gehören.
Die zuletzt abgeschlossene Phase wird am unteren Rand der Liste angezeigt.
64
Validierungsoptionen für eine Mount-Kopie
Validierung für differenzielle Backupkopien wird nicht unterstützt.
Validierung der Datenbank und der Protokolle
Bei der Erstellung eines Replikats von einer oder mehreren Microsoft ExchangeDatenbanken sollten Sie das Replikat mounten und für Konsistenz zu testen. Wenn Sie
sich dafür entscheiden, das Replikat automatisch auf einen alternativen Host zu
mounten, sobald es erstellt wurde, sollten Sie eine Konsistenzprüfung auf dem Replikat
ausführen. Gültige Validierungsoptionen:
l
Sequentiell – Führen Sie Tests für eine Datenbank zu einem Zeitpunkt nacheinander
durch (serieller Modus). Wählen Sie diese Option, wenn Sie über mehrere ExchangeDatenbanken auf einer LUN verfügen.
l
Parallel – Führen Sie Tests auf mehreren Datenbanken gleichzeitig aus (paralleler
Modus).
Minimieren des Überprüfens von Protokolldateien
Wenn „Minimize log checking“ ausgewählt wird, prüft AppSync eine Teilmenge der
Exchange-Protokolle, die im Replikat enthalten sind. Wenn Ihr Backupzeitfenster klein ist,
ist diese Option nützlich. Jedoch kann das Replikat Protokolle enthalten, die nicht auf
Konsistenz überprüft wurden.
Für maximalen Schutz deaktivieren Sie die Option „Minimize log checking“. Aktivieren
Sie sie für maximale Performance.
Arbeitsverzeichnis – In diesem Feld können Sie das Verzeichnis angeben, zu dem die
entsprechenden Protokolldateien zur Ausführung der Prüfung verschoben werden, da
eine Konsistenzprüfung nur für alle Protokolle in einem einzelnen Verzeichnis ausgeführt
werden kann.
Drosselung der Validierung
Wählen Sie dies, um I/O während der Konsistenzprüfung zu drosseln. Diese Option ist für
fortgeschrittene Benutzer und sollte in der Regel nicht ausgewählt werden, es sei denn,
Sie arbeiten mit EMC Support zur Lösung eines Problems in Bezug auf den I/O-Durchsatz.
Die Drosselungsoption ist in der Regel nicht erforderlich.
Wenn Sie die I/O-Drosselung wählen, haben Sie die folgenden zwei Optionen.
l
Pause after I/O count of: 100 – Mit dieser Option können Sie auswählen, wie viele
I/O zwischen Pausen auftreten können. Sie können einen beliebigen Wert zwischen
100 und 10.000 I/O auswählen.
l
Duration of pause (in milliseconds): 1000 – Sie können die Dauer der Pause in
Millisekunden festlegen. 1000 Millisekunden = 1 Sekunde. Wenn diese Option nicht
verfügbar ist, ist die Pause eine Sekunde lang.)
Unmounten einer Exchange-Kopie
Wenn Sie eine Kopie zum Unmounten auswählen, wird der Mount-Vorgang auch für
andere Kopien ausgeführt, die zusammen mit der ausgewählten Kopie gemountet waren.
Bevor Sie beginnen
l
l
Wenn die Kopie aufgrund der Ausführung einer Wiederherstellung auf Elementebene
gemountet wird, überprüfen Sie, ob alle Vorgänge in der ItemPoint-Anwendung vor
dem Unmounten der Kopie abgeschlossen sind.
Sie können eine Kopie nur aus einer Liste von Kopien unmounten, die für eine Datenbank
erstellt wurde.
Unmounten einer Exchange-Kopie
65
Vorgehensweise
1. Navigieren Sie von den Seiten Data Protection oder Service Plan zur Seite Copies:
l
Copy Management > Microsoft Exchange > Wählen Sie den ExchangePostfachserver aus, der die Datenbank hostet, und wählen Sie dann die
Datenbank mit der Kopie aus, die Sie unmounten möchten.
l
Service Plans > Microsoft Exchange> Wählen Sie einen Serviceplan aus und wählen
Sie dann die Registerkarte Copies aus.
2. Wählen Sie aus der Liste der Kopien eine Kopie aus und klicken Sie auf Unmount.
Das Dialogfeld Unmount Confirmation zeigt die Kopien von anderen Datenbanken an,
die zusammen mit der ausgewählten Kopie gemountet wurden, die Sie unmounten
möchten.
3. Klicken Sie auf Yes, um das Unmounten aller Kopien zu bestätigen, die im Dialogfeld
angezeigt werden.
Im Fenster Unmount wird der Fortschritt des Unmount-Vorgangs angezeigt. Der
Unmount-Vorgang wird bei allen Kopien ausgeführt, die der ausgewählten Kopie
zugeordnet sind.
Übersicht über das Wiederherstellen einer Exchange-Kopie
Hier erhalten Sie Informationen zu den Exchange-Wiederherstellungsfunktionen und den
zugehörigen Speicherlevels für Kopien.
Mit AppSync können Sie die folgenden Objekte wiederherstellen:
l
Eine Datenbank mit zugehörigen Protokollen
l
Eine .edb-Datenbankdatei
l
Nur die Protokolle für eine Datenbank
l
Eine aktive oder passive Datenbank (in Verbindung mit einer der drei bereits
genannten Punkte), wenn der Server Mitglied einer DAG (Database Availability Group)
ist.
AppSync stellt die VNX/VMAX-Kopien auf LUN-Ebene und VNXe-Kopien auf Ebene der
LUN-Gruppe wieder her. In einer RecoverPoint-Umgebung findet die Wiederherstellung
auf Ebene der Consistency Group statt.
Von der Wiederherstellung betroffene Einheiten
Bei der Wiederherstellung von einer Kopie werden Sie möglicherweise aufgefordert,
weitere als die von Ihnen ausgewählten Elemente wiederherzustellen.
Eine betroffene Einheit sind Daten auf dem Produktionshost, die aufgrund ihrer Nähe zu
den Daten, die geschützt werden sollen, unbeabsichtigt Teil eines Replikats werden. Sie
können dies vermeiden, indem Sie Ihr Datenlayout ordnungsgemäß auf Grundlage der
Replikatgranularität planen. Die Granularität eines Replikats hängt von der Umgebung ab.
Wenn betroffene Einheiten in der zugrunde liegenden Speicherkonfiguration vorhanden
sind, werden Sie im Wiederherstellungsassistenten auf diese Einheiten hingewiesen. In
den folgenden Szenarien ergeben sich betroffene Einheiten, für die Sie bestätigen
müssen, dass zusätzliche Elemente wiederhergestellt werden:
66
l
Wenn die Datenbanken für RecoverPoint in derselben Consistency Group sind,
werden sie zu betroffenen Einheiten, wenn die andere Datenbank geschützt ist.
l
Wenn die Datenbanken für VNXe in derselben LUN-Gruppe sind, werden sie zu
betroffenen Einheiten, wenn eine andere Datenbank in der Gruppe geschützt ist.
l
Wenn die Datenbanken für VMAX, VNX, VNXe oder XtremIO auf derselben LUN sind,
werden sie zu betroffenen Einheiten, wenn die andere Datenbank geschützt ist.
l
Da bei virtuellen VMware-Laufwerken zur Wiederherstellung ein Datenspeicher
erforderlich ist, führt eine Wiederherstellung aller Anwendungen im selben
Datenspeicher (virtuelle Laufwerke im selben Datenspeicher) ebenfalls zu
betroffenen Einheiten.
Wenn die betroffene Einheit zusammen mit der für die Wiederherstellung ausgewählten
Datenbank geschützt wurde, wird sie durch AppSync wiederhergestellt. Alle anderen
Datenbanken, die nicht geschützt waren, aber betroffene Einheiten sind, werden
überschrieben. AppSync berechnet die betroffenen Einheiten für die Consistency Groups,
LUN-Gruppen oder LUNs von der Datenbank, die zur Wiederherstellung ausgewählt ist.
Wenn sich die betroffenen Datenbanken teilweise auf anderen Consistency Groups, LUNGruppen oder LUNs befinden, berechnet AppSync die betroffenen Einheiten auf diesen
Consistency Groups nicht. LUN-Gruppen oder LUNs:
Betroffene Einheiten werden auf Basis der Wiederherstellungsgranularität berechnet.
Wenn Daten und Protokolle zur Wiederherstellung ausgewählt sind, werden betroffene
Einheiten für alle Consistency Groups, LUN-Gruppen oder LUNs berechnet, auf denen sich
die Datenbank befindet. Wenn nur die Wiederherstellung von Daten oder Protokollen
ausgewählt ist, werden die betroffenen Einheiten nur für die Consistency Group, LUNGruppe oder LUN der ausgewählten Komponente berechnet.
Wenn sich die Datenbankdaten und die Protokolldateikomponenten auf derselben
Consistency Group, LUN-Gruppe oder LUN befinden, ist die Option, nur Protokolle oder
nur Daten wiederherzustellen, nicht verfügbar. Sie haben nur die Option, Daten und
Protokolle wiederherzustellen. Die einzige Ausnahme für dieses Szenario ist, wenn Sie
eine differenzielle Kopiewiederherstellung durchführen.
Da die Wiederherstellung einen Datenspeicher mit virtuellen VMware-Laufwerken
erfordert, führt eine Wiederherstellung aller Anwendungen im selben Datenspeicher
(virtuelle Laufwerke im selben Datenspeicher) ebenfalls zu betroffenen Einheiten.
Wiederherstellen aus einer Exchange-Kopie
Sie können eine Wiederherstellung einer Exchange-Kopie von einer Kopie oder einer
Datenbank ausführen.
Bevor Sie beginnen
Vorgehensweise
1. Wählen Sie Recover > Restore > Databases and Logs aus den Aktionsschaltflächen im
unteren Bereich der Seite aus.
2. Wählen Sie die wiederherzustellende Kopie aus und klicken Sie auf Next.
3. Wählen Sie auf der Seite Select Options die entsprechenden
Wiederherstellungsoptionen aus und klicken Sie auf Next.
Option
Beschreibung
Both data and logs
Verfügbar bei Wiederherstellung aus vollständigen und
Kopiebackups.
Daten
Verfügbar bei Wiederherstellung aus vollständigen und
Kopiebackups.
Logs
Verfügbar bei der Wiederherstellung aus vollständigen,
Kopie- und differenziellen Backups.
Wiederherstellen aus einer Exchange-Kopie
67
Option
Beschreibung
Recover and mount
databases after
restore
Lassen Sie diese Option aktiviert. Wenn diese Option nicht
aktiviert ist, müssen Sie die Datenbank manuell
wiederherstellen.
Allow AppSync to
activate databases.
Nur für DAG verfügbar. Bei Auswahl dieser Option wird die
Datenbankkopie auf dem Server vor der Wiederherstellung
aktiviert.
Hinweis
Exchange führt die Wiederherstellung nur in die aktive Kopie
aus und AppSync führt die Wiederherstellung auf dem Server
aus, mit dem die Kopie erstellt wurde.
Die Seite Restore Warnings wird angezeigt. Diese Seite wird möglicherweise
angezeigt, wenn die ausgewählte Kopie betroffene Entitäten aufweist.
4. Lesen Sie die Warnmeldungen für die betroffenen Datenbanken.
Im Falle von Exchange 2013 ermittelt AppSync, ob die ausgewählte Datenbank oder
eine der betroffenen Entitäten das Postfach mit öffentlichen Ordnern primärer
Hierarchie enthält. Wenn eine Übereinstimmung gefunden wird, wird die
Fehlermeldung angezeigt, dass der Wiederherstellungsvorgang nicht fortgesetzt
werden kann.
Um zu ermitteln, wo sich das Postfach mit öffentlichen Ordnern primärer Hierarchie
befindet, muss Ihr Benutzerprofil bei AppSync über eine zusätzliche Exchange-Rolle
verfügen - die Organisationsrolle mit lediglich Anzeigerechten. Wenn Ihr Konto nicht
über diese Rolle verfügt, wird eine Warnmeldung angezeigt.
5. Aktivieren Sie das Kontrollkästchen, um Ihr Einverständnis zu erklären, dass die
anderen Entitäten zusammen mit der Kopie wiederhergestellt werden.
Sie müssen die zu überschreibenden Datenbanken manuell unmounten.
6. Überprüfen Sie die Seite Summary, und klicken Sie auf Finish, um die Kopie
wiederherzustellen.
7. Klicken Sie auf der Seite Results auf View Details, um den Fortschritt der
verschiedenen Phasen mitzuverfolgen, die zur Wiederherstellung einer Kopie gehören.
Manuelles Wiederherstellen einer Exchange-Datenbank
Führen Sie eine manuelle Recovery aus, wenn Sie die Option Recover and mount the
databases after restore im Wiederherstellungsassistenten nicht ausgewählt haben.
Bevor Sie beginnen
Wenn Sie nur eine Datenbankdatei wiederherstellen, überprüfen Sie, ob die für die
Recovery erforderlichen Transaktionsprotokolldateien vorhanden sind. Es ist eine
geschlossene Reihenfolge erforderlich. Führen Sie zum Ermitteln des erforderlichen
Mindestbereichs der Protokolle den folgenden Befehl für jede Datenbank nach der
Wiederherstellung und vor dem Ausführen der Recovery aus: ESEUTIL /mh
<database name>. Suchen Sie die erforderlichen Protokollformationen in der ESEUTILAusgabe.
Wenn die Datenbank die aktive Kopie ist, müssen Sie diese zuerst unmounten, um den
Befehl ESEUTIL erfolgreich ausführen zu können.
68
Vorgehensweise
1. Löschen Sie die Kontrollpunktdatei (Enn.chk).
Dieser Schritt ist optional.
2. Löschen Sie die Datei restore.env (EnnRESTORE.env).
3. Stellen Sie die Datenbanken manuell im Soft-Recovery-Modus mithilfe des Befehls
ESEUTIL wieder her.
eseutil /r E<nn> /l <logpath> /s <chkpt file path> /d
<database path>
4. Verwenden Sie die Exchange-Verwaltungskonsole, um alle wiederhergestellten
Datenbanken zu mounten.
Wiederherstellen einer eigenständigen Exchange-Datenbank auf XtremIO
Dieses Verfahren gilt nur für XtremIO 3.x. XtremIO 4.0 und höher verfügt über eine
formelle Wiederherstellung mithilfe des Wiederherstellungsassistenten.
Überprüfen Sie und führen Sie diese Schritte zur Wiederherstellung einer XtremIOSnapKopie für eine eigenständige Exchange-Datenbank aus, die sich auf einem XtremIO 3.xArray befindet.
Vor der manuellen Wiederherstellung (Mounten mit Validierungsphase) mit diesem
Verfahren wird die gemountete Kopie validiert.
Hinweis
Beschränkungen: Umbenannte und gelöschte Datenbanken können nicht
wiederhergestellt werden. Das Wiederherstellen von (ausschließlich) Daten oder
(ausschließlich) Protokollen wird nicht unterstützt.
Vorgehensweise
1. Unterbrechen Sie AppSync-Planungen, die Auswirkungen auf die
wiederherzustellende Kopie haben.
2. Verwenden Sie die AppSync-Konsole zum Mounten der Kopie, um die Kopie auf dem
Produktionshost wiederherzustellen. Sorgen Sie dafür, dass Sie die
Validierungsphase ausgewählt ist.
a. Sorgen Sie dafür, dass das Mounten mit Lese-/Schreibzugriff ausgeführt wird.
b. Führen Sie das Mounten mit Standardpfad oder einem benutzerdefinierten Pfad
aus
3. Beenden Sie die Produktionsanwendung mithilfe der Exchange-Verwaltungskonsole
Dismount Production database.
4. Unmounten Sie die Exchange-Datenbank von der Exchange-Verwaltungskonsole.
5. Entfernen Sie die Laufwerksbuchstaben für Laufwerke der Produktionsdatenbank.
6. Weisen Sie der gemounteten Datenbank Laufwerksbuchstaben der
Produktionsdatenbank zu (jeweils Daten- und Protokolldateilaufwerke). Prüfen Sie
dann die Daten- und Protokollpfade.
7. Mounten Sie die Produktionsdatenbank in der Exchange-Verwaltungskonsole.
8. Klicken Sie zum Entfernen von Kopien aus der AppSync-Datenbank auf der Seite
Copies der AppSync-Konsole auf Remove.
Die Funktion Remove ähnelt der Funktion Expire. Bei Remove werden die Kopien
jedoch nicht aus dem Speicher entfernt.
Wiederherstellen einer eigenständigen Exchange-Datenbank auf XtremIO
69
9. Verschieben Sie auf der AppSync-Konsole die gemounteten Snapshots in den
Produktionsordner im XtremIO-Array.
10. Testen Sie die wiederhergestellten Inhalte zur Bestätigung einer erfolgreichen
Wiederherstellung.
11. Entfernen Sie die Produktions-Volumes auf XtremIO mit derAppSync-Konsole.
Aus Snapshots von gelöschten Volumes werden Produktions-Volumes.
12. Falls die Laufwerke der Daten und Protokolldateien vDisks waren, führen Sie eine
erneute VMware Virtual Center-Erkennung in AppSync aus.
13. Führen Sie zum Erstellen einer neuen Kopie aus den wiederhergestellten Daten den
Serviceplan aus.
14. Setzen Sie die unterbrochenen Planungen wieder fort.
15. Bereinigen oder löschen Sie gegebenenfalls Produktionsgeräte vom Produktionshost
und entfernen Sie AppSync-Mount-Punkte, die während der Mount-Phase erstellt
wurden.
Wiederherstellen einer Exchange-Datenbank-DAG auf XtremIO
Dieses Verfahren gilt nur für XtremIO 3.x. XtremIO 4.0 und höher verfügt über eine
formelle Wiederherstellung über die Schaltfläche Restore und den
Wiederherstellungsassistenten.
In diesen Schritten wird Ihnen vermittelt, wie Sie eine XtremIOSnap-Kopie einer
Exchange-Datenbank mit DAG wiederherstellen, die sich auf einem XtremIO 3.x-Array
befindet.
Vor der manuellen Wiederherstellung (Mounten mit Validierungsphase) mit diesem
Verfahren wird die gemountete Kopie validiert.
Hinweis
Beschränkungen: Umbenannte und gelöschte Datenbanken können nicht
wiederhergestellt werden. Das Wiederherstellen von (ausschließlich) Daten oder
(ausschließlich) Protokollen wird nicht unterstützt.
Vorgehensweise
1. Unterbrechen Sie AppSync-Planungen, die Auswirkungen auf die
wiederherzustellende Kopie haben.
2. Verwenden Sie die AppSync-Konsole zum Mounten der Kopie, um die Kopie auf dem
Produktionshost wiederherzustellen. Sorgen Sie dafür, dass Sie die
Validierungsphase ausgewählt ist.
a. Stellen Sie sicher, dass das Mounten mit Lese-/Schreibzugriff ausgeführt wird.
b. Führen Sie das Mounten mit Standardpfad oder einem benutzerdefinierten Pfad
aus (DAG-Mitglied, auf dem die Kopie geschützt wurde).
3. Beenden Sie die Produktionsanwendung mithilfe der Exchange-Verwaltungskonsole.
Unterbrechen Sie passive Kopien und unmouten Sie dann die Produktions[Active]Datenbank.
4. Entfernen Sie die Laufwerksbuchstaben für Laufwerke der Produktionsdatenbank.
5. Weisen Sie der gemounteten Datenbank Laufwerksbuchstaben der
Produktionsdatenbank zu (jeweils Daten- und Protokolldateilaufwerke) und prüfen Sie
dann die Daten- und Protokollpfade.
6. Mounten Sie die Produktionsdatenbank in der Exchange-Verwaltungskonsole.
70
7. Führen Sie zum Aktualisieren von passiven Kopien den folgenden Befehl für alle DAGMitglieder aus: Update-MailboxDatabaseCopy -Identity <Database
Name>\<DAG member> -SourceServer <DAG Member>
8. Klicken Sie in der AppSync-Konsole auf der Seite AppSync Copies auf Remove, um
Kopien aus der AppSync-Datenbank zu entfernen.
Die Funktion Remove funktioniert wie die Funktion Expire. Bei Remove werden die
Kopien jedoch nicht aus dem Speicher gelöscht.
9. Verschieben Sie auf der AppSync-Konsole die gemounteten Snapshots in den
Produktionsordner im XtremIO-Array.
10. Testen Sie die wiederhergestellten Inhalte zur Bestätigung einer erfolgreichen
Wiederherstellung.
11. Entfernen Sie die Produktions-Volumes auf XtremIO mit derAppSync-Konsole.
Aus Snapshots von gelöschten Volumes werden Produktions-Volumes.
12. Falls die Laufwerke der Daten und Protokolldateien vDisks waren, führen Sie eine
erneute VMware Virtual Center-Erkennung in AppSync aus.
13. Führen Sie zum Erstellen einer neuen Kopie aus den wiederhergestellten Daten den
Serviceplan aus.
14. Setzen Sie die unterbrochenen Planungen wieder fort.
15. Bereinigen oder löschen Sie gegebenenfalls Produktionsgeräte vom Produktionshost
und entfernen Sie AppSync-Mount-Punkte, die während der Mount-Phase erstellt
wurden.
Teilwiederherstellung
Bei einer Teilwiederherstellung stellen Sie nur die Daten oder die Daten und
anschließend die Protokolle wieder her.
Stellen Sie vor einer Teilwiederherstellung sicher, dass das Datenbanklayout bestimmte
Bedingungen erfüllt.
Überlegungen zur Teilwiederherstellung
In einer RecoverPoint-Umgebung erfolgt die Granularität der Wiederherstellung auf Ebene
der Consistency Group. Wenn Sie eine Datenbank aus einem Lesezeichen
wiederherstellen, werden alle Lesezeichen gelöscht, die neuer als das Lesezeichen sind,
das wiederhergestellt wird. Die entsprechenden Anwendungskopien werden ebenfalls
gelöscht. Die folgenden Best Practices werden empfohlen:
l
Die Datenbanken und die Protokolle müssen sich in unterschiedlichen Consistency
Groups befinden.
Wenn Daten und Protokolle für eine Exchange-Datenbank in derselben Consistency
Group vorliegen, wird eine Teilwiederherstellung nicht unterstützt.
l
Die Protokolle müssen dann von einer neueren differenziellen Backupkopie
wiederhergestellt werden. In AppSync wird die Wiederherstellung nur der Protokolle
aus einem kompletten oder Kopiebackup in einer RecoverPoint-Umgebung nicht
unterstützt.
In einer VMAX/VNX-Umgebung müssen sich die Datenbanken und Protokolle auf
verschiedenen LUNs befinden.
Teilwiederherstellung
71
Wiederherstellen von Daten
Wiederherstellen von Daten aus einem kompletten oder Kopiebackup Sie können nur die
Daten wiederherstellen, um die Protokolle auf dem Produktionshost beizubehalten.
Stellen Sie im Wiederherstellungsassistenten die Daten von der neuesten Kopie wieder
her und wählen Sie die Option Recover and mount the databases after restore aus.
Wiederherstellen von Protokollen
Stellen Sie Daten aus einem kompletten oder einem Kopiebackup wieder her und stellen
Sie dann die Protokolle aus einer späteren Kopie wieder her, um die Kopie aktuell zu
machen.
Die Wiederherstellung einer Kopie aus den Protokollen ist ein zweistufiger Prozess.
Führen Sie den Wiederherstellungsassistenten aus und wählen Sie eine komplette
Backupkopie aus, um nur die Daten wiederherzustellen. Wählen Sie bei dieser
Ausführung nicht die OptionRecover and mount the databases after restore aus.
Führen Sie den Wiederherstellungsassistenten erneut aus und wählen Sie eine
Backupkopie aus (ein differenzielles Backup im Falle von RecoverPoint), um nur die
Protokolle wiederherzustellen. Wählen Sie dieses Mal die Option Recover and mount the
databases after restore aus. Diese Kopie muss später als die Backupkopie sein, die Sie
während der ersten Ausführung ausgewählt haben.
Note
Wenn der Wiederherstellungsvorgang das Wiederherstellen von Protokollen umfasst,
werden alle Protokolle, die seit der Erstellung der Kopie erstellt wurden, überschrieben.
Daher spiegelt die Datenbank nach der Wiederherstellung den Point-in-Time wieder, zu
dem die Kopie erstellt wurde. Wenn Sie die Protokolle bewahren möchten, die seit der
Kopie erstellt wurden, stellen Sie nur die Datenbanken wieder her. Dadurch wird
verhindert, dass AppSync ältere Protokolle statt der neueren wiederherstellt. Sie können
außerdem eine Kopie der aktuellen Protokolldateien auf einem anderen Volume anlegen.
Wiederherstellen von Protokollen aus absturzkonsistenten (APiT) Kopien
Wiederherstellen einer Kopie zu jedem beliebigen Point-in-Time (APiT) mithilfe von
Protokollen.
Bevor Sie beginnen
Dies gilt nur bei einer RecoverPoint-Umgebung.
Hinweis
Das Wiederherstellen von Protokollen aus einer absturzkonsistenten Kopie ist keine
empfohlene Vorgehensweise, da das Backup nicht mit dem Exchange Writer erstellt wird.
Allerdings kann die Option verwendet werden, um Datenverlust zu minimieren, wenn
anwendungskonsistente Kopien für dieses Zeitfenster nicht zur Wiederherstellung
verfügbar sind.
Vorgehensweise
1. Stellen Sie eine Datenbank aus einer anwendungskonsistenten Kopie wieder her,
ohne für sie eine Recovery auszuführen.
2. Mounten Sie eine Kopie von einem neueren Point-in-Time.
3. Kopieren Sie die neueren Protokolldateien in das Volume des Produktionsprotokolls.
72
4. Verwenden Sie ESEUTIL /k Enn (Enn ist das Protokollpräfix für die Datenbank),
um die Protokolle zu prüfen, und stellen Sie dann die Datenbank wieder her und
mounten Sie sie.
Wiederherstellen einer gelöschten Exchange-Datenbank
AppSync kann eine Datenbank wiederherstellen, selbst wenn sie aus Exchange in
eigenständigen und DAG-Umgebungen gelöscht wird.
Bevor Sie beginnen
l
Wenn Sie die Datenbankdateien gelöscht und eine leere Datenbank erstellt haben,
heben Sie die Bereitstellung der Datenbank auf und löschen Sie ihre Dateien. Die
Datenbank, die Sie wiederherstellen, darf keine Daten und Protokolldateien am
ursprünglichen Speicherort aufweisen, an dem sie sich beim Erstellen der leeren
Datenbank befanden. Die Protokolldateisignaturen stimmen ansonsten nicht mit
denen in der AppSync-Kopie überein und die Wiederherstellung schlägt fehl.
l
Wenn Sie die Datenbank vollständig entfernen und neu erstellen, müssen der
Datenbankname und ihr Dateipfad sowie die Namen genau dieselben wie die in Ihrer
AppSync-Kopie sein. Wenn Sie die gelöschte Datenbank nicht neu erstellen, wird
diese von AppSync neu erstellt.
l
In einer DAG-Umgebung:
n
Es dürfen keine aktiven oder passiven Kopien der gelöschten DAG-Datenbank
vorhanden sein.
n
AppSync erstellt ausschließlich die aktive Datenbankkopie neu und stellt sie auf
dem Server wieder her, mit dem die AppSync-Kopie erstellt wurde. Nachdem die
Datenbank wiederhergestellt und eine Recovery ausgeführt wurde, können Sie die
passiven DAG-Kopien neu erstellen.
Wenn Sie die Option Recover and mount the databases after restore im
Wiederherstellungsassistenten nicht ausgewählt haben, führen Sie die folgenden
manuellen Schritte zur Wiederherstellung der Datenbank aus.
Vorgehensweise
1. Kopieren Sie die erforderlichen Protokolle aus dem _restoredLogs-Verzeichnis in
das Verzeichnis, in dem sich die aktuellen Protokolle befinden.
2. Wenn sich das Protokolldateipräfix geändert hat, benennen Sie die erforderlichen
Protokolldateien um, um das neue Präfix zu verwenden.
3. Löschen Sie die E<nn>restore.env file.
4. Stellen Sie die Datenbanken manuell im Soft-Recovery-Modus mithilfe des Befehls
ESEUTIL wieder her.
eseutil /r E<nn> /l <logpath> /s <chkpt file path> /d
<database path>
5. Löschen Sie das _restoredLogs-Verzeichnis, das nach dem Wiederherstellen der
Datenbank leer sein sollte.
Wiederherstellung auf Elementebene
AppSync kann einzelne Exchange 2010- und Exchange 2013-Postfächer und -Nachrichten
wiederherstellen, wenn EMC ItemPoint für Microsoft Exchange Server installiert ist.
Die folgende Software muss installiert und auf dem Mount-Host ausgeführt werden, in
dem die Wiederherstellung auf Elementebene durchgeführt werden soll:
Wiederherstellen einer gelöschten Exchange-Datenbank
73
l
AppSync-Host-Plug-in
l
EMC ItemPoint für Microsoft Exchange Server
l
Microsoft Exchange MAPI-Client
l
Microsoft Outlook-32-Bit-Client
Weitere Informationen zu ItemPoint finden Sie in der ItemPoint-Dokumentation auf der
EMC Supportwebsite.
Wiederherstellen einzelner Postfächer und Postfachelemente
Verwenden Sie ItemPoint zum Wiederherstellen einzelner Exchange-Postfächer und
Postfachelemente.
Bevor Sie beginnen
Vorgehensweise
1.
Melden Sie sich beim Mount-Host als ItemPoint ausführender Benutzer an. Sie
müssen ein lokaler Administrator sein.
2. Wählen Sie Recover > Restore > Individual Items auf der Seite Databases oder Copies
aus.
3. Wählen Sie auf der Seite Select Copy eine Kopie aus der Liste aus.
Wenn die Kopie mit RecoverPoint erstellt wurde, können Sie die Option Add a desired
Point in time verwenden und diese Kopie auswählen. Geben Sie bei Auswahl dieser
Option ein Datum und eine Uhrzeit (und ggf. einen DAG-Server) an. (Wenn Sie den
Assistenten von einer Kopie gestartet haben, führen Sie diesen Schritt nicht aus).
4. Wenn die Kopie nicht gemountet ist, wählen Sie die Mount-Optionen aus. Wählen Sie
auf der Seite Select Mount Optionsden Mount-Host und den Mount-Pfad aus
(ursprünglicher Pfad oder Standard).
5. Geben Sie auf der Seite Item Level Restore Settings die Benutzeranmeldedaten und
das Passwort ein, um auf den Assistenten zur Wiederherstellung auf Elementebene
zuzugreifen, und wählen Sie ein temporäres Verzeichnis aus.
Das temporäre Verzeichnis wird von ItemPoint zum Speichern von Dateien verwendet,
die für die Wiederherstellung von Daten verwendet werden. Diese Dateien benötigen
unter Umständen genauso viel Speicherplatz wie die .LOG-Dateien. Verwenden Sie die
in Schritt 1 beschriebenen Benutzeranmeldedaten.
Für diesen Vorgang sind der Microsoft Exchange MAPI-Client und der Outlook-32-BitClient erforderlich. Zusätzliche Details zu erforderlichen Exchange-Rollen und Berechtigungen für das zum Zugriff auf ItemPoint verwendete Konto finden Sie in der
EMC ItemPoint for Microsoft Exchange Server-Dokumentation.
6. Bestätigen Sie Ihre Einstellungen auf der Seite Summary und wählen Sie Finish aus,
um EMC ItemPoint for Microsoft Exchange Server zu starten.
Weitere Erfordernisse
l
74
Nachdem Sie den Vorgang abgeschlossen haben, verwenden Sie ItemPoint zur
Wiederherstellung von Postfachelementen. Weitere Informationen zur Verwendung
von EMC ItemPoint for Microsoft Exchange Server finden Sie in der EMC ItemPoint for
Microsoft Exchange Server-Dokumentation.
Hinweis
Unmounten Sie die mithilfe von Item Point wiederherzustellende Kopie nicht, bis der
gesamte Prozess innerhalb von Item Point abgeschlossen ist.
Troubleshooting des EMCAppSync Exchange Interface-Service
Beachten Sie die folgenden Tipps zum Troubleshooting:
Ist ein Neustart erforderlich?
Wenn Sie dasAppSync-Host-Plug-in zum ersten Mal installieren, müssen Sie
möglicherweise Ihren Exchange-Server nach Abschluss der Installation neu starten. In
einigen Umgebungen ist zur Installation der Visual C++ 2010-Laufzeit ein Neustart
erforderlich. In früheren Versionen vonAppSync wurde die Installation automatisch ohne
Warnung neu gestartet. Der automatische Neustart wurden mit AppSync 2.0 und höher
entfernt. Um zu überprüfen, ob ein Neustart erforderlich ist, suchen Sie in Windows
\temp\appsync_host_plugin_setup.log nach folgendem Eintrag:
>: "C:\Program Files\EMC\AppSync Host
Plug-in\msredist\vcredist-10.0.40219.1-x64.exe" /q
Command.run(): starting stdout monitor...
Command.run(): starting stderr monitor...
Command.complete(): waiting for process to complete.
Command.complete(): process completed with exit
code: 3010
Der Exitcode 3010 weist darauf hin, dass ein Neustart erforderlich ist.
Hat das Benutzerkonto die richtigen Rechte?
Wenn der EMC AppSync Exchange Interface-Service nicht ordnungsgemäß registriert wird,
überprüfen Sie die Datei ExchangeInterfaceInstall.log im Verzeichnis host
plug-in\logs von AppSync. Ein gängiges Problem ist, dass das Benutzerkonto für den
ausgeführten Service nicht über die richtige Log on as a batch job-Berechtigung
verfügt.
Wenn AppSync keine Datenbanken erkennt, überprüfen Sie, ob das Benutzerkonto für
den EMCAppSync Exchange Interface-Service die richtigen Berechtigungen für Exchange
hat.
Manuelles Registrieren des Service
1. Gewähren Sie dem Benutzerkonto, auf dem der EMC AppSync Exchange InterfaceService ausgeführt wird, die Benutzerberechtigungen Log on as a batch job
und Log on as a service.
2. Öffnen Sie eine Eingabeaufforderung und navigieren Sie zu dem Verzeichnis, in dem
das AppSync-Host-Plug-in installiert ist. Der Standardspeicherort lautet C:
\Program Files\EMC\AppSync Host Plug-in.
3. Führen Sie den folgenden Befehl aus, um den Service und die DCOM-Komponente zu
registrieren: awExchangeInterface /service /user <"domain
\username"> /password <"password"> /nopriv Beispiel:
awExchangeInterface /service /user mydomain /
appsyncexchuser /password mYp@55W0rd.
4. Führen Sie zum Konfigurieren des Passworts für die DCOM-Komponente DCOMCNFG
aus.
5. Erweitern Sie Component Services > Computer > Arbeitsplatz > DCOM Config.
Troubleshooting des EMCAppSync Exchange Interface-Service
75
6. Klicken Sie mit der rechten Maustaste auf EMC AppSync Exchange Interface und
wählen Sie Properties.
7. Klicken Sie auf die Registerkarte Identity.
8. Wählen Sie This user und geben Sie das Benutzerkonto und Passwort aus Schritt 3
ein.
9. Klicken Sie auf OK.
10. Überprüfen Sie, ob Sie den EMC AppSync Exchange Interface-Service starten können,
indem Sie net start appsyncexchangeinterface ausführen..
11. Verwenden Sie die AppSync-Konsole, um den Server erneut zu erkennen. Navigieren
Sie zu Settings > Servers, wählen Sie den Server aus und klicken Sie dann auf
Rediscover.
12. Entdecken Sie die Exchange-Mailbox-Datenbanken. Navigieren Sie zu Copy
Management > Exchange und klicken Sie auf den Exchange Server. Sie müssen
möglicherweise die Anmeldedaten erneut eingeben.
Was ist zu tun, wenn der Service teilweise registriert ist?
Wenn die Rechte und Berechtigungen für das Benutzerkonto nicht ordnungsgemäß
gewährt wurden oder wenn nicht kompatible Software installiert ist, wird der EMC
AppSync Exchange Interface-Service nicht korrekt registriert. Möglicherweise müssen Sie
eine manuelle Bereinigung durchführen. Führen Sie die folgenden Schritte aus:
1. Öffnen Sie eine Eingabeaufforderung und navigieren Sie zu dem Verzeichnis, in dem
das AppSync-Host-Plug-in installiert ist. Der Standardspeicherort lautet C:
\Program Files\EMC\AppSync Host Plug-in.
2. Führen Sie den folgenden Befehl aus, um den Service zu entfernen und die DCOMKomponente zu löschen: awExchangeInterface /unregserver
3. Überprüfen Sie anhand der Servicekonsole (service.msc), ob der EMC AppSync
Exchange Interface-Service entfernt wurde. Wenn der Fehler weiterhin auftritt, führen
Sie Folgendes aus: sc delete AppSyncExchangeInterface
4. Überprüfen Sie anhand der Komponentenservices-Konsole (DCOMCNFG), ob die EMC
AppSync Exchange Interface DCOM-Komponente entfernt wurde. Erweitern Sie
Component Services > Computer > Arbeitsplatz > DCOM-Config.
5. Wenn die Komponente weiterhin fehlerhaft ist, klicken Sie auf DCOM-Konfiguration,
klicken Sie auf EMC AppSync Exchange Interface und klicken Sie dann auf Delete.
76
KAPITEL 6
l
l
l
l
l
l
l
l
l
Übersicht über die SQL Server-Unterstützung........................................................ 78
Unterstützung für AlwaysOn-Verfügbarkeitsgruppen..............................................81
SQL Server-Transaktionsprotokollbackup.............................................................. 82
Überlegungen für die Arbeit mit SQL Server in einem Cluster................................. 91
SQL Server-Benutzerdatenbank-Ordner................................................................. 93
Schützen einer SQL-Datenbank............................................................................. 94
Mount-Überlegungen für SQL Server....................................................................107
Wiederherstellung von SQL Server-Datenbanken – Übersicht.............................. 114
Neuverwendung von SQL Server-Datenbankkopien............................................. 127
77
Übersicht über die SQL Server-Unterstützung
Verwenden Sie AppSync zum Erstellen und Verwalten anwendungskonsistenter Kopien
von Microsoft SQL Server-Datenbanken.
Die AppSync-Unterstützung für Microsoft SQL-Anwendungen umfasst:
l
Unterstützung für AlwaysOn-Verfügbarkeitsgruppen
l
Dynamische Ermittlung der Benutzerdatenbanken beim Ausführen des Serviceplans
l
Unterstützung für Datenbanken auf physischen Hosts, RDMs und virtuellen
Laufwerken auf virtuellen Hosts
Hinweis
AppSync unterstützt RDMs nur im physischen Kompatibilitätsmodus. RDMs im
virtuellen Modus werden nicht unterstützt.
l
Schutz für eigenständige und geclusterte SQL Server-Produktionsinstanzen.
l
Mounten auf einem eigenständigen Server oder Cluster-Nodes von alternativen
Clustern oder Produktionsclustern als Ressource ohne Cluster. Mounten mit Recovery
auf einer Instanz ohne Cluster.
Unterstützung für die Neuverwendung von SQL Server-Datenbankkopien
SQL Server-Voraussetzungen
Vergewissern Sie sich, dass die SQL Server-Konfiguration die Voraussetzungen erfüllt, die
hier aufgeführt sind. DieAppSync Support Matrix unter https://
elabnavigator.emc.com/eln/extendedSupport ist die maßgebliche Informationsquelle zu
unterstützten Softwareprogrammen und Plattformen.
78
l
Die SQL Server-Datenbank und ihre Transaktionsprotokolle müssen sich auf
Laufwerken im gleichen Speicher-Array befinden.
l
Die SQL Server-Datenbank muss während der Replikation online sein.
l
Volltext-Kataloge, die einer Dateigruppe zugeordnet sind, werden als Bestandteil
eines Replikats dieser Dateigruppe eingeschlossen. Wenn sich die Volltext-Kataloge
nicht auf einem unterstützten Speicher befinden, schlägt der Schutz fehl. Stellen Sie
bei der Verwendung von Volltext-Katalogen sicher, dass das Speichergerät, auf dem
sich der Katalog befindet, nicht Daten enthält, die nicht zur Datenbank gehören.
l
Wenn Sie die Datenbanken von der gemounteten Kopie wiederherstellen möchten,
muss der Mount-Host über einen installierten SQL Server verfügen. Es wird
empfohlen, dieselbe Version von SQL Server auf dem Produktionshost und dem
Mount-Host zu verwenden.
l
In Hyper-V-Umgebungen erfordert AppSync, dass sich der Speicher für die SQLDatenbank und die Protokolldateien auf NPIV Fibre-Geräten, iSCSI Direct AttachedGeräten oder SCSI-Pass-Through-Geräten befindet. Das Filtern von SCSI Command
Descriptor Block (CDB) muss in der übergeordneten Partition deaktiviert sein. Es ist
standardmäßig aktiviert. Für SQL Server-Cluster erfordert AppSync, dass sich der
Speicher auf NPIV Fibre- oder iSCSI Direct Attached-Geräten befindet.
l
Systemdatenbanken werden nicht unterstützt.
l
SQL Server-Datenbank-Snapshots werden nicht erkannt.
l
Das Erstellen einer Kopie einer Datenbank-Spiegelung wird nicht unterstützt. Der
Versuch, dies dennoch zu tun, führt zu einem Fehler, der besagt, dass die Datenbank
nicht in einem gültigen Status ist.
SQL Server-unterstützte Konfigurationen
AppSync bietet Unterstützung für die SQL-Konfigurationen, die hier aufgeführt sind.
l
Mehrere SQL Server-Datenbanken können auf demselben Volume oder über mehrere
Volumes vorhanden sein. Es ist jedoch eine empfohlene Vorgehensweise, die
Datenbanken von mehr als einer SQL Server-Instanz auf einem Volume nicht zu
mischen.
l
Mehrere SQL Server-Instanzen können auf demselben Host vorhanden sein.
Unterstützung für SQL Server auf virtuellen Laufwerken
Sie können eigenständige und geclusterte SQL Server-Datenbanken auf virtuellen
VMware-Laufwerken schützen, mounten und wiederherstellen.
Während des Schutzes:
l
Für eine erfolgreiche Zuordnung muss der VirtualCenter dem AppSync-Server
hinzugefügt werden, und Erkennung muss durchgeführt werden.
l
Für einen erfolgreichen Schutz müssen sich Protokolldateien und Datenbankdateien
auf virtuellen Laufwerken befinden. Es darf keine Kombination aus physischen und
virtuellen Speichern sein.
l
Der Schutz von SQL Server-Datenbanken auf virtuellen Maschinen, die denselben
Datenspeicher gemeinsam nutzen, wird nicht unterstützt.
l
Bei der Wiederherstellung von geclusterten SQL Server-Datenbanken müssen Sie alle
Eigentümer-Nodes der geclusterten SQL Server-Instanz zu AppSync hinzufügen.
Erforderliche Berechtigungen und Rechte
Benutzer müssen bestimmte Berechtigungen und Rechte zum Schutz von Datenbanken
in einer SQL Server-Umgebung besitzen. Das Benutzerkonto muss so konfiguriert sein,
dass entweder die SQL Server-Authentifizierung oder die Windows-Authentifizierung
genutzt wird.
Bei dem Windows-Benutzerkonto kann es sich um ein Mitglied der Gruppe der lokalen
Administratoren oder um ein Nicht-Administratorkonto handeln.
Bei SQL Server 2012 hat das im Service-Startkonto der Datenbank-Engine verwendete
virtuelle Standardkonto die erforderlichen Dateisystemberechtigungen für den Zugriff auf
die gemounteten oder wiederhergestellten Datenbankdateien nicht. Aus diesem Grund
kann die Recovery von SQL-Datenbanken fehlschlagen. Um dies zu überwinden, müssen
Sie das Service-Startkonto für die SQL Server-Datenbank-Engine so ändern, dass ein
Domainbenutzerkonto mit entsprechenden Rechten und Berechtigungen verwendet wird.
Einrichten von Berechtigungen für ein Domainkonto, das nicht über lokale Administratorrechte
verfügt.
Zusätzliche Konfiguration ist erforderlich, wenn Sie ein Domainkonto verwenden, das
nicht über lokale Administratorrechte verfügt.
Vorgehensweise
1. Erstellen Sie einen Windows-Domainbenutzer (z. B. sqluser) und legen Sie diesen
Benutzer als Teil der Domainbenutzergruppe fest.
SQL Server-unterstützte Konfigurationen
79
2. Erstellen Sie in SQL Server Management Studio eine neue Anmeldung mithilfe des
neu erstellten Domainkontos und wählen Sie Windows-Authentifizierung aus.
3. Wählen Sie auf der Seite General die Option master als Standarddatenbank aus.
4. Wählen Sie auf der Seite Server Roles die Optionen sysadmin und public aus.
5. Setzen Sie auf der Seite User Mapping die Rollenmitgliedschaft für die Datenbank auf
Public.
6. Fügen Sie den Benutzer zu jeder SQL Server-Instanz hinzu, zu der dieser Benutzer
Zugriff benötigt:
a. Auf den Domain-Controller: Auf die Hosts, die der Domain hinzugefügt werden:
Start > Programs > Administrative Tools > Domain Controller Security Policy
Auf die Hosts, die der Domain hinzugefügt werden: Start > Programs >
Administrative Tools > Local Security Policy
b. Rufen Sie die Sicherheitseinstellungen auf und lassen Sie eine lokale Anmeldung
zu (Security Settings > Local Policies > User Rights Assignment > Allow log on
locally)
c. Fügen Sie den Benutzer hinzu (in diesem Beispiel: sqluser), den Sie vorher erstellt
haben.
7. Melden Sie sich für jeden Host, welcher der Domain hinzugefügt wurde, die AppSync
verwendet, bei der Domain-Controller-Maschine an und legen Sie dann die
Sicherheitsrichtlinie fest.
8. Gewähren Sie diesem Benutzer Lese- und Schreibberechtigungen für das Verzeichnis,
in dem das AppSync-Plug-in installiert wurde (normalerweise C:\Program Files
\EMC\AppSync Host Plug-in).
9. Verwenden Sie diesen Benutzer von AppSync, wenn Sie Schutz konfigurieren oder
andere Aktionen ausführen, die Zugriff auf SQL Server erfordern.
10. Zum Zeitpunkt der Wiederherstellung, wenn Sie die Option für das Backup der
Transaktionsprotokolle in eine Datei auswählen, muss der Benutzer über Rechte zum
Zugriff auf das Zielverzeichnis verfügen.
Festlegen von Berechtigungen für einen lokalen Benutzer ohne Administratorrechte
Ein Benutzerkonto, das nicht über lokale Administratorrechte verfügt, benötigt bestimmte
Berechtigungen, bevor es zum Zugriff auf den SQL Server über AppSync verwendet
werden kann.
Vorgehensweise
1. Erstellen Sie einen Windows-Benutzer und legen Sie diesen Benutzer als Teil der
Benutzergruppe fest.
2. Erstellen Sie in SQL Server Management Studio eine neue Anmeldung mithilfe des
neu erstellten Kontos. Wählen Sie als Authentifizierungstyp WindowsAuthentifizierung aus.
3. Wählen Sie auf der Seite Server Roles sysadmin und public aus.
4. Setzen Sie auf der Seite User Mapping die Rollenmitgliedschaft für die Datenbank auf
public.
5. Fügen Sie den Benutzer zu jeder SQL Server-Instanz hinzu, zu der dieser Benutzer
Zugriff benötigt:
a. Legen Sie auf dem Host, der das Plug-in ausführt, die Sicherheitsrichtlinie fest.
Führen Sie auf dem Domain-Controller Start > Programs > Administrative Tools >
Local Security Policy aus.
80
Führen Sie auf den Hosts, die der Domain hinzugefügt werden, Folgendes aus:
Start > Programs > Tools > Local Security Policy
b. Rufen Sie die Sicherheitseinstellungen auf und lassen Sie eine lokale Anmeldung
zu (Security Settings > Local Policies > User Rights Assignment > Allow log on
locally).
c. Fügen Sie den Benutzer hinzu (in diesem Beispiel: sqluser), den Sie vorher erstellt
haben.
6. Gewähren Sie diesem Benutzer Lese- und Schreibberechtigungen für den Ordner, in
dem das AppSync-Plug-in installiert wurde.
7. Wenn Sie die Wiederherstellungsoption für das Backup der Transaktionsprotokolle in
eine Datei auswählen, muss der Benutzer über Zugriffsrechte für das Zielverzeichnis
verfügen.
Aktualisieren von Anmeldedaten für eine SQL Server-Instanz
Wenn sich die Anmeldedaten für eine SQL Server-Instanz geändert haben, müssen Sie
diese in AppSync aktualisieren.
Bevor Sie beginnen
Dieser Vorgang erfordert die Datenadministratorrolle in AppSync Darüber hinaus sollten
Sie die neuen Anmeldeinformationen für die SQL Server-Instanz kennen.
Vorgehensweise
1. Wählen Sie Copy Management aus.
2. Wählen Sie Microsoft SQL Server aus.
3. Wählen Sie eine Instanz aus.
4. Klicken Sie auf Connection Settings in der unten stehenden Zeile der Schaltflächen.
5. Geben Sie die SQL Server-Anmeldedaten ein.
Bei den Anmeldedaten kann es sich um einen Windows-Benutzer oder einen SQLBenutzer mit den erforderlichen Rechten handeln.
Unterstützung für AlwaysOn-Verfügbarkeitsgruppen
Die Verfügbarkeitsgruppen können Teil von geclusterten und nicht geclusterten SQL
Server-Instanzen sein, die auf AlwaysOn-Failover-Clustern installiert sind.
AppSync unterstützt komplette oder Kopiebackups primärer Datenbanken und
Kopiebackups sekundärer Datenbanken. Mit der Option Auto Switch to Copy in der Phase
Create copy des SQL Server-Serviceplans können Sie für sekundäre Datenbanken von Full
auf Copy wechseln.
Besondere Überlegungen bei der Verwendung von AlwaysOn-Verfügbarkeitsgruppen:
l
Um sekundäre Datenbanken zu schützen, müssen diese schreibgeschützt sein. Die
Option Lesbare sekundäre in SQL Server Management Studio muss auf Ja
festgelegt sein. Nur Lese-Absicht wird nicht unterstützt.
l
Verwenden Sie nicht den ursprünglichen Pfad beim Mounten einer AppSync-Kopie
mit einem Node im gleichen Cluster, wenn dieser Node eine Kopie der Datenbank
hostet.
l
Es wird empfohlen, Replikate im synchronen Commit-Modus zu schützen.
l
Die Überlegungen für das Arbeiten mit SQL Server in einem Cluster gelten auch für
Verfügbarkeitsgruppen. Siehe Überlegungen für SQL in einem Cluster auf Seite 91.
Aktualisieren von Anmeldedaten für eine SQL Server-Instanz
81
l
Mehrere Subnetze werden für AlwaysOn-Verfügbarkeitsgruppen unterstützt, solange
keine der Datenbankkopien zu einer geclusterten SQL Server-Instanz gehören.
SQL Server-Transaktionsprotokollbackup
AppSync 2.1 oder höher unterstützt das SQL Server-Transaktionsprotokollbackup.
Erfahren Sie wichtige Überlegungen sowie Einschränkungen vor der Implementierung
Ihrer Backups.
Jede SQL Server-Datenbank verfügt über ein Transaktionsprotokoll. Schreiben Sie die
Protokollbackups auf EMC Speichersysteme, die von AppSync unterstützt werden, damit
Sie Kopien des Protokollbackup-Volume erstellen können. Wenn Sie die Protokolle für
Datenbanken in einer Failover-Cluster-Umgebung sichern, verwenden Sie gemeinsamen
Speicher oder eine Netzwerkfreigabe, damit die Protokollbackups auf denselben
Speicherort geschrieben werden.
Backups von Transaktionsprotokollen können während der Recovery einer
Produktionsdatenbank oder beim Erstellen einer Kopie der Produktionsdatenbank
verwendet werden. Abhängig vom Datenbank-Recovery-Modell kann das
Transaktionsprotokoll voll ausgelastet werden. Um die Akkumulierung von Protokollen zu
verhindern, führen Sie Backups von Transaktionsprotokollen mit aktivierter Kürzung
regelmäßig durch.
AppSync kann Transaktionsprotokolle in Umgebungen von AlwaysOnVerfügbarkeitsgruppen (AAG) sichern. Sie können primäre oder sekundäre
Datenbankkopien sichern. Wenn Kürzung aktiviert ist, sichern Sie entweder das primäre
oder sekundäre Datenbanktransaktionsprotokoll, um die Kürzung zu initiieren.
Backups von Transaktionsprotokollen werden nur bei der Verwendung von
Streamingbackup unterstützt. Sie werden bei der Verwendung von VSS-HardwareSnapshot-Technologie nicht unterstützt. Sie können AppSync verwenden, um
Transaktionsprotokolle in einer Datei zu sichern. Die Datei kann auf ein lokales Volume
oder eine Netzwerkfreigabe unter Verwendung eines UNC-Pfads geschrieben werden.
Beschränkungen
l
Um ein Transaktionsprotokoll zu sichern, muss das Datenbank-Recovery-Modell
entweder „Full“ oder „Bulk-logged“ sein. AppSync überspringt das Sichern des
Protokolls für jede Datenbank mit einfachem Recovery-Modell.
l
Um ein Protokollbackup mit Protokollkürzung zu erstellen, müssen Sie zunächst
mindestens ein vollständiges Datenbankbackup erstellen.
l
Zum Kürzen der Transaktionsprotokolle benötigt AppSync eine vollständige
Datenbankbackupkopie.
l
Abonnieren Sie für eine Datenbank nur einen Serviceplan mit aktiviertem
Prokollbackup.
l
Um die Protokolle in einer AAG-Umgebung zu kürzen, abonnieren Sie nur für eine
Kopie einer Datenbank einen Serviceplan, der für vollständige Datenbankbackups
und Backups von Transaktionsprotokollen mit Protokollkürzung konfiguriert ist.
l
Zum Sichern von Transaktionsprotokollen für Datenbanken, die zu einer
Verfügbarkeitsgruppe gehören, verändern Sie die Planung so, dass unterschiedliche
Kopien der Datenbank nicht gleichzeitig gesichert werden.
Verwandte Themen
82
l
Konfigurieren von SQL Server-Backups von Transaktionsprotokollen auf Seite 83
l
Ausführen eines Protokollbackups nach Bedarf auf Seite 85
l
Anzeigen von Protokollbackups für einen Serviceplan auf Seite 86
l
Anzeigen der Protokollbackupliste für eine einzelne Datenbank auf Seite 88
Erfahren Sie, wie Sie Backups von Transaktionsprotokollen für einen SQL ServerServiceplan durch Aktivieren des Kontrollkästchens Enable log backup auf der Seite
Create Copy options der AppSync-Konsole aktivieren können.
Bevor Sie beginnen
Überprüfen Sie, ob das Benutzerkonto, das Sie für Backups auswählen, die vollständige
Kontrolle über das Verzeichnis hat. Dieses Konto ist das Benutzerkonto, das Sie bei der
Erkennung von Datenbanken eingegeben haben. Überprüfen Sie auch, ob das Konto, das
für den SQL Server-Datenbank-Engine-Service der zu schützenden SQL Serverinstanz
konfiguriert wurde, die vollständige Kontrolle über das Backupverzeichnis hat.
Nachdem Sie dieses Kontrollkästchen aktiviert haben, wird das Dialogfeld Transaction
Log Backup Options aktiviert, in dem Sie die Einstellungen dahingehend anpassen
können, wann und wie Protokollbackups ausgeführt und wo die Dateien der
Protokollbackups geschrieben werden sollen. Die Backups von Transaktionsprotokollen
werden sequenziell ausgeführt.
Abbildung 3 Dialogfeld Transaction Log Backup Options
Vorgehensweise
1. Verwenden Sie das Feld Schedule, um das Ausführen von Protokollbackups
festzulegen.
Sie können auswählen, die Backups von Transaktionsprotokollen einmal unmittelbar
nach dem Ausführen eines Datenbankbackups auszuführen, oder Sie können
83
auswählen, die Protokollbackups für einen bestimmten Zeitpunkt zu planen. Sie
können die Planungen für Protokollbackups so festlegen, dass die Backups alle 15
oder 30 Minuten oder jede Stunde bis alle 24 Stunden ausgeführt werden. Wenn Sie
festlegen, einen Serviceplan nach Bedarf auszuführen, deaktivieren Sie damit die
Planung für Protokollbackups.
Wenn Sie festlegen, Protokollbackups in einem vorgegebenen Intervall auszuführen,
werden mit dem Serviceplan zwei Planungen verknüpft: eine für Datenbankbackups
und eine für Protokollbackups. Das Protokollbackup wird als alternative Planung
bezeichnet. Die Protokollbackups werden zwischen den Datenbankbackups mit der
alternativen Planung ausgeführt.
2. Bearbeiten Sie das Feld Backup path, um den Speicherort festzulegen, in den
AppSync die Dateien der Protokollbackups schreibt.
Bei Default path wird das standardmäßige SQL Serverinstanz-Backupverzeichnis
verwendet. Sie können auch einen Pfad auf jedes Volume auf dem Server oder den
UNC-Pfad eines Netzwerk-Share eingeben.
AppSync erstellt das Verzeichnis, wenn es nicht bereits vorhanden ist. Darüber hinaus
erstellt AppSyn ein Unterverzeichnis mit dem Namen der SQL Serverinstanz. Die
Dateinamen der Protokollbackups weisen folgendes Format auf:
EMC_AppSync_databasename_timestamp.trn, zum Beispiel:
EMC_AppSync_AdventureWorks_2014_10_18_15_38_32.trn
3. Verwenden Sie das Feld Free space on volume, um einen Wert zum Überprüfen der
Menge des freien Speicherplatzes auf dem Volume festzulegen, bevor AppSync mit
der Ausführung eines Backups von Transaktionsprotokollen beginnt.
Wenn nicht genügend freier Speicher verfügbar ist, wird eine Warnmeldung erzeugt
und das Protokollbackup schlägt fehl.
4. Verwenden Sie das Feld Backup group size, um die Anzahl der parallelen
Protokollbackups für eine SQL Serverinstanz zu steuern. Der Standardwert beträgt 5
(AppSync führt Protokollbackups in Gruppen von jeweils Fünf aus).
Wenn Sie beispielsweise einen Serviceplan für 15 Datenbanken aus derselben SQL
Serverinstanz abonnieren, werden drei Protokollbackups parallel ausgeführt. Die
Backups von Transaktionsprotokollen werden sequenziell ausgeführt.
5. Aktivieren oder deaktivieren Sie das Feld Truncate the logs, wenn Sie komplette
Datenbankbackups erstellen.
Dieses Feld ist standardmäßig aktiviert, wenn Sie den Typ Full backup auswählen, und
es ist deaktiviert, wenn Sie Copy auswählen. Wählen Sie zum Schutz von sekundären
Datenbanken und Kürzen von Protokollen die Optionen Auto switch to copy und
Truncate the logs aus.
6. Wählen Sie zum Ermitteln einer Prüfsumme für das Protokollbackup das Feld
Checksum the backup aus.
7. Verwenden Sie die Option Minimum Retention Hours, um zu steuern, wann die
Backupdateien von Transaktionsprotokollen gelöscht werden sollen.
Das Ablaufen lassen der Backups von Transaktionsprotokollen wird ausgeführt, wenn
keine älteren Datenbankbackups vorhanden sind. AppSync löscht die
Protokollbackupdateien und die Protokollbackupinformationen in der AppSyncDatenbank. Die Standardeinstellung ist 24 Stunden, was bedeutet, dass AppSync
kein Protokollbackup ablaufen lässt, bevor es mindestens 24 Stunden alt ist. Der
zulässige Bereich liegt zwischen 0 und 10.000 Stunden.
84
Konfigurieren von Protokollbackup-Skripten
Sie können Skripte vor und nach Protokollbackups ausführen, indem Sie die Prä- und
Postprotokollbackup-Skripte aktivieren.
Das Präprotokollbackup-Skript wird auf dem Produktionshost ausgeführt. Das
Postprotokollbackup-Skript kann auf dem Produktionshost oder dem Mount-Host (wenn
Mount aktiviert ist) ausgeführt werden, oder Sie können einen Server angeben. Auf dem
Server muss das AppSync-Host-Plug-In installiert sein.
Abbildung 4 Konfigurieren von Protokollbackup-Skripten
Ausführen eines Protokollbackups nach Bedarf
Sie können SQL Server-Protokollbackups entweder planen und ausführen oder die
Protokollbackups nach Bedarf ausführen lassen.
Bevor Sie beginnen
Zur Ausführung von Protokollbackups müssen Sie dafür sorgen, dass die Option Enable
Log Backup des Serviceplans aktiviert ist.
Sie können ein Protokollbackup nach Bedarf für einen gesamten Serviceplan oder ein
Protokollbackup nach Bedarf für eine einzige Datenbankinstanz ausführen.
Vorgehensweise
1. Rufen Sie zum Ausführen eines Protokollbackups nach Bedarf für einen gesamten
Serviceplan Service Plans > Microsoft SQL Server auf, wählen Sie den gewünschten
Serviceplan durch Aktivieren der Schaltfläche Run Log Backups aus und klicken Sie
Konfigurieren von Protokollbackup-Skripten
85
dann auf Run Log Backups, um das Backup für den gesamten Serviceplan
auszuführen.
2. Rufen Sie zum Ausführen eines Protokollbackups für eine einzelne Datenbank die
Option Copy Management >Microsoft SQL Server auf, wählen Sie eine SQL ServerInstanz sowie die gewünschte Datenbank und anschließend die Registerkarte Log
Backups aus. Wählen Sie abschließend den entsprechenden Serviceplan aus der
Liste Create log backup using plan aus, um das Protokollbackup auszuführen.
Anzeigen von Protokollbackups für einen Serviceplan
Die Liste der SQL Server-Protokollbackups kann über die Registerkarte Service Plan Log
Backups oder die Registerkarte Database Log Backups angezeigt werden.
Bevor Sie beginnen
Für diesen Vorgang ist die Datenadministratorrolle in AppSync erforderlich.
Die Liste der Kopien kann nach Erstellungszeit und nach Serviceplan gefiltert werden.
Unter der Registerkarte Service Plan Copies können Sie auch nach Instanz filtern.
Vorgehensweise
1. Navigieren Sie zu Service Plans > Microsoft SQL Server, um die Liste aller
Protokollbackups für einen Serviceplan anzuzeigen.
2. Wählen Sie einen Serviceplan aus.
3. Klicken Sie auf die Registerkarte Log Backups.
Ergebnisse
Die Liste der Protokollbackups für den Serviceplan wird nun angezeigt. In der folgenden
Tabelle werden die Details zum Protokollbackup beschrieben:
Tabelle 8 Details zu Protokollbackups von Serviceplänen
Spalte
Beschreibung
Status
l
Grün: erfolgreich
l
Gelb: Einige der Protokollbackups wurden bei der Ausführung des Serviceplans
mit Fehlern abgeschlossen.
l
Rot: fehlgeschlagen
Instanz
Name der SQL Server-Instanz
Datenbank
Name der SQL Server-Datenbank
Name
Name der Kopie des Protokollbackups. Die Kopie wird nach der Uhrzeit benannt, zu
der sie erstellt wurde.
Service Plan Name des Serviceplans, dem das Protokollbackup zugeordnet ist.
Gekürzt
Gibt an, ob das Transaktionsprotokoll vom Protokollbackup gekürzt wurde. Yes,
falls das Protokoll gekürzt wurde, andernfalls No.
Backup File
Der Name der Protokollbackupdatei und deren Speicherort.
Anzeigen von SQL-Datenbankkopien
Zeigen Sie die Liste von Datenbankkopien durch Navigieren zu Copy Management >
Microsoft SQL Server an und wählen Sie einen SQL Server und dann eine Datenbank aus.
86
Bevor Sie beginnen
Außerdem können Sie die Details einer Kopie unter der Registerkarte Copies des
Serviceplan anzeigen lassen.
Sie können die Liste der Kopien nach Erstellungszeit und nach Serviceplan filtern. Unter
der Registerkarte Service Plan Copies können Sie auch nach Instanz filtern.
Tabelle 9 Details zur Serviceplankopie
Spalte
Beschreibung
Status
l
Grün: erfolgreich
l
Gelb: mit Fehlern abgeschlossen
l
Rot: Fehler
Name
Name der Kopie Die Kopie wird nach der Uhrzeit benannt, an der sie
erstellt wurde.
Serviceplan
Name des Serviceplans, dem die Kopie zugeordnet ist. Das Feld
Serviceplan ist bei Kopien der Funktion neue Verwendung leer.
SQL Server-Backuptyp
SQL-Backuptyp: Full oder Copy
l
Mit dem Backuptyp Full wird die Datenbank und der aktive Teil
des Transaktionsprotokolls geschützt. Mit dem Backuptyp Copy
wird die Datenbank und der aktive Teil des
Transaktionsprotokolls ohne Auswirkung auf die Reihenfolge der
Backups geschützt.
l
Sekundäre Datenbanken sind schreibgeschützt und können nur
mit dem Backuptyp Copy gesichert werden. Auto Switch to
Copy wird nur aktiviert, wenn Full als Backuptyp ausgewählt
wird. Die Option ist jedoch standardmäßig deaktiviert. Das
Aktivieren der Option Auto Switch to Copy weist AppSync an, zu
überprüfen, ob die Datenbankrolle sekundär ist, und wenn dies
der Fall ist, den Backuptyp auf Copie zu wechseln. Wenn die
Option Auto Switch to Copy nicht aktiviert ist, schlagen die
Backups für alle sekundären Datenbanken fehl.
Mount Status
Zeigt an, ob die Kopie gemountet wurde. Wenn sie gemountet wurde,
wird der Name des Mount-Hosts angezeigt.
Recovery Status
Verfügbare Werte:
l
Not Recovered: wenn Kopie nicht gemountet ist oder es sich um
einen Dateisystem-Mount handelt
l
Successful: wenn die Recovery erfolgreich war
l
Failed: wenn die Recovery fehlgeschlagen ist
Availability Group
In der Spalte Availability Group wird die Verfügbarkeitsgruppe
angezeigt, zu der die Datenbank gehört.
Erstellung
Wird für neu verwendete Kopien genutzt. In dieser Spalte wird
beschrieben, bei wie vielen entfernten Generationen die Kopie in der
Produktionsdatenbank vorhanden ist.
Anzeigen von SQL-Datenbankkopien
87
Tabelle 9 Details zur Serviceplankopie (Fortsetzung)
Spalte
Beschreibung
Quelle
In dieser Spalte wird die Quelldatenbank oder Kopie anzeigt, aus der
eine Kopie erstellt wurde.
Copy Type
Der Kopietyp kann Folgendes sein:
l
RecoverPoint Continuous Data Protection Bookmark
l
RecoverPoint Continuous Remote Replication Bookmark
l
VNX Snap
l
VNXeSnap
l
VNXe FileSnap
l
VMAX Snap, VMAX Clone
Für die obigen Kopietypen werden die folgenden zusätzlichen Details
unter der Registerkarte Service Plan Copies angezeigt:
l
Instance: Die SQL Server-Instanz, welche die Datenbank hostet.
l
Datenbankname: Der Name der zur Kopie gehörenden
Datenbank.
l
Uhrzeit: Die Uhrzeit, zu der die Datenbankkopie erstellt wurde.
l
Server/cluster: Name des Servers oder des Clusters, der die SQL
Server-Instanz hostet.
l
Site: RecoverPoint
Copy Type (Fortsetzung):
l
XtremIO Snapshot
l
VMAX 3 SnapVXClone, SnapVXSnap
Hinweis
Auf dieser Seite ist die Schaltfläche Repurpose aktiviert. Wenn Sie die Option 1st
Generation copy auswählen, wird der Assistent zum Festlegen einer neuen Verwendung
gestartet, in dem Sie Kopien der 2. Generation erstellen können.
Anzeigen der Protokollbackupliste für eine einzelne Datenbank
Sie können auch die Protokollbackups für eine einzelne Datenbank anzeigen lassen.
Führen Sie die folgenden Schritte aus:
Vorgehensweise
1. Navigieren Sie zu Copy Management > Microsoft SQL Server und wählen Sie dann eine
SQL Server-Instanz aus.
2. Klicken Sie auf den Ordner User Databases.
3. Klicken Sie auf eine Datenbank in der Liste und wählen Sie die Registerkarte Log
Backups aus.
Ergebnisse
Die Liste der Protokollbackups für die Datenbank wird nun angezeigt. In der folgenden
Tabelle werden die Details zum Protokollbackup beschrieben:
88
Tabelle 10 Details zum Protokollbackup für Datenbanken: SQL Server-Instanz
Spalte
Beschreibung
Status
l
Grün: erfolgreich
l
Gelb: Einige der Protokollbackups wurden bei der Ausführung des Serviceplans
mit Fehlern abgeschlossen.
l
Rot: fehlgeschlagen
Name
Name der Kopie des Protokollbackups. Die Kopie wird nach der Uhrzeit benannt, zu
der sie erstellt wurde.
Service Plan Name des Serviceplans, dem das Protokollbackup zugeordnet ist.
Gekürzt
Gibt an, ob das Transaktionsprotokoll vom Protokollbackup gekürzt wurde. Yes,
falls das Protokoll gekürzt wurde, andernfalls No.
Backup File
Der Name der Protokollbackupdatei und deren Speicherort.
Ablauf von Protokollbackups
Protokollbackups laufen in AppSync ab, wenn der Serviceplan ausgeführt wird, um ein
neues Protokollbackup zu erstellen. Beim Ablauf eines Protokollbackups in AppSync
werden die Protokollbackupdatei und die Informationen über das Backup aus der
AppSync-Datenbank gelöscht.
Protokollbackups basieren immer auf dem letzten kompletten Datenbankbackup. Sie
brauchen aber nicht AppSync zu verwenden, um das komplette Datenbankbackup zu
erstellen. Sie können AppSync zum Erstellen einer Kopiedatenbank und eines
Protokollbackups verwenden.
Darüber hinaus kann AppSync vollständige Datenbank- und Protokollbackups mit oder
ohne Protokollkürzung erstellen. Das Verhalten beim Ablauf von Protokollbackups hängt
vom Typ des erstellten Datenbankbackups ab.
Protokollbackups laufen unter den folgenden Bedingungen ab:
l
Das Protokollbackup ist älter als die Einstellung für den Serviceplan unter Minimum
Retention Hours.
l
Alle älteren Datenbankbackups sind abgelaufen. Es hängt vom Backuptyp für SQL
Server ab, welche Datenbankbackups in diese Prüfung aufgenommen werden.
n
Wenn der Backuptyp für SQL Server im Serviceplan für das Protokollbackup auf
Copy festgelegt ist, werden bei der Suche nach älteren Datenbankbackups nur die
durch diesen Serviceplan erstellten Datenbankbackups berücksichtigt.
n
Wenn der Backuptyp für SQL Server im Serviceplan für das Protokollbackup auf
Full festgelegt ist, werden die von einem beliebigen Serviceplan erstellten
kompletten Datenbankbackups berücksichtigt.
Beispiel 1: Betrachten Sie folgendes Szenario:
l
Das Protokollbackup ist für den Serviceplan aktiviert.
l
Der Datenbankbackuptyp ist auf Copy festgelegt.
l
Die Rotation ist auf Eine festgelegt.
l
Die Mindestaufbewahrungsfrist für Protokolle ist auf 24 Stunden festgelegt.
Der Serviceplan wurde mehrmals ausgeführt und hat ein Datenbankbackup und mehrere
Protokollbackups erstellt. Der Serviceplan wird erneut ausgeführt, erstellt ein
Ablauf von Protokollbackups
89
Datenbankbackup und lässt das erste Datenbankbackup ablaufen. Dies führt dazu, dass
für mehrere Protokollbackups kein älteres Datenbankbackup vorhanden ist. Der
Serviceplan wird erneut ausgeführt, erstellt ein Protokollbackup und lässt alle früheren
Protokollbackups, die mindestens 24 Stunden alt sind, ablaufen.
Beispiel 2: Betrachten Sie folgendes Szenario:
l
Sie haben zwei Servicepläne.
l
Für beide ist der Datenbankbackuptyp auf Full eingestellt.
l
Unter Serviceplan 1 wird ein Mal pro Woche ein Datenbankbackup durchgeführt,
wobei die Rotation auf vier festgelegt ist.
l
Serviceplan 2 wird täglich um 8 Uhr mit einer Rotation von sieben ausgeführt.
l
Für Serviceplan 2 ist festgelegt, dass das Protokollbackup jede Stunde ausgeführt
wird, wobei die Mindestaufbewahrungszeit auf 24 Stunden eingestellt ist.
l
Beide Servicepläne wurden ausgeführt.
l
Serviceplan 1 hat vier Datenbankkopien und Serviceplan 2 hat sieben
Datenbankkopien. Serviceplan 2 verfügt außerdem über viele Protokollbackups, die
zwischen den Aktualisierungsintervallen der sieben Datenbankkopien ausgeführt
wurden.
l
Serviceplan 2 wird erneut ausgeführt, erstellt eine Kopie der Datenbank und lässt
dann die älteste Kopie ablaufen. Er wird eine Stunde später ausgeführt, erstellt ein
Protokollbackup und sucht nach Protokollbackups, die ablaufen sollen.
Es stehen keine Protokollbackups zum Ablauf zur Verfügung, da Serviceplan 1 über
komplette Datenbankbackups verfügt, die älter als alle Protokollbackups sind. Wenn
Serviceplan 1 das nächste Mal ausgeführt wird, läuft das älteste Datenbankbackup ab.
Dann stehen Protokollbackups zum Ablauf zur Verfügung.
Manuelles Ablaufen von Protokollbackups
Sie können Protokollbackups auch manuell ablaufen lassen.
So lassen Sie Protokollbackups für mehrere Datenbanken ablaufen:
1. Navigieren Sie zu Service Plans > Microsoft SQL Server und klicken Sie auf einen
Serviceplan.
2. Klicken Sie auf die Registerkarte Log Backups.
3. Wählen Sie die Protokollbackups aus, die ablaufen sollen, und klicken Sie dann auf
Expire.
4. Klicken Sie im Bestätigungsdialogfeld auf OK. AppSync löscht die
Protokollbackupdatei und entfernt Informationen über das Backup aus der AppSyncDatenbank..
So lassen Sie Protokollbackups für eine einzige Datenbank ablaufen:
1. Navigieren Sie zu Copy Management > Microsoft SQL Server und wählen Sie eine SQL
Server-Instanz aus.
2. Klicken Sie auf den Ordner User Databases.
3. Klicken Sie auf eine Datenbank in der Liste und wählen Sie die Registerkarte Log
Backups aus.
4. Wählen Sie die Protokollbackups aus, die ablaufen sollen, und klicken Sie dann auf
Expire.
5. Klicken Sie im Bestätigungsdialogfeld auf OK.
90
Überlegungen für die Arbeit mit SQL Server in einem Cluster
Bei der Arbeit mit SQL Server in einem Cluster gibt es spezielle Überlegungen.
Beim Schutz von SQL Server-Datenbanken in einer Clusterumgebung müssen Sie das
AppSync-Host-Plug-in auf allen Nodes installieren, die mögliche Eigentümer einer SQL
Server-Instanz sind. Sie können die AppSync-Konsole zum Installieren des Plug-ins
verwenden oder das Plug-in manuell auf jedem Server installieren. Wenn das Plug-in
installiert ist, fügen Sie mithilfe der AppSync-Konsole den Netzwerknamen oder die IPAdresse der geclusterten SQL Server-Instanzen hinzu.
Beim Schutz von geclusterten SQL Server-Instanzen:
l
Sie müssen den virtuellen Server für SQL Server zu AppSync hinzufügen, wenn Sie die
AppSync-Host-Plug-in-Software auf jedem Node installiert haben.
l
Nur einzelne Subnetze werden unterstützt.
l
Mounten von AppSync-Kopien:
n
Sie können auf geclusterten Datenbanken erstellte AppSync-Kopien auf einem
eigenständigen Server oder Cluster-Node mounten.
n
Sie können auf eigenständigen Datenbanken erstellte AppSync-Kopien auf einem
eigenständigen Server oder einem Cluster-Node mounten.
Beim Mounten einer SQL Server-Kopie auf einem Cluster gilt Folgendes:
l
Unterstützt Mounten auf einem alternativen Cluster oder Produktionscluster als
Ressource ohne Cluster.
l
Unterstützt nur Mounten auf einem Cluster-Node, nicht auf einem virtuellen Server
oder Mounten und Wiederherstellen auf einer geclusterten Instanz.
l
Mounten wird in den Umgebungen VMAX, VNX, VNXe, XtremIO oder RecoverPoint
unterstützt. Im AppSync Installation and Configuration Guide sind die erforderlichen
Schritte für die Speicherkonfiguration beschrieben.
l
Wählen Sie je nach Ihrem Cluster und Ihrer Speicherkonfiguration die entsprechende
Mount-Option für Cluster-Mounts aus.
l
Deaktivieren Sie automount manuell. Führen Sie diskpart an einer
Eingabeaufforderung aus und geben Sie dann in der DISKPART>Eingabeaufforderung automount disable ein.
Besondere Überlegungen für das Mounten auf einem Produktionscluster:
l
Mounten auf einem Produktionscluster-Node mithilfe des ursprünglichen Pfads wird
nicht unterstützt.
l
Wenn der ursprüngliche Server ein virtueller Server ist, wird Mounten auf einem
Produktionscluster mithilfe der Option für den „ursprünglichen Server“ nicht
unterstützt und Mountvorgänge schlagen fehl.
l
Statisches Mounten von RecoverPoint SQL-Kopien auf Produktionscluster wird nicht
unterstützt. Für dieses Szenario müssen Sie dynamische Mounts verwenden.
l
Eine auf RecoverPoint gemountete Wiederherstellung, während die Kopie auf einem
Produktionscluster gemountet ist, wird nicht unterstützt.
l
Mounten von RecoverPoint SQL APIT-Kopien auf Produktionscluster-Nodes wird nicht
unterstützt.
Überlegungen für die Arbeit mit SQL Server in einem Cluster
91
Beispiel 1 Schutz von Datenbanken, die im Besitz von geclusterten SQL Server-Instanzen sind
In diesem Beispiel möchten Sie Datenbanken schützen, die im Besitz von geclusterten
Instanzen von SQL Server sind. Darüber hinaus gehören einige dieser Datenbanken zu
AlwaysOn-Verfügbarkeitsgruppen. In der folgenden Abbildung finden Sie ein Beispiel:
Abbildung 5 Clusterinformationen
Dieses Cluster hat die folgende Konfiguration:
l
lrmq093 ist ein virtueller Server für SQL Server und hostet Datenbanken, die zu
AlwaysOn-Verfügbarkeitsgruppen gehören.
l
lrmq094 ist ein virtueller Server für SQL Server.
l
lrmq120, lrmq121 und lrmq122 gehören zu einem AlwaysOn-Failovercluster für SQL
Server.
l
lrmq120 und lrmq121 sind mögliche Besitzer der geclusterten SQL Server-Instanzen,
die im Besitz von lrmq093 und lrmq094 sind.
l
lrmq122 verfügt über eine Installation einer eigenständigen Instanz von SQL Server,
die Datenbanken hostet, die zu AlwaysOn-Verfügbarkeitsgruppen gehören.
l
lrmq126 ist der Mount-Host mit einer Installation einer eigenständigen Instanz von
SQL Server.
Führen Sie die folgenden Schritte aus, um die Datenbanken, die zur geclusterten und zur
eigenständigen Instanz gehören, zu schützen:
1. Verwenden Sie die AppSync-Konsole, um lrmq120, lrmq121 und lrmq122
hinzuzufügen. AppSync installiert das Plug-in auf diesen Servern und entdeckt alle
nicht geclusterten Instanzen. Wenn Sie einen Mount-Host benötigen, können Sie jetzt
lrmq126 hinzufügen.
2. Fügen Sie mithilfe der AppSync-Konsole die virtuellen Server für die geclusterten
Instanzen hinzu, fügen Sie lrmq093 und lrmq094 hinzu.
92
SQL Server-Benutzerdatenbank-Ordner
Der SQL Server-Benutzerdatenbank-Ordner enthält alle Benutzerdatenbanken für diese
SQL Server-Instanz, die erkannt und in der AppSync-Datenbank gespeichert wurden.
Von der Schaltfläche Protect können Sie für den Ordner einen Plan abonnieren. Dadurch
werden alle Datenbanken, die Teil dieses Ordners sind, ebenfalls geschützt. Sobald sie
geschützt sind, wird in der Spalte Service Plan der Name des Plans angezeigt.
Durch Klicken des Ordners User Databases werden die einzelnen Datenbanken
aufgeführt, die Teil dieser SQL Server-Instanz sind.
Auf der Seite „Datenbanken“ zeigt ein Eintrag in der Spalte Service Plans, dass alle
Datenbanken, die Teil des Ordners sind, geschützt werden. Jede Benutzerdatenbank,die
der Instanz hinzugefügt wird, wird ebenfalls geschützt. AppSync wird das Schützen aller
Datenbanken, die von der Instanz entfernt werden, automatisch beenden.
Hinweis
Wenn eine oder mehrere Benutzerdatenbanken für eine SQL Server-Instanz einen
Serviceplan abonniert haben, können Sie für den Benutzerdatenbank-Ordner nicht
denselben Serviceplan abonnieren. Im umgekehrten Fall, wenn der BenutzerdatenbankOrdner einen Serviceplan abonniert, können die einzelnen Benutzerdatenbank-Instanzen
nicht den gleichen Serviceplan abonnieren.
Erkennen von SQL Server-Instanzen
Beim Erstellen oder Löschen von Instanzen müssen Sie eine Erkennung von SQL ServerInstanzen ausführen, um AppSync auf dem aktuellen Stand zu halten.
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Copy Management > Microsoft SQL Server.
2. Gehen Sie in der unten angezeigten Pop-up-Schaltfläche Discover Instances
folgendermaßen vor:
l
Wählen Sie On Server aus und dann einen der Server, auf dem Instanzen erkannt
werden sollen.
l
Wählen Sie Add Servers aus, um AppSync einen neuen Server hinzuzufügen.
Erkennung von SQL Server-Datenbanken
AppSync erkennt neue Benutzerdatenbanken nach Bedarf oder automatisch beim
Ausführen eines Serviceplans.
Wenn Sie den Benutzerdatenbank-Ordner zum ersten Mal klicken, erkennt AppSync die
Datenbanken und führt diese auf. Um Datenbanken manuell erneut zu erkennen, klicken
Sie auf Discover Databases auf der Seite Databases.
Wenn Sie andererseits für den Benutzerdatenbank-Ordner einen Plan abonnieren,
werden die Datenbanken automatisch bei jeder Ausführung des Plans erkannt. Alle
Datenbanken, die derzeit ONLINE sind, einschließlich derjenigen, die der SQL-Instanz
nach dem letzten Ausführen des Serviceplans hinzugefügt wurden, werden automatisch
geschützt.
Wenn einzelne Datenbanken anstelle des Benutzerdatenbank-Ordners einen Plan
abonnieren, erkennt AppSync nicht automatisch alle neuen Datenbanken, die nach der
SQL Server-Benutzerdatenbank-Ordner
93
letzten Ausführung des Plans erstellt wurden. In diesem Fall erkennt AppSync die
Datenbankinformationen aller Datenbanken, die ursprünglich den Plan abonnierten,
erneut und schützt diejenigen, die ONLINE sind.
Schützen einer SQL-Datenbank
Schützen Sie eine SQL-Datenbank, indem Sie für diese einen AppSync-Serviceplan
abonnieren.
Zur Optimierung der Performance erstellt AppSync Kopien von maximal 35 Datenbanken
pro Instanz. Wenn mehr als 35 Datenbanken pro Instanz abonniert sind, unterteilt
AppSync diese in Gruppen von 35 und erstellt Kopien der Gruppen sequenziell. Wenn für
mehr als 35 Datenbanken ein Serviceplan abonniert ist und sich die Datenbanken auf
derselbe Speichereinheit (CG, LUN, DS und so weiter) befinden, wird die Aufteilung in
Gruppen mit 35 Datenbanken nicht durchgeführt. Eine einzelne Kopie ist für eine
Konfiguration wünschenswert, bei der der Speicher auf der gleichen Speichereinheit ist.
Diese Zahl (35) ist eine Servereinstellung und kann bei Bedarf geändert werden. Wenden
Sie sich diesbezüglich an EMC Support.
Sie können Objekte auf unterschiedliche Arten von verschiedenen Stellen in AppSync
schützen:
l
Wählen Sie Subscribe to Plan and Run, wenn Sie eine ausgewählte Datenbank sofort
schützen möchten. Der Serviceplan wird für die Datenbank allein ausgeführt.
l
Wählen Sie Subscribe to Plan, wenn Sie den Schutz für einen späteren Zeitpunkt
l
Wählen Sie einen entsprechenden Serviceplan unter Create copy using plan auf der
Datenbankseite „Copies“ aus.
l
Wählen Sie Run auf der Seite „SQL Server Service Plans“, um den gesamten Plan
sofort auszuführen.
Konfigurieren von Schutz für SQL Server-Datenbanken
Sie können einen Serviceplan für eine Datenbank oder für den Ordner von
Benutzerdatenbanken abonnieren und den Serviceplan sofort ausführen lassen oder die
Ausführung des Serviceplans für einen späteren Zeitpunkt festlegen.
Bevor Sie beginnen
Vorgehensweise
2. Klicken Sie auf eine Serverinstanz, um deren Datenbanken anzuzeigen.
l
Wählen Sie den Ordner User Database aus, um alle Datenbanken innerhalb des
Ordners der Benutzerdatenbank zu schützen.
l
Klicken Sie auf User Databases und wählen Sie eine Datenbank in der Liste aus,
um eine einzelne Datenbank zu schützen.
3. Wählen Sie in der unten angezeigten Pop-up-Schaltfläche Protect den
entsprechenden Serviceplan aus folgenden Optionen aus:
94
Option
Beschreibung
Subscribe to Plan
and Run
Mit dieser Option wird für die Datenbank ein Serviceplan zum
Schutz abonniert und der Plan wird sofort für die
ausgewählten Datenbanken ausgeführt.
Subscribe to Plan
Mit dieser Option wird für die Datenbank ein Serviceplan zum
Schutz abonniert. Der Schutz wird für alle Datenbanken, die
Teil des Serviceplans sind, zur geplanten Zeit ausgeführt.
Wenn Sie das Abonnement eines Serviceplans für eine einzelne Datenbank beenden,
werden alle vorhandenen Datenbankkopien beibehalten. Es wird lediglich die weitere
Ausführung der Schutzfunktion aufgehoben.
Bevor Sie beginnen
Vorgehensweise
2. Klicken Sie auf die SQL Server-Instanz.
3. Klicken Sie auf User Databases.
4. Wählen Sie die Datenbank aus, für die Sie das Abonnement eines Serviceplans
beenden möchten.
l
Wählen Sie den Plan aus, dessen Abonnement Sie beenden möchten Protect >
Unsubscribe from Plan. Es befinden sich nur die Pläne in der Pop-up-Liste, die für
die Datenbank abonniert sind.
l
Wählen Sie zum Beenden des Abonnements für alle Servicepläne Unsubscribe
from Plan > All aus.
Erkennen von SQL Server-Datenbanken
Verwenden Sie den Befehl Discover New Databases, um die SQL Server-Datenbanken zu
aktualisieren, die AppSync bekannt sind.
Bevor Sie beginnen
Vorgehensweise
2. Klicken Sie auf eine Serverinstanz und dann auf den Ordner User Databases.
3. Klicken Sie auf der Seite User Databases auf Discover New Databases in der Zeile der
unten angezeigten Schaltflächen.
Je nach der Größe der Instanz kann die Erkennung einige Minuten in Anspruch
nehmen.
Abonnieren Sie einen AppSync-SQL Server-Serviceplan auf der Seite Copies, um eine
Kopie einer Datenbank zu erstellen.
95
Bevor Sie beginnen
Vorgehensweise
2. Klicken Sie auf eine Serverinstanz und dann auf User Databases, um deren
3. Klicken Sie auf einen Ordner, um User Databases anzuzeigen.
4. Klicken Sie in dieser Liste auf die Datenbank, um ihre Kopien anzuzeigen.
5. Wählen Sie aus der Liste Create a copy using plan den entsprechenden Serviceplan
aus.
Der Serviceplan wird sofort für die Datenbank ausgeführt.
Ablaufen lassen einer SQL-Datenbankkopie nach Bedarf
Beim Ablaufen lassen einer Datenbankkopie wird diese aus der AppSync-Datenbank
entfernt und dadurch kann je nach Replikationstechnologie und Status der Kopie
Speicherplatz freigesetzt werden.
Bevor Sie beginnen
Vorgehensweise
1. Wählen Sie Copy Management > Microsoft SQL Server aus.
2. Klicken Sie auf eine SQL Serverinstanz, um deren Datenbankordner anzuzeigen.
3. Klicken Sie auf den Ordner User Database.
4. Klicken Sie auf die Datenbank, deren Kopien Sie ablaufen lassen möchten.
5. Wählen Sie auf der Seite Copies eine oder mehrere Kopien aus, die Sie ablaufen
lassen möchten.
Darüber hinaus können Sie diese Aktion unter der Registerkarte Copies des
Serviceplans ausführen.
6. Wählen Sie Expire in der unten stehenden Zeile der Schaltflächen aus.
Überprüfen Sie, ob Sie die Kopie, die Sie ausgewählt haben, und alle zugehörigen
aufgeführten Kopien ablaufen lassen möchten und bestätigen Sie dies.
Zusammenfassung und Einzelheiten von Serviceplänen
Die Registerkarte Settings des Serviceplans zeigt den Namen, die Beschreibung, den
Zeitplan und den Status des Serviceplans an. Klicken Sie auf die Phasen für die
detaillierten Serviceplaneinstellungen und weitere Registerkarten für Informationen zu
Abonnements, Listen von Kopien und vom Plan generierte Ereignisse.
Servicezeitplan
96
l
l
l
l
n
n
n
n
n
n
n
werden
n
ist Mitternacht.
n
n
n
Bevor Sie beginnen
Vorgehensweise
Auf der rechten Seite wird der Bereich Plan Startup Defaults angezeigt.
3. Notieren Sie sich den Recurrence Type, der für den Plan ausgewählt wurde.
Type ausgewählt wird.
4. Wählen Sie die Phase Start service plan aus.
Auf der rechten Seite wird der Bereich Start service plan angezeigt.
Ein Wiederholungstyp kann nur dann festgelegt werden, wenn Automatic in der
Option Startup ausgewählt wurde.
Sie können die Liste aller Datenbanken anzeigen, für die der Plan abonniert wurde.
7. Wählen Sie eine oder mehrere Datenbanken aus und klicken Sie auf Override
Schedule.
Das Dialogfeld Override Schedule wird angezeigt.
97
8. Legen Sie den Plan auf Grundlage Ihrer Anforderungen fest und klicken Sie auf OK.
Wenn beispielsweise der Standardwiederholungstyp On specified days of the month
ist und die Regeleinstellung Run at 12:00 AM am 1st day of every month festgelegt
wurde, können Sie die Uhrzeit und den Tag für die einzelnen Datenspeicher außer
Kraft setzen.
Ein Bleistiftsymbol weist darauf hin, dass die Standardeinstellungen außer Kraft
gesetzt wurden.
Anwendungserkennung
Vor der Erstellung der Kopie des Benutzerdatenbank-Ordners prüft AppSync die SQL
Server-Instanz auf Änderungen wie beispielsweise das Hinzufügen, Löschen,
Umbenennen oder Verschieben von Datenbanken. Wenn einzelne Datenbanken
geschützt sind, erkennt AppSync Informationen über die ausgewählte Datenbank erneut.
Eine Datenbank wird nur geschützt, wenn sie sich im Status ONLINE befindet.
deaktiviert werden.
Anwendungszuordnung
deaktiviert werden.
Pre-copy script
Um vorbereitende Schritte vor dem Erstellen einer Kopie auszuführen, geben Sie ein
Präkopieskript und Parameter in der Registerkarte Settings eines Serviceplans an.
Das Präkopieskript wird gemäß dem Zeitplan ausgeführt, der in der Phase Plan Startup
eingestellt wurde. Gültige Skriptformate sind .bat, .exe und .ps1 (PowerShell-Skripte). Sie
können optional Anmeldedaten eingeben, um das Skript unter einem bestimmten
Benutzer auszuführen. Das Skript wird standardmäßig unter dem lokalen System
ausgeführt.
Ausführungsrichtlinien festlegen.
2. Legen Sie die PowerShell-Ausführungsrichtlinie so fest, dass Sie das Skript ausführen
Zeile ein, die das PowerShell-Skript aufruft. Der standardmäßige Speicherort des
Skripts ist %ProgramData%\EMC\AppSync\scripts\ auf dem
Anwendungshost.
doppelte Anführungszeichen gesetzt sein.
98
Kopie erstellen
Die Phase Create Copy erstellt eine Kopie basierend auf der Replikationstechnologie, die
im Serviceplan angegeben ist.
Diese Phase gibt den Backuptyp der zu erstellenden SQL Server-Kopie an. Für VNXSnapshot-Kopien legt diese Phase auch den Zeitraum für den automatischen Ablauf der
Kopien fest.
Weitere Informationen zur Serviceplankopie finden Sie unter Übersicht: Serviceplan auf
Seite 10.
SQL Server-Backuptyp
Zwei Hauptbackuptypen werden unterstützt: „Full“ und „Copy“
l
Full schützt die Datenbank und den aktiven Teil des Transaktionsprotokolls. Dieser
Kopietyp wird normalerweise verwendet, wenn die Kopie als Backup der Datenbank
betrachtet wird oder wenn die Kopie gemountet wird, um ein Produkt von
Drittanbietern zur Erstellung eines Backups der Datenbank zu verwenden. Mit diesem
Typ der Kopie können Sie Transaktionsprotokolle wiederherstellen, um die
Datenbank nach vorn auf einen Point-in-Time zu bringen, der neuer ist als die Kopie,
vorausgesetzt, dass Sie diese Transaktionsprotokolle gesichert haben. AppSyncnutzt
die Microsoft SQL Server-VDI-Snapshot-Funktion, um diese Art von Kopie zu erstellen.
n
Auto Switch to Copy wird nur aktiviert, wenn Full als Backuptyp ausgewählt ist. Es
ist jedoch standardmäßig deaktiviert. Wenn Auto Switch to Copy aktiviert ist, prüft
AppSync, ob die Datenbankrolle sekundär ist, und wenn dies so ist, ändert den
Backuptyp auf Copy.
Hinweis
Wenn Auto Switch to Copy nicht aktiviert ist, schlagen die Backups für alle
sekundären Datenbanken fehl.
l
Copy schützt die Datenbank und den aktiven Teil des Transaktionsprotokolls ohne
Auswirkung auf die Reihenfolge der Backups. Dadurch erhalten DBAs eine
Möglichkeit, eine Kopie erstellen, ohne die Backupanwendungen von Drittanbietern
zu beinträchtigen, die vollständige bzw. differenzielle Backups der SQL ServerDatenbanken erstellen. AppSync nutzt die VDI-Snapshot-Funktion von Microsoft SQL
Server, um diese Art von Kopie zu erstellen.
Hinweis
Sekundäre Datenbanken sind schreibgeschützt und können nur mit dem Backuptyp
Copy gesichert werden.
maximale gewünschte Anzahl von Snap-, Clone- oder Lesezeichen-Kopien an, die
gleichzeitig vorhanden sein können.
Wenn der Wert "Always keep x copies" erreicht ist, laufen ältere Kopien ab, um freien
Speicherplatz für die nächste Kopie in der Rotation zu gewinnen. Fehlgeschlagene Kopien
werden nicht gezählt. AppSync lässt die älteste Kopie erst ablaufen, wenn dessen Ersatz
erfolgreich erstellt wurde. Wenn beispielsweise die Anzahl der aufzubewahrenden Kopien
7 beträgt, lässt AppSync die älteste Kopie nicht ablaufen, bis die 8. Kopie erstellt wurde.
99
l
l
Diese Einstellung ist unabhängig von den VNX-Pool Policy-Einstellungen in Unisphere
zum automatischen Löschen von ältesten Snapshots. Die Serviceplanadministrator sollte
mit dem Speicheradministrator zusammenarbeiten, um sicherzustellen, dass die VNXPool Policy-Einstellungen die Unterstützung der angegebenen Anzahl von SnapshotKopien für die Anwendung ermöglicht, die sich in diesem Pool befindet.
Hinweis
Post-copy script
Geben Sie ein Postkopieskript und Parameter in der Registerkarte Settings des
Serviceplans an, um eine Bereinigung oder andere Schritte nach dem Erstellen einer
Kopie durchzuführen.
Das Skript wird nach dem erfolgreichen Abschluss der Phase Create copy ausgeführt.
Gültige Skriptformate sind .bat, .exe und .ps1 (PowerShell-Skripte). Sie können optional
Anmeldedaten eingeben, um das Skript unter einem bestimmten Benutzer auszuführen.
Das Skript wird standardmäßig unter dem lokalen System ausgeführt.
Wenn AppSync Kopien von Anwendungselementen in einem Serviceplan erstellt, kann es
die Anwendungselemente zum Schutz teilen und in separate Gruppen platzieren. Diese
Aktion kann aus Performance-Gründen (z. B. VSS für Exchange und SQL) durchgeführt
werden oder weil die Elemente in einem Serviceplan durch verschiedene
Replikationstechnologien geschützt werden. Beispielsweise kann ein Serviceplan einige
Anwendungselemente enthalten, die teilweise von VNX Snapshots und teilweise durch
RecoverPoint-Lesezeichen geschützt sind. Daher werden Anwendungselemente in diesen
Gruppen unabhängig voneinander geschützt.
Wenn AppSync ein Postkopieskript aufruft, übermittelt AppSync die Kopien, die in der
Gruppe erstellt wurden, durch Aufrufen des Skripts mit -appCopies <ANW1> <ANW2>,
wobei ANW1 und ANW2 die Namen der Anwendungselemente in dieser Gruppierung sind.
Ausführungsrichtlinie festlegen
2. Legen Sie die PowerShell-Ausführungrichtlinie so fest, dass Sie das Skript ausführen
Zeile ein, die das PowerShell-Skript aufruft.
Wenn AppSync das Postkopieskript ausführt, wird es für die Anwendungselemente
ausgeführt, die Teil einer Gruppe sind. Wenn mehrere Gruppen vorhanden sind, wird das
100
Postkopieskript mehrfach ausgeführt. Wenn AppSync das Postkopieskript ausführt,
übermittelt AppSync die Liste der Anwendungselemente in der Replikationsgruppe als
Argumente an das Skript direkt nach den Benutzer-Argumenten. Die Syntax lautet:
-applicationCopies <ITEM1> <ITEM2> <ITEM3>
wobei <ITEMx> der Name des Anwendungselements ist, das geschützt wird.
doppelte Anführungszeichen gesetzt werden.
statt durch den Serviceplan gemountet wurde. In diesem Fall wird ein Unmount-Vorgang
für die nach Bedarf gemountete Kopie nicht durchgeführt.
Alle wiederhergestellten Datenbanken werden im Rahmen dieser Phase
heruntergefahren. Es sind keine Benutzereinstellungen mit dieser Phase verknüpft und
sie kann aktiviert oder deaktiviert werden.
Kopie mounten
In der Phase „Mount copy“ wird die Kopie entweder gemountet oder gemountet und
wiederhergestellt. Diese Phase kann aktiviert oder deaktiviert werden.
In den Einstellungen unter Mount Copy Defaults können Sie die Werte auf „Mount copy“
oder „Mount and recover copy“ einstellen.
In den Einstellungen unter Mount copy legen Sie den Mount-Hostwert, Mount-Pfad und
die Mount-Berechtigungen (schreibgeschützt oder Lesen / Schreiben) fest. Andere
Mount-Einstellungen bestimmen, wohin die SQL-Metadatendateien kopiert werden und
den Zugriffstyp für das RecoverPoint-Image.
Feld
Beschreibung
Mount on
Server
Der Server, auf den die Kopie zu mounten ist. Zur Auswahl stehen nur
die Nodes der Cluster oder eigenständige Hosts. Virtuelle SQLMaschinen werden herausgefiltert.
Mount with
access
Zugriffstyp, mit dem die Kopie gemountet werden soll.
Mount path
l
Der Default Mount Path ist %SystemDrive%\AppSyncMounts\
%%ProdServerName%%.
l
Um den Wert einer Windows-Umgebungsvariablen im Mount-Pfad
anzugeben, begrenzen Sie den Variablennamen mit einem
Prozentzeichen (%).
l
Der Standardpfad enthält auch eine AppSync-Variable
(ProdServerName), die mit 2 Prozentzeichen (%) begrenzt ist.
l
Die folgenden Zeichen sind im Pfad nicht zulässig: < > : " / | ? *
101
Feld
Copy metadata
files to
Image access
mode (during
RecoverPoint
mount)
Beschreibung
l
Der Mount-Pfad kann auch Same as Original Path sein. Diese
Option ist jedoch nicht verfügbar, wenn der Mount-Host mit dem
Produktionshost identisch ist.
l
Wenn Sie einen nicht standardmäßigen Mount-Pfad angeben, darf
das Laufwerk, das für das Mounten angegeben ist, kein
Clusterlaufwerk sein.
l
Die Default Path ist der Speicherort zum Kopieren von VDI- und
VSS-Metadatendateien:%SystemDrive%\AppSyncMounts\%
%ProdServerName%%
l
l
Wenn Sie die Datenbank auf einem anderen Medium sichern,
müssen Sie die Metadatendateien ebenfalls sichern.
l
AppSync kann mit Backupsoftware von Drittanbietern integriert
werden, um Band-Backups von SQL Server-Kopien zu erstellen.
Das Zielverzeichnis, das hier angegeben wird, muss Teil des
Backups.
l
Logged access: Verwenden Sie diese Mount-Option, wenn die
Integritätsprüfung das Scannen von großen Bereichen der
replizierten Volumes umfasst. Protokollierter Zugriff ist die einzige
l
Virtual access with roll: Bietet nahezu sofortigen Zugriff auf die
Kopie, aktualisiert jedoch auch das replizierte Volume im
Hintergrund. Wenn die replizierten Volumes am angeforderten
Point-in-Time liegen, wechselt die RPA transparent zum direkten
Replikat-Volume-Zugriff, wodurch die Verarbeitung von Prozessen
mit hoher Auslastung ermöglicht wird. Virtueller Zugriff mit
Rollback wird mit RP VMAX und RP XtremIO nicht unterstützt.
l
Virtual access: Bietet nahezu sofortigen Zugriff auf das Image.
Virtueller Zugriff ist für die Verarbeitung von Prozessen mit hoher
Auslastung nicht vorgesehen. Virtueller Zugriff mit RP VMAX und
RP XtremIO wird nicht unterstützt.
Service Level
Nur für VMAX 3-Arrays. Die Einstellung „Desired Service Level
Objective (SLO) Objective (SLO)“ wird im Mount-Assistenten angezeigt und gibt die
erforderlichen VMAX 3-Service-Level-Ziele an. SLO definiert den
Servicezeitbetriebsbereich einer Speichergruppe.
Use Dedicated
Storage Group
102
l
Dies gilt nur für physische Hosts oder virtuelle Maschinen mit
direktem iSCSI als Teil des Clusters.
l
Standardmäßig aktiviert. Durch das Aktivieren dieser Option kann
AppSync eine dedizierte VMAX-, VNX- und XtremIOSpeichergruppe für ein Mounten erzwingen. (Eine dedizierte
VMAX- oder VNX-Speichergruppe enthält nur den ausgewählten
Mount-Host.) Bei XtremIO gilt diese Option für eine XtremIOInitiatorgruppe, die nur einen Initiator für den Mount-Host enthält.
Das Mounten schlägt fehl, wenn Sie auf einen Node eines Clusters
mounten, der in einer Speichergruppe ist, die mit den anderen
Nodes gemeinsam verwendet wird.
Feld
Beschreibung
Hinweis
Verwenden Sie diese Option, um die Kopie auf einen Node für
Kopievalidierung oder Backup auf Band zu mounten. In diesem
Szenario benötigen Sie zwei Speichergruppen. Eine
Speichergruppe ist für den passiven Node, der als Mount-Host
verwendet wird, dediziert und die andere Speichergruppe für den
Rest der Nodes im Cluster. Beide Speichergruppen enthalten den
gemeinsamen Speicher für das Cluster.
l
Wenn diese Option deaktiviert ist, erzwingt AppSync die
Verwendung von einer dedizierten Speichergruppe für ein
Mounten nicht.
Hinweis
Deaktivieren Sie diese Option, wenn Sie Zielgeräte als
Clusterspeicher manuell hinzufügen und den geclusterten SQL
Server-Instanzen für die Neuverwendung von Daten und Data
Mining präsentieren möchten.
In den Einstellungen unter Mount and recover copy geben Sie die Recovery-Instanz, den
Recovery-Typ und die Datenbankbenennungsdetails an. Andere Einstellungen ähneln den
Einstellungen unter „Mount copy“ wie beispielsweise der Mount-Pfad und
Imagezugriffstyp.
Feld
Beschreibung
Recovery
Instance
Die SQL Server-Instanz, die für die Recovery verwendet werden soll.
Wenn die Verbindungseinstellungen nicht eingestellt oder für die
Instanz ungültig sind, wird das Dialogfeld für die SQL ServerVerbindungseinstellungen angezeigt. Klicken Sie auf Connection
Settings, um die Anmeldedaten zurückzusetzen.
Hinweis
Geclusterte SQL Server-Instanzen werden in dieser Ansicht
herausgefiltert.
Wenn Sie ein VMAX 3-Array verwenden, steht außerdem die Einstellung
„Desired Service Level Objective (SLO)“ zur Verfügung. Die Option wird
im Mount-Assistenten angezeigt und gibt die erforderlichen VMAX 3Service-Level-Ziele an. SLO definiert den Servicezeit-Betriebsbereich
einer Speichergruppe
Recovery Type
Verfügbare Optionen: „Recovery“ (Standardwert), „No Recovery“ und
„Standby“
Database
renaming
Diese Dropdown-Liste umfasst:
l
Use original database names (Standardwert bei alternativer
Instanz): Dies ist zur Auswahl nicht verfügbar, wenn Recovery
Instance die Produktionsinstanz ist.
103
Feld
Beschreibung
l
Naming Suffix
Mount path
Copy metadata
files to
Image access
mode (during
RecoverPoint
mount)
104
Use original database names with suffix: Dies ist die
Standardeinstellung, wenn Recovery Instance die
Produktionsinstanz ist.
Wird nur angezeigt, wenn Original database names with Suffix in der
Dropdown-Liste Database renaming ausgewählt wird. Der
Standardwert ist AppSync
l
Der standardmäßige Mount-Pfad, wenn der Mount-Host identisch
mit dem Produktionshost ist, ist %SystemDrive%
\AppSyncMounts\%%ProdServerName%%.
l
Prozentzeichen (%).
l
(ProdServerName), die mit zwei Prozentzeichen (%) begrenzt wird.
l
l
Der Mount-Pfad kann auch.Same as Original Path sein. Sie können
eine der Optionen auswählen.
l
das für das Mounten angegebene Laufwerk nicht eine geclusterte
Festplatte sein.
l
Standardmäßig ist der Speicherort zum Kopieren der VSSMetadatendateien identisch mit dem Mount-Pfad.
l
Wenn der Mount-Pfad identisch mit dem ursprünglichen Pfad ist,
wird standardmäßig %SystemDrive%\AppSyncMounts\%
%ProdServerName%% verwendet.
l
l
müssen Sie diese Metadatendateien ebenfalls sichern.
l
AppSync kann in Backupsoftware von Drittanbietern integriert
Das hier angegebene Zielverzeichnis muss Teil des Backups sein.
l
Logged Access: Verwenden Sie diese Mount-Option, wenn die
replizierten Volumes umfasst. Dies ist die einzige verfügbare
Option, wenn Sie auf den Produktionshost mounten.
l
Virtual Access with Roll: Bietet nahezu sofortigen Zugriff auf die
mit hoher Auslastung ermöglicht wird.
l
Virtual Access: Bietet nahezu sofortigen Zugriff auf das Image.
Diese Option ist nicht für die Verarbeitung von Prozessen mit hoher
Auslastung vorgesehen.
Feld
Use Dedicated
Storage Group
Beschreibung
l
direktem iSCSI-Teil des Clusters.
l
Standardmäßig aktiviert. Durch Aktivieren dieser Option kann
AppSync eine dedizierte VMAX-, VNX- oder XtremIOSpeichergruppe erzwingen. Bei XtremIO gilt diese Option für eine
XtremIO-Initiatorgruppe, die nur einen Initiator für den Mount-Host
enthält. Die Speichergruppe enthält den ausgewählten Mount-Host
für nur ein Mounten und das Mounten schlägt fehl, wenn Sie auf
einen Node eines Clusters mounten, der sich in einer
Speichergruppe befindet, die mit anderen Nodes gemeinsam
verwendet wird.
Hinweis
Szenario benötigen Sie zwei Speichergruppen. Eine Speichergruppe
ist für den passiven Node, der als Mount-Host verwendet wird,
dediziert und die andere Speichergruppe für den Rest der Nodes im
Cluster. Beide Speichergruppen enthalten den gemeinsamen
Speicher für das Cluster.
l
Wenn dieses Kontrollkästchen deaktiviert ist, erzwingt AppSync die
Verwendung einer dedizierten Speichergruppe für ein Mounten
nicht und der Mount-Vorgang wird fortgesetzt. Host-Initiatoren
können nur zu einer Initiatorgruppe in XtremIO gehören. Deshalb
müssen Sie diese Option verwenden, um sicherzustellen, dass Sie
auf einen Mount-Host mounten, der der einzige Host in der
Initiatorgruppe ist.
Hinweis
Deaktivieren Sie diese Option, wenn Sie Zielgeräte als geclusterter
Speicher manuell hinzufügen und sie den geclusterten SQL ServerInstanzen für die Neuverwendung von Daten und Data Mining
präsentieren möchten.
Außer Kraft setzen von Mount-Einstellungen in einem Serviceplan
Wenn es mehrere registrierte SQL Server gibt, für die der gleiche Plan abonniert wurde,
können Sie verschiedene Mount- und Wiederherstellungseinstellungen für jeden SQL
Server auswählen und damit die allgemeinen Einstellungen außer Kraft setzen.
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Service Plans > Microsoft SQL Server und klicken Sie auf einen der
Pläne aus der Liste.
3. Wählen Sie im rechten Bereich die Registerkarte Mount Copy Overrides aus.
Die Liste der Server enthält alle SQL Servers, für deren Datenbanken dieser Plan
abonniert wurde.
105
Je nachdem, ob die Option Mount copy oder Mount and recover copy ausgewählt
wird, werden die Standardeinstellungen für alle Server angezeigt.
4. Wählen Sie den Server aus, dessen Einstellungen Sie außer Kraft setzen möchten, und
klicken Sie auf Set Overrides.
Das Dialogfeld Override Default Mount Settings wird angezeigt.
5. Wählen Sie die Optionen nur für die Mount-Einstellungen aus, die Sie außer Kraft
setzen möchten.
Felder, die kein Auswahlfeld aufweisen, behalten ihre Standardeinstellungen bei.
In der ersten Spalte der Zeile des Servers, dessen Standard-Mount-Einstellungen Sie
geändert haben, wird ein Bleistiftsymbol angezeigt.
7. Klicken Sie zum Zurücksetzen eines Servers auf die Standardeinstellungen auf Use
Default Settings.
Post-mount script
auszuführen.
Kopie unmounten
Die finale Phase im Serviceplan führt einen Unmount-Vorgang für die Kopie durch. Diese
Phase wird deaktiviert, wenn die Phase Unmount previous copy aktiviert ist. Es sind
keine Benutzereinstellungen mit dieser Phase verknüpft.
Wenn Sie Mount and recover copy in der Phase Mount copy ausgewählt haben, werden
alle gemounteten Datenbanken im Rahmen dieser Phase heruntergefahren.
Benutzerdefiniertes Skript zum Herunterfahren vor dem Unmounten
Wenn Sie vor dem Unmounten ein benutzerdefiniertes Herunterfahren der Datenbanken
durchführen möchten, können Sie ein Skript am folgenden Speicherort ablegen:
%ProgramData%\EMC\AppSync\script.
Der Name des Skripts muss in diesem Format sein:
<ServicePlanName>_<host_ProductionInstanceName OR
ProductionInstanceName>_ ShutdownSQL.bat Hierbei gilt:
106
l
ServicePlanName ist der Name des Serviceplans, den die Datenbank abonniert
l
host_ProductionInstanceName ODER ProductionInstanceName:
n
In host_ProductionInstanceName können Sie host durch einen anderen
Namen ersetzen. ProductionInstanceName ist unabhängig davon
erforderlich, ob es verschiedene SQL-Instanzen gibt oder nicht.
n
Verwenden Sie ProductionInstanceName im Falle einer
Standardproduktionsinstanz, die dem Hostnamen entspricht.
Hinweis
n
Es wird empfohlen, dass Sie das Skript als Windows-Benutzer ausführen. Um das
Skript als SQL Server-Benutzer in der SQL Server 2012-Umgebung auszuführen,
muss der lokale Systembenutzer über die Sysadmin-Rolle verfügen.
n
Die Verwendung von _ als Trennzeichen im Skriptdateinamen ist obligatorisch.
Ist ein benutzerdefiniertes Skript nicht vorhanden, führt AppSync ein Herunterfahren der
Datenbanken vor dem Unmounten durch.
Mount-Überlegungen für SQL Server
Erfahren Sie Informationen zu Mount-Host-Anforderungen einschließlich Regeln für die
Mount- und Produktionshost-Versionen und die VM-Mount-Host-Unterstützung.
Der Mount-Host erfordert die gleichen Versionen des AppSync-Agent-Plug-In, SQL Server
und HBA-Treibers wie der Produktionshost. Mount-Hosts müssen einen SQL Server
installiert haben, wenn Sie Datenbanken von der gemounteten Kopie wiederherstellen
möchten. Wird Datenbank-Recovery nicht durchgeführt, ist SQL Server auf dem MountHost nicht erforderlich.
Mount- und Produktionshost-Versionen
l
Wenn Sie Mount-Vorgänge auf den Windows-Failover-Cluster-Node durchführen,
finden Sie weitere Informationen im Abschnitt „Microsoft Cluster Server Mounts“ des
EMC AppSync Installations- und Konfigurationsleitfadens.
l
Wenn die Hauptversion der SQL Server-Instanz auf dem Produktions-Mount-Host
höher als die des Mount-Host ist, schlägt die Recovery für alle Datenbanken, die zu
dieser Instanz gehören, fehl.
l
niedriger als die des Mount-Host ist, ist die Recovery nur erfolgreich, wenn der
Recovery-Typ entweder RECOVERY oder NORECOVERY ist. Recovery schlägt fehl, wenn
der Recovery-Typ STANDBY ist.
l
dieselbe ist wie die des Mount-Host, aber die Nebenversion niedriger ist, schlägt
Recovery für alle Datenbanken, die zu dieser Instanz gehören, fehl.
l
dieselbe ist wie die des Mount-Host, aber die Nebenversion höher ist, ist die
Recovery nur erfolgreich, wenn der Recovery-Typ RECOVERY oder NORECOVERY ist.
Recovery schlägt fehl, wenn der Recovery-Typ STANDBY ist.
Unterstützung für virtuelle Laufwerke
Wenn der Mount-Host eine virtuelle Maschine ist, muss VirtualCenter mit AppSync
registriert sein. Dies ist für das Mounten von RDMs erforderlich.
Für virtuelle Laufwerke:
l
Produktions-Mount wird nicht unterstützt, wenn die ESX-Host-Version niedriger als
5.0 ist.
Mount-Überlegungen für SQL Server
107
l
Nicht persistente virtuelle Laufwerke werden nicht unterstützt.
l
Für das Mounten von Datenspeichern und virtuellen Festplatten auf Umgebungen für
ESXi 5.x und RecoverPoint 4.1.7.7 deaktivieren Sie die Hardwarebeschleunigung, um
sicherzustellen, dass Mounts mit virtuellen Zugriffstypen erfolgreich sind. Weitere
Informationen finden Sie im Knowledgebase-Artikel 2006858.
Für Hyper-V-SCSI-Pass-Through kann der Mount-Host kein Hyper-V-Host, sondern muss
ein physischer Host oder eine VM mit NPIV oder iSCSI Direct Attached sein.
Mounten von SQL Server-Datenbankkopien nach Bedarf
Sie können das Mounten einer Datenbankkopie nach Bedarf von einer Kopie oder eine
Datenbank initiieren.
Bevor Sie beginnen
Vorgehensweise
1. Wählen Sie auf der Seite Datenbanken Recover > Mount a Copy aus.
Wählen Sie auf der Seite Copies eine Kopie aus und klicken Sie auf Mount.
Der SQL Server-Mount-Assistent wird gestartet.
2. Verwenden Sie die Filter Database, Copies oder Service Plan, um die entsprechende
Kopie auszuwählen, die Sie mounten möchten.
3. Wählen Sie die Kopie aus, die gemountet werden soll.
Bei einer RecoverPoint-Kopie haben Sie auch die Möglichkeit, ein Lesezeichen
basierend auf einem bestimmten Zeitpunkt auszuwählen. Es muss jedoch eine Kopie
in AppSync vor der Auswahl der Option Mount verfügbar sein.
Klicken Sie auf Select a point in time, um eine Kopie mit einem bestimmten
Zeitstempel auszuwählen. Bei der hier angezeigten Zeit handelt es sich um die
Uhrzeit der Konsole. Wenn sich die Konsole in einer anderen Zeitzone als die
RecoverPoint-Appliance (RPA) befindet, geben Sie zum Mounten der Kopie die Uhrzeit
gemäß der Serverzeitzone ein.
Bei VMAX 3-Arrays wird ein SLO-Drop-down-Menü angezeigt. Sie können das
gewünschten Service Level-Ziel (Service Level Objective, SLO) für die Mount-Kopie
auswählen. Falls eine Speichergruppe für den Mount-Host mit der gewünschten SLO
vorhanden ist, fügt AppSync die LUN zur Speichergruppe hinzu. Wenn diese
Speichergruppe nicht vorhanden ist, fügt AppSync die LUN zu einer Speichergruppe
hinzu, die gegenüber dem Host maskiert ist. Wenn eine Speichergruppe zur Auswahl
von Zielgeräten konfiguriert ist, entfernt AppSync die Geräte aus der Speichergruppe
zum Zeitpunkt des Mountens und fügt sie der Speichergruppe für den Mount-Host
hinzu. Die Geräte werden der ursprünglichen Speichergruppe hinzugefügt, wenn die
Kopie abgelaufen ist.
Kopien aus, die Sie mounten möchten. Die hier aufgeführten Kopien gehören zu
anderen Datenbanken, die zur selben Zeit geschützt waren und sich auf demselben
SQL Server wie die von Ihnen im vorherigen Schritt ausgewählte Kopie befinden.
5. Wählen Sie auf der Seite Select Mount Optionsdie Option Mount copy oder Mount
and recover copy aus.
6. Überprüfen Sie auf der Seite Summary die Auswahlen, die Sie auf den vorherigen
Seiten getroffen haben, und klicken Sie auf Finish, um die Kopie zu mounten.
108
7. Wählen Sie auf der Seite Results die Option View Details aus, um den Fortschritt der
verschiedenen Phasen anzuzeigen, die zum Mounten einer Kopie gehören.
SQL Server-Optionen für das Mounten von Kopien
Übersicht über Felder zum Mounten von Kopien mit SQL Server und deren
Beschreibungen.
Feld
Beschreibung
Mount on
Server
Der Server, auf den die Kopie zu mounten ist. Zur Auswahl stehen nur
die Nodes der Cluster oder eigenständige Hosts. Virtuelle SQLMaschinen werden herausgefiltert.
Mount with
access
Zugriffstyp, mit dem die Kopie gemountet werden soll.
Mount path
Copy metadata
files to
Image access
mode (during
RecoverPoint
mount)
l
Der Default Mount Path ist %SystemDrive%\AppSyncMounts\
%%ProdServerName%%.
l
Prozentzeichen (%).
l
(ProdServerName), die mit 2 Prozentzeichen (%) begrenzt ist.
l
l
Der Mount-Pfad kann auch Same as Original Path sein. Diese
Option ist jedoch nicht verfügbar, wenn der Mount-Host mit dem
Produktionshost identisch ist.
l
das Laufwerk, das für das Mounten angegeben ist, kein
Clusterlaufwerk sein.
l
Die Default Path ist der Speicherort zum Kopieren von VDI- und
VSS-Metadatendateien:%SystemDrive%\AppSyncMounts\%
%ProdServerName%%
l
l
müssen Sie die Metadatendateien ebenfalls sichern.
l
AppSync kann mit Backupsoftware von Drittanbietern integriert
Das Zielverzeichnis, das hier angegeben wird, muss Teil des
Backups.
l
replizierten Volumes umfasst. Protokollierter Zugriff ist die einzige
l
Virtual access with roll: Bietet nahezu sofortigen Zugriff auf die
109
Feld
Beschreibung
l
Virtual access: Bietet nahezu sofortigen Zugriff auf das Image.
Virtueller Zugriff ist für die Verarbeitung von Prozessen mit hoher
Auslastung nicht vorgesehen. Virtueller Zugriff mit RP VMAX und
Service Level
Nur für VMAX 3-Arrays. Die Einstellung „Desired Service Level
Objective (SLO) Objective (SLO)“ wird im Mount-Assistenten angezeigt und gibt die
erforderlichen VMAX 3-Service-Level-Ziele an. SLO definiert den
Servicezeitbetriebsbereich einer Speichergruppe.
Use Dedicated
Storage Group
l
direktem iSCSI als Teil des Clusters.
l
Standardmäßig aktiviert. Durch das Aktivieren dieser Option kann
AppSync eine dedizierte VMAX-, VNX- und XtremIOSpeichergruppe für ein Mounten erzwingen. (Eine dedizierte
VMAX- oder VNX-Speichergruppe enthält nur den ausgewählten
Mount-Host.) Bei XtremIO gilt diese Option für eine XtremIOInitiatorgruppe, die nur einen Initiator für den Mount-Host enthält.
Das Mounten schlägt fehl, wenn Sie auf einen Node eines Clusters
mounten, der in einer Speichergruppe ist, die mit den anderen
Nodes gemeinsam verwendet wird.
Hinweis
Szenario benötigen Sie zwei Speichergruppen. Eine
verwendet wird, dediziert und die andere Speichergruppe für den
Rest der Nodes im Cluster. Beide Speichergruppen enthalten den
gemeinsamen Speicher für das Cluster.
l
Mounten nicht.
Hinweis
Deaktivieren Sie diese Option, wenn Sie Zielgeräte als
Clusterspeicher manuell hinzufügen und den geclusterten SQL
Server-Instanzen für die Neuverwendung von Daten und Data
Mining präsentieren möchten.
Optionen zum Mounten und Wiederherstellen der Kopie mit SQL Server
Die Optionen zum Mounten und Wiederherstellen der Kopie mit SQL werden in der
folgenden Tabelle erläutert:
110
Feld
Beschreibung
Recovery
Instance
Die SQL Server-Instanz, die für die Recovery verwendet werden soll.
Wenn die Verbindungseinstellungen nicht eingestellt oder für die
Feld
Beschreibung
Instanz ungültig sind, wird das Dialogfeld für die SQL ServerVerbindungseinstellungen angezeigt. Klicken Sie auf Connection
Settings, um die Anmeldedaten zurückzusetzen.
Hinweis
Geclusterte SQL Server-Instanzen werden in dieser Ansicht
herausgefiltert.
Wenn Sie ein VMAX 3-Array verwenden, steht außerdem die Einstellung
„Desired Service Level Objective (SLO)“ zur Verfügung. Die Option wird
im Mount-Assistenten angezeigt und gibt die erforderlichen VMAX 3Service-Level-Ziele an. SLO definiert den Servicezeit-Betriebsbereich
einer Speichergruppe
Recovery Type
Verfügbare Optionen: „Recovery“ (Standardwert), „No Recovery“ und
„Standby“
Database
renaming
Diese Dropdown-Liste umfasst:
Naming Suffix
Mount path
Copy metadata
files to
l
Use original database names (Standardwert bei alternativer
Instanz): Dies ist zur Auswahl nicht verfügbar, wenn Recovery
Instance die Produktionsinstanz ist.
l
Use original database names with suffix: Dies ist die
Standardeinstellung, wenn Recovery Instance die
Produktionsinstanz ist.
Wird nur angezeigt, wenn Original database names with Suffix in der
Dropdown-Liste Database renaming ausgewählt wird. Der
Standardwert ist AppSync
l
Der standardmäßige Mount-Pfad, wenn der Mount-Host identisch
mit dem Produktionshost ist, ist %SystemDrive%
\AppSyncMounts\%%ProdServerName%%.
l
Prozentzeichen (%).
l
(ProdServerName), die mit zwei Prozentzeichen (%) begrenzt wird.
l
l
Der Mount-Pfad kann auch.Same as Original Path sein. Sie können
eine der Optionen auswählen.
l
das für das Mounten angegebene Laufwerk nicht eine geclusterte
Festplatte sein.
l
Standardmäßig ist der Speicherort zum Kopieren der VSSMetadatendateien identisch mit dem Mount-Pfad.
l
Wenn der Mount-Pfad identisch mit dem ursprünglichen Pfad ist,
wird standardmäßig %SystemDrive%\AppSyncMounts\%
%ProdServerName%% verwendet.
l
111
Feld
Image access
mode (during
RecoverPoint
mount)
Use Dedicated
Storage Group
Beschreibung
l
müssen Sie diese Metadatendateien ebenfalls sichern.
l
AppSync kann in Backupsoftware von Drittanbietern integriert
Das hier angegebene Zielverzeichnis muss Teil des Backups sein.
l
l
mit hoher Auslastung ermöglicht wird.
l
Diese Option ist nicht für die Verarbeitung von Prozessen mit hoher
Auslastung vorgesehen.
l
l
Standardmäßig aktiviert. Durch Aktivieren dieser Option kann
AppSync eine dedizierte VMAX-, VNX- oder XtremIOSpeichergruppe erzwingen. Bei XtremIO gilt diese Option für eine
XtremIO-Initiatorgruppe, die nur einen Initiator für den Mount-Host
enthält. Die Speichergruppe enthält den ausgewählten Mount-Host
für nur ein Mounten und das Mounten schlägt fehl, wenn Sie auf
einen Node eines Clusters mounten, der sich in einer
Speichergruppe befindet, die mit anderen Nodes gemeinsam
verwendet wird.
Hinweis
Szenario benötigen Sie zwei Speichergruppen. Eine Speichergruppe
ist für den passiven Node, der als Mount-Host verwendet wird,
dediziert und die andere Speichergruppe für den Rest der Nodes im
Cluster. Beide Speichergruppen enthalten den gemeinsamen
Speicher für das Cluster.
l
112
Wenn dieses Kontrollkästchen deaktiviert ist, erzwingt AppSync die
Verwendung einer dedizierten Speichergruppe für ein Mounten
nicht und der Mount-Vorgang wird fortgesetzt. Host-Initiatoren
können nur zu einer Initiatorgruppe in XtremIO gehören. Deshalb
müssen Sie diese Option verwenden, um sicherzustellen, dass Sie
auf einen Mount-Host mounten, der der einzige Host in der
Initiatorgruppe ist.
Feld
Beschreibung
Hinweis
Deaktivieren Sie diese Option, wenn Sie Zielgeräte als geclusterter
Speicher manuell hinzufügen und sie den geclusterten SQL ServerInstanzen für die Neuverwendung von Daten und Data Mining
präsentieren möchten.
Unterstützte Mount-Recovery-Modi
Die folgenden Mount-Recovery-Typen sind verfügbar, wenn Sie eine Kopie der SQLDatenbank wiederherstellen.
RecoveryTyp
Beschreibung
Recovery
Weist den Wiederherstellungsvorgang an, ein Rollback für alle
unvollendeten Transaktionen durchzuführen. Nach dem Recovery-Prozess
ist die Datenbank einsatzbereit.
No
Recovery
Weist den Wiederherstellungsvorgang an, kein Rollback für alle
unvollendeten Transaktionen durchzuführen. Im Modus „No Recovery“
kann die Datenbank nicht verwendet werden. Diese Option ist nützlich,
wenn der Datenbankadministrator eine oder mehrere Backups von
Transaktionsprotokollen wiederherstellen muss. Die Datenbank ist an die
Instanz angeschlossen, die für die Recovery ausgewählt wurde, und bleibt
im Wiederherstellungsstatus.
Standby
Stellt Dateien wieder her und öffnet die Datenbank im schreibgeschützten
Modus. Anschließend kann der Datenbankadministrator zusätzliche
Backups von Transaktionsprotokollen manuell anwenden.
Hinweis
Wenn Sie eine Datenbank einer älteren Version von SQL Server auf eine
neuere Version von SQL Server wiederherstellen, verwenden Sie nicht den
Stand-by-Modus. Wenn Sie „Standby“ verwenden, kann das Upgrade auf
die neuere Version nicht stattfinden und die Operation schlägt fehl.
Unmounten eine SQL Server-Kopie
Wenn Sie eine SQL Server-Kopie zum Unmounten auswählen, wird der Mount-Vorgang
auch für andere Kopien ausgeführt, die zusammen mit der ausgewählten Kopie
gemountet waren.
Bevor Sie beginnen
Sie können eine Kopie nur aus einer Liste von Kopien unmounten, die für eine Datenbank
erstellt wurde.
Vorgehensweise
1. Navigieren Sie von den Seiten Copy Management oder Service Plan zur Seite Copies:
Unmounten eine SQL Server-Kopie
113
l
Copy Management > Microsoft SQL Server > Wählen Sie den Server aus, der das
Dateisystem hostet, das Sie unmounten möchten, und wählen Sie dann die
Datenbankinstanz mit der Kopie aus, die Sie unmounten möchten.
l
Service Plans > Microsoft SQL Server > Wählen Sie einen Serviceplan aus und
wählen Sie dann die Registerkarte Copies aus.
2. Wählen Sie aus der Liste der Kopien die Kopie aus und klicken Sie auf Unmount über
die Schaltfläche im unteren Teil der Seite.
Das Dialogfeld Unmount Confirmation zeigt alle Kopien von anderen Datenbanken an,
die zusammen mit der ausgewählten Kopie gemountet wurden, die Sie unmounten
möchten.
angezeigt werden.
Auf der Seite Unmount wird der Fortschritt des Unmount-Vorgangs angezeigt. Der
zugeordnet sind.
Wiederherstellung von SQL Server-Datenbanken – Übersicht
Lesen und berücksichtigen Sie die folgenden Abschnitte zu den
Wiederherstellungsoptionen für SQL Server-Datenbanken.
Dazu gehören:
l
Wiederherstellungsüberlegungen für Datenbanken in einer Verfügbarkeitsgruppe
l
Betroffene Entitäten während der Wiederherstellung
l
Wiederherstellen einer primären Datenbank oder einer sekundären Datenbank mit
Failover
l
Wiederherstellen einer sekundären Datenbank ohne Failover
l
So verwaltet AppSync beschädigte SQL-Datenbanken
l
Wiederherstellung einer SQL Server-Kopie
l
Wiederherstellung einer SQL Server-Kopie auf XtremIO
l
SQL-Wiederherstellungsdienstprogramm (assqlrestore)
Wiederherstellungsüberlegungen für Datenbanken in einer Verfügbarkeitsgruppe
AppSync stellt Kopien von primären und sekundären Datenbanken wieder her.
Berücksichtigen Sie Folgendes bei der Wiederherstellung einer Datenbank in einer
Verfügbarkeitsgruppe.
114
l
Die Wiederherstellung erfolgt in der LUN-Ebene und muss zur Quell-LUN erfolgen, die
zum Erstellen der AppSync-Kopie verwendet wurde.
l
AppSync setzt die Datenverschiebung im Rahmen des Wiederherstellungsprozesses
aus.
l
Eine Datenbank kann nicht wiederhergestellt werden, wenn sie Teil einer
Verfügbarkeitsgruppe ist. Im Rahmen des Wiederherstellungsprozesses entfernt
AppSync die Datenbank aus der Verfügbarkeitsgruppe.
l
AppSync fügt die Datenbank der Verfügbarkeitsgruppe nicht wieder hinzu. Weitere
Informationen zur Wiederherstellung von Datenbanken in einer Verfügbarkeitsgruppe
finden Sie unter "Wiederherstellen einer primären Datenbank oder einer sekundären
Datenbank mit Failover" und "Wiederherstellen einer sekundären Datenbank ohne
Failover".
Elemente zusätzlich zu denjenigen, die Sie ausgewählt haben, wiederherzustellen.
Eine betroffene Entität sind Daten, die sich auf dem Produktionshost befinden und
unbeabsichtigterweise Teil eines Replikats werden, weil sie in der Nähe von Daten
stehen, die Sie schützen möchten. Sie können Situationen mit betroffenen Entitäten
vermeiden, indem Sie Ihr Datenlayout ordnungsgemäß auf Grundlage der ReplikatGranularität planen. Die Granularität eines Replikats hängt von der Umgebung ab.
Wenn betroffene Entitäten in der zugrunde liegenden Speicherkonfiguration vorhanden
sind, wird der Wiederherstellungs-Assistent Sie über diese Elemente informieren. Die
folgenden Szenarien erstellen betroffene Entitäten, für die Sie bestätigen müssen, dass
zusätzliche Elemente wiederhergestellt werden sollen:
l
Wenn bei RecoverPoint die Datenbanken in derselben Konsistenzgruppe sind,
werden sie zu betroffenen Entitäten, wenn die andere Datenbank geschützt wird.
l
Wenn bei VNXe die Datenbanken in der gleichen LUN-Gruppe sind, werden sie zu
betroffenen Entitäten, wenn die andere Datenbank geschützt wird.
l
Wenn sich bei VNX/VMAX, VNX, VNXe oder XtremIO die Datenbanken auf derselben
LUN sind, werden sie zu betroffenen Entitäten, wenn die andere Datenbank geschützt
wird.
l
Da bei virtuellen VMware-Festplatten die Wiederherstellung einen Datenspeicher
erfordert, gibt es bei der Wiederherstellung aller Anwendungen, die sich im gleichen
Datenspeicher (in virtuellen Laufwerken auf demselben Datenspeicher) befinden,
ebenfalls betroffene Entitäten.
Wenn die betroffene Entität zusammen mit der Datenbank geschützt wurde, die zur
Wiederherstellung ausgewählt ist, wird sie von AppSync wiederhergestellt. Alle anderen
Datenbanken, die nicht geschützt wurden, aber betroffene Entitäten sind, werden
überschrieben.
AppSync berechnet die betroffenen Entitäten für die Konsistenzgruppen oder LUNGruppen der Datenbank, die zur Wiederherstellung ausgewählt ist. Wenn sich die
betroffenen Datenbanken wiederum teilweise auf einer anderen Konsistenzgruppe oder
LUN-Gruppe befinden, berechnet AppSync auf diesen Konsistenzgruppen oder LUNGruppen keine betroffenen Entitäten.
Je nach Typ der betroffenen Entitä, werden die betroffenen Datenbanken durch AppSync
getrennt oder Sie müssen sie manuell von der SQL Server-Instanz trennen.
Betroffene Entitäten werden nur für die SQL Server-Instanzen berechnet, für die
Anmeldedaten konfiguriert sind. AppSync führt für alle diese Instanzen vor der
Berechnung der betroffenen Entitäten eine neue Datenbankerkennung durch.
Failover
Sobald Sie auf die Schaltfläche Finish im Assistenten SQL Server Restore klicken, führt
AppSync die folgenden Aktionen aus:
1. Wenn Sie das Kontrollkästchen Failover the Availability Group if the current role is
Secondary aktiviert haben, überprüft AppSync die Integrität der Datenbanken in der
Verfügbarkeitsgruppe, die nicht wiederhergestellt werden. Wenn diese nicht fehlerfrei
sind, kann AppSync das Failover nicht ausführen und der Wiederherstellungsvorgang
115
schlägt fehl. Sie müssen den Wiederherstellungsvorgang wiederholen, ohne das
Kontrollkästchen zu aktivieren.
2. Wenn Sie die Option zum Sichern des Transaktionsprotokolls auswählt haben, führt
AppSync eine Sicherung des Transaktionsprotokolls aus.
3. AppSync unterbricht Datenverschiebungen für alle Replikate der ausgewählten
Datenbank vor dem Entfernen aller Replikate der ausgewählten Datenbank aus der
4. Wenn die wiederherzustellende Datenbank sekundär ist, initiiert AppSync das
Failover.
5. AppSync stellt die LUNs der ausgewählten Datenbank wieder her.
6. AppSync stellt letztlich die Datenbank wieder her und behält für die Datenbank den
Recovery-Status bei, den Sie im Assistenten SQL Server Restore ausgewählt haben.
Nachdem AppSync die Wiederherstellung abgeschlossen hat, müssen Sie die folgenden
Schritte ausführen.
Vorgehensweise
1. Stellen Sie alle Protokollbackups wieder her und führen Sie eine Recovery für die
primäre Datenbank aus.
2. Fügen Sie die Datenbank wieder der Verfügbarkeitsgruppe hinzu.
3. Falls für die primäre Datenbank ein Rollforward ausgeführt wurde und sie daher die
gleiche Uhrzeit wie die sekundäre Datenbank aufweist, fügen Sie die sekundären
Kopien erneut der Verfügbarkeitsgruppe hinzu.
4. Falls für die primäre Datenbank kein Rollforward ausgeführt wurde:
a. Löschen Sie alle sekundären Kopien der wiederhergestellten Datenbank.
b. Führen Sie ein erneutes Seeding für die Replikate der sekundären Datenbank aus
und fügen Sie die Replikate erneut der Verfügbarkeitsgruppe hinzu.
Hinweis
Nachdem AppSync die Kopie der primären Datenbank entfernt hat, befindet sich die
Kopie im wiederhergestellten Zustand, sofern diese fehlerfrei ist. Wenn Sie eine
sekundäre Kopie mit Failover wiederhergestellt haben, wurde die primäre Rolle in eine
andere SQL Server-Instanz verschoben. Sie müssen die ursprüngliche primäre
Datenbank löschen und für sie erneut ein Seeding ausführen.
Wiederherstellen einer sekundären Datenbank ohne Failover
Sobald Sie auf die Schaltfläche Finish im Assistenten SQL Server Restore klicken, führt
AppSync die folgenden Aktionen aus:
1. Wenn Sie die Option zum Sichern des Transaktionsprotokolls auswählt haben, führt
AppSync eine Sicherung des Transaktionsprotokolls aus.
2. AppSync unterbricht die Datenverschiebung für das ausgewählte sekundäre
Datenbank-Replikat. Die Replikation wird für andere Replikate der Datenbank
fortgesetzt.
3. AppSync entfernt das ausgewählte sekundäre Datenbank-Replikat aus der
4. AppSync stellt die LUNs der ausgewählten Datenbank wieder her.
116
5. AppSync stellt letztlich die Datenbank wieder her und behält für die Datenbank den
Recovery-Status bei, den Sie im Assistenten SQL Server Restoreausgewählt haben.
Nachdem AppSync die Wiederherstellung abgeschlossen hat, müssen Sie die folgenden
Schritte ausführen.
Vorgehensweise
1. Stellen Sie alle Protokollbackups wieder her und behalten Sie für die sekundäre
Datenbank den Status „NO RECOVERY“ bei.
2. Fügen Sie die sekundäre Datenbank wieder der Verfügbarkeitsgruppe hinzu.
So werden beschädigte SQL-Datenbanken von AppSync verwaltet
Bei beschädigten Datenbanken fehlen Datendateien oder diese sind beschädigt,
während die Protokolldateien intakt sind. AppSync kann Protokollfragmentbackups für
beschädigte Datenbanken erstellen. Eine beschädigte Datenbank darf
massenprotokollierte Änderungen nicht enthalten und darf nicht im Status OFFLINE sein.
Wenn die Produktionsdatenbank beschädigt ist und Sie das Kontrollkästchen Database
is damaged während der Wiederherstellung aktivieren, sichert AppSync das
Protokollfragment der beschädigten Datenbank vor dem Fortfahren der
Wiederherstellung. Wenn die beschädigte Datenbank für die Wiederherstellung aussteht
oder fehlerverdächtig ist, versucht AppSync zunächst, die Datenbank durch Einstellen
des Notfallmodus zu trennen. Wenn AppSync den Notfallmodus der Datenbank nicht
einstellen kann, wird die Datenbank ausgelassen und die Wiederherstellung fortgesetzt.
Sobald die Wiederherstellung erfolgreich ist, können Sie die Datenbank manuell mithilfe
des Protokollfragmentbackups wiederherstellen.
Weitere Informationen finden Sie unter Wiederherstellungsverfahren mit XtremIO auf
Seite 216.
Wiederherstellen einer SQL Server-Kopie
Sie können eine SQL Server-Kopie auf der Seite Copies des Servers oder der Servicepläne
oder auf der Seite Databases wiederherstellen .
Bevor Sie beginnen
Vorgehensweise
1. Wählen Sie auf der Seite Databases Recover > Restore aus.
Wählen Sie eine Kopie auf der Seite Copies aus und klicken Sie auf Restore.
Der Assistent SQL Server Restore wird gestartet.
2. Wählen Sie die wiederherzustellende Kopie aus.
Verwenden Sie die Filter Time oder Service Plan, um die entsprechende
wiederherzustellende Kopie auszuwählen. Die Liste der Kopien wird basierend auf
den ausgewählten Filtern aktualisiert.
3. Klicken Sie auf Next.
Wenn die ausgewählte Kopie betroffene Entitäten aufweist, wird die Seite Restore
Warnings angezeigt.
4. Lesen Sie die Warnmeldungen für die betroffenen Datenbanken. Aktivieren Sie das
Kontrollkästchen, um Ihr Einverständnis zu erklären, dass die anderen Entitäten
zusammen mit der Kopie wiederhergestellt werden.
5. Wählen Sie im Schritt Backup Transaction Logs Yes aus, um die Protokolle vor der
Wiederherstellung zu sichern.
So werden beschädigte SQL-Datenbanken von AppSync verwaltet
117
a. Geben Sie im Feld Backup up to den Speicherort an, in dem die Protokolle
gesichert werden sollen. Die Dateien erhalten den Namen der Datenbank.
b. Aktivieren Sie das Kontrollkästchen Add a file extension to the backup file name
und geben Sie eine Erweiterung für die gesicherten Dateien an. Die StandardErweiterung lautet .trn.
c. Aktivieren Sie das Kontrollkästchen Add a prefix to the backup file names und
geben Sie ein Präfix für die gesicherten Dateien an. Das Standardpräfix lautet
AppSync.
d. Aktivieren Sie das Kontrollkästchen Database is damaged, um
Protokollfragmentdateien zu sichern.
e. Aktivieren Sie bei Bedarf das Kontrollkästchen Truncate the transaction logs.
Dieses Kontrollkästchen ist nicht zur Auswahl verfügbar, wenn Sie das
Kontrollkästchen Database is damaged ausgewählt haben.
f. Aktivieren Sie bei Bedarf das Kontrollkästchen Overwrite existing backup files.
Dieses Kontrollkästchen ist nicht zur Auswahl verfügbar, wenn Sie das
Kontrollkästchen Database is damaged ausgewählt haben.
6. Klicken Sie auf Next zum Aufrufen der Restore Options.
Die Seite Restore Options wird angezeigt.
7. Wählen Sie die entsprechenden Recovery- oder Wiederherstellungsoptionen aus.
a. Wählen Sie zum Wiederherstellen der Datenbank eine der folgenden Optionen
aus:
l
Leave database ready to use: Diese Option ist nicht verfügbar, wenn Sie die
Option zum Sichern von Transaktionsprotokollen ausgewählt haben.
l
Leave databases non-operational
Hinweis
Wählen Sie diese Option aus, wenn Sie eine sekundäre Datenbank ohne
Failover wiederherstellen. Auf diese Weise bleibt die sekundäre Datenbank im
Status der Wiederherstellung, damit die Transaktionsprotokolle
wiederhergestellt werden können und dabei die Datenbank erneut der
Verfügbarkeitsgruppe hinzugefügt werden kann.
l
Leave databases in read-only mode: Wenn Sie diese Option auswählen, geben
Sie den Speicherort im Feld
Standby file location an, an dem die Stand-by-Dateien gespeichert werden
müssen. Der Standardpfad lautet C:\temp.
b. Aktivieren Sie das Kontrollkästchen Overwrite the existing databases, um eine
Wiederherstellung durch Überschreiben der vorhandenen Datenbank zu
erzwingen.
Diese Option ist unter normalen Bedingungen nicht erforderlich.
Diese Option ist nicht verfügbar, wenn Sie die Option zum Sichern von
Transaktionsprotokollen ausgewählt haben.
c. Aktivieren Sie im Falle der Verfügbarkeitsgruppen das Kontrollkästchen Failover
the Availability Group if the current role is Secondary, um ein Failover vor der
Wiederherstellung zu initiieren, wenn Sie eine sekundäre Datenbank
wiederherstellen.
118
Es wird eine Warnung angezeigt, dass die Datenbank aus der
Verfügbarkeitsgruppe entfernt wird und Sie diese wieder der Gruppe hinzufügen
müssen, nachdem AppSync das Volume wiederhergestellt hat.
d. Aktivieren Sie das Kontrollkästchen I have read and understand the warning
above, and want to continue with the restore, um die Meldung zu bestätigen.
Die Seite Summary wird angezeigt.
9. Überprüfen Sie die Seite Summary und klicken Sie auf Finish, um die
Wiederherstellung auszuführen.
11. Nachdem AppSync eine Datenbank in einer Verfügbarkeitsgruppe wiederhergestellt
hat, führen Sie bei Bedarf die folgenden zusätzlichen Schritte aus:
l
Failover auf Seite 115.
l
Wiederherstellen einer sekundären Datenbank ohne Failover auf Seite 116.
l
Manuelles Wiederherstellen einer SQL Server-Kopie auf XtremIO auf Seite 119
Wiederherstellen einer SQL Server-Kopie auf XtremIO
Version 2.2.2 von AppSync und höher unterstützt die automatisierte Wiederherstellung
von Kopien auf XtremIO 4.0 und höher. In diesem Abschnitt wird erläutert, wie die
Versionen 2.1 - 2.2.1 von AppSync und eine niedrigere XtremIO-Version als 4.0 zur
Wiederherstellung einer SQL Server-Datenbank auf einen Point-in-Time mithilfe eines
halbmanuellen Wiederherstellungsprozesses verwendet werden. Die Wiederherstellung
der Backups von SQL Server-Transaktionsprotokollen wird nicht unterstützt.
Bevor Sie beginnen
Weitere Informationen zur automatischen Wiederherstellung finden Sie unter
Wiederherstellen einer SQL Server-Kopie auf Seite 117.
Sorgen Sie bei einer halbmanuellen Wiederherstellung dafür, dass die folgenden
Voraussetzungen erfüllt sind, und führen Sie dann das Verfahren aus:
l
SQL Server-Datenbanken und XtremIO-Speicher werden mit der AppSyncKonfiguration ausgeführt.
l
Ein AppSync-Serviceplan, mit dem die Datenbank repliziert wird.
Vorgehensweise
1. Wählen Sie auf der AppSync- Konsole Service Plans > Microsoft SQL Server aus und
klicken Sie dann auf den gewünschten Serviceplan, z. B. Bronze.
Auf der Seite Copies werden die vorhandenen Kopien angezeigt.
2. Mounten Sie die Kopien, die Sie wiederherstellen möchten. Wenn Sie dazu
aufgefordert werden, Mount Additional Copies, wählen Sie alle
Datenbankkopien aus, die sich auf den zu ersetzenden Festplattenlaufwerken
befinden.
Das Dialogfeld Select Mount Option wird geöffnet.
119
Abbildung 6 Wählen Sie die Mount Option aus
3. Wählen Sie im Dialogfeld Select Mount Optiondie Option Mount copy aus.
4. Da es mit AppSync nicht möglich ist, die Produktionsinstanz wiederherzustellen,
wählen Sie im Listenfeld Mount on Server die Option Original Server aus.
5. Wählen Sie im Listenfeld Mount with access die Option Read-write aus.
6. Wählen Sie im Listenfeld Mount Path die Option Default Path aus (da Sie auf den
ursprünglichen Server mounten).
7. Beenden Sie alle Anwendungen auf dem Produktionshost, welche die
wiederherzustellenden Datenbanken verwenden.
8. Setzen Sie die Datenbanken mithilfe von SQL Server Management Studio in den
Offline-Modus und trennen Sie sie.
Denken Sie daran, dass Sie die Festplattenlaufwerke der Produktion durch die
AppSync-Snapshots ersetzen. Trennen Sie daher alle Datenbanken, welche die
gleichen Geräte verwenden.
9. Nachdem Sie die betroffenen Datenbanken getrennt haben, löschen Sie mithilfe von
Windows Server Manager den Laufwerksbuchstaben oder Mount-Punkt für die
Laufwerke, die Sie wiederherstellen. Notieren Sie sich die Festplattennummer und die
Laufwerksbuchstaben-Zuweisungen für den Fall, dass Sie die Schritte der
Wiederherstellung rückgängig machen müssen.
Nachdem der AppSync-Mount abgeschlossen ist, befinden sich die Laufwerke für die
Wiederherstellungskopien als Mount-Punkte in C:\AppSyncMounts
\<SERVERNAME>.
10. Starten Sie Windows Server Manager, um die bereitgestellten Geräte zu suchen, und
weisen Sie dann Laufwerksbuchstaben oder Mount-Punkte zu, um diejenigen zu
ersetzen, die Sie in Schritt 8 entfernt haben.
11. Verwenden Sie SQL Server Management Studio zur Anbindung der Datenbanken, die
Sie wiederherstellen möchten. Zeigen Sie mit der Maus auf die gemounteten
AppSync-Kopien für die Datenbanken. Wenn die Datenbank 17 oder mehr Dateien
aufweist, verwenden Sie CREATE database_name FOR ATTACH.
120
Abbildung 7 Anhängen von Datenbanken
Zu diesem Zeitpunkt sollten alle wiederhergestellten Datenbanken online sein und
Sie können dann alle Datenbankanwendungen neu starten, die Sie zuvor angehalten
haben. Sie können die folgenden Schritte ausführen, ohne SQL Server zu
beeinträchtigen.
12. Kehren Sie auf der AppSync-Konsole zur Seite Database Copies zurück, die in Schritt 1
beschrieben wird, und klicken Sie dann für jede gemountete Kopie auf Remove.
Mit dieser Aktion wird die Kopie aus der AppSync-Datenbank entfernt, ohne die
Snapshots auf dem Mount-Host der Produktion oder dem XtremIO-Speicherarray zu
entfernen. Es wird eine Warnmeldung angezeigt.
Hinweis
Wenn der Serviceplan mehrere Datenbanken enthält, verbleibt der Speicher für alle
Datenbanken im Serviceplan auf dem XtremIO-Speicherarray. Sie können diese nach
Ihrem Ermessen entfernen.
Abbildung 8 Bestätigen Sie die folgenden Optionen zum Entfernen
13. Verschieben Sie die gemounteten Snapshots aus dem/AppSyncSnapshots-Ordner
in den Ordner, in dem sich die auszutauschende Produktions-LUN befindet. Achten
Sie darauf, dass Sie die gemounteten Snapshots verschieben, das heißt, die
Snapshots, die aktuell gegenüber der ESX-Initiatorgruppe maskiert sind (wenn der
Produktionshost eine virtuelle Maschine ist). Wenn es sich beim Produktionshost um
121
einen physischen Host handelt, verschieben Sie die Snapshots in den Ordner, in dem
sich die Produktions-LUNs befinden.
Die Produktions-LUN und der Snapshot werden im selben Ordner angezeigt.
Abbildung 9 LUN-Zuordnungskonfiguration
Beachten Sie nach dem Verschieben, dass es sich bei den wiederhergestellten
Geräten um einen Snapshot und bei den Produktionsgeräten um Volumes (LUN)
handelt.
Abbildung 10 Beispiel für Snapshot und LUN
14. Perform this step only if the production host is a virtual
machine.
a. Heben Sie die Zuordnung der ursprünglichen Produktions-Volumes zum
Produktionshost auf.
b. Scannen Sie den ESX-Host erneut.
c. Entfernen Sie die RDMs aus der Produktions-VM-Konfiguration.
15. Perform this step only If the production host is a physical
machine.
a. Heben Sie die Zuordnung der ursprünglichen Produktions-Volumes zum
Produktionshost auf.
b. Führen Sie einen erneuten Scanvorgang für das Gerät auf dem Host aus, um die
alten Produktionsgeräte zu entfernen.
16. Entfernen Sie die Produktions-Volumes.
Diese Aktion führt dazu, dass aus den wiederhergestellten Snapshots Volumes
werden.
122
Abbildung 11 Aus wiederhergestellten Snapshots werden Volumes
17. Benennen Sie die Snapshots auf die Produktions-Volume-Namen um.
Abbildung 12 Snapshots auf Produktions-Volume-Namen umbenennen
Beachten Sie in der AppSyncXtremIO-Konsole, dass aus den anderen Snapshots im /
AppSyncSnapshots-Ordner für die Produktions-XtremIO-Volumes, die Sie im
vorherigen Schritt entfernt haben, auch Volumes geworden sind.
Abbildung 13 Aus Snapshots werden LUNs
18. Führen Sie den Datenbank-Serviceplan zur Erstellung eines Snapshot der
wiederhergestellten Datenbanken aus.
SQL Server-Wiederherstellungsdienstprogramm (Assqlrestore)
AppSync beinhaltet ein SQL Server-Wiederherstellungsdienstprogramm namens
assqlrestore. In diesem Abschnitt werden dessen Funktion und Verwendung
beschrieben.
Mit dem Dienstprogramm assqlrestore können Sie die einzelnen SQL ServerDatenbanken von einem Band-Backup oder einer gemounteten Kopie wiederherstellen,
ohne eine umgekehrte Synchronisierung des Zielgeräts über das Quellgerät
durchzuführen. Sie können eine Datenbank, Dateigruppe oder Datei wiederherstellen.
Das Dienstprogramm kann zur ursprünglichen Datenbank oder zu einer neuen Datenbank
wiederherstellen. SQL Server-VDI-Metadaten, die als Teil der Replikationsaktivität erstellt
wurden, sind erforderlich, um eine Datenbank mit assqlrestore wiederherzustellen.
123
assqlrestore ist eine Befehlszeilenoberfläche, die Sie in einem
Eingabeaufforderungsfenster auf dem AppSync-Client ausführen. Es wird auf dem Client
als Teil der AppSync-Installation installiert.
Das Wiederherstellen einer einzelnen Datenbank von einer gemounteten Kopie ist
besonders nützlich, wenn Sie nur eine Datenbank wiederherstellen müssen und nicht mit
einer normalen AppSync-Wiederherstellung das gesamte Gerät überschreiben möchten.
Assqlrestore-Befehlssyntax mit Beispielen
In diesem Thema wird die Befehlssyntax für den assqlrestore-Befehl mit
nachfolgenden Beispielen für die Befehle aufgeführt.
Befehlssyntax
Die folgende Tabelle listet die Befehlssyntax für den assqlrestore-Befehl.
Tabelle 11 assqlrestore -Befehlssyntax
Option
Beschreibung
Erforderlich
-s
SQL Servername einschließlich Instanzname (Host\Instanz).
-f
Metadaten-Dateiname und Speicherort.
-d
Datenbankname.
Verbindungsarten (-E- oder
- U)
E
Benutzer, der für die Windows-Authentifizierung verwendet wird
(Geben Sie den Benutzernamen an)
%U
SQL Server-Anmeldeinformationen.
-P
Klartext-Passwort (nur bei den Optionen -E und -U).
-p
Verschlüsseltes Passwort (bei den Optionen -E und -U).
Optional
124
-r
Wiederherstellungsoption - RECOVERY, NORECOVERY
(Standardwert) oder STANDBY.
-u
Dateiname rückgängig machen, für STANDBY erforderlich
-m
Datei verschieben. Diese Option hat zwei Parameter:
logical_file_name und operating_system_file_name.
Die Pfadnamen müssen vorhanden sein. Wiederholen Sie die Option
für jede Datei, einschließlich der Protokolldateien oder
Volltextkatalogdateien. Wenn Sie zu einem neuen Datenbanknamen
wiederherstellen, verwenden Sie die Option -m, damit die
ursprünglichen Dateien nicht überschreiben werden. Beispiel: -m
logicalfilenameS:\existingdir\newfilename.mdf
-fg
Wiederherzustellende Dateigruppe. Wiederholen Sie diese Option
für jede Dateigruppe.
-lf
Logische wiederherzustellende Datei. Wiederholen Sie diese Option
für jede logische Datei.
Tabelle 11 assqlrestore -Befehlssyntax (Fortsetzung)
Option
Beschreibung
-e
Zeigt verschlüsseltes Passwort an, wenn das unverschlüsselte
Passwort als Argument angegeben wird. Diese Option wird nicht mit
anderen Parametern verwendet.
-v
Ausführlicher Modus.
-q
Stiller Modus. Stellt keine Fragen.
-l <log_dir>
Erstellt Protokolldateien im angegebenen Verzeichnis.
-h
Hilfe.
Beispiel 2 Befehlssyntax-Beispiele
Bei den Befehlsoptionen wird Groß-/Kleinschreibung beachtet. Eine Beschreibung für TSQL finden Sie in der "SQL Server-Onlinedokumentation"
Hinweis
Die Befehlsparameter unterscheiden sich vom Replication Manager-Dienstprogramm
(rmsqlrestore)
l
Wiederherstellung mit Windows-Authentifizierung ohne Anwendung von Protokollen.
assqlrestore exe -E Administrator -P password -s sql1\instance1 d custinfo
-f "C:\AppSyncMounts\sql1\APPSYNC_VDI_INSTANCE1_ custinfo.bin" -r
RECOVERY
l
Wiederherstellung auf einen neuen Datenbanknamen und Verschieben der Dateien
mit SQL-Anmeldedaten und verschlüsseltem Passwort:
assqlrestore -s sql1\instance1
-d custinfoTest
-f "C:\AppSyncMounts\sql1\APPSYNC_VDI_INSTANCE1_ custinfoTest.bin"
-r RECOVERY
-m custinfo_Data S:\custinfoTest.mdf
-m custinfo_Log T:\custinfoTest.ldf
-U sa -p 1EMC_4roJdyU5;x
n
So erhalten Sie das verschlüsselte Passwort:
assqlrestore -e <unencrypted_password>
Wiederherstellen einer SQL Server-Datenbank mit assqlrestore
Die grundlegenden Schritte zur Wiederherstellung einer Datenbank finden Sie hier.
Möglicherweise sind weitere Schritte erforderlich. Sie können jedoch diese als ein
Framework verwenden.
Bevor Sie beginnen
Melden Sie sich als Benutzer mit Administratorrechten beim SQL Server-System an und
sichern Sie dann das SQL Server-Transaktionsprotokoll.
Vorgehensweise
1. Setzen Sie die Zieldatenbank von SQL Server in den Offline-Modus.
125
2. Stellen Sie die Datenbankdateien mithilfe von Bändern wieder her (.ldf, .ndf und .mdf)
oder kopieren Sie sie aus einem gemounteten Replikat. Sie können sie über die
ursprünglichen Dateien oder an einen neuen Speicherort kopieren.
3. Öffnen Sie ein Eingabeaufforderungsfenster und wechseln Sie auf das Verzeichnis
(cd): C:\Program Files\EMC\AppSync\Host Plug-in\
4. Führen Sie den Befehl assqlrestore aus.
Beispiele zu Befehlen finden Sie in der Befehlssyntax Assqlrestore im Abschnitt für
Beispiele. Die grundlegende Befehlssyntax lautet:
assqlrestore -s <SQLservername> -d <databasename> -f
<metadatafile> -r <recovery_type>
5. Falls erforderlich, verwenden Sie die Transaktionsprotokolle und stellen Sie die
Datenbank wieder her.
Wiederherstellen einer Datei oder einer Dateigruppe mit dem Dienstprogramm zur SQL ServerWiederherstellung
Erfahren Sie, wie eine Sie eine Datei oder Dateigruppe mit dem SQL Server
assqlrestore-Dienstprogramm wiederherstellen können.
Bevor Sie beginnen
Sie müssen nachvollziehen können, wie sich die wiederherzustellenden Dateien und
Dateigruppen in SQL Server verhalten, bevor Sie mit dem Vorgang fortfahren.
Hinweis
Sie können das assqlrestore-Dienstprogramm nicht verwenden, um eine SQL ServerDateigruppe wiederherzustellen, wenn der Name der Dateigruppe ASCII-fremde Zeichen
enthält.
Melden Sie sich als Benutzer mit Administratorrechten beim SQL Server-System an und
sichern Sie dann das SQL Server-Transaktionsprotokoll. Für eine Wiederherstellung einer
Datei oder Dateigruppe muss die Datenbank online sein.
Vorgehensweise
1. Öffnen Sie ein Eingabeaufforderungsfenster und wechseln Sie auf das Verzeichnis
(cd): C:\Program Files\EMC\AppSync\Host Plug-in\
2. Führen Sie den Befehl assqlrestore aus.
a. Wenn assqlrestore den Wiederherstellungsbefehl anzeigt, der ausgeführt
werden soll, bestätigen Sie mit , dass die Ausführung des Befehls korrekt ist.
b. Wenn assqlrestore die Eingabeaufforderung restore the files you
are recovering anzeigt, geben Sie ein, um fortzufahren.
Führen Sie zum Wiederherstellen von zwei Dateien beispielsweise den folgenden
Befehl aus:
assqlrestore -s <SQLservername> -d <databasename>
-f <metadatafile> -lf <logical_filename1>
-lf <logical_filename2> -r norecovery
Führen Sie zum Wiederherstellen von zwei Dateigruppen den folgenden Befehl aus:
assqlrestore
-s <SQLservername>
126
-d <databasename>
-f <metadatafile>
-lf <logical_filename1>
-fg <logical_filegroupname1>
-fg <logical_filegroupname2>
-r norecovery
Verwenden Sie für das Wiederherstellen einer Datei oder Dateigruppe nicht den QuietModus. Sie können -lf und -fg im selben Wiederherstellungsbefehl verwenden.
Neuverwendung von SQL Server-Datenbankkopien
In diesem Thema wird erläutert, wie die AppSync-Neuverwendungsfunktion für
Datenbank- und Lesezeichenkopien verwendet wird.
Lesen und berücksichtigen Sie die folgenden Informationen zu den
Neuverwendungsfunktionen:
l
Bei der Neuverwendung wird eine Multi-Level-Struktur von Kopien der Datenbank
erstellt.
l
AppSync identifiziert die Kopien, die von einer Neuverwendungsaktion durch eine
Anzahl von entfernten Generationen von den Produktionsquelldaten wie
beispielsweise Gen 1, Gen 2 usw. erstellt wurden.
l
Es gibt keine praktische Begrenzung der Anzahl der Generationen, die Unterstützung
ist jedoch auf zwei Generationen beschränkt, die von den Produktionsdaten entfernt
werden.
l
Eine Kopie der ersten Generation (1. Generation) erstellt eine Kopie, die als Quelle für
andere Kopien verwendet werden kann. Bei dieser Aktion wird eine Kopie der Kopie
erstellt.
l
Neuverwendungskopien sind für das Mounten für einen längeren Zeitraum für
verschiedene Zwecke vorgesehen.
l
Nach der Verwendung werden Neuverwendungskopien entweder gelöscht oder
aktualisiert.
l
Neuverwendungskopien werden bei der RPO-Berechnung nicht berücksichtigt.
l
Sie können Kopien der 1. Generation jetzt ausführen oder ihre Ausführung für einen
späteren Zeitpunkt planen.
Die Konsole zeigt alle geplanten Neuverwendungsaktionen an. Wählen Sie eine Aktion
aus und klicken Sie auf die Schaltfläche „Delete“. Die geplante Aktivität wird entfernt.
Wenn Sie Hot-Backup aktivieren, erstellt die Kopie der 1. Generation der Datenbank die
anwendungskonsistente Kopie. Diese umfasst Anwendungserkennung, Zuordnung und
Sperren/Entsperren der Datenbank. AppSync legt das Sperren/Entsperren der Datenbank
nicht standardmäßig für Neuverwendungskopien der 1. Generation fest.
Kopien der zweiten Generation (2. Generation) werden als Kopien von Kopien erstellt,
wobei die Kopie der 1. Generation als Quelle verwendet wird. Anwendungserkennung,
Zuordnung und Sperren/Entsperren der Datenbank sind nicht enthalten. Daher werden
Kopien der 2. Generation wesentlich schneller als Kopien der 1. Generation erstellt.
Hinweis
Neuverwendungskopien werden für Oracle-Datenbanken auf VNX File-Speichern oder
NFS-Dateisystemen nicht unterstützt.
Neuverwendung von SQL Server-Datenbankkopien
127
Aktualisierung der Neuverwendung
Aktualisierung bedeutet, dass die aktuelle Kopie verworfen wird (abläuft) und die Inhalte
der Kopie mithilfe der übergeordneten Kopie neu erstellt werden.
128
l
Kopien der 1. und 2. Generation können aktualisiert werden.
l
Bei der Aktualisierung einer Kopie der 1. Generation wird eine
anwendungskonsistente Kopie mit einer neuen Zeit erstellt.
l
Kopien der 2. Generation werden nicht geändert, wenn Sie die Kopie der 1.
Generation aktualisieren.
l
Bei der Aktualisierung der Kopie der 2. Generation wird die Kopie der 2. Generation
mit der übergeordneten Kopie der 1. Generation neu synchronisiert. (Verwenden Sie
diese Option, um Änderungen der Kopie der 2. Generation zu verwerfen und neu zu
beginnen).
l
Der Zeitstempel der 2. Generation ist identisch mit dem der Kopie der 1. Generation.
l
Durch die Aktualisierung ist es möglich, dass die Kopien der 1. und 2. Generation
verschiedene Zeitstempel haben.
l
Wenn Sie „Unmount Previous Copy“ bei der Erstellung der Kopie der 2. Generation
angegeben haben, führt AppSync einen Unmount-Vorgang für die Kopie durch, bevor
die neue Kopie erstellt wird.
l
Aktualisierung der Kopie der 1. Generation auf XtremIO: Erstellen Sie nur neue
Snapshots, wenn sich die Anzahl der LUNs in der Quelldatenbank ändert.
Beispielsweise verwendet AppSync die durch das XtremIO-Array bereitgestellte
Aktualisierung von Quell-LUNs, um Snapshot-Kopien der 1. Generation zu erstellen.
l
Aktualisierung der Kopie der 2. Generation auf XtremIO: Wenn Sie die Quellkopie der
1. Generation aktualisieren und sich die Anzahl der LUNs in der Quelldatenbank
geändert hat, erstellen Sie nur die neuen Snapshots. Verwenden Sie andernfalls die
vom XtremIO-Array bereitgestellte Aktualisierung von Snapshots der 1. Generation
auf Snapshot-Kopien der 2. Generation.
l
Nach der Aktualisierung führt AppSync einen Mount-Vorgang für die Kopie durch,
wenn die Kopie gemountet war.
l
Die Kopie der 2. Generation wird von der übergeordneten Kopie der 1. Generation neu
erstellt. Wenn die übergeordnete Kopie der 1. Generation nicht mehr vorhanden ist,
schlägt die Aktualisierung fehl.
l
Die Kopie der 1. Generation wird von der Anwendung neu erstellt.
l
Für die aktuelle Kopie, die Sie aktualisieren möchten, muss ein Unmount-Vorgang
durchgeführt werden (wenn sie gemountet ist). Wenn Sie Mount Copy im Assistenten
für die Neuverwendung ausgewählt haben, mountet AppSync die Kopie erneut.
Sie können eine Neuverwendungskopie jederzeit aktualisieren. So starten Sie die
Aktualisierung:
1. Von der Registerkarte Applications der AppSync-Konsole wählen Sie die
Neuverwendungskopie, die Sie aktualisieren möchten.
2. Klicken Sie auf Refresh.
Einschränkungen für die SQL Server-Neuverwendung
AppSync unterstützt die SQL Server-Neuverwendung in eigenständigen Umgebungen und
Failover-Cluster-Umgebungen mit oder ohne AlwaysOn-Verfügbarkeitsgruppen.
Die Neuverwendung von SQL Server-Kopien unterstützt die Auswahl mehrerer
Datenbanken für Neuverwendungskopien. AppSync unterstützt die Neuverwendung
mehrerer Arrays oder das dynamische Datenbankabonnement nicht. Nur für eine einzelne
Datenbank oder eine Reihe von Datenbanken, die zum gleichen Host im gleichen Array
gehören, kann die Kopie der 1. Generation erstellt werden. Die Aktualisierung funktioniert
nur für die Datenbanken, die zuvor abonniert wurden. AppSync abonniert nicht den
gesamten Benutzerdatenbank-Ordner für den Serviceplan der SQL-Neuverwendung.
Das System zeigt Neuverwendungskopien einer SQL Server-Datenbank hierarchisch an.
Das System zeigt die (übergeordnete) Kopie der 1. Generation an, und zeigt anschließend
Kopien der 2. Generation als untergeordnete Kopien der Kopie der 1. Generation an.
Hinweis
Wenn Sie XtremIO 3.x als Quelle der Kopie der 1. Generation verwenden, dann ein
Upgrade auf XtremIO 4.x durchführen und versuchen, eine Kopie der 2. Generation zu
erstellen, müssen Sie die Kopie der 1. Generation aktualisieren oder der Vorgang schlägt
fehl.
Verwenden Sie bei Bedarf den Assistenten zum Festlegen einer neuen Verwendung zur
Planung oder sofortigen Erstellung von Kopien der 1. und 2. Generation.
Bevor Sie beginnen
Sie benötigen AppSync-Administratorrechte, um für die Datenbankinstanz eine neue
Verwendung festzulegen.
129
Gehen Sie folgendermaßen vor, um die Liste verfügbarer Anwendungen anzuzeigen.
Vorgehensweise
1. Melden Sie sich bei der AppSync-Konsole an und navigieren Sie zu Copy
Management.
Option
Beschreibung
So legen Sie für eine SQL-Kopie eine neue Verwendung
fest:
Wählen Sie SQL Server aus
So legen Sie für eine Oracle-Kopie eine neue
Verwendung fest:
Wählen Sie Oracle aus
Es wird eine Liste der verfügbaren Datenbanken zur Auswahl der Anwendung geladen.
2. Klicken Sie auf die Datenbankinstanz, für die Sie eine neue Verwendung festlegen
möchten, und wählen Sie dann Repurpose aus der Drop-down-Liste unten links im
Konsolenbildschirm aus.
Mit dieser Aktion wird der Assistent zum Festlegen einer neuen Verwendung gestartet.
Sie werden zur Seite Intentions weitergeleitet, in der Sie AppSync vorgeben können,
welche Aktion Sie ausführen möchten:
l
Create First Generation copy
l
Create First Generation copy and a Second Generation copy
3. Wählen Sie den gewünschten Kopietyp aus und wählen Sie Local oder Remote in der
Drop-down-Liste der Website aus, um mit dem Erstellen der Kopie fortzufahren.
4. Klicken Sie auf Next, um den Bildschirm Settings zu starten.
Im Bildschirm Settings können Sie die spezifischen Optionen für die Kopien der 1.
und 2. Generation definieren. Sie haben insbesondere folgende Möglichkeiten:
l
Definieren von Bezeichnungen für jede Kopie zur Identifizierung des Zwecks jeder
Kopie.
l
Auswahl von anwendungsspezifischen Kopieroptionen für ausschließlich die
Kopie der 1. Generation.
l
Auswahl des entsprechenden Kopietyps (Assistent schlägt bei falsch
ausgewähltem Typ fehl).
5. Wählen Sie die gewünschten Optionen für die Kopie aus und klicken Sie dann auf
Next.
Die Seite Schedule des Assistenten wird angezeigt, sodass Sie ermitteln können,
wann die Kopie der 1. Generation erstellt werden soll. Erstellen Sie die Kopie jetzt
oder planen Sie die Kopie für einen geeigneten Zeitpunkt.
6. Wählen Sie Run now oder Run later aus, gefolgt von der Eingabe des Datums und der
Uhrzeit der Ausführung, und klicken Sie dann auf Next, um den Assistenten
abzuschließen.
Der Repurpose Monitor
Mit dem Repurpose Monitor können Sie alle derzeit ausgeführten Aktivitäten der neuen
Verwendung anzeigen und deren Fortschritt überwachen. Der Repurpose Monitor zeigt
das neu verwendete Element (Quelle) und die Bezeichnung des zu erstellenden oder zu
130
aktualisierenden Elements mit dem Anwendungstyp an. Weitere Informationen finden Sie
unter Der Repurpose Monitor auf Seite 230.
Anzeigen oder Abbrechen geplanter Neuverwendungskopien
Sie können eine geplante Neuverwendungskopie der ersten Generation anzeigen oder
abbrechen.
Vorgehensweise
1. Navigieren Sie in der Appsync-Konsole zu Application > Copy Management, und
wählen Sie dann die entsprechende Datenbank.
2. Wählen Sie Repurpose > View Scheduled Repurpose Copy, um alle geplanten
Neuverwendungsaktionen anzuzeigen.
3. Um eine Aktion zu löschen, wählen Sie eine oder mehrere gewünschte Aktionen und
klicken auf Delete, um die Aktion zu entfernen.
131
132
KAPITEL 7
Schutz von Oracle
l
l
l
l
l
l
Überblick über die Oracle-Unterstützung............................................................. 134
Schutz einer Datenbank...................................................................................... 144
Zusammenfassung von Serviceplan und -details................................................. 148
Mounten einer Oracle-Kopie................................................................................ 156
Wiederherstellen einer Oracle-Kopie................................................................... 163
Übersicht über die Neuverwendung.....................................................................172
Schutz von Oracle
133
Schutz von Oracle
Überblick über die Oracle-Unterstützung
Mit AppSync können Sie anwendungskonsistente (über den Hot-Backupmodus) und
absturzkonsistente (ohne Hot-Backupmodus) Kopien von Oracle® Datenbanken erstellen
und managen. Diese Kopien können für das Mounten (mit/ohne Recovery) und das
Wiederherstellen verwendet werden.
DieAppSync Support Matrix unter https://elabnavigator.emc.com/eln/extendedSupport
ist die maßgebliche Informationsquelle zu unterstützten Softwareprogrammen und
Plattformen..
AppSync unterstützt:
l
Oracle – eigenständige und Oracle Real Application Cluster) und unter Linux und AIX
l
Oracle-Installationen auf physischen Hosts sowie auf virtuellen Maschinen (mit
pRDMs und Vdisks) – kein Support für RDMs im virtuellen Modus
l
Oracle-Datenbanken auf NFS-Dateisystemen mit VNX-Speicher
l
Oracle-Datenbanken auf ASM-Dateisystemen
l
RMAN-Katalogisierung von Datenbanken in einem Remotekatalog
l
Neuverwendung von Oracle-Datenbankkopien Weitere Informationen finden Sie im
Thema zur Neuverwendung weiter oben in diesem Dokument.
Oracle-Berechtigungen
Diese Berechtigungen sind für AppSync für das Arbeiten mit Oracle erforderlich.
l
Root- oder Sudo-Zugriff auf den Oracle Produktions- und Mount-Server.
l
Beim Verbinden mit Oracle-Datenbanken verwendet AppSync eine BequeathVerbindung und stellt diese immer als SYSDBA her.
l
Beim Verbinden mit Oracle ASM verwendet AppSync eine Bequeath-Verbindung und
stellt diese immer als SYSASM her.
Integration von Red Hat Cluster Services mit AppSync
AppSync kann mit eigenständigen Oracle-Datenbanken eingesetzt werden, die in einer
RHCS-Umgebung (Red Hat Cluster Services) für ein Failover von Node zu Node konfiguriert
sind.
Überblick
Wenn während einer Replikation der Node, den Sie zum Erstellen eines Serviceplans
verwendet haben, nicht zugänglich ist, führt AppSync die Replikation auf einen anderen
Node im Cluster aus. Wenn der Node, den Sie zum Erstellen der ursprünglichen Kopie
verwendet haben, nicht zugänglich ist, stützt AppSync sich nicht auf die virtuelle IP für
die Oracle-Servicegruppe. Aus diesem Grund müssen Sie dafür sorgen, dass alle Nodes
im RHCS-Cluster beim AppSync-Server für die Datenbankreplikation registriert werden.
Aus Sicht der Wiederherstellung kann AppSync nur eine Wiederherstellung auf den Node
vornehmen, auf dem die Kopie ursprünglich erstellt wurde. Daher muss der ursprüngliche
Node aktiv sein, damit der Wiederherstellungsvorgang nicht fehlschlägt.
Anforderungen
Überprüfen Sie die folgenden Anforderungen für eine eigenständige Datenbank, für die
im Rahmen eines RHCS-Clusters ein Failover durchgeführt wird:
l
134
Das AppSync-Host-Plug-in muss auf allen Nodes des Clusters installiert sein.
Schutz von Oracle
l
Die IP-Ressource muss in der Oracle-Services-Gruppe für die Cluster-Datenbank
konfiguriert sein.
l
Wenn ein Failover während der Ausführung eines Replikations- oder
Wiederherstellungsprozesses erfolgt, schlägt der Vorgang fehl. Das Node-Failover
muss vor dem Ausführen des Serviceplans, vor dem Start einer Replikation oder dem
Beginn einer Wiederherstellung durchgeführt werden.
l
Die Datei Oratab muss über einen Eintrag für alle möglichen SIDs verfügen, die auf
dem angegebenen Node (passive und aktive Instanzen) ausgeführt werden können.
l
Das Paket sg3_utils, das Dienstprogramme für den Zugriff auf Geräte enthält, die
SCSI-Befehlssätze verwenden, muss auf allen Nodes installiert sein.
Überlegungen zum Mounten
l
Der Mount-Host darf nicht Teil des RHCS-Clusters sein.
l
Auf dem Mount-Host muss die gleichen Oracle-Version wie auf dem Kopier-Host
ausgeführt werden.
l
Das AppSync-Host-Plug-in muss auf dem Mount-Host installiert sein.
l
Das Paket sg3_utils, das Dienstprogramme für den Zugriff auf Geräte enthält, die
SCSI-Befehlssätze verwenden, muss auf allen Nodes installiert sein.
Überlegungen zum Wiederherstellen
l
AppSync kann nur eine Wiederherstellung auf den Node durchführen, auf dem die
Kopie ursprünglich erstellt wurde. Daher muss der ursprüngliche Node aktiv sein.
Andernfalls schlägt die Wiederherstellung fehl und die Datenbank wird beschädigt.
Die Konsole gibt vor dem Neustart der Wiederherstellung eine detaillierte
Warnmeldung hierzu aus.
l
Führen Sie zur Wiederherstellung in einer RHCS-Umgebung die folgenden Schritte
aus:
1. Führen Sie die Wiederherstellung durch.
2. Starten Sie die Mount-Instanz.
3. Führen Sie eine manuelle Recovery durch.
4. Fahren Sie die abgebrochene Datenbank herunter.
5. Aktivieren Sie die Service-Gruppe.
Unterstützung für Oracle Data Guard
AppSync unterstützt eine Oracle Data Guard-Konfiguration für eine primäre
(Quelldatenbank) und eine physische Stand-by-Datenbank (Zieldatenbank), die im
aktiven oder passiven/nicht aktiven Modus geöffnet ist.
Es gibt drei Arten von Stand-by-Datenbanken:
l
Physische Stand-by-Datenbank
l
Logische Stand-by-Datenbank
l
Snapshot-Stand-by-Datenbank
Alle drei Konfigurationen können in einem der folgenden Modi geöffnet sein:
l
Active standby mode – Stand-by-Datenbank nur im Lese- oder im Lese-/
Schreibmodus
l
Passive/non-active standby mode – Stand-by-Datenbank im gemounteten Modus
AppSync unterstützt derzeit nur die physische Data Guard-Stand-by-Konfiguration im
aktiven oder nicht aktiven Modus.
135
Schutz von Oracle
Wenn eine physische Stand-by-Datenbank im aktiven Modus geöffnet ist, kann die
Stand-by-Datenbank während der Anwendung von Protokollen nur im schreibgeschützten
Modus geöffnet werden. Mit dieser Aktion können Sie Informationen bei der Datenbank
abfragen, während Data Guard Protokolle anwendet.
Bei Snapshot- und logischen Stand-by-Konfigurationen kann die Datenbank auch im
Lese-/Schreibmodus geöffnet sein. Eine passive/nicht aktive Einstellung bedeutet, dass
die Datenbank im gemounteten Modus gestartet werden kann und Protokolle im
Hintergrund angewendet werden können.
Physische Stand-by-Datenbank
In einer Umgebung mit physischen Stand-by-Datenbanken werden Archivprotokolle
angewendet, wenn sie empfangen werden. Eine physische Stand-by-Datenbank verfügt
über eine 1:1-Zuordnung des Datei- und Speicherlayouts zwischen der primären und der
Stand-by-Datenbank. Eine physische Stand-by-Datenbank kann im schreibgeschützten
oder im gemounteten Modus geöffnet sein, was bedeutet, dass entweder eine aktive
oder eine passive/nicht aktive Konfiguration vorliegt.
Das folgende Diagramm zeigt eine typische Data Guard-Konfiguration der primären/
Stand-by-Datenbank (Quelle/Ziel):
Abbildung 14 Physische Stand-by-Umgebung
Kopienmanagement
Wechseln Sie auf der AppSync Konsole zur Seite Copy Management > Oracle. Eine Spalte
mit den Data Guard-Beziehungen wird angezeigt. Wenn Sie eine vorhandene Data GuardBeziehung haben, können Sie zwei Datenbanken anzeigen, die Teil einer Konfiguration
mit Data Guard sind. Eine Datenbank ist die primäre Datenbank und die andere ist die
physische Stand-by-Datenbank (nicht aktiv).
Beachten Sie beim Kopienmanagement die folgenden Überlegungen zu Data Guard:
136
l
Um eine primäre Data Guard-Datenbank (Quelldatenbank) zu schützen, erstellen Sie
eine Kopie wie bei jeder anderen eigenständigen Datenbank. Sie können eine HotBackup-Kopie erstellen.
l
Für den Schutz einer aktiven Stand-by-Datenbank mit Data Guard (Zieldatenbank):
Schutz im Hot-Backupmodus einer aktiven Stand-by-Datenbank ist nicht zulässig, da
sich die Stand-by-Datenbank im schreibgeschützten Modus befindet. Darüber hinaus
enthält die Stand-by-Datenbank aktuelle Archivprotokolle und ist eine exakte Kopie
der primären Datenbank, sodass zur Recovery keine Archivprotokolle kopiert werden
müssen. Sie können aber eine Kopie einer Stand-by-Datenbank ohne Hot-Backup
erstellen.
Schutz von Oracle
l
Beim Schutz einer passiven/nicht aktiven Stand-by-Datenbank mit Data Guard
(Zieldatenbank) gilt Folgendes: Eine passive/nicht aktive Stand-by-Datenbank wird
auf die gleiche Weise wie eine aktive Stand-by-Datenbank ausgeführt. Eine HotBackup-Kopie der Datenbank ist nicht zulässig. Der Unterschied ist hierbei, dass die
Kopie aus der gemounteten Datenbank erstellt wird, ohne dass die Datenbank im
Lese- oder im Lese-/Schreibmodus geöffnet wird.
l
Das Erstellen einer Kopie einer gemounteten Datenbank ist nur für eine passive/nicht
aktive Stand-by-Datenbank mit Data Guard im gemounteten Status erfolgreich.
Eigenständige Oracle-Datenbanken, die gemountet sind, können nicht geschützt
werden. Sie werden auf der Seite Database Protection der Konsole als offline
angezeigt.
Mounten und Wiederherstellen (Recovery)
Beachten Sie die folgenden Überlegungen für Mounten und Wiederherstellen mit Data
Guard:
l
Primäre Datenbank (Quelldatenbank): Mounten und Wiederherstellen funktionieren
bei einer primären Data Guard-Datenbank auf die gleiche Weise wie bei einer
eigenständigen Oracle-Datenbank. Wenn Sie zum Konfigurieren der primären
Datenbank RAC verwenden, gelten die Regeln zum Mounten/Wiederherstellen von
AppSync.
l
Aktive Stand-by-Datenbank (Zieldatenbank): Mounten und Wiederherstellen
funktionieren bei einer aktiven Data Guard-Datenbank auf die gleiche Weise wie bei
jeder anderen eigenständigen Oracle-Datenbank. Wenn die Stand-by-Datenbank mit
RAC konfiguriert wurde, gelten die RAC-Regeln zum Mounten/Wiederherstellen von
AppSync.
l
Passive/nicht aktive Stand-by-Datenbank (Zieldatenbank): Mounten und
Wiederherstellen funktionieren bei einer passiven/nicht aktiven Stand-by-Data
Guard-Datenbank wie bei jeder anderen eigenständigen Oracle-Datenbank. Wenn die
Stand-by-Datenbank mit RAC konfiguriert wurde, gelten die RAC-Regeln für Mounten/
Wiederherstellen von AppSync.
Hinweis
Wenn Sie eine primäre oder Stand-by-Datenbank mounten und wiederherstellen, wird die
Datenbank als eigenständige Oracle-Datenbank auf der Konsole angezeigt. Die früheren
Konfigurationen von Data Guard werden nicht aufbewahrt.
Neuverwenden (kopieren oder eine Kopie) von Data Guard-Datenbanken
Allgemeine Informationen zur Neuverwendung finden Sie in der AppSyncBenutzerdokumentation.
Beachten Sie bei der Neuverwendung die folgenden Überlegungen zur Data Guard:
l
Neuverwendung einer primären Datenbank (Quelldatenbank): Die Neuverwendung
einer primären Data Guard-Datenbank funktioniert auf die gleiche Weise wie bei einer
eigenständigen Oracle-Datenbank.
l
Neuverwendung einer aktiven Stand-by-Datenbank (Zieldatenbank): Die
Neuverwendung einer aktiven Data Guard-Stand-by-Datenbank funktioniert auf die
gleiche Weise wie bei jeder eigenständigen Oracle-Datenbank. Eine neu verwendete
Kopie einer Stand-by-Datenbank kann nicht per Hot-Backup gesichert werden.
l
Neuverwendung einer passiven/nicht aktiven Stand-by-Datenbank (Zieldatenbank):
Die Neuverwendung einer passiven/nicht aktiven Stand-by-Data Guard-Datenbank
funktioniert auf die gleiche Weise wie bei einer eigenständigen Oracle-Datenbank.
Eine neu verwendete Kopie einer Stand-by-Datenbank kann nicht per Hot-Backup
gesichert werden.
137
Schutz von Oracle
Wiederherstellen von Data Guard-Datenbanken
Wiederherstellung einer primären Datenbank (Quelldatenbank): Die Wiederherstellung
einer primären Data Guard-Datenbank funktioniert auf die gleiche Weise wie bei jeder
anderen eigenständigen Oracle-Datenbank. Stellen Sie die Datenbank manuell wieder
her und synchronisieren Sie dann die primären und die Stand-by-Datenbanken, wenn der
AppSync-Wiederherstellungsprozess abgeschlossen ist.
Integration von Veritas Cluster Services
AppSync kann mit eigenständigen Oracle-Datenbanken arbeiten, die für das Failover von
Node zu Node in einer VCS-Umgebung (Veritas Cluster Services) konfiguriert sind.
Einführung
Wenn der Node, der zum Erstellen des Serviceplans verwendet wurde, während eines
Replikationsvorgangs nicht zugänglich ist, führt AppSync die Replikation auf einem
anderen Node im Cluster aus. AppSync verlässt sich nicht auf die virtuelle IP für die
Oracle-Servicegruppe. Registrieren Sie daher alle Nodes im VCS-Cluster auf dem AppSync
Server, bevor Sie die Datenbank replizieren.
Aus Sicht der Wiederherstellung kann AppSync nur auf den Node wiederherstellen, auf
dem die Kopie ursprünglich erstellt wurde. Der ursprüngliche Node muss aktiv sein,
andernfalls schlägt der Wiederherstellungsvorgang fehl.
Anforderungen
Die folgenden Anforderungen gelten für die Verwendung einer eigenständigen
Datenbank, die ein Failover als Teil eines VCS-Clusters durchführt:
l
Installieren Sie das AppSync-Host-Plug-In auf allen Nodes des Clusters.
l
Konfigurieren Sie die IP-Ressource in der Oracle-Servicegruppe für eine geclusterte
Datenbank.
l
Wenn ein Failover während der Ausführung eines Replikations- oder
Wiederherstellungsprozesses erfolgt, schlägt der Vorgang fehl. Node-Failover tritt vor
der Ausführung eines Serviceplans vor dem Start einer Replikation oder einer
Wiederherstellung auf.
l
Die Datei Oratab sollte einen Eintrag für alle möglichen SIDs haben, die auf dem
angegebenen Node ausgeführt werden können (passive und aktive Instanzen).
l
Vergewissern Sie sich, dass tnsnames.ora-Dateien auf allen Nodes Einträge für
alle eigenständigen Instanzen enthalten, einschließlich der virtuellen IP-Adresse der
Oracle-Servicegruppe (laut Symantec-Dokumentation).
l
Die folgenden Dateien sollten für alle Nodes im Cluster zugänglich sein, in dem die
Datenbank ausgeführt wird:
l
n
Datenbank init/spfile
n
Passwortdatei
Auf allen Nodes das Paket sg3_utils installieren, das Dienstprogramme für alle
Nodes zum Zugriff auf Geräte enthält, die SCSI-Befehlsammlungen verwenden.
138
l
Der Mount-Host darf nicht Teil des VCS-Clusters sein.
l
Der Mount-Host erfordert die Installation von VxVM Storage Foundations 6.1 oder
höher.
l
Das Paket sg3_utils, das Dienstprogramme zum Zugriff auf Geräte enthält, die
SCSI-Befehlsammlungen verwenden, muss auf dem Mount-Host installiert sein.
Schutz von Oracle
Überlegungen zur Wiederherstellung
AppSync kann nur auf den Node wiederherstellen, auf dem die Kopie ursprünglich erstellt
wurde. Aus diesem Grund muss der ursprüngliche Node aktiv sein. Führen Sie zur
Wiederherstellung in einer VCS-Umgebung die folgenden Schritte aus:
1. Sperren Sie die Oracle-Servicegruppe: >hagrp -freeze
<service_group_name>
3. Starten Sie die Instanz.
5. Öffnen Sie die Datenbank.
6. Heben Sie die Sperrung der Oracle-Servicegruppe auf: >hagrp -unfreeze
<service_group_name>.
Hinweis
AppSync kann nur auf den Node wiederherstellen, auf dem die Kopie ursprünglich erstellt
wurde. Aus diesem Grund muss der ursprüngliche Node aktiv sein. Andernfalls schlägt
der Wiederherstellungsvorgang fehl und die Datenbank bleibt in einem beschädigten
Zustand. Die Konsole zeigt eine detaillierte Meldung an, die Sie vor diesem Szenario vor
dem Neustart der Wiederherstellung warnt.
HACMP-Clusterintegration
AppSync kann mit eigenständigen Oracle-Datenbanken arbeiten, die in einer IBM®
HACMP-Clusterumgebung für ein Failover von Node zu Node konfiguriert sind.
Einführung
AppSync schützt die Datenbank auf dem Node, auf dem der aktuelle Status vor der
Ausführung des Serviceplans aktiv ist.AppSync stützt sich nicht auf die virtuelle IP für die
Oracle-Servicegruppe. Aus diesem Grund sollten alle Nodes im HACMP-Cluster beim
AppSync-Server registriert werden, um die Datenbank zu replizieren, wenn der zum
Erstellen der ursprünglichen Kopie verwendete Node nicht zugänglich ist.
AppSync führt eine Wiederherstellung auf dem Cluster-Node durch, auf dem die Kopie
ursprünglich erstellt wurde. Der Wiederherstellungsprozess schlägt fehl, wenn der Node
während des Wiederherstellungsprozesses nicht aktiv ist.
Voraussetzungen in der HACMP-Umgebung für die Zusammenarbeit mit AppSync
Im folgenden sind die Anforderungen für den Schutz einer eigenständigen Datenbank
aufgeführt, auf die als Teil eines HACMP-Clusters ein Failover durchgeführt wird:
l
Das AppSync-Host-Plug-in muss auf allen Nodes des Clusters installiert werden.
l
Die IP-Ressource muss in der Oracle-Servicegruppe für die geclusterte Datenbank
konfiguriert werden.
l
Wenn ein Failover während der Ausführung einer Replikation oder Wiederherstellung
erfolgt, schlägt der Vorgang fehl. Das Node-Failover muss vor dem Ausführen des
Serviceplans oder bei Beginn der Wiederherstellung durchgeführt werden.
l
Die Datei Oratab muss einen Eintrag für alle möglichen SIDs haben, die auf dem
angegebenen Node (passive und aktive Instanzen) ausgeführt können.
l
Die folgenden Dateien müssen für alle Nodes in dem Cluster zugänglich sein, auf dem
die Datenbank ausgeführt wird:
n
Datenbank- init/spfile
HACMP-Clusterintegration
139
Schutz von Oracle
n
Passwortdatei
l
Der Mount-Host darf nicht Teil des HACMP-Clusters sein.
l
Das AppSync-Host-Plug-in muss auf dem Mount-Host installiert sein.
Überlegungen zur Wiederherstellung
AppSync kann nur eine Wiederherstellung auf den Node vornehmen, an dem die Kopie
ursprünglich erstellt wurde, daher muss der ursprüngliche Node aktiv sein. Führen Sie zur
Wiederherstellung in einer HACMP-Umgebung die folgenden Schritte aus:
1. Blockieren Sie die Oracle-Servicegruppe: >hagrp -freeze
<service_group_name>
3. Starten Sie die Instanz.
5. Öffnen Sie die Datenbank.
6. Heben Sie die Blockierung der Oracle-Servicegruppe auf: >hagrp -unfreeze
<service_group_name>.
Hinweis
AppSync kann nur eine Wiederherstellung auf den Node vornehmen, auf dem die Kopie
ursprünglich erstellt wurde, daher muss der ursprüngliche Node aktiv sein. Andernfalls
schlägt der Wiederherstellungsvorgang fehl und die Datenbank ist beschädigt. Die
Konsole gibt vor dem Start der Wiederherstellung eine detaillierte Warnmeldung zu
diesem Szenario aus.
Verfahren nach der Wiederherstellung in einer HACMP-Umgebung
Erfahren Sie, wie Sie manuelle Schritte einer Wiederherstellung in einer HACMPUmgebung nach einer Wiederherstellung ausführen können.
Nach der Wiederherstellung mountet ein Dateisystem auf dem Produktionshost in einem
nicht gleichzeitigen Modus. Entfernen Sie das Dateisystem aus der Ressourcengruppe,
machen Sie es zu einer gleichzeitigen Volume-Gruppe und fügen Sie diese dann wieder
der Ressourcengruppe hinzu.
Führen Sie diese Schritte auf einem aktiven Node aus:
Vorgehensweise
1. Dateisystem unmounten.
2. Führen Sie Varyoffvg aus
3. Führen Sie Varyonvg mit der Option -c aus (um den gleichzeitigen Modus zu
aktivieren)
4. Führen Sie importvg auf dem passiven Node aus.
Überprüfung:
Der Befehl lspv sollte vg im gleichzeitigen Modus auf beiden Nodes
folgendermaßen anzeigen:
node 2
hdiskpower8
hdiskpower9
140
00c2bfb0f1ee76ca
00c2bfb0f1f434e3
oradata concurrent
oralogs concurrent
Schutz von Oracle
node 1
hdiskpower18
hdiskpower19
00c2bfb0f1ee76ca
00c2bfb0f1f434e3
oradata concurrent
oralogs concurrent
5. Fügen Sie das Dateisystem dann wieder der Ressourcengruppe hinzu.
6. Überprüfen und synchronisieren Sie die Konfiguration.
Voraussetzungen und unterstützte Konfigurationen
Erfahren Sie mehr über die Voraussetzungen und unterstützten Konfigurationen für
Oracle mit AppSync. Dies umfasst Informationen über unterstützte
Gerätekonfigurationen, Oracle auf Dateisystemen, logische Volume-Manager und ASMbasierten Speicher, RecoverPoint Consistency Group-basierten Speicher, Linux- und AIXKonfigurationen, einschließlich Sudo-Benutzer, und Unterstützung für
Virtualisierungssetups.
In AppSync können anwendungskonsistente Kopien (mit Oracle-Hot-Backup) und
absturzkonsistente Kopien (ohne Hot-Backup) erstellt werden. Damit AppSync
anwendungskonsistente Kopien von Oracle-Datenbanken erstellen kann, dürfen sich die
Datendateien und die Archivprotokolle nicht im selben Dateisystem, in derselben
Volume-Gruppe, ASM-Laufwerksgruppe, RP-Consistency Group oder im selben
Datenspeicher befinden. Wenn die Oracle-Konfiguration so festgelegt ist, dass die
Datendateien und Archivprotokolle beliebige dieser Gruppierungen gemeinsam
verwenden können, kann AppSync absturzkonsistente Kopien für solche Datenbanken
erstellen.
Sorgen Sie bei VNX dafür, dass es sich bei allen Consistency Groups um VNX-Consistency
Groups handelt. Bei Verwendung von ViPR Controller stellen Sie sicher, dass alle
Consistency Groups ViPR-Consistency-Groups sind. Darüber hinaus müssen sich die
Archivprotokolldateien in einer anderen Consistency Group als der Rest der
Datenbankdateien befinden.
Oracle auf dateisystembasierten Speicherkonfigurationen
Es folgen einige Beispiele für Oracle-Konfigurationen, für die AppSync sowohl
anwendungskonsistente als auch absturzkonsistente Kopien bieten kann:
l
Einzelne Datenbank: Datenbankdateien, z. B. auf /data; Archivprotokolldateien,
z. B. auf/archive.
l
Mehrere Datenbanken, die einen einzigen Speicherort für Archivprotokolle
gemeinsam nutzen: z. B. Datenbank 1 auf /db1, Datenbank 2 auf /db2,
Archivprotokolle auf /arch.
l
Mehrere Datenbanken, die Speicherorte für Daten und Archivierungsprotokolle
gemeinsam nutzen: z. B. Dateien für Datenbank 1, 2, 3 auf /data,
Archivprotokollstandorte für Datenbank 1, 2, 3 auf /archive
l
Szenario zu betroffenen Datenbanken: Zwei Dateisysteme auf einer Volume-Gruppe
mit zwei weiteren Dateisystemen auf einer anderen Volume-Gruppe, sodass eine
Oracle-Datenbank Daten auf fs1 in vg1 und Protokolle auf fs1 auf vg2 hat und die
zweite Oracle-Datenbank Daten auf fs2 auf vg1 und Protokolle auf fs2 auf vg2 hat.
Hinweis
AppSync bietet keine Unterstützung für die folgende Konfiguration: eine OracleDatenbank mit Datendateien auf fs1 in vg1 und Protokolle auf fs1 auf vg2 und eine
zweite Oracle-Datenbank mit Datendateien auf fs2 auf vg2 hat und Protokollen auf fs2
auf vg1.
141
Schutz von Oracle
Oracle auf Speicherkonfigurationen auf der Basis von logischen Volume-Managern
(LVM/VxVM)
l
Einzelne Datenbank: Datenbankdateien auf einem Volume wie beispielsweise
datavg und dann Archivprotokolldateien in einem Volume wie beispielsweise
archvg.
l
gemeinsam nutzen: Database 1-Dateien auf einem Volume beispielsweise auf
data1vg und Database 2-Dateien auf einem Volume beispielsweise auf data2vg
und dann Archivprotokolle in einem Volume beispielsweise auf archvg.
l
Mehrere Datenbanken, die Speicherorte für Daten und Archivprotokolle gemeinsam
nutzen: Database 1, 2, 3-Dateien in einem Volume beispielsweise auf datavg und
dann Database 1, 2, 3-Archivprotokollspeicherorte in einem Volume beispielsweise
auf archvg.
Oracle auf ASM-basierten Speicherkonfigurationen
l
Einzelne Datenbank: Datenbankdateien beispielsweise auf Laufwerksgruppe +data
und dann Archivprotokolldateien beispielsweise auf Laufwerksgruppe +arch.
l
Mehrere Datenbanken, die einen einzelnen Speicherort für Archivprotokolle
gemeinsam nutzen: Database 1-Dateien beispielsweise auf Laufwerksgruppe
+data1 und Database 2-Dateien auf beispielsweise Laufwerksgruppe +data2, dann
Archivprotokolle auf beispielsweise Laufwerksgruppe +fra.
l
Mehrere Datenbanken, die einen einzelnen Speicherort für Archivprotokolle
gemeinsam nutzen: Database 1-Dateien beispielsweise auf Laufwerksgruppe
+data1 und Database 2-Dateien auf beispielsweise Laufwerksgruppe +data2, dann
Archivprotokolle auf beispielsweise Laufwerksgruppe +fra.
Oracle auf RecoverPoint Consistency Group-basiertem Speicher
l
Einzelne Datenbank: Datenbankdateien auf LUNs in einer RP Consistency Group,
beispielsweise DATACG, und Archivprotokolldateien in einer RP Consistency Group,
beispielsweise ARCHCG.
l
gemeinsam nutzen: Database 1-Dateien auf LUNs in einer RP Consistency Group,
beispielsweise DATA1CG, dann Database 2-Dateien auf LUNs in RP Consistency
Group DATA2CG und dann Archivprotokolldateien in einer RP Consistency Group,
beispielsweise ARCHCG.
l
nutzen: Database 1, 2, 3-Dateien auf LUNs in einer RP Consistency Group,
beispielsweise DATACG, dann Database 1, 2, 3-Archivprotokolle auf LUNs in einer RP
Consistency Group, beispielsweise ARCHCG.
Oracle auf Datenspeicher-basierten Speicherlayouts
142
l
Einzelne Datenbank: Datenbankdateien auf vDISKs beispielsweise aus
Datenspeicher DATADS und Archivprotokolldateien auf vDISKs beispielsweise aus
Datenspeicher ARCHDS.
l
gemeinsam nutzen: Database 1-Dateien auf vDISKs beispielsweise aus
Datenspeicher DATA1DS, dann Database 2-Dateien auf vDISKs beispielsweise aus
Datenspeicher DATA2DS und dann Archivprotokolldateien auf vDISKs beispielsweise
aus Datenspeicher ARCHDS.
Schutz von Oracle
l
nutzen: Database 1, 2, 3-Dateien auf vDISKs beispielsweise aus Datenspeicher
DATADS, dann Database 1, 2, 3Archivprotokolle auf vDISKs beispielsweise aus Datenspeicher ARCHDS.
Oracle auf VNXe-LUN-Gruppe-basiertem Speicher
Folgende Konfigurationen werden unterstützt
l
Einzelne Datenbank: Datenbankdateien auf LUNs in VNXe-LUN-Gruppen, z. B. Dateien
in LUN-Gruppe DATALUNGRP und Archivprotokolldateien in LUN-Gruppe ARCHCG.
l
gemeinsam nutzen: Database 1-Dateien beispielsweise auf LUNs in der VNXe-LUNGruppe DATA1LUNGRP, dann Database 2-Dateien auf LUNs in der VNXe-LUN-Gruppe
DATA2LUNGRP und dann Archivprotokolldateien beispielsweise in der VNXe-LUNGruppe ARCHLUNGRP.
l
nutzen: Database 1, 2, 3-Dateien beispielsweise auf LUNs in der VNXe-LUN-Gruppe
DATALUNGRP, dann Database 1, 2, 3-Archivprotokolldateien beispielsweise in der
VNXe-LUN-Gruppe ARCHLUNGRP.
Unterstützte Virtualisierungskonfigurationen
AppSync unterstützt Schutz, Mounting und Wiederherstellen von Oracle-Datenbanken auf
vDisks in eigenständigen Konfigurationen und RAC.
AppSync unterstützt keine Konfigurationen, bei denen Daten und Archivprotokolle eine
Mischung aus RDM und VDisks sind.
Überlegungen:
l
Für Oracle-Datenbanken auf VDisks auf VMs auf ESX:
n
Deaktivieren Sie das Sperrkennzeichen VMFS3hardwareaccelated auf dem
ESX, das die VMs hostet, die die Oracle-Datenbanken auf vDisks hosten.
n
Wenn die ATS-Sperre für den Datenspeicher VMFS3/5 aktiviert ist, schlägt das
Mounten des Datenspeichers mit AppSync fehl.
l
Wenn Sie SCSI-Befehle von AppSync ausführen möchten, legen Sie die Option
disk.EnableUUID auf der VM fest.
l
Stellen Sie sicher, dass Ihr VM-Datenspeicher nicht dasselbe VMFS nutzt wie Ihre
Oracle-Datenbanken
Hinweis
AppSync bietet keine Unterstützung für die folgenden Konfigurationen:
l
ASM-Datenbank auf VXVM-Volume-Gruppen
l
ASM-Datenbank auf VXDMP-Geräten
l
ASM-Datenbank auf Raw-Geräten unter Kontrolle der VXVM
l
Andere als ASM-Datenbanken auf einer nativen LVM-Volume-Gruppe auf VXDMPGeräten
Support für Oracle auf virtuellen VMware-Laufwerken
Sie können eigenständige und geclusterte Datenbanken auf virtuellen Laufwerken von
VMware in Oracle schützen, mounten und wiederherstellen.
Berücksichtigen Sie die folgenden Informationen, wenn Sie mit Oracle und virtuellen
Laufwerken von VMware arbeiten.
143
Schutz von Oracle
l
Fügen Sie dem AppSync Server für eine erfolgreiche Zuordnung den vCenter hinzu
und führen Sie eine Erkennung durch, bevor Sie den Oracle-Host hinzufügen.
Andernfalls müssen Sie den Oracle-Host nach dem Hinzufügen von vCenter erneut
erkennen.
l
Für einen erfolgreichen Schutz müssen sich Protokolldateien und Datenbankdateien
auf virtuellen Laufwerken befinden. Es kann keine Kombination aus physischen und
virtuellen Speichern geben.
l
AppSyncunterstützt nicht:
l
n
NFS-Datenspeicher
n
Schutz von Oracle-Datenbanken auf virtuellen Maschinen, die denselben
Datenspeicher verwenden
Zum Mounten und zur Recovery von Oracle in einem virtualisierten Host benötigen
Sie VMware-Berechtigungen zur Änderung der VMware-Konfiguration der Mount-VM
(Erstellen von RDM- und SCSI-Adaptern) und zum neuen Einlesen von Datenspeichern
und VMFS.
Weitere Informationen finden Sie in Oracle-vDisk-Wiederherstellung mit betroffene
Entitäten auf Seite 165.
Unterstützung für VIO vSCSI
Oracle mit AIX LPARs kann jetzt auch „virtuelle“ Verbindungen zum Speicher verwenden.
Überblick: Unterstützung für VIO vSCSI (Virtual I/O-Laufwerke)
Zuvor hat AppSync Oracle auf physischen AIX-Maschinen und auf virtuellen AIXMaschinen (LPARs) unterstützt, die physische oder NPIV-Verbindungen zu den
Arrayspeichern verwenden. AppSync unterstützt jetzt Oracle AIX LPARs mit virtuellen
Verbindungen.
Alle unterstützten Anwendungen und Anwendungsbeispiele für AIX-Hosts mit physischen
oder NPIV-Speicherverbindungen werden jetzt auch auf VIO VSCSI-Geräten unterstützt.
Zwei Einschränkungen gelten für diese Unterstützung:
l
Mounten von Replikaten muss erfolgen, um Hosts mit physischen oder NPIVSpeicherverbindungen zu mounten. Mounts können nicht als virtuelle Laufwerke
erstellt werden.
l
Der VIO-Server muss dem VIO-Client vollständige unformatierte Laufwerke zuordnen.
Logische Volumes aus dem VIO-Server dürfen nicht zugeordnet werden.
Darüber hinaus können AppSync und AIX Live Partition Mobility nebeneinander
existieren. AppSync wird Anwendungen nach der Migration von einer Clientpartition auf
einen neuen gemanagten Server weiterhin schützen und neuverwenden.
Unterstützte Versionen
Bei einer AppSync Supportmatrix werden AIX Virtual I/O-Laufwerke als ein gültiger
virtueller Festplattentyp unterstützt, der als Server-Virtualisierungslösung bekannt ist.
Schutz einer Datenbank
Sie können eine Datenbank durch Abonnieren eines AppSync-Serviceplans schützen.
Sie können Objekte auf unterschiedliche Weise und von verschiedenen Speicherorten in
AppSync schützen:
l
144
Wählen Sie Subscribe to Plan and Run aus, wenn Sie eine ausgewählte Datenbank
sofort schützen möchten. Der Serviceplan wird nur für diese Datenbank ausgeführt.
Schutz von Oracle
l
l
Wählen Sie einen entsprechenden Serviceplan unter Create copy aus. Verwenden Sie
dazu einen Plan auf der Seite Copies der Datenbank.
l
Wählen Sie auf der Seite Oracle Service Plans die Option Run aus, um den gesamten
Plan sofort auszuführen.
Erkennen von Datenbanken
Beim Erstellen, Löschen oder Umbenennen von Datenbanken müssen Sie eine Erkennung
von Datenbanken auf dem Oracle-Server ausführen, um AppSync auf dem aktuellen
Stand zu halten.
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Copy Management > Oracle, um die Seite Databases anzuzeigen.
Nur Datenbanken, die gestartet wurden und sich im geöffneten Zustand befinden,
werden auf der Seite Databases als Online-Datenbanken angezeigt. Datenbanken, die
keinen Eintrag in der /etc/oratab-Datei aufweisen sowie heruntergefahrene
Datenbanken werden nicht angezeigt.
2. Klicken Sie im Drop-down-Menü Discover Databases im unteren linken Bereich des
Bildschirms auf On Server, und klicken Sie dann auf den gewünschten Server, auf
dem sich die zu erkennende Datenbank befindet.
Abonnieren eines Serviceplans für eine Datenbank
Sie können einen Serviceplan für eine Datenbank abonnieren und den Serviceplan sofort
ausführen lassen oder die Ausführung des Serviceplans für einen späteren Zeitpunkt
festlegen.
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Copy Management > Oracle.
2. Wählen Sie eine oder mehrere Oracle-Datenbanken aus.
3. Wählen Sie unter der Pop-up-Schaltfläche Protect den entsprechenden Serviceplan
aus, zum Beispiel:
Tabelle 12 Schutzoptionen eines Serviceplans
Option
Beschreibung
Subscribe to Plan and
Run
Zum Abonnieren des Schutzes für die Datenbank und das sofortige
Ausführen des Plans für alle ausgewählten Datenbanken.
Subscribe to Plan
Zum Abonnieren des Schutzes für die Datenbank. Die Schutzfunktion
für alle Datenbanken, die Teil des Serviceplans sind, wird zur
Erkennen von Datenbanken
145
Schutz von Oracle
Abonnement eines Serviceplans für eine Datenbank beenden
Wenn Sie das Abonnement eines Serviceplans für eine einzelne Datenbank beenden,
behält AppSync alle vorhandenen Datenbankkopien bei. Es wird lediglich die weitere
Ausführung der Schutzfunktion aufgehoben.
Bevor Sie beginnen
Vorgehensweise
2. Wählen Sie die Datenbank aus, für die Sie das Abonnement eines Serviceplans
beenden möchten.
l
Wählen Sie den Plan aus, für den Sie das Abonnement beenden möchten: Protect >
Unsubscribe from Plan. In der Pop-up-Liste werden nur die Pläne angezeigt, zu
denen ein Abonnement für die Datenbank vorlag.
l
Wählen Sie zum Beenden des Abonnements für alle Servicepläne Unsubscribe
from Plan > All aus.
Oracle-Kopien-Seite
Sie können Details einer Kopie auf der Registerkarte „Copies“ des Serviceplans anzeigen.
Die Liste der Kopien kann nach Zeit der Erstellung und nach Serviceplan gefiltert werden.
Tabelle 13 Felder der Kopien-Seite
Spalte
Beschreibung
Status
l
Grün: erfolgreich
l
Gelb: mit Fehlern abgeschlossen
l
Rot: fehlgeschlagen
Name
Name der Kopie Der Name der Kopie ist die Zeit, in der AppSync sie
erstellt hat.
Service Plan
Name des Serviceplans, dem die Kopie zugeordnet ist.
Label
Bezeichnung, die der Kopie im Falle einer Neuverwendung zugewiesen ist.
Application
Consistent
l
Ja, wenn die Datenbank beim Erstellen der Kopie erfolgreich in den
Hot-Backupmodus gesetzt wurde.
l
Nein, wenn der Hot-Backupmodus in der Kopieerstellungsphase nicht
ausgewählt wurde.
l
Nein, wenn der Hot-Backupmodus ausgewählt wurde und die
Datenbank nicht in den Hot-Backupmodus gesetzt werden konnte.
Mount Status
Status der Kopie: gemountet oder nicht gemountet Wenn die Kopie
gemountet ist, wird der Name des Mount-Host angezeigt
Recovery Status
Wurde die Kopie nach dem Mounten wiederhergestellt oder nicht
Folgende Werte können verwendet werden:
l
146
Not Recovered - Kopie wurde nicht gemountet oder die Kopie war ein
Dateisystem-Mount.
Schutz von Oracle
Tabelle 13 Felder der Kopien-Seite (Fortsetzung)
Spalte
Copy Type
Beschreibung
l
Successful: Recovery war erfolgreich.
l
Failed: Recovery ist fehlgeschlagen.
l
CDP-Lesezeichen
l
CRR-Lesezeichen
l
VNX Snap, VNXeSnap
l
VMAX-Clone
l
VMAX-Snap
l
VMAX V3: SnapVXSnap, SnapVXClone
l
XtremIO Snap
l
ViPRSnap
Generation
Kopie der ersten oder zweiten Generation: für die Neuverwendung
Source
Produktionsdatenbank (für Kopie der ersten Generation) oder Kopie einer
Kopie (Kopien der zweiten Generation).
Standort
RecoverPoint-Standortinformationen.
Speichersystem
Array-Seriennummer/-Name
Anzeigen von Datenbankkopien
Gehen Sie zum Anzeigen einer Kopie der Oracle-Datenbank in der AppSync-Konsole wie
folgt vor.
Bevor Sie beginnen
Vorgehensweise
2. Klicken Sie auf eine Datenbank, um die vorhandenen Kopien der Datenbank
anzuzeigen
Sie können die Details einer Kopie unter der Registerkarte Copies des Serviceplans
anzeigen. Die Liste der Kopien kann nach Erstellungszeit und nach Serviceplan
gefiltert werden.
Erstellen Sie eine Kopie einer Datenbank durch Abonnieren eines AppSync-OracleServiceplans für diese Datenbank auf der Seite Copies.
Bevor Sie beginnen
Vorgehensweise
Oracle-Kopien-Seite
147
Schutz von Oracle
2. Klicken Sie auf eine Datenbank, um die vorhandenen Kopien anzuzeigen.
3. Wählen Sie aus der Liste Create a copy using a service plan den entsprechenden
Serviceplan aus.
Der Serviceplan wird sofort für die ausgewählte Datenbank ausgeführt.
Ablaufen lassen einer Datenbankkopie nach Bedarf
Beim Ablaufen lassen einer Datenbankkopie wird diese aus der AppSync-Datenbank
entfernt und dadurch kann je nach Replikationstechnologie und Status der Kopie
Speicherplatz freigesetzt werden.
Bevor Sie beginnen
Vorgehensweise
2. Klicken Sie auf die gewünschte Datenbank, um die Kopie ablaufen zu lassen.
lassen möchten.
Darüber hinaus können Sie diese Aktion in der Registerkarte Copies des Serviceplans
ausführen.
4. Wählen Sie Expire in der Zeile der Schaltflächen im unteren Teil des Bildschirms aus.
5. Überprüfen Sie, ob Sie die entsprechende Kopie und alle zugehörigen, ebenfalls
aufgeführten Kopien ausgewählt haben, und bestätigen Sie.
Zusammenfassung von Serviceplan und -details
Auf der Registerkarte Settings des Serviceplans finden Sie den Namen die Beschreibung,
den Zeitplan und den Status des Serviceplans.
Klicken Sie auf die Phasen für die detaillierten Serviceplaneinstellungen und weitere
Registerkarten, um Informationen zu Abonnements, Listen von Kopien und durch den
Plan generierte Ereignisse aufzurufen.
Unter Übersicht: Serviceplan auf Seite 10 finden Sie weitere Informationen zu
Serviceplan-Kopien.
Servicezeitplan
Die Planung eines Serviceplans wird in der Phase Plan Startup festgelegt. Je nach Startup
Type (geplant oder nach Bedarf) wird der Plan manuell gestartet, konfiguriert oder nach
einem Zeitplan ausgeführt wird.
Optionen für die Zeitplanung eines Serviceplans umfassen:
l
l
148
Festlegen eines Recovery Point Objective (RPO)
n
Legen Sie ein RPO von 30 Minuten oder 1, 2, 3, 4, 6, 8, 12 oder 24 Stunden fest.
n
Legen Sie die Minuten nach der vollen Stunde in 5-Minuten-Intervallen fest.
n
Das Standard-RPO beträgt 24 Stunden.
Wird täglich zu bestimmten Zeiten ausgeführt.
Schutz von Oracle
l
l
n
Wählen Sie bis zu zwei verschiedene Zeiten während des Tages aus.
n
Legen Sie die Minuten nach der vollen Stunde in 5-Minuten-Intervallen fest.
n
Es ist kein Standardwert ausgewählt.
Führen Sie den Plan zu einem bestimmten Zeitpunkt an ausgewählten Tagen der
Woche aus.
n
Sie können einen oder mehrere Tage in der Woche (bis zu sieben Tage)
auswählen.
n
Es gibt keine Standardvorgabe für den Tag der Woche. Die standardmäßige
Tageszeit ist 12:00 Uhr.
Wird zu einem bestimmten Zeitpunkt an ausgewählten Tagen des Monats ausgeführt.
n
Wählen Sie einen oder mehrere Tage im Monat aus (bis zu allen Tagen).
n
n
Der Standardwert ist der erste Tag des Monats.
Bevor Sie beginnen
Dieser Vorgang erfordert die Rolle eines Serviceplanadministrators in AppSync.
Sie können nur die Einstellungen des Wiederholungstyps außer Kraft setzen, der zuvor für
den Serviceplan ausgewählt wurde.
Vorgehensweise
Der Bereich Plan Startup Defaults wird auf der rechten Seite angezeigt.
Type festgelegt wurde.
4. Wählen Sie die Option Start service plan phase aus.
Auf der rechten Seite wird der Bereich Start service plan angezeigt.
5. Notieren Sie sich den Wiederholungstyp, der für den Plan ausgewählt wurde.
Ein Wiederholungstyp kann nur dann festgelegt werden, wenn Automatic in der Phase
Startup festgelegt wurde.
Sie können die Liste aller Datenbanken anzeigen lassen, für die der Plan abonniert
wurde.
7. Wählen Sie eine oder mehrere Datenbanken aus und klicken Sie auf Override
Schedule.
Das Dialogfeld Override Schedule wird angezeigt.
8. Legen Sie den Plan auf Grundlage Ihrer Anforderungen fest und klicken Sie dann auf
OK.
Wenn beispielsweise der Standardwiederholungstyp für die angegebenen Tage des
Monats festgelegt wurde und die Regeleinstellung auf die Ausführung am 1. Tag jedes
149
Schutz von Oracle
Monats um 24:00 Uhr festgelegt wurde, können Sie die Uhrzeit und den Tag für die
einzelnen Datenspeicher außer Kraft setzen.
Ergebnisse
Ein Bleistiftsymbol weist darauf hin, dass die Standardeinstellungen außer Kraft gesetzt
wurden.
Anwendungserkennung
Vor dem Erstellen der Datenbankkopie überprüft AppSync die Oracle-Datenbank auf dem
Host, um herauszufinden, ob etwas zur Datenbank hinzugefügt oder aus ihr entfernt
wurde, ob sie heruntergefahren wurde oder ob Änderungen am offenen Status
vorgenommen wurde.
Eine Datenbank ist nur im Status ONLINE geschützt. Das bedeutet, dass die
Datenbank(en) im Status open vorliegen muss bzw. müssen (Datenbanken im Modus
nomount oder im Modus mount und Offline-Datenbanken sind nicht geschützt).
Es sind keine Benutzereinstellungen mit dieser Phase verknüpft und die Phase kann
Anwendungszuordnung
Nach dem Erkennen der Anwendung inAppSync findet eine Zuordnung der Anwendung
zum Arrayspeicher und zu Schutzservices wie RecoverPoint statt.
Speichereinstellungen
Legt die bevorzugte Reihenfolge der zu verwendenden Speichertechnologie für das
Erstellen von Kopien fest, z. B. VNX Snapshot oder VMAX-Clone/Snap oder RecoverPointLesezeichen.
Verwenden sie die Schaltfläche Move Up und Move Down. Wann immer möglich, werden
Kopien über die erste Technologieeinstellung vorgenommen. Wenn die erste Technologie
aufgrund der vorliegenden Bedingungen nicht mehr verwendet werden kann, werden alle
verbleibenden Kopien stattdessen über die nächste Einstellung verarbeitet. Beispiel:
Wenn Ihre erste Einstellung ein Lesezeichen war, aber nicht alle Anwendungsdaten im
Serviceplan RecoverPoint zugeordnet werden konnten, verwendet AppSync stattdessen
Snap.
Hinweis
Ein einzelner Serviceplan kann eine Mischung aus Datensätzen enthalten, die auf VNX/
VMAX Block/-Datei und RecoverPoint konfiguriert wurden. Wenn Sie bei VNX
beispielsweise einen Bronze-Serviceplan für Oracle haben, können die abonnierten
Datenbanken eine Kombination aus RecoverPoint- und VNX/VMAX-Objekten sein.
Eine Datenbank-Kombination aus VNX und VMAX wird nicht unterstützt. Um eine RPLesezeichenkopie für eine Datenbank zu erhalten, müssen außerdem alle LUNs in der
Datenbank mit RecoverPoint-Schutz konfiguriert werden. Anderenfalls werden für diese
Datenbank Snap-Kopien erstellt.
Präkopieskript
Geben Sie auf der Registerkarte Settings des Serviceplans ein Präkopieskript und
Parameter an, um vor dem Erstellen einer Kopie vorbereitende Schritte durchzuführen.
150
Schutz von Oracle
Das Präkopieskript wird gemäß dem in der Phase Plan startup festgelegten Zeitplan
durchgeführt. AppSync führt dieses Skript einmal pro Host pro auf dem Produktionshost
ausgeführten Serviceplan durch.
Alle Skriptphasen sind nicht blockierend. Wenn also eine Phase fehlschlägt, wird die
Ausführung des Serviceplans nicht beendet, sondern die nächste Phase wird fortgesetzt.
Überprüfen Sie Folgendes, um eine erfolgreiche Skriptausführung zu gewährleisten:
l
Die Skriptphase ist aktiviert.
l
Das Skript ist unter dem angegebenen Pfad vorhanden. Es wird der absolute Pfad
zum Skript bereitgestellt, kein standardmäßiger Standort.
l
Es werden gültige Skriptformate verwendet: alle ausführbaren Dateien unter UNIX
werden unterstützt. Das Skript muss Ausführungsberechtigungen für den
angegebenen Benutzer erfordern.
l
Das Präkopieskript wird gemäß dem Zeitplan ausgeführt, der in der Plan StartupPhase eingestellt wurde.
l
Das Skript wird standardmäßig nur unter Windows als lokales System ausgeführt.
l
Das Skript versetzt die Datenbanken/den Tablespace nicht in den Backupmodus.
l
Das Skript fährt die Datenbank nicht herunter.
Tabelle 14 Felder der Präkopieskript-Konsole
Feld in der Benutzeroberfläche Beschreibung
Full path to script
Der vollständige Pfad zum Skriptstandort.
Script parameters
Parameter, die während der Ausführung an das Skript
übergeben werden.
Run as username
Der Benutzer, der über Ausführungsberechtigungen für das
Skript verfügt.
Password
Passwort des Benutzers.
Kopie erstellen
Die Phase Create Copy erstellt eine Kopie, die auf der im Serviceplan angegebenen
replikationsbasierten Technologie basiert.
Die Phase Create Copy gibt den Backuptyp für die Oracle-Datenbankkopie an, die
AppSync erstellt, einschließlich: Snap (VNX-Snapshot, XtremIO-Snapshots, VNX File
SnapSure, TimeFinder VP Snap), Clone (TimeFinder Clone) oder Lesezeichen
(RecoverPoint CDP/CRR/CLR).
Diese Phase legt auch den Zeitraum für den automatischen Ablauf der Kopien fest.
Es gibt drei Arten von Kopierphasen (abhängig vom verwendeten Plan):
l
Create local Copy: Für Servicepläne des Typs Bronze wird eine lokale Kopie auf dem
Produktionsspeichersystem oder am lokalen Standort erstellt. Der Kopiertyp umfasst
Folgendes:
n
Snap – VNX Snapshots, VNX File SnapSure, TimeFinder VP Snap, XtremIOSnapshot, VNX2e Advanced Snapshots, ViPR Snapshot, VMAX3 SnapVX-Snapshot
im NoCopy-Modus
Kopie erstellen
151
Schutz von Oracle
n
Clone – TimeFinder-Clone
n
Lesezeichen RecoverPoint RecoverPoint Continuous Data Protection, VMAX3
SnapVX-Snapshot im Copy-Modus
– VNX-Quellvolume, VNX-Zielvolume – virtuell und virtuell mit RollbackZugriffsmodi werden unterstützt.
– VMAX V3 mit RecoverPoint wird nicht unterstützt. VMAX V2 mit RecoverPoint
wird in 2.2.2 und höher unterstützt.
l
Create remote copy: Für Servicepläne des Typs Silber wird eine Remotekopie auf dem
Remotespeichersystem (über RemoteReplicator oder SRDF) am Remotestandort
erstellt. Der Kopiertyp umfasst Folgendes:
n
Lesezeichen – RecoverPoint RecoverPoint Continuous Remote Replication
– VNX-Quellvolume, VMAX-Zielvolume – virtuell und virtuell mit RollbackZugriffsmodi werden nicht unterstützt.
– VMAX-Quellvolume, VNX-Zielvolume – virtuell und virtuell mit RollbackZugriffsmodi werden unterstützt.
l
Create local and remote copy: Für Servicepläne des Typs Gold werden lokale und
Remotekopien erstellt. Der Kopiertyp umfasst Folgendes:
n
Snap – VNX File SnapSure
n
Clone – TimeFinder-Clone
n
Lesezeichen – RecoverPoint CLR
Der automatische Ablaufwert in der Phase Create copy eines Serviceplans gibt die
maximal gewünschte Anzahl von Snaps, Clones oder Lesezeichen an, die gleichzeitig
vorhanden sein kann.
Wenn der Wert „Always Keep x Kopien“ erreicht ist, laufen ältere Kopien ab, um Speicher
für die nächste Kopie in der Rotation freizusetzen. Fehlgeschlagene Kopien werden nicht
gezählt. Die älteste Kopie in AppSync läuft erst dann ab, wenn ein Ersatz erstellt wurde.
Wenn beispielsweise vor dem Ablaufen mindestens 7 Kopien aufbewahrt werden sollen,
läuft die älteste Kopie in AppSync erst dann ab, wenn die 8. Kopie erstellt ist. Unter den
folgenden Umständen laufen Kopien in AppSync nicht ab:
l
l
Diese Einstellung ist unabhängig von allen Einstellungen für Speicher-Policys (z. B. den
Einstellungen für die VNX-Pool-Policy in Unisphere zum automatischen Löschen der
ältesten Snapshots). Der Serviceplanadministrator sollte mit dem Speicheradministrator
zusammenarbeiten, um sicherzustellen, dass die Einstellungen für die Speicher-Policy
die festgelegte Anzahl von Snap-Kopien für diese Anwendung unterstützen.
um RecoverPoint-Kopien beim Berechnen von Rotationen zu berücksichtigen.
Hinweis
152
Schutz von Oracle
Postkopieskript
Geben Sie auf der Registerkarte Settings des Serviceplans ein Postkopieskript und
Parameter an, um eine Bereinigung oder andere Postkopieschritte nach dem Erstellen
einer Kopie durchzuführen.
Das Präkopieskript wird gemäß dem Zeitplan ausgeführt, der in der Plan Startup-Phase
eingestellt wurde. Sie können diese Phase einmal pro Host und pro
Serviceplanausführung durchführen. Wenn diese Skriptphase aktiviert ist, aber keine
richtigen Berechtigungen zu ihrer Ausführung vorhanden sind, oder wenn das Skript nicht
unter dem angegebenen Pfad vorhanden ist, schlägt die Ausführung des Serviceplans mit
einem entsprechenden Fehler fehl.
Für diesen Prozess ist die Rolle des AppSync-Datenadministrators erforderlich. AppSync
führt dieses Skript einmal pro Host pro auf dem Produktionshost ausgeführtem
Serviceplan durch.
Alle Skriptphasen sind nicht blockierend. Wenn also eine Phase fehlschlägt, wird die
Ausführung des Serviceplans nicht beendet, sondern die nächste Phase wird fortgesetzt.
Überprüfen Sie Folgendes, um eine erfolgreiche Skriptausführung zu gewährleisten:
l
Das Skript ist unter dem angegebenen Pfad vorhanden. Es wird der absolute Pfad
zum Skript bereitgestellt, kein standardmäßiger Standort.
l
Es werden gültige Skriptformate verwendet: alle ausführbaren Dateien unter UNIX
werden unterstützt. Das Skript muss Ausführungsberechtigungen für den
angegebenen Benutzer erfordern.
Tabelle 15 Felder der Postkopieskript-Konsole
Full path to script
Script parameters
Die Parameter, die während der Ausführung an das Skript
übergeben werden.
Run as username
Skript verfügt.
Password
Das Passwort des Benutzers.
Unmount previous copy
eine zuvor gemountete Kopie durch.
Eine Ausnahme bildet eine Kopie, die nach Bedarf statt nach dem Serviceplan gemountet
wurde. In diesem Fall wird kein Unmount-Vorgang für die nach Bedarf gemountete Kopie
durchgeführt.
Alle wiederhergestellten Datenbanken werden im Rahmen dieser Phase
heruntergefahren. Es sind keine Benutzereinstellungen mit dieser Phase verknüpft und
die Phase kann aktiviert oder deaktiviert werden.
Pre-Mount script
Sie können diese Phase aktivieren, wenn Sie ein Skript ausführen möchten, bevor
AppSync einen Mount-Vorgang durchführt.
Postkopieskript
153
Schutz von Oracle
Dieses Skript wird einmal pro Host pro Serviceplanausführung ausgeführt. Wenn diese
Skriptphase aktiviert ist, aber keine richtigen Berechtigungen zu ihrer Ausführung
vorhanden sind, oder wenn das Skript nicht unter dem angegebenen Pfad vorhanden ist,
schlägt die Ausführung des Serviceplans mit einem entsprechenden Fehler fehl.
Gehen Sie mit Bedacht vor, wenn Sie mehrere Mount-Hosts in einer
Serviceplanausführung verwenden. (Siehe Außer Kraft setzen von Mount-Einstellungen in
einem Serviceplan auf Seite 155. Sie müssen Same as mount host in der Option Run on
host auswählen, damit das Skript auf alle Mount-Hosts ausgeführt wird.
Tabelle 16 Beschreibungen der Felder für Pre mount script
Full path to script
Script parameters
übergeben werden.
Run as username
Benutzer, der über Ausführungsberechtigungen für das Skript
verfügt
Password
Passwort des Benutzers.
Run on host
Host, auf dem das Skript ausgeführt werden muss. Wählen
Sie Same as mount host aus, wenn mehrere Mount-Hosts
beteiligt sind.
Kopien mounten
In der Phase Kopien mounten wird die Kopie entweder gemountet oder das Mounting
aufgehoben und die Kopie wiederhergestellt. Diese Phase kann aktiviert oder deaktiviert
werden.
In den Einstellungen unter Mount Copy Defaults können Sie die Werte Mount copy oder
Mount and recover copy einstellen.
In den Einstellungen unter Mount copy können Sie den Mount-Hostwert und den MountPfad sowie den RecoverPoint-Imagezugriffstyp festlegen.
In den Einstellungen unter Mount and recover copy können Sie die Recovery-Instanz, den
Recovery-Typ und die Datenbankbenennungsdetails angeben. Andere Einstellungen
ähneln den Einstellungen unter Mount copy, wie Mount-Pfad und Imagezugriffstyp.
Wenn Sie bei der Oracle-Mountoption Mount on standalone server and prepare scripts
for Manual Recovery die Skriptphase nach Abschluss der Mountvorgänge aktivieren,
erstellt AppSync Skripts auf dem Mount-Host, den Sie zur Wiederherstellung der
Datenbank ausführen. Es gibt zwei Arten von Skripten, RMAN- und SQL. Die Skripte
werden unter /tmp/<MOUNTED_SID_NAME>/RecoveryScripts erstellt.
Beschreibung der Konsolenfelder:
154
l
Host name: In diesem Feld wird der Host angegeben, auf dem Sie die Oracle-Kopie
mounten möchten.
l
Mount to path: Der Pfad, auf dem Datenbankdateien und Dateisysteme gemountet
werden sollen. Für ASM RAC wird diese Einstellung nicht verwendetet/ignoriert.
l
Service Level Objective (SLO): Wenn Sie ein VMAX 3-Array verwenden, ist die
Einstellung Desired Service Level Objective (SLO) verfügbar. Diese Option wird im
Mount-Assistenten angezeigt und gibt die erforderlichen VMAX 3-Service-Level-Ziele
an. SLO definiert den Betriebsbereich für die Servicezeiten einer Speichergruppe.
Schutz von Oracle
l
Database name: Dieses Feld gibt das Namensformat der gemounteten Datenbank an.
Mit dem Token %DB% können Sie den ursprünglichen Datenbanknamen festlegen.
Beispiel: Mit TEST%DB% legen Sie den ursprünglichen Namen mit dem Präfix TEST
fest.
l
SID name: Dieses Feld gibt das Format für den gemounteten Instanznamen an. Mit
dem Token %SID% legen Sie den ursprünglichen Instanznamen fest. Beispiel: Mit
TEST%SID% legen Sie den ursprünglichen Namen mit dem Präfix TEST fest.
l
ASM Diskgroup: Dieses Feld gibt das Format der ASM-Laufwerksgruppe an. Mit dem
Token %DG% legen Sie den ursprünglichen Festplatten-Gruppennamen fest. Beispiel:
Mit TEST%DG% legen Sie den ursprünglichen Namen mit dem Präfix TEST fest.
l
Custom initialization parameters: Dies ist ein mehrzeiliges Feld zur Angabe von
Einstellungen, die alle ursprünglichen Datenbankeinstellungen auf der gemounteten
Datenbankkopie außer Kraft setzen. Dieses Feld ist zur Bearbeitung von Optionen wie
Speichereinstellungen nützlich.
Wenn es mehrere Datenbanken gibt, für die der gleiche Plan abonniert wurde, können Sie
verschiedene Mount-Einstellungen für jede Datenbank auswählen und damit die
allgemeinen Einstellungen außer Kraft setzen. Recovery-Einstellungen können nicht
überschrieben werden.
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Service Plans > Oracle und klicken Sie auf einen der Servicepläne
aus der Liste.
Die Liste der Server enthält alle Oracle-Hosts, für deren Datenbanken dieser Plan
abonniert wurde.
4. Wählen Sie den Server aus, für den die Einstellungen außer Kraft gesetzt werden
sollen, und klicken Sie dann auf Set Overrides.
Das Dialogfeld Override Default Mount Settings wird angezeigt.
5. Wählen Sie Optionen für die Mount-Einstellungen aus, die Sie außer Kraft setzen
möchten.
In der ersten Spalte der Zeile des Servers wird ein Bleistiftsymbol mit Ihren
geänderten Einstellungen angezeigt.
7. Klicken Sie zum Zurücksetzen eines Servers auf die Standardeinstellungen auf Use
Default Settings.
Post mount script
Sie können diese Phase aktivieren, wenn Sie ein Skript ausführen möchten, nachdem
AppSync einen Mount-Vorgang durchführt.
Dieses Skript wird einmal pro Host pro Serviceplan ausgeführt. Wenn diese Skriptphase
aktiviert ist, aber keine richtigen Berechtigungen zu ihrer Ausführung vorhanden sind,
155
Schutz von Oracle
oder wenn das Skript nicht unter dem angegebenen Pfad vorhanden ist, schlägt die
Ausführung des Serviceplans mit einem entsprechenden Fehler fehl.
Gehen Sie mit Bedacht vor, wenn Sie mehrere Mount-Hosts in einer
Serviceplanausführung verwenden. (Siehe Abschnitt „Außer Kraft setzen von MountEinstellungen in einem Serviceplan“. Sie müssen Same as mount host in der Option Run
on host auswählen, damit das Skript auf alle Mount-Hosts ausgeführt wird.
Tabelle 17 Beschreibungen der Felder für Post mount script
Full path to script
Script parameters
übergeben werden
Run as username
Skript verfügt.
Run on host
Host, auf dem das Skript ausgeführt werden muss. Wählen
Sie Same as mount host, wenn mehrere Mount-Hosts
beteiligt sind.
Unmount copy
Die finale Phase im Serviceplan führt einen Unmount-Vorgang für die Kopie durch.
Diese Phase wird deaktiviert, wenn die Phase Unmount previous copy aktiviert ist. Es
sind keine Benutzereinstellungen mit dieser Phase verknüpft.
Wenn Sie Mount-Vorgänge mit Recovery-Optionen (eigenständig, RMAN oder ClusterMount-Vorgang) in der Phase Mount copy ausgewählt haben, werden alle gemounteten
Datenbanken im Rahmen dieser Phase heruntergefahren.
Mounten einer Oracle-Kopie
Bevor Sie einen Oracle-Mountvorgang auf einem eigenständigen Server durchführen,
müssen Sie die Mount-Felder der AppSync-Konsole und ihre Bedeutungen verstehen.
Mountvorgänge
Tabelle 18 Konsolenfeldbeschreibungen
Feld
Beschreibung
Mount on Server
Der Server, auf dem die Kopie gemountet werden soll.
Mount path
Der Mount-Standardpfad lautet /appsync. Der Mount-Pfad kann auch Same
as Original Path sein. Jedoch ist diese Option nicht verfügbar, wenn der
Mount-Host = Produktionshost ist. Sie können den Mount-Standardpfad auch
ändern, z. B. /EMC statt /AppSync.
Image access
mode (during
RecoverPoint
mount)
156
l
Protokollierter Zugriff: Verwenden Sie diese Mount-Option, wenn die
Integritätsprüfung das Scannen von großen Bereichen der replizierten
Volumes umfasst. Dies ist die einzige verfügbare Option, wenn Sie auf
den Produktionshost mounten. Virtueller Zugriff mit RP-VMAX wird nicht
unterstützt.
Schutz von Oracle
Tabelle 18 Konsolenfeldbeschreibungen (Fortsetzung)
Feld
Beschreibung
l
Virtual access with roll: Bietet nahezu sofortigen Zugriff auf die Kopie,
aktualisiert jedoch auch das replizierte Volume im Hintergrund. Wenn die
replizierten Volumes am angeforderten Point-in-Time liegen, wechselt die
RPA transparent zum direkten Replikat-Volume-Zugriff, wodurch die
Verarbeitung von Prozessen mit hoher Auslastung ermöglicht wird.
Virtueller Zugriff mit Rollback wird mit RP-VMAX und RP-XtremIO nicht
unterstützt.
l
Virtual access: Bietet nahezu sofortigen Zugriff auf das Image. Diese
Option ist nicht für die Verarbeitung von Prozessen mit hoher Auslastung
vorgesehen. Virtueller Zugriff wird mit RP-VMAX und RP-XtremIO nicht
unterstützt.
Sie können eine Kopie mounten, die auf einem Produktionshost eines MultipathingGeräts erstellt wurde, und sie auf einem beliebigen Mount-Host eines MultipathingGeräts mounten. Das heißt, Sie können eine Kopie auf Block-/PowerPath-/MPIO-Geräten
erstellen und sie auf einen Mount-Host mit einer dieser Kombinationen mounten.
Stellen Sie für DMP sicher, dass Sie DMP auf dem Produktions- und dem Mount-Host
installieren.
Zusätzliche Serverinformationen
l
Bei AppSync 2.2.1 und höher können Sie einen temporären Speicherort pro UNIXHost in der AppSync-Konsole auf der Seite „Servers“ konfigurieren.
n
AppSync verwendet den festgelegten temporären Speicherort während der OracleMount-Vorgänge für die Speicherinformationen, die sich vorher in /tmp/<SID>/
befanden.
n
/tmp/ ist der temporäre Standardspeicherort, sofern Sie nichts anderes angeben.
Auf der AppSync-Konsole können Sie einen Mount-Vorgang für eine Kopie mithilfe des
Assistenten zum Mounten von Oracle ausführen.
Bevor Sie beginnen
Vorgehensweise
1. Wählen Sie auf der Seite Databases die Optionen Recover > Mount a Copy aus.
Es wird eine Liste der Oracle-Datenbankinstanzen angezeigt.
2. Wählen Sie auf der Seite Copies eine Kopie aus und klicken Sie auf Mount.
Der Assistent zum Mounten von Oracle wird gestartet.
3. Verwenden Sie die Filter Copies oder Service Plan oder Type , um die Kopie
auszuwählen, die Sie mounten möchten.
Die Liste wird basierend auf den ausgewählten Filtern aktualisiert.
4. Wählen Sie die Kopie aus, die Sie mounten möchten. (Bei einer RecoverPoint-Kopie
haben Sie auch die Möglichkeit, ein Lesezeichen auszuwählen, das auf einem
bestimmten Zeitraum basiert. Vergewissern Sie sich jedoch, ob eine Kopie in AppSync
157
Schutz von Oracle
vorhanden ist.) Wählen Sie die Kopie aus und klicken Sie auf Mount, um den
Assistenten Mount Copy of Oraclezu starten.
5. Klicken Sie auf Select a point in time, um eine Kopie mit einem bestimmten
Uhrzeit der Konsole. Wenn sich die Konsole in einer anderen Zeitzone als die
6. Wählen Sie auf der Seite Mount Options unter der Drop-down-Liste Mount operation
eine der folgenden Optionen aus: Mount on standalone server, Mount on standalone
server and create RMAN catalog entry, Mount on standalone server and recover,
Mount on standalone server and prepare scripts for manual recovery oder Mount on
grid cluster and recover as RAC database.
Wenn Sie Mount on standalone server and recover, Mount on standalone server and
prepare scripts for manual recovery oder Mount on grid cluster and recover as RAC
database mit offenem Lese-/Schreibzugriffsmodus für Recovery auswählen, wird die
Option Create TempTable Space aktiviert. Diese Option dient zum Erstellen des TEMP
TableSpace auf der über Recovery gemounteten Datenbankkopie. Nachdem Sie Create
TEMP TableSpace ausgewählt haben, zeigt AppSync zwei weitere Optionen an:
a. Anzahl der TEMPFILES': Anzahl der zu TEMP TableSpace hinzuzufügenden Dateien.
Dabei wird die Größe für jede Datei in der Option „Size of each file“ festgelegt.
b. Die size_clause gibt eine Anzahl von Byte, Kilobyte (KB), Megabyte (MB),
Gigabyte (GB), Terabyte (TB), Petabyte (PB) oder Exabyte (EB) an. Mit der
size_clause können Sie die Menge des Speicherplatzes auf Festplatten oder
im Arbeitsspeicher festlegen, z. B. 10 M. Die Größe der TempTable Space
entspricht der Temp-Tabellendatei, die mit der Größe der einzelnen Dateien
multipliziert wird. Wenn zum Beispiel die Anzahl der Temp-Tabellendateien 2
beträgt und die Größe jeder Datei 10 MB, dann beträgt die Speicherplatzgröße von
TempTable 20 MB.
AppSync erzeugt den Namen des TempTable Space in Form von
<DBNAME>_TEMP. Dieser neu erstellte TableSpace wird als Standard-TEMP
TableSpace der gemounteten Datenbankinstanz festgelegt. Während des UnmountVorgangs legt AppSync den erstellten TEMP TableSpace ab.
Hinweis
l
Beim manuellen Recovery-Mounten werden Skripte zur Erstellung
('Step-5_createTempTableSpace.sql') und zum Ablegen
('Step-6_dropTempTableSpace.txt') von TEMP TableSpace bereitgestellt. Sie
sollten den erstellten TEMP-TableSpace manuell ablegen, bevor Sie eine Kopie mit
AppSync unmounten.
l
Falls das Ablegen des TEMP Tablespace durch AppSync während des UnmountVorgangs fehlschlägt und ein Wiederherstellungsvorgang mithilfe dieser Kopie
ausgeführt wird, wird der Tablespace wiederhergestellt.
l
Wenn Sie versuchen, eine RecoverPoint-Kopie wiederherzustellen, wird der TEMPTableSpace, falls er während des Mount-Vorgangs mit Recovery erstellt wurde,
ebenfalls in der Produktion wiederhergestellt. Sie müssen den TEMP TableSpace
manuell aus der gemounteten Datenbankkopie ablegen und dann eine
Wiederherstellung starten.
7. Überprüfen Sie die Mount- und Recovery-Standardeinstellungen und nehmen Sie bei
Bedarf Änderungen vor.
158
Schutz von Oracle
Bei VMAX 3-Arrays steht Ihnen eine SLO-Drop-down-Liste zur Verfügung. Sie können
das Service-Level-Ziel (Service Level Objective, SLO) für die Mount-Kopie auswählen.
Wenn eine Speichergruppe für den Mount-Host mit der gewünschten SLO vorhanden
ist, fügt AppSync die LUN zur Speichergruppe hinzu. Wenn diese Speichergruppe
nicht vorhanden ist, fügt AppSync die LUN zu einer Speichergruppe hinzu, die
gegenüber dem Host maskiert ist. Wenn eine Speichergruppe zur Auswahl von
Zielgeräten konfiguriert ist, entfernt AppSync die Geräte aus der Speichergruppe zum
Zeitpunkt des Mountens und fügt sie der Speichergruppe für den Mount-Host hinzu.
Die Geräte werden der ursprünglichen Speichergruppe hinzugefügt, wenn die Kopie
abgelaufen ist. Nachfolgend finden Sie ein Beispiel für das SLO-Menü:
Abbildung 15 Wählen Sie für VMAX3™ SLO aus.
8. Klicken Sie auf Next, um die Seite Summary anzuzeigen.
9. Überprüfen Sie die Mount-Einstellungen und klicken Sie auf Finish, um den MountVorgang abzuschließen.
10. Auf der Seite Results können Sie den Fortschritt der verschiedenen Phasen
nachverfolgen, die zum Mounten einer Kopie gehören.
Die zuletzt abgeschlossene Phase wird unten in der Liste angezeigt.
RMAN-Katalogisierungsfunktion
Dieser Abschnitt enthält die Voraussetzungen und Einschränkungen für die Erstellung
von RMAN-Katalogeinträgen und für das Kopieren von BCT-Dateien.
Mount-Vorgang: Auf eigenständigen Server mounten und RMAN-Katalogeintrag erstellen
Tabelle 19 Konsolenfeldbeschreibungen
Feld in der
Benutzeroberfläche
Beschreibung
RMAN user
Katalogeigentümer
RMAN-Katalogisierungsfunktion
159
Schutz von Oracle
Tabelle 19 Konsolenfeldbeschreibungen (Fortsetzung)
Feld in der
Benutzeroberfläche
Beschreibung
RMAN password
Passwort des Katalogeigentümers
RMAN connect string
Das für die Verbindung mit dem Remote-RMAN-Katalog
verwendete TNS-Alias
TNS_ADMIN
Pfad der tnsnames.ora-Datei, in der das TNS-Alias angegeben
ist. (Standardpfad: $ORACLE_HOME\network\admin\)
ORACLE_HOME
ORACLE_HOME-Pfad für die Oracle-Binärdateien.
Standardwert: Der gleiche Wert wie der Produktionshost
ASM Diskgroup Name
Geben Sie ein Präfix oder Suffix zur Umbenennung der
Festplattengruppen auf dem Mount-Host oder % DG % an
(wenn der Produktionsname der ASM-Festplattengruppe beim
Mounten verwendet werden soll). Standardwert: APS%DG%
Skip Data Files
Überspringen der Katalogisierung von DatenbankDatendateien. Standardwert: Nicht ausgewählt
Hinweise zu den Voraussetzungen
l
Die RMAN-Katalog-Datenbank muss vorhanden und im selben Netzwerk wie der
Mount-Host zugänglich sein.
l
Die tnsnames.ora-Datei auf dem Mount-Host muss einen TNS-Alias enthalten, der
auf die RMAN-Katalog-Datenbank verweist, in der EMC AppSync die Kopie
katalogisieren sollte.
l
Der Katalog und der Katalogeigentümer müssen vor dem Mounten einer Kopie zur
Katalogisierung erstellt werden.
l
Die Produktionsdatenbank muss im RMAN-Katalog vor dem Mounten der Kopie
registriert werden.
l
Die Oracle-Version, die die RMAN-Katalog-Datenbank ausführt, muss gleich oder
höher als die höchste Oracle-Version aller Produktionsdatenbanken sein, die in
diesem Katalog registriert sind.
l
Kopien, die mit RMAN-Integration gemountet wurden, können nicht über die Option
zum Umbenennen der Datenbank umbenannt werden. Das bedeutet auch, dass nur
eine Kopie pro Datenbank auf einem Mount-Host zur RMAN-Katalogisierung
gemountet werden kann und dass Mount to Original Host nicht möglich ist.
l
Mit Lesezugriff gemountete Kopien können nicht mit RMAN katalogisiert werden.
l
Die Datenbank muss in den Hot-Backupmodus versetzt werden.
l
Create backup controlfile muss in der Phase Create Copy ausgewählt werden.
Auf eigenständigem Server mounten und Skripte für eine manuelle Recovery
vorbereiten
Diese Aktion setzt die Mounteinstellungen auf einem Serviceplan außer Kraft. Dieser
Abschnitt enthält die Voraussetzungen und Details für ein eigenständiges Mounten einer
Oracle-Kopie für die Verwendung mit manuellen Recovery-Schritten anhand eines Skripts.
160
Schutz von Oracle
l
Mount to server: In diesem Feld geben Sie den Host an, auf dem die Oracle-Kopie
gemountet werden soll.
l
Mount to path: Der Pfad, auf dem Datenbankdateien und Dateisysteme gemountet
werden sollen. Für ASM RAC wird diese Einstellung nicht verwendetet/ignoriert.
l
Mit dem Token %DB% legen Sie den ursprünglichen Datenbanknamen fest. Beispiel:
Wenn Sie den ursprünglichen Namen mit dem Präfix TEST festlegen möchten,
verwenden Sie TEST%DB%.
l
SID name: Dieses Feld gibt das Format für den Namen der gemounteten Instanz an.
Mit dem Token %SID% legen Sie den ursprünglichen Instanznamen fest. Beispiel:
verwenden Sie TEST%SID%.
l
Token %DG% legen Sie den ursprünglichen Laufwerksgruppennamen fest. Beispiel:
verwenden Sie TEST%DG%.
l
Custom initialization parameters: Dies ist ein mehrzeiliges Feld zum Festlegen der
Einstellungen, die alle ursprünglichen Datenbankeinstellungen auf der gemounteten
Datenbankkopie außer Kraft setzen. Dies ist zum Bearbeiten von Optionen wie
Wenn die Mountvorgänge abgeschlossen sind, erstellt AppSync Skripte auf dem MountHost, den Sie zur Wiederherstellung der Datenbank ausführen müssen. Bei den Skripten
handelt es sich um RMAN- und SQL-Skripte. Die Skripte werden in /tmp/
<MOUNTED_SID_NAME>/RecoveryScripts erstellt. Die Skriptdateien werden
Step-<number>_<operation>.<extension> benannt. <number> steht für die
Datei, die zuerst ausgeführt werden muss usw. <operation> gibt an, welchen Vorgang
das Skript ausführt.. <extension> gibt den Typ des Skripts an, entweder RMAN oder
SQL. Je nach Typ des Skripts führen Sie es in RMAN oder über SQLPlus aus. Unten finden
Sie die generierten Dateinamen:
Step-1_DatabaseRename.sql
Step-1_DatabaseFileRename.sql
Step-2_RecoverDatabase.rman
Step-3_RecoverDatabase.sql
Step-4_OpenDatabase.sql
Je nachdem, ob der Recoveryprozess mit dem Namen der Produktions-SID oder einem
geänderten SID-Namen durchgeführt wurde, wird nur eine Step-1-Datei erstellt. Gehen
Sie als Oracle-Benutzer folgendermaßen vor, um die Skripte auszuführen:
1. Exportieren Sie die Oracle-SID als die SID, die während der Recovery verwendet
wurde.
2. Wenn Sie ein SQL-Skript ausführen, melden Sie sich bei SQLPlus unter Verwendung
von sqlplus / als sysdba an. Sie können das Skript dann ausführen: @/tmp/
<MOUNTED_SID_NAME>/RecoveryScripts/Step<number>_<operation>.sql
3. Beim Ausführen eines RMAN-Skripts melden Sie sich mit rman target=/ bei
RMAN an. Sie können das Skript dann als @/tmp/<MOUNTED_SID_NAME>/
RecoveryScripts/Step-<number>_<operation>.rman ausführen.
Auf eigenständigem Server mounten und Skripte für eine manuelle Recovery vorbereiten
161
Schutz von Oracle
Hinweis
Stellen Sie sicher, dass Sie die Reihenfolge dieser Schritte während der Recovery
befolgen.
Auf Cluster mounten und wiederherstellen
Dieser Abschnitt enthält Voraussetzungen und Details für das Mounten einer Kopie, die
eine Oracle RAC-Datenbank enthält, als RAC-Datenbank auf einem anderen Cluster oder,
wenn umbenannt, zurück im selben Cluster. Die Einstellungen hierfür lauten wie folgt:
l
Mount to cluster: In diesem Feld geben Sie das Cluster an, auf dem die Kopie
gemountet werden soll. Alternativ kann es sich um das ursprüngliche Cluster
handeln, das zurück auf das Produktionscluster gemountet werden soll.
l
Mount to servers: Sie können eine Teilmenge von Nodes aus dem ausgewählten
Cluster oder alternativ alle Nodes im Cluster auswählen, die AppSync hinzugefügt
wurden.
Hinweis
AppSync führt nur einen Mountprozess auf Cluster-Nodes durch, die registriert
wurden. Nicht registrierte Nodes werden nicht verwendet.
l
Mount to path: Ignorieren Sie diese Einstellung für ASM RAC.
l
Mit dem Token %DB% legen Sie den ursprünglichen Datenbanknamen fest. Beispiel:
verwenden Sie TEST%DB%.
l
SID name: Dieses Feld gibt das Format für den Namen der gemounteten Instanz an.
Mit dem Token %SID% legen Sie den ursprünglichen Instanznamen fest. Beispiel:
verwenden Sie TEST%SID%.
Hinweis
Für RAC-Mounts erhält jeder Node im Cluster einen eindeutigen Instanznamen mit
einer anschließenden Ziffer.
l
Token %DG% legen Sie den ursprünglichen Laufwerksgruppennamen fest. Beispiel:
verwenden Sie TEST%DG%.
l
Custom initialization parameters: Dies ist ein mehrzeiliges Feld zum Festlegen von
Einstellungen, die alle ursprünglichen Datenbank-Einstellungen auf der gemounteten
Datenbankkopie außer Kraft setzen. Dies ist zum Bearbeiten von Optionen wie
Mounten und Unmounten von VMAX 3-Kopien
Mount-/Unmount-Vorgänge auf VMAX 3 umfassen das Masking/Unmasking von LUNs
oder einer Gruppe von LUNs für einen Host. AppSync stützt sich auf die AutoProvisioning-Funktion von VMAX 3.
Der Mount-Host muss dem VMAX 3-Array per Zoning zugewiesen werden. Als Nächstes
können Sie eine Masking-Ansicht mit der entsprechenden Initiatorgruppe, Portgruppe
und Speichergruppe erstellen.
162
Schutz von Oracle
Wenn AppSync einen Mount-Vorgang auf VMAX 3 ausführt, erkennt es zuerst den
Hostinitiator für den Mount-Host und ordnet dann basierend auf diesem Hostinitiator
AppSync der Masking-Ansicht zu (oder entfernt die Zuordnung). Dieser Vorgang
bestimmt, in welcher Speichergruppe die Ziel-LUNs maskiert/demaskiert werden. Beim
Mounten/Unmounten von RDM oder Vdisk identifiziert AppSync die Masking-Ansicht, die
auf dem Hostinitiator für den ESX-Server basiert.
Sie können das erwünschte Service-Level-Ziel (SLO) für die Ziel-LUN in der Mount-Phase
des Serviceplans auswählen. Wenn eine Speichergruppe für den Mount-Host mit der
gewünschten SLO vorhanden ist, fügt AppSync die LUN zur Speichergruppe hinzu. Wenn
diese Speichergruppe nicht vorhanden ist, fügt AppSync die LUN einer Speichergruppe
hinzu, die für den Host maskiert ist.
Wenn eine Speichergruppe zur Auswahl von Zielgeräten konfiguriert ist, entfernt AppSync
die Geräte aus der Speichergruppe zum Zeitpunkt des Mount-Vorgangs und fügt sie der
Speichergruppe hinzugefügt, wenn die Kopie abgelaufen ist.
Wiederherstellen einer Oracle-Kopie
Sie können eine Wiederherstellung einer Oracle-Kopie mithilfe des Assistenten zum
Wiederherstellen von Oracle auf der AppSync-Konsole ausführen.
Bevor Sie beginnen
Hinweis
Bei AppSync 2.2.2 und höher sowie XtremIO 4.0 und höher ist die Schaltfläche Restore
im Assistenten für die automatische Wiederherstellung aktiviert. Wenn Sie zwei Kopien
wiederherstellen, eine für XtremIO 3.x und eine weitere für XtremIO 4.0, stellt AppSync
lediglich die 4.0-Kopie wieder her (Warnung für 3.x-Kopie wird angezeigt).
Vorgehensweise
1. Klicken Sie auf der AppSync-Konsole auf die Registerkarte Copy Management und
wählen Sie dann Oracle aus der Drop-down-Liste aus.
Es wird eine Liste der Oracle-Datenbankinstanzen angezeigt.
2. Wählen Sie eine Datenbank aus, um die Seite Copies Page für die ausgewählte
Oracle-Datenbank zu öffnen, in der eine Liste der verfügbaren Kopien mit Datum der
Kopie angezeigt wird.
3. Wählen Sie die gewünschte Kopie aus und klicken Sie dann auf Restore, um den
Assistenten Oracle Restore zu starten.
Sie erhalten möglicherweise die folgende Warnmeldung: You are attempting
to perform a restore on a cluster. Please follow the
instructions in the AppSync documentation for specific
cluster restore procedures.
4. Wählen Sie die wiederherzustellende Kopie aus und klicken Sie dann auf Next.
Die Seite Restore Options wird angezeigt.
5. Klicken Sie in die Drop-down-Liste Restore und wählen Sie eine der folgenden
Optionen zum Wiederherstellen aus: Data,Archive logs oder Both Data and Archive
logs.
Falls sich die wiederherzustellende Datenbank auf alle anderen Datenbanken
auswirkt, erhalten Sie möglicherweise eine Warnmeldung im Hinblick auf die
betroffene Einheit.
Wiederherstellen einer Oracle-Kopie
163
Schutz von Oracle
6. Klicken Sie auf Next, um die Seite Summary anzuzeigen.
7. Überprüfen Sie Ihre Einstellungen zur Wiederherstellung und klicken Sie auf Finish,
um die Wiederherstellung abzuschließen.
Auf der Seite Results können Sie den Fortschritt der verschiedenen Phasen
mitzuverfolgen, die zur Wiederherstellung einer Kopie gehören.
Ergebnisse
Appsync zeigt nur Warnungen bezüglich der Wiederherstellung für durch AppSync
erkennbare Datenbanken an, die für diesen Host üblich sind. Es werden keine
Warnungen für Datenbanken angezeigt, die entweder für den Host nicht üblich oder nicht
erkennbar sind.
Weitere Informationen finden Sie auch unter Wiederherstellen einer RAC-Kopie auf Seite
165.
Von der Wiederherstellung betroffene Einheiten
weitere als die von Ihnen ausgewählten Elemente wiederherzustellen.
Eine betroffene Einheit sind Daten auf dem Produktionshost, die aufgrund ihrer Nähe zu
den Daten, die geschützt werden sollen, unbeabsichtigt Teil eines Replikats werden. Sie
können dies vermeiden, indem Sie Ihr Datenlayout ordnungsgemäß auf Grundlage der
Replikatgranularität planen. Die Granularität eines Replikats hängt von der Umgebung ab.
Bei Oracle kann es sich bei einer betroffenen Einheit um eine oder mehrere andere
Datendateien in der Oracle-Datenbank oder um Archivprotokolle handeln. Sie können bei
der Wiederherstellung eine von drei Optionen auswählen. Dadurch wird die Ebene
festgelegt, bis zu der die betroffene Entitäten bestimmt werden.
l
Nur Daten
l
Nur Archivprotokolle
l
Daten und Archivprotokolle
Die betroffenen Einheiten werden nur gemäß der Wiederherstellungsoption angezeigt.
Wenn Sie Data auswählen, sucht Appsync nach betroffenen Einheiten in Bezug auf die
Datei- und Speichersysteme für Oracle-Datenbank-Daten. AppSync verwendet zur
Überprüfung von betroffenen Einheiten keine gespeicherten Archivprotokolle für OracleDatenbanken.
Wenn Sie Archive logs auswählen, gilt das Gegenteil. Zum Überprüfen von betroffenen
Einheiten werden nur die Datei- und Speichersystem für OracleDatenbankarchivprotokolle verwendet, nicht die Dateisysteme für OracleDatenbankdaten.
Wenn Sie sowohl Data als auch Archive logs auswählen, werden die Datei- und
Speichersysteme aus den Oracle-Datenbankdaten und den Archivprotokollen zur
Überprüfung betroffener Einheiten verwendet.
Wenn betroffene Einheiten in der zugrunde liegenden Speicherkonfiguration vorhanden
sind, werden Sie im Wiederherstellungsassistenten auf diese Einheiten hingewiesen. In
den folgenden Szenarien ergeben sich betroffene Einheiten, für die Sie bestätigen
müssen, dass zusätzliche Elemente wiederhergestellt werden:
164
l
Wenn sich die Datenbanken bei RecoverPoint und ViPR Controller in derselben
Consistency Group befinden, werden sie zu betroffenen Einheiten, wenn die andere
Datenbank geschützt ist.
l
Wenn sich die Datenbanken bei VNX, VNXe, VMAX, XtremIO und ViPR Controller auf
derselben LUN befinden, werden sie zu betroffenen Einheiten, wenn die andere
Schutz von Oracle
Datenbank geschützt ist. Wenn die Datenbanken bei VNXe in derselben LUN-Gruppe
sind, werden sie zu betroffenen Einheiten, wenn die andere Datenbank geschützt ist.
l
Wenn die Datendateien bei vDISK/Datenspeicher aus zwei Datenbasen stammen, gilt
Folgendes: DB1 und DB2 befinden sich auf Datenspeicher [DS1] bzw. die
Archivprotokolle derselben beiden Datenbanken befinden sich auf Datenspeicher
[DS2], sodass beide zu betroffenen Einheiten werden.
Wenn die betroffene Einheit zusammen mit der für die Wiederherstellung ausgewählten
Oracle-Datenbank geschützt wurde, wird sie durch AppSync wiederhergestellt. Alle
anderen Oracle-Datenbanken, die nicht geschützt waren, aber betroffene Einheiten sind,
werden überschrieben
AppSync berechnet die betroffenen Einheiten für die Consistency Groups, LUN-Gruppen
oder LUNs von der Oracle-Datenbank, die zur Wiederherstellung ausgewählt ist. Wenn
sich die betroffenen Datenbanken teilweise auf anderen Consistency Groups, LUNGruppen oder LUNs befinden, berechnet AppSync die betroffenen Einheiten auf diesen
Consistency Groups, LUN-Gruppen oder LUNs nicht.
Betroffene Einheiten werden auf Basis der Wiederherstellungsgranularität berechnet.
Wenn Daten und Protokolle zur Wiederherstellung ausgewählt sind, werden betroffene
Einheiten für alle Consistency Groups, LUN-Gruppen oder LUNs berechnet, auf denen sich
die Datenbank befindet. Wenn nur die Wiederherstellung von Daten oder Protokollen
ausgewählt ist, werden die betroffenen Einheiten nur für die Consistency Group, LUNGruppe, LUN oder den Datenspeicher der ausgewählten Komponente berechnet.
Wenn sich die Datenbankdaten und die Protokolldateikomponenten auf derselben
Consistency Group oder LUN befinden, ist die Option, nur Protokolle oder nur Daten
wiederherzustellen, nicht verfügbar. Sie haben nur die Option, Daten und Protokolle
wiederherzustellen. Die einzige Ausnahme für dieses Szenario ist, wenn Sie auswählen,
eine differenzielle Kopiewiederherstellung durchzuführen.
Vdisk-Wiederherstellung mit betroffenen Entitäten
Überprüfen Sie diese Informationen für eine Vdisk-Wiederherstellung mit betroffenen
Entitäten.
l
Wenn es während der Wiederherstellung betroffene Datenbanken auf virtuellen
Laufwerken gibt, die nicht durch AppSync geschützt sind, fahren Sie diese
Datenbanken einschließlich alle nicht gemounteten Dateisysteme herunter.
Entfernen Sie darüber hinaus Vdisks aus VM, bevor Sie mit der LUN-LevelWiederherstellung fortfahren.
l
Wenn sich betroffene Datenbanken auf Volume- oder Festplattengruppen befinden,
dann führen Sie einen Deport- und Unmount-Vorgang für die Volume- oder
Festplattengruppen vor der Wiederherstellung durch und importieren und mounten
sie dann manuell nach der Wiederherstellung. (Da Appsync diese Entitäten nicht
steuert, kann eine LUN-Wiederherstellung nach dem Speichern beim Importieren/
Mounten der betroffenen Volume- und Festplattengruppen auf dem Produktionshost
fehlschlagen.)
l
Datenbanken betroffener Entitäten auf Vdisks mit VG oder ASM werden nicht
unterstützt.
Wiederherstellen einer RAC-Kopie
Führen Sie dieses Verfahren aus, um eine RAC-Kopie wiederherzustellen.
Bevor Sie beginnen
Führen Sie auf Remote-Nodes die folgenden Schritte aus:
Vdisk-Wiederherstellung mit betroffenen Entitäten
165
Schutz von Oracle
1. Fahren Sie alle betroffenen Datenbanken als Oracle-Benutzer herunter: oracle>
srvctl stop instance -d <RACDB> -i <DbInstanceOnRemoteNodes>
2. Unmounten Sie alle betroffenen ASM-Laufwerksgruppen als Rasterbenutzer: grid>
asmcmd umount <DG>
Führen Sie auf dem Wiederherstellungs-Node die Wiederherstellung aus. Führen Sie die
Vorgehensweise
1. Navigieren Sie auf der AppSync-Konsole zu Copy Management > Oracle.
2. Wählen Sie die gewünschte Datenbank aus und klicken Sie dann im Drop-down-Menü
in der unteren Mitte des Bildschirms auf Recover und wählen Sie Restore aus.
Der Oracle-Wiederherstellungsassistent wird gestartet.
3. Wählen Sie auf der Seite Select Copy die wiederherzustellende Kopie aus und klicken
Sie dann auf Next.
4. Wählen Sie unter Restore Options die gewünschte Option aus und klicken Sie dann
auf Next.
Die Seite Summary wird geöffnet.
5. Überprüfen Sie Ihre Wiederherstellungsaktionen und klicken Sie auf Finish.
6. Überprüfen Sie, ob die ausgewählte Datenbank heruntergefahren wird.
7. Überprüfen Sie die Nachricht, dass der Unmount-Vorgang für die Laufwerksgruppen
und Geräte ausgeführt wird.
8. Überprüfen Sie, ob die Wiederherstellung erfolgreich war.
Ergebnisse
Nach der Wiederherstellung:
1. Mounten Sie die Laufwerksgruppen erneut auf den Remote-Nodes als
Rasterbenutzer: grid> asmcmd mount <DG>.
2. Führen Sie auf einem beliebigen Node eine Recovery der wiederhergestellten
Datenbank mithilfe von Redo oder mit Archive with resetlogs aus:
Oracle > startup mount
Oracle > recover database
3. Öffnen Sie die Datenbank auf dem Recovery-Node:
Oracle > alter database open
4. Starten Sie die Instanzen auf den zusätzlichen Nodes:
srvctl start instance -d <RACDB> -i <DbInstanceOnRemoteNodes>
Wiederherstellen einer RAC-Kopie für betroffene Entitäten
So erstellen Sie Ihre Wiederherstellung:
Bevor Sie beginnen
Führen Sie auf Remote-Nodes die folgenden Schritte aus:
1. Fahren Sie alle betroffenen Datenbanken als Oracle-Benutzer herunter: oracle>
srvctl stop instance -d <RACDB> -i <DbInstanceOnRemoteNodes>
2. Fahren Sie andere betroffenen Datenbanken herunter: oracle>srvctl stop
database -d <RACDB2>
166
Schutz von Oracle
3. Unmounten Sie alle betroffenen ASM-Laufwerksgruppen als Rasterbenutzer: grid>
asmcmd umount <DG>
Führen Sie die Wiederherstellung auf dem Wiederherstellungs-Node aus. Führen Sie die
Vorgehensweise
1. Navigieren Sie auf der AppSync-Konsole zu Copy Management > Oracle.
2. Wählen Sie die gewünschte Datenbank aus. Klicken Sie dann im Drop-Down-Menü in
der unteren Mitte des Bildschirms auf Recover und wählen Sie Restore aus.
Der Oracle-Wiederherstellungsassistent wird gestartet.
Überprüfen Sie die Warnmeldung:
You are attempting to perform a restore on a cluster. Please
follow the instructions in the AppSync documentation for
specific cluster restore procedures.
3. Auf der Seite Select Copy sollte die Kopie bereits ausgewählt sein. Klicken Sie auf
Next.
4. Wählen Sie unter Restore Options die Option Data aus und klicken Sie auf Next.
Überprüfen Sie, ob die Warnung Affected Entities mit der Meldung angezeigt wurde,
dass es eine betroffene Datenbank gibt und dass Sie die Datenbank manuell
herunterfahren müssen.
Hinweis
Eine Datenbank kann zugehörige Entities im selben Speicher, aber in einem anderen
Node aufweisen. Wenn dies der Fall ist, wird diese Warnung nicht angezeigt.
5. Klicken Sie im Bildschirm der betroffenen Entitäten auf Next.
6. Überprüfen Sie die Zusammenfassung und klicken Sie auf Finish.
7. Überprüfen Sie, ob die ausgewählte Datenbank heruntergefahren wird.
8. Überprüfen Sie die Nachricht, dass Laufwerksgruppen und Geräte unmountet werden.
9. Überprüfen Sie, ob die Wiederherstellung erfolgreich war.
Ergebnisse
Nach der Wiederherstellung:
1. Mounten Sie die Laufwerksgruppen erneut als Rasterbenutzer auf den RemoteNodes:grid> asmcmd mount <DG>.
2. Führen Sie auf einem beliebigen Node eine Recovery der wiederhergestellten
Datenbank mithilfe von Redo oder Archive with Resetlogs aus:
Oracle > startup mount
Oracle > recover database
3. Öffnen Sie die Datenbank auf dem Recovery-Node:
Oracle > alter database open
4. Starten Sie die Instanzen auf den zusätzlichen Nodes:
srvctl start instance -d <RACDB> -i <DbInstanceOnRemoteNodes>
5. Wiederholen Sie die Schritte 2 und 3, um die betroffene Datenbank <RACDB2>
wiederzuherstellen.
6. Starten Sie die betroffene Datenbank <RACDB2>
Wiederherstellen einer RAC-Kopie für betroffene Entitäten
167
Schutz von Oracle
Wiederherstellen einer Kopie aus XtremIO
Überprüfen Sie diese Informationen zum Wiederherstellen einer Oracle-Kopie aus
XtremIO.
Für AppSync 2.2.2 und höher und XtremIO 4.0 und höher ist die Schaltfläche „Restore“
im Oracle-Wiederherstellungsassistenten für die automatische Wiederherstellung
aktiviert. Wenn Sie zwei Kopien, eine für XtremIO 3.x und eine weitere für XtremIO 4.0
wiederherstellen, stellt AppSync nur die 4.0-Kopie wieder her (Warnmeldung für 3.xKopie wird angezeigt).
Um eine Oracle-Datenbank für XtremIO 3.x wiederherzustellen, mounten Sie die
gewünschte AppSync-Kopie auf dem Produktionshost und verwenden dann RMAN, um
die Datenbank auf den gewünschten Point-in-Time wiederherzustellen (einschließlich
RAC-Konfigurationen).
Wenn Sie die Datenbank unter Verwendung von RMAN nicht wiederherstellen können,
können Sie die folgenden Wiederherstellungsschritte ausführen, um die OracleDatenbank vollständig zu ersetzen (wiederherzustellen). Da Oracle-Konfigurationen in
Linux-Umgebungen (ASM, Udev, MPIO, LVM usw.) variieren, sollten Sie die Verfahren zur
vollständigen Wiederherstellung auf einer Nichtproduktionskonfiguration von Oracle, die
auf ähnliche Weise wie Ihr Produktionshost konfiguriert ist, testen und dokumentieren,
bevor Sie die Verfahren in einer echten Disaster-Recovery-Situation verwenden. Auf diese
Weise stellen Sie eine erfolgreiche Wiederherstellung sicher. Das folgende Beispiel eines
Verfahrens zur vollständigen Wiederherstellung basiert auf einer eigenständigen OracleDatenbank auf ASM, die Udev-Geräte verwendet.
Das Hauptanliegen während des Verfahrens zur Wiederherstellung besteht darin, einen
Konflikt zwischen der Produktionskonfiguration und der gemounteten Konfiguration zu
vermeiden. Stellen Sie sicher, dass Sie das Produktionsobjekt (z. B. Oracle-Datenbank,
ASM-Festplattengruppe und so weiter) herunterfahren, bevor Sie versuchen, die Kopie in
die Produktion zu konvertieren.
Wiederherstellen der Oracle-Datenbankkopie mitAppSync und XtremIO
Dieser Abschnitt enthält Schritte zur manuellen Wiederherstellung einer OracleDatenbankkopie auf einemXtremIO-Array für 2.2.1 und früher und auf XtremIO-Versionen
vor 4.0.
Bevor Sie beginnen
Verwenden Sie mit AppSync 2.2.2 und höher und XtremIO 4.0 und höher zum
Wiederherstellen von Kopien den Wiederherstellungsassistenten. Weitere Informationen
finden Sie unterWiederherstellen einer Oracle-Kopie auf Seite 163.
Für die manuelle Wiederherstellung benötigen Sie eine Kopie der Oracle-Datenbank
aufXtremIO-Speicher mit einemAppSync-Serviceplan, der die Datenbank repliziert.
Setzen Sie alleAppSync-Servicepläne aus, die möglicherweise die Datenbank replizieren,
die Sie wiederherstellen wollen.
Vorgehensweise
1. Mounten Sie in derAppSync-Konsole die Oracle-Kopie, die Sie wiederherstellen
möchten. Wählen SieMount on standalone server und anschließend Original Server
aus oder geben Sie den Produktionshost an, auf dem die Kopie gemountet werden
soll.
Da Sie auf den ursprünglichen Server mounten, wählen SieDefault Path als MountPfad aus.
2. Beenden Sie alle Anwendungen auf dem Produktionshost, die die
wiederherzustellende Datenbank verwenden.
168
Schutz von Oracle
3. Fahren Sie auf dem Produktionshost die Oracle-Instanz herunter, die
wiederhergestellt wird.
Es wird von einer ASM-Konfiguration ausgegangen.
4. Identifizieren Sie die ASM-Festplattengruppen für die Oracle-Datenbank, die
wiederhergestellt wird, und unmounten Sie diese.
Abbildung 16 Unmounten von ASM-Festplattengruppen
Abbildung 17 Ändern von Festplattengruppen
5. Prüfen Sie die Parameter für die ASM-Festplattenzeichenfolge (asm_diskstring)
und entfernen Sie das ASM-Produktionsgerätemuster.
Die gemounteten ASM-Geräte haben das Muster /dev/emc-appsync als Präfix. Im
folgenden Beispiel verwenden die ASM-Produktionslaufwerke /dev/asm-disk* als
Gerätemuster.
Abbildung 18 Muster:/dev/asm-disk*
169
Schutz von Oracle
6. Mounten Sie die ASM-Festplattengruppen, die auf die gemountete Snapshot-Kopie
verweisen.
Abbildung 19 Mounten von ASM-Festplattengruppen
7. Passen Sie die Bindungen für die Festplattengruppe so an, dass keine EMC
Bindungen verwendet werden. Sie können diese Aufgabe jetzt oder später
durchführen.
Wenn Sie die Bindungen für die Festplattengruppe später anpassen, beenden Sie
Oracle und unmounten Sie dann die Festplattengruppen. Bei ASM unter Verwendung
von udev-Geräten auf SuSe Linux bedeutet das ein Ändern der Regeldateien
unter /etc/udev/rules.d. Jeder Version von Linux ist anders, daher müssen Sie
die Umgebung und die Konfiguration von Oracle unbedingt verstehen. Wenn Sie
diesen Schritt jetzt ausführen, fügen Sie die ursprünglichen ASM-Bindungen erneut zu
asm_diskgroup hinzu.
8. Starten Sie Oracle und stellen Sie die Datenbank wieder her.
Abbildung 20 Starten Sie neu und stellen Sie dann die Datenbank wieder her.
Die wiederhergestellte Datenbank sollte online sein.
9. Starten Sie alle Datenbankanwendungen neu, die Sie in Schritt 2 beendet haben.
10. Wählen Sie auf der AppSync-Konsole die OptionRemove aus, um die gemountete
Kopie zu entfernen.
170
Schutz von Oracle
Mit dieser Aktion wird die Kopie aus der AppSync-Datenbank entfernt. Der Snapshot
auf dem Produktions-Mount-Host oder auf dem XtremIO-Speicherarray wird aber nicht
gelöscht. Sie können eine gemountete Kopie entfernen, der Ablauf für eine
gemountete Kopie kann aber nicht festgelegt werden.
11. Verschieben Sie den gemounteten Snapshot aus dem Ordner /AppSyncSnapshots
in den Ordner, in dem die auszutauschenden Produktions-LUNs gespeichert sind.
Verschieben Sie den gemounteten Snapshot (der Snapshot, der derzeit für die ESXInitiatorgruppe maskiert ist), wenn der Produktionshost eine virtuelle Maschine ist.
Wenn es sich beim Produktionshost um einen physischen Host handelt, verschieben
Sie den Snapshot in den Ordner, in dem die Produktions-LUNs gespeichert sind. Zum
Schluss sehen Sie die Produktions-LUNs und den Snapshots im selben Ordner.
Abbildung 21 Vor der Snapshot-Verschiebung
Abbildung 22 Nach der Snapshot-Verschiebung
12. Wenn es sich beim Produktionshost um eine virtuelle Maschine handelt, heben Sie
die Zuordnung zwischen den ursprünglichen Produktionsvolumes und dem ESXServer auf. Scannen Sie den ESX-Host neu und entfernen Sie dann die RDMs aus der
Konfiguration der virtuellen Produktionsmaschine. Wenn der Produktionshost ein
physischer Host ist, heben Sie die Zuordnung zwischen den ursprünglichen
Produktionsvolumes und dem Produktionshost auf und führen Sie dann erneut einen
Gerätescan auf dem Host durch, um die alten Produktionsgeräte zu entfernen.
13. Entfernen Sie die früheren Produktionsvolumes aus der XtremIO-Konsole.
Die wiederhergestellten Snapshots werden zu Volumes.
171
Schutz von Oracle
Abbildung 23 Wiederhergestellte Snapshot werden zu Volumes
14. Benennen Sie die Snapshots mit den Produktionsvolumenamen um.
Abbildung 24 Umbenennen von Snapshots
Die anderen Snapshots im Ordner /AppSyncSnapshots für die alten XtremIOProduktionsvolumes, die Sie in Schritt 11 entfernt haben, werden ebenfalls zu
Volumes.
Abbildung 25 Entfernte Snapshots werden zu Volumes
15. Ermitteln Sie den Produktionshost neu, um die AppSync-Konsolenansicht der ASMKonfiguration zu aktualisieren. Führen Sie als Nächstes den Serviceplan aus, um
einen Snapshot der wiederhergestellten Datenbank zu erstellen, und aktivieren Sie
dann alle in Schritt 1 unterbrochenen Servicepläne.
Übersicht über die Neuverwendung
In diesem Thema wird erläutert, wie Sie die AppSync-Neuverwendungsfunktion für
Datenbank- und Lesenzeichenkopien verwenden.
AppSync unterstützt die Ad-Hoc-Erstellung von Oracle- und SQL Server auf Seite 127Datenbankkopien sowie von RecoverPoint-Lesezeichenkopien, gefolgt von der Erstellung
von Kopien dieser Kopien. Diese Vorgehensweise wird als Neuverwendung bezeichnet.
Die Neuverwendung hat viele nützliche Funktionen, einschließlich Test und Entwicklung,
Reparatur, Data Mining und Reporting.
Überprüfen und berücksichtigen Sie die folgenden Informationen zu den
Neuverwendungsfunktionen:
l
172
Durch die Neuverwendung wird eine mehrstufige Struktur von Datenbankkopien
erstellt.
Schutz von Oracle
AppSync identifiziert die Kopien, die aus einem Neuverwendungsvorgang erstellt
werden, mit einer eine Generation weitergeführten Nummer aus den
Produktionsquelldaten, beispielsweise Gen 1, Gen 2 usw.
l
Es gibt keine Begrenzung für die Anzahl von Generationen, der Support ist jedoch auf
zwei von den Produktionsdaten weitergeführte Generationen beschränkt.
l
Beim Kopieren einer ersten Generation(1. Gen) wird eine Kopie erstellt, die als Quelle
für andere Kopien verwendet werden kann. Mit dieser Aktion wird eine Kopie der
Kopie erstellt.
l
Neuverwendungskopien sind für das Mounten über einen längeren Zeitraum für
verschiedene Zwecke gedacht.
l
Nach der Verwendung werden die Neuverwendungskopien entweder gelöscht oder
aktualisiert.
l
Neuverwendungskopien werden in RPO-Berechnungen nicht berücksichtigt.
l
Sie können Kopien der 1. Generation jetzt ausführen oder sie für einen späteren
Zeitpunkt planen.
l
Von AppSync unterstützte Kopiertypen umfassen VNX Snap, TimeFinder-Clone von
Clone, Snapshot von Clones auf VMAX, SnapVx von SnapVx für VMAX 3, XtremIOSnapshot und RecoverPoint-Lesezeichen.
l
Die Wiederherstellung wird nicht von Kopien der 2. Generation unterstützt.
Die Konsole zeigt alle geplanten Neuverwendungsaktionen. Wählen Sie eine beliebige
Aktion aus und klicken Sie auf die Schaltfläche Delete. Die geplante Aktivität wird
entfernt.
l
Wenn Sie Hot-Backup aktivieren, erstellt die Kopie der 1. Generation der Datenbank die
anwendungskonsistente Kopie. Diese umfasst Anwendungserkennung, Zuordnung und
Datenbank-Einfrieren/Wiederaufnehmen. AppSync legt Datenbank-Einfrieren/
Wiederaufnehmen nicht als Standard für Neuverwendungskopien der 1. Generation fest.
Kopien der zweiten Generation werden als Kopien von Kopien erstellt, wobei die Kopie
der ersten Generation als Quelle verwendet wird. Sie umfassen keine
Anwendungserkennung, Zuordnung und Datenbank-Einfrieren/Wiederaufnehmen. Daher
werden Kopien der 2. Generation wesentlich schneller als Kopien der 1. Generation
erstellt.
Hinweis
Neuverwendungskopien werden nicht für Oracle-Datenbanken auf VNX-Dateispeicher
oder NFS-Dateisystemen unterstützt.
Übersicht über die Neuverwendung
173
Schutz von Oracle
Aktualisierung für neue Verwendung
Aktualisierung bedeutet, die aktuelle Kopie zu verwerfen (Ablauf) und die Inhalte der
Kopie mithilfe der übergeordneten Kopie neu zu erstellen.
174
l
Kopien der 1. und der 2. Generation können aktualisiert werden.
l
Durch Aktualisieren einer Kopie der ersten Generation wird eine
anwendungskonsistente Kopie mit einer neuen Zeit erstellt.
l
Kopien der 2. Generation werden nicht geändert, wenn Sie die Kopie der 1.
Generation aktualisieren.
l
Durch Aktualisierung der Kopie der 2. Generation wird die Kopie der 2. Generation
neu mit der übergeordneten 1. Generation synchronisiert. (Verwenden Sie dies zum
Verwerfen von Änderungen an der Kopie der 2. Generation und nachfolgendem
Neubeginn.)
l
Der Zeitstempel der Kopie der 2. Generation ist mit dem der 1. Generation identisch.
l
Durch die Aktualisierung ist es möglich, Kopien der 1. und der 2. Generation mit
unterschiedlichen Zeitstempeln zu haben.
l
Wenn Sie beim Erstellen der Kopie der 2. Generation die Option Unmount Previous
Copy angegeben, unmountet AppSync die Kopie vor dem Erstellen der neuen Kopie.
l
Aktualisieren einer Kopie der 1. Generation auf XtremIO: Wenn sich die Anzahl der
LUNs in der Quelldatenbank ändert, erstellen Sie nur neue Snapshots. Beispielsweise
verwendet AppSync die vom XtremIO-Array aus den Quell-LUNs bereitgestellte
Aktualisierung, um die Snapshot-Kopie der 1. Generation zu erstellen.
l
Aktualisieren der Kopie der 2. Generation auf XtremIO: Wenn Sie die Quellkopie der 1.
Generation aktualisiert haben und sich die Anzahl der LUNs in der Quelldatenbank
geändert hat, erstellen Sie nur neue Snapshots. Verwenden Sie andernfalls die vom
XtremIO-Array bereitgestellte Aktualisierung, um von Snapshots der 1. Generation auf
Snapshot-Kopien der 2. Generation zu aktualisieren.
l
Nach der Aktualisierung remountet AppSync die Kopie, wenn die Kopie gemountet
war.
l
Die Kopie der 2. Generation wird aus der übergeordneten 1. Generation neu erstellt.
Wenn die übergeordnete 1. Generation nicht mehr vorhanden ist, schlägt die
Aktualisierung fehl.
l
Die Kopie der 1. Generation wird von der Anwendung neu erstellt.
l
Die aktuelle Kopie, die Sie aktualisieren möchten muss ungemountet werden (wenn
sie gemountet ist). Wenn Sie im Assistenten zum Festlegen einer neuen Verwendung
Schutz von Oracle
die Option Mount Copy ausgewählt haben, wird die Kopie in AppSync neu
gemountet.
Sie können eine Kopie für die neue Verwendung jederzeit aktualisieren. So starten Sie die
Aktualisierung:
1. Wählen Sie auf der Registerkarte Applications in der AppSync-Konsole die neu
verwendete Kopie aus, die Sie aktualisieren möchten.
2. Klicken Sie auf Refresh.
Ablauf für neue Verwendung
Wenn die Kopien der 1. oder der 2. Generation abgelaufen sind, gibt es keine Möglichkeit
mehr, die Kopie zu aktualisieren. Der Ablauf einer Kopie der 1. Generation schlägt fehl,
wenn aus der Kopie der 1. Generation eine Kopie der 2. Generation erstellt wurde.
Wenn Sie mit einer Kopie fertig sind, lassen Sie die Kopie ablaufen.
Verwenden Sie bei Bedarf den Assistenten zum Festlegen einer neuen Verwendung zur
Planung oder sofortigen Erstellung von Kopien der 1. und 2. Generation.
Bevor Sie beginnen
Sie benötigen AppSync-Administratorrechte, um für die Datenbankinstanz eine neue
Verwendung festzulegen.
Gehen Sie folgendermaßen vor, um die Liste verfügbarer Anwendungen anzuzeigen.
Vorgehensweise
1. Melden Sie sich bei der AppSync-Konsole an und navigieren Sie zu Copy
Management.
Option
Beschreibung
So legen Sie für eine SQL-Kopie eine neue Verwendung
fest:
Wählen Sie SQL Server aus
So legen Sie für eine Oracle-Kopie eine neue
Verwendung fest:
Wählen Sie Oracle aus
Es wird eine Liste der verfügbaren Datenbanken zur Auswahl der Anwendung geladen.
2. Klicken Sie auf die Datenbankinstanz, für die Sie eine neue Verwendung festlegen
möchten, und wählen Sie dann Repurpose aus der Drop-down-Liste unten links im
Konsolenbildschirm aus.
Mit dieser Aktion wird der Assistent zum Festlegen einer neuen Verwendung gestartet.
Sie werden zur Seite Intentions weitergeleitet, in der Sie AppSync vorgeben können,
welche Aktion Sie ausführen möchten:
l
Create First Generation copy
l
Create First Generation copy and a Second Generation copy
3. Wählen Sie den gewünschten Kopietyp aus und wählen Sie Local oder Remote in der
Drop-down-Liste der Website aus, um mit dem Erstellen der Kopie fortzufahren.
4. Klicken Sie auf Next, um den Bildschirm Settings zu starten.
Im Bildschirm Settings können Sie die spezifischen Optionen für die Kopien der 1.
und 2. Generation definieren. Sie haben insbesondere folgende Möglichkeiten:
175
Schutz von Oracle
l
Definieren von Bezeichnungen für jede Kopie zur Identifizierung des Zwecks jeder
Kopie.
l
Auswahl von anwendungsspezifischen Kopieroptionen für ausschließlich die
Kopie der 1. Generation.
l
Auswahl des entsprechenden Kopietyps (Assistent schlägt bei falsch
ausgewähltem Typ fehl).
5. Wählen Sie die gewünschten Optionen für die Kopie aus und klicken Sie dann auf
Next.
Die Seite Schedule des Assistenten wird angezeigt, sodass Sie ermitteln können,
wann die Kopie der 1. Generation erstellt werden soll. Erstellen Sie die Kopie jetzt
oder planen Sie die Kopie für einen geeigneten Zeitpunkt.
6. Wählen Sie Run now oder Run later aus, gefolgt von der Eingabe des Datums und der
Uhrzeit der Ausführung, und klicken Sie dann auf Next, um den Assistenten
abzuschließen.
Der Repurpose Monitor
Mit dem Repurpose Monitor können Sie alle derzeit ausgeführten Aktivitäten der neuen
Verwendung anzeigen und deren Fortschritt überwachen. Der Repurpose Monitor zeigt
das neu verwendete Element (Quelle) und die Bezeichnung des zu erstellenden oder zu
aktualisierenden Elements mit dem Anwendungstyp an. Weitere Informationen finden Sie
unter Der Repurpose Monitor auf Seite 230.
Anzeigen oder Abbrechen geplanter Neuverwendungskopien
Sie können eine geplante Neuverwendungskopie der ersten Generation anzeigen oder
abbrechen.
Vorgehensweise
1. Navigieren Sie in der Appsync-Konsole zu Application > Copy Management, und
wählen Sie dann die entsprechende Datenbank.
2. Wählen Sie Repurpose > View Scheduled Repurpose Copy, um alle geplanten
Neuverwendungsaktionen anzuzeigen.
3. Um eine Aktion zu löschen, wählen Sie eine oder mehrere gewünschte Aktionen und
klicken auf Delete, um die Aktion zu entfernen.
Mounten und Wiederherstellen des Oracle-Clone eines Clone für ein RecoverPointLesezeichen
In diesen Schritten wird erläutert, wie Sie einen Oracle-Datenbank-Clone des Clone für
eine RecoverPoint-Lesezeichenkopie auf VMAX mounten und wiederherstellen können.
Bevor Sie beginnen
Vergewissern Sie sich, ob die AppSync-Konfiguration über eine Oracle-Datenbankkopie
auf RecoverPoint mit VMAX verfügt. Aktivieren Sie das Hot-Backup für Kopien der 1.
Generation für eine sichere Recovery.
Vorgehensweise
1. Navigieren Sie auf der AppSync-Konsole zu Applications > Oracle, wählen Sie eine
Oracle-Datenbank aus, die sich auf dem VMAX-Speicher befindet, und wählen Sie
dann Repurpose aus.
Durch die Aktion wird die Seite Intentions des Assistenten zum Festlegen einer neuen
Verwendung gestartet.
176
Schutz von Oracle
2. Wählen Sie auf der Seite Intentions die Option zur Erstellung von Kopien create 1st
Gen und create 2nd Gen aus. Wählen Sie dann die Option Use Bookmark as an
intermediate step aus und klicken Sie auf Next.
3. Wählen Sie unter Settings > 1st Gen copy > Create a label den Kopietyp Clone aus.
4. Wählen Sie auf der Einstellungsseite für die Kopie der 2. Generation eine Bezeichnung
aus und dann Clone als Kopietyp.
5. Wählen Sie die Mount-Einstellungen für die Kopie der 1. Generation und dann die
Phase Unmount für die Kopie der 1. Generation aus.
6. Wählen Sie für die Mount-Einstellungen Mount and Recovery für die Kopie der 2.
Generation aus und dann die Phase Unmount für die Kopie der 2. Generation.
7. Wählen Sie auf der Seite Planung Run Now aus, um den Assistenten abzuschließen.
Mounten und Wiederherstellen des Oracle-Snap eines Clone-RecoverPointLesezeichens
In diesen Schritten wird erläutert, wie Sie einen Oracle-Datenbank-Snapshot des Clone
für eine RecoverPoint-Lesezeichenkopie auf VMAX mounten und wiederherstellen
können.
Bevor Sie beginnen
Vergewissern Sie sich, ob die AppSync-Konfiguration über eine Datenbank im
RecoverPoint VNX-Speicher und eine weitere im RecoverPoint VMAX-Speicher verfügt.
Snap eines Snap für VNX und Snap eines Snap für VMAXwird nicht unterstützt.
Wählen Sie die Kopien der 1. Generation mit der OptionHot-Backup aktiviert für eine
sichere Recovery aus.
Vorgehensweise
1. Navigieren Sie auf der AppSync-Konsole zu Applications > Oracle, wählen Sie eine
Oracle-Datenbank aus, die sich auf dem VMAX-Speicher befindet, und wählen Sie
dann Repurpose aus.
Durch die Aktion wird die Seite Intentions des Assistenten zum Festlegen einer neuen
Verwendung gestartet.
2. Wählen Sie auf der Seite Intentions die Option zur Erstellung von Kopien create 1st
Gen und create 2nd Gen aus. Wählen Sie dann die Option Use Bookmark as an
intermediate step aus und klicken Sie auf Next.
3. Navigieren Sie zu Settings > 1st Gen copy > Create a label und wählen Sie dann den
Kopietyp Clone aus.
4. Navigieren Sie zu Settings > 2nd Gen copy > Select Snap copy type und wählen Sie
dann eine Bezeichnung aus.
5. Wählen Sie Mount Settings für die Kopie der 2. Generation aus.
6. Wählen Sie auf der Seite Planung Run now undFinish aus.
Mounten und Wiederherstellen des Oracle-Snap eines Clone-RecoverPoint-Lesezeichens
177
Schutz von Oracle
178
KAPITEL 8
l
l
l
l
Übersicht über die Unterstützung für das Dateisystem........................................ 180
Zusammenfassung der Serviceplaneinstellungen für Dateisysteme..................... 182
Mounten einer Kopie mit dem Assistenten für das Mounten von Dateisystemen.. 191
Wiederherstellen eines Dateisystems.................................................................. 193
179
Übersicht über die Unterstützung für das Dateisystem
MitAppSync können Sie anwendungskonsistente Kopien von Dateisystemen erstellen
und managen.
Die Dateisystemfunktionen umfassen unter anderem Folgendes:
l
Dynamische Ermittlung von Dateisystemen während der Ausführung des Serviceplans
l
Schutz von Dateisystemen anhand des Serviceplans oder mit der Option Copy now.
Sie können eines oder mehrere Dateisysteme, die geschützt werden sollen,
gleichzeitig auswählen oder auf SELECT ALL klicken, um alle Dateisysteme auf der
Seite für die Liste der Dateisysteme zu schützen.
l
Listet Kopien auf, die Sie nach Erstellungszeit, Kopierstatus und Serviceplan filtern
können.
l
Mounten auf einem eigenständigen Server
Schutz von NFS-Dateisystemen auf VNX-Speicher
Erfahren Sie, wie AppSync den Schutz von NFS-Dateisystemen auf VNX-Speicher
unterstützt.
AppSync unterstützt den Schutz von NFS-Dateisystemen auf Linux (RHEL, SUSE und OEL)
und AIX. Sie können diese Kopien für die betriebliche Recovery verwenden.
Verwenden Sie Bronze-, Silber- und Gold-Servicepläne. Bei für den Remoteschutz
konfigurierten Serviceplänen wird die NFS-Kopie als ein SnapSure-Snapshot auf dem
lokalen bzw. Remote-Dateisystem erstellt. Kopien von NFS-Datenspeichern können aus
Serviceplänen erstellt werden, die für lokalen oder Remote- sowie für lokalen und
Remote-Schutz konfiguriert wurden. AppSync kann außerdem für Bronze-, Silber- und
Gold-Servicepläne Kopien für Dateisysteme auf einer Oracle-Datenbank erstellen.
Während der Wiederherstellung von einer NFS-Kopie erstellt AppSync einen RollbackSnapshot für jedes Dateisystem, das wiederhergestellt wurde. Die Namen der einzelnen
Rollback-Snapshots finden Sie in den Wiederherstellungsdetails. Sie können den
Rollback-Snapshot nach Überprüfung der Inhalte der Wiederherstellung manuell löschen.
Wenn Sie diese Snapshots über die Nutzungsdauer hinaus aufbewahren, führt dies
möglicherweise zu einem vollen VNX-Snapshot-Cache und Ressourcenproblemen.
Überprüfen Sie die folgenden Voraussetzungen für Silber und Gold-Kopien:
l
Registrieren Sie Remote-VNX-Arrays bei AppSync.
l
Erstellen Sie Remote-Replikationssitzungen mit entsprechenden Remote-Arrays für
jedes NFS-Dateisystem, in denen Silber- und Gold-Kopien erstellt werden sollen.
Stellen Sie sicher, dass der Array-Status OK ist.
Seite Hostdateisysteme
Die Seite Hostdateisysteme zeigt alle Hostinstanzen, die derzeit mit AppSync registriert
sind.
Sie können auf dieser Seite einen Host (Windows und UNIX) hinzufügen und die auf den
Hosts verfügbaren Dateisysteme erkennen.
Weitere Informationen über Dateisysteme finden Sie unter:
180
l
Seite Dateisysteme auf Seite 181
l
Seite Dateisystemkopien auf Seite 181
l
Mounten einer Kopie mit dem Assistenten für das Mounten von Dateisystemen auf
Seite 191
Seite Filesystem
Die Seite Filesystem listet alle verfügbaren Dateisysteme auf, die für die ausgewählte
Serverinstanz erkannt werden.
Klicken Sie auf den Namen eines Dateisystems, um Kopien des Dateisystems anzuzeigen.
Die Informationen zum Dateisystem umfassen Folgendes:
l
Status der Serviceplan-Ausführung, z. B. Häkchen in einem grünen Kreis = erfolgreich
abgeschlossen
l
Name
l
Typ, z. B. NTFS
l
Format, z. B. MBR
l
Serviceplans, zum Beispiel Bronze
Einige Dateisysteme können mehrere Servicepläne abonniert haben.
l
Speichergröße in GB
l
Senden von Warnmeldungen an (falls angefordert)
Sie können auswählen, ein oder mehrere Dateisysteme gleichzeitig zu schützen. Klicken
Sie auf SELECT ALL, um alle Dateisysteme auf dieser Seite zu schützen (mit Ausnahme
des Dateisystems C:\, das Informationen zum Hostsystem enthält). Weitere
Informationen über Dateisysteme finden Sie unter:
l
Seite Filesystem copies auf Seite 181
l
Seite Filesystem hosts auf Seite 180
l
Seite 191
Seite Filesystem Copies
Auf dieser Seite können Sie die Liste der Dateisystemkopien anzeigen.
Die Liste der Kopien kann nach Erstellungszeit, Status der erstellten Kopien und
Serviceplan gefiltert werden.
Wählen Sie eine Kopie aus, um die Ereignisse für die Kopie im Detailbereich am unteren
Rand der Seite Copies anzuzeigen.
Auf der Seite Copies können Sie auswählen, Kopien zu mounten, wiederherzustellen oder
ablaufen zu lassen.
Weitere Informationen über Dateisysteme finden Sie unter:
l
Seite Filesystems auf Seite 181
l
Seite Filesystem hosts auf Seite 180
l
Seite 191
Schutz von NFS-Dateisystemen auf VNX-Speicher
181
Zusammenfassung der Serviceplaneinstellungen für
Dateisysteme
Verwenden Sie diese Tabelle, um die Standardeinstellungen für Dateisysteme für die
Serviceplanphasen einschließlich Start, Erkennung, Zuordnung, Prä- und
Postkopyskripting, Mounten/Unmounten und Kopieren kennenzulernen.
alle 24 Stunden erstellt. Nur die Replikationstechnologie, die durch den Kopietyp in der
Phase zur Erstellung der Kopie vorgegeben wird, unterscheidet sich bei den einzelnen
Plänen. In der folgenden Tabelle werden die Standardeinstellungen zusammengefasst:
Dateisysteme
Einstellung
nicht
aktiviert
Zeitplan
Plan Startup
Aktiviert
Typ des Wiederholung: Erstellt
eine Kopie alle 24 Stunden, mit
der ersten Ausführung um
Mitternacht (00:00).
Recovery Point Objective (RPO):
Eine Kopie sollte alle 24 Stunden
erstellt werden. (Warnmeldung
wird ausgegeben, wenn das Ziel
nicht erreicht wird.)
Application
discovery
Aktiviert
Keine
Durch die Planstartphase
bestimmt.
Application
mapping
Aktiviert
Keine
Anwendungserkennungsphase.
Pre-copy script
Nicht
aktiviert
Keine
Anwendungszuordnungsphase
Create copy
Aktiviert
Kopietyp:
Präkopieskript-Phase
l
Bronze: Lokale Kopie
erstellen
l
Silber: Remote-Kopie
erstellen (VMAX v2, v3
VMAX, RecoverPoint und
VNX File).
l
Gold: Lokale und
Remotekopie erstellen
(RecoverPoint und VNX
File).
Auch:
l
182
Storage Ordered
Preference: Snapshot,
Clone und Lesezeichen
Einstellung
nicht
aktiviert
l
Zeitplan
Include RecoverPoint
copies in expiration
rotation policy – Wählen
Sie diese Option aus, um
RecoverPoint-Kopien
beim Berechnen von
Rotationen
einzubeziehen. Wenn Sie
diese Option nicht
auswählen, sammeln sich
RecoverPoint-Kopien an
und werden beibehalten,
bis ihre Lesezeichen aus
der RecoverPointAppliance „herausfallen“.
Post-copy script
Nicht
aktiviert
Keine
Kopieerstellungsphase
Unmount
previous copy
Nicht
aktiviert
Keine
Postkopieskript-Phase
Mount copy
(Eine
PrämountskriptPhase ist
verfügbar für
Servicepläne für
Dateisysteme)
Nicht
aktiviert
Mount Copy
Phase zum Unmounten der
vorherigen Kopie
l
Mount on Server:
Ursprünglicher Host
l
Mount with access:
Lesen/Schreiben
l
Mount Path:
Standardpfadimage
l
Access mode:
Protokollierter Zugriff
l
Copy to Mount: Lokal (nur
für Gold-Pläne)
l
Use Dedicated Storage
Group: Standardmäßig
ausgewählt
Post-mount
script
Nicht
aktiviert
Keine
Phase zum Mounten der Kopie
Unmount copy
Nicht
aktiviert
Keine
Postmountskript-Phase
Zusammenfassung der Serviceplaneinstellungen für Dateisysteme
183
Abonnieren eines Serviceplans für ein Dateisystem
In diesem Abschnitt wird erläutert, wie Sie einen Serviceplan für ein Dateisystem
abonnieren. Der Schutz für alle Dateisysteme, die Teil eines Serviceplans sind, wird zur
Vorgehensweise
1. Navigieren Sie zu Copy Management > Filesystem.
2. Klicken Sie auf den gewünschten Server.
Die Seite File Systems wird für den ausgewählten Server geladen.
3. Wählen Sie die Dateisysteme aus, die Sie schützen möchten, und klicken Sie dann in
der Drop-down-Liste Protect auf Subscribe to Service Plan.
4. Wählen Sie den Serviceplan Gold, Silver oderBronze aus.
Sie können auch die Option Subscribe to Service Plan and run für sofortiges
Abonnieren und sofortigen Schutz auswählen.
Sie können verschiedene Planungen für einzelne Anwendungen, für die ein Serviceplan
abonniert wurde, durch außer Kraft setzen der allgemeinen Wiederholungseinstellungen
festlegen.
Bevor Sie beginnen
Vorgehensweise
3. Notieren Sie sich im Bereich Plan Startup Default auf der rechten Seite den
Sie können die Liste aller Anwendungen anzeigen lassen, für die der Plan abonniert
wurde.
5. Wählen Sie eine oder mehrere Anwendungen aus und klicken Sie auf Override
Schedule.
6. Legen Sie im Dialogfeld Override Schedule die auf Ihren Anforderungen basierende
Planung fest und klicken Sie auf OK.
ist und die Regeleinstellung Run at 12:00 AM am 1st day of every month festgelegt
wurde, können Sie die Uhrzeit und den Tag für die einzelnen Anwendungen außer
Kraft setzen.
gesetzt wurden.
184
Servicezeitplan
l
l
l
l
n
n
n
n
n
n
n
werden
n
ist Mitternacht.
n
n
n
Anwendungserkennung
Vor dem Erstellen einer Dateisystemkopie untersucht AppSync das Dateisystem auf
Änderungen, also ob etwas im Dateisystem hinzugefügt, gelöscht, umbennant oder
verschoben wurde. Wenn einzelne Dateisysteme geschützt werden, erkennt AppSync die
Informationen über das ausgewählte Dateisystem neu.
Anwendungszuordnung
deaktiviert werden.
Phase Pre-copy script
Um vorbereitende Schritte ausführen, bevor Sie eine Kopie erstellen, geben Sie auf der
Registerkarte Einstellungen des Serviceplans ein Präkopieskript und Parameter an.
Dieser Vorgang erfordert die Rolle Serviceplanadministrator in.
Servicezeitplan
185
Das Präkopieskript wird gemäß dem in der Phase Plan Startup festgelegten Zeitplan
ausgeführt. Gültige Skriptformate sind .bat, .exe und .ps1 (PowerShell-Skripte) für
Windows und .sh für UNIX.
AppSync unterstützt keine direkte Ausführung von PowerShell-Skripten. Sie müssen in
der Regel in einer .bat-Datei eingeschlossen werden. Die andere Option besteht darin,
den Standardwert „Open“ für ps1-Dateien wie folgt festzulegen: C:\WINDOWS
\system32\WindowsPowerShell\v1.0\powershell.exe. Wenn das PS-Skript
ausgeführt wird, erhalten Sie möglicherweise einen Fehler und müssen eine
entsprechenden Ausführungspolicy festlegen.
So führen Sie PowerShell-Befehle von Skripten aus:
1. Geben Sie den vollständigen Pfadnamen zur PowerShell-Befehlsdatei in der .batDatei ein:powershell -command C:\PshellCommands.ps1 <nul
2. Legen Sie die PowerShell-Ausführungspolicy so fest, dass Sie Ihr Skript ausführen
eingeschränkte Policy wie folgt aussehen: powershell -command setexecutionpolicy unrestricted <nul
3. Um eine korrekte Beendigung der PowerShell-Sitzung zu gewährleisten, fügen Sie am
Ende der Zeile, mit der Ihr PowerShell-Skript aufgerufen wird, <nul hinzu.
Für Windows können Sie optional die Anmeldedaten eingeben, um das Skript als ein
bestimmter Benutzer auszuführen Das Skript wird standardmäßig als lokales System
ausgeführt. Für UNIX sind die Anmeldedaten erforderlich.
Für Windows ist der standardmäßige Speicherort des Skripts %ProgramData%\EMC
\AppSync\scripts\ auf dem Anwendungshost.
Für UNIX muss im Feld Datei der vollständige Pfad zu den auszuführenden Skripten
angegeben werden.
doppelte Anführungszeichen gesetzt werden. Dieser Phase kann aktiviert oder deaktiviert
werden. Für diesen Vorgang ist die Rolle Serviceplanadministrator in AppSynch
erforderlich.
Phase Create Copy mit den Callout-Skripten Einfrieren und Wiederaufnehmen
In der Phase Create Copy wird eine Kopie erstellt, die auf der im Serviceplan festgelegten
Replikationstechnologie basiert. In dieser Phase können Sie Callout-Skripte zum
Einfrieren und Wiederaufnehmen konfigurieren und ausführen.
Konfigurieren und Ausführen von Callout-Skripten zum Einfrieren und Wiederaufnehmen
AppSync bietet während der Ausführung der Phase Create Copy zwei verschiedene
Skripte, die Callout-Skripte zum Einfrieren und Wiederaufnehmen. Im Gegensatz zu den
Phasen Prä- und Postkopieskript, die vor und nach der Phase Create Copy ausgeführt
werden, können die Skripte zum Einfrieren und Wiederaufnehmen nicht über die GUI
festgelegt werden. Die Skripte werden in einem vorab festgelegten Speicherort mit einem
vordefinierten Namen abgelegt. Sie können diese Skripte zum Stilllegen (E/A
unterbrechen) und Einfrieren aller in AppSync nicht unterstützten Datenbanken
verwenden, die sich für einen kurzen Zeitraum (in der Regel nur wenige Sekunden) auf
den abonnierten Dateisystemen befinden. Während dieser Zeit wird die Kopie aktiviert.
Die Skripte werden mit den Anmeldedaten des Benutzers verwendet, mit denen das HostPlug-in mit AppSync registriert wurde.
Wenn während der Phase Create Copy diese Skripte in AppSync ausgeführt werden, wird
eine temporäre XML-Datei als einziges Argument für diese Callout-Skripte bereitgestellt.
Diese XML-Datei enthält die Liste der Dateisysteme, die durch die Phase Create Copy
geschützt werden.
186
AppSync fährt mit der normalen Kopieerstellung fort, wenn kein Callout-Skript gefunden
wird oder wenn das Callout-Skript nicht ausführbar ist. Wenn eines der Callout-Skripte
fehlschlägt (Exitwert ungleich Null), schlägt die Kopieerstellung fehl und die Phase Create
Copy wird mit einem Fehler abgeschlossen. Wenn das Callout-Skript zum Einfrieren
erfolgreich ausgeführt wird und die Kopieerstellung dann aufgrund eines
Speicherproblems fehlschlägt, wird das Skript zum Wiederaufnehmen ausgeführt, bevor
die Phase Create Copy mit einem Fehler beendet wird.
Legen Sie bei einem Windows Host-Plug-in die ausführbaren Callout-Skripte im Ordner
%ProgramData%\ EMC\AppSync\scripts ab und benennen Sie ihn
appsync_freeze_filesystem_<service plan name in lower case>.bat
für das Callout zum Einfrieren. Benennen Sie das Callout-Skript zum Wiederaufnehmen:
appsync_thaw_filesystem_<service plan name in lower case>.bat
Beispielsweise wird dieses Skript in AppSync wie folgt ausgeführt:
C:\ProgramData\EMC\AppSync\scripts
\appsync_freeze_filesystem_bronze.bat, C:\Windows\TEMP
\d575f2e6-7dc4-4389-87c9-491effc57318.xml
Dabei liegt der C:\Windows\TEMP
\d575f2e6-7dc4-4389-87c9-491effc57318.xml-Dateiinhalt im folgenden
Format vor:
<Application type='Filesystem'><sourceVolumePath>F:\</
sourceVolumePath><sourceVolumePath>G:\</sourceVolumePath></
Application>
Legen Sie bei einem UNIX Host-Plug-in die ausführbaren Callout-Skripte im
Ordner /var/opt/emc/appsync/scripts ab und benennen Sie ihn
appsync_freeze_filesystem_<service plan name in lower case> für
das Callout zum Einfrieren und appsync_thaw_filesystem_<service plan
name in lower case> für das Callout zum Wiederaufnehmen. Verwenden Sie keine
Dateinamenerweiterungen wie .pl oder .sh. Die Skripte sollten ausführbar sein.
AppSync führt dieses Skript wie folgt aus:
/var/opt/emc/appsync/scripts/
appsync_freeze_filesystem_bronze /tmp/904f510f-47ce-402f-a27ab3a48840a279ybo61k.xml
Dabei liegt der/tmp/904f510f-47ce-402f-a27a-b3a48840a279ybo61k.xmlDateiinhalt im folgenden Format vor: <Application
type='Filesystem'><filesystems><filesystem><name>/FS1</name></
filesystem><filesystem><name>/FS2</name></filesystem></
filesystems></Application>
Phase Post-copy script
Geben Sie nach dem Erstellen einer Kopie ein Postkopieskript und Parameter auf der
Registerkarte Post-copy script eines Serviceplans an, um eine Bereinigung oder andere
Postkopieschritte durchzuführen.
Für diesen Vorgang ist die Rolle Serviceplanadministrator in AppSync erforderlich.
Das Skript wird beim erfolgreichen Abschluss der Phase Create copy ausgeführt. Gültige
Skriptformate sind bat, .exe und .ps1 (PowerShell-Skripte) für Windows und .sh für UNIX.
AppSync unterstützt keine direkte Ausführung von PowerShell-Skripten. Sie müssen in
der Regel in einer .bat-Datei eingeschlossen werden. Die andere Option besteht darin,
den Standardwert „Open“ für ps1-Dateien wie folgt festzulegen: C:\WINDOWS
Phase Post-copy script
187
\system32\WindowsPowerShell\v1.0\powershell.exe. Wenn das PS-Skript
ausgeführt wird, erhalten Sie möglicherweise einen Fehler und müssen eine
entsprechenden Ausführungspolicy festlegen.
So führen Sie PowerShell-Befehle von Skripten aus:
1. Geben Sie den vollständigen Pfadnamen zur PowerShell-Befehlsdatei in der .batDatei ein: powershell -command C:\PshellCommands.ps1 <nul
2. Legen Sie die PowerShell-Ausführungspolicy so fest, dass Sie das Skript ausführen
eingeschränkte Policy wie folgt aussehen: powershell -command setexecutionpolicy unrestricted <nul
3. Um eine korrekte Beendigung der PowerShell-Sitzung zu gewährleisten, fügen Sie am
Ende der Zeile, mit der Ihr PowerShell-Skript aufgerufen wird, <nul hinzu.
Für Windows können Sie optional die Anmeldedaten eingeben, um das Skript als ein
bestimmter Benutzer auszuführen. Das Skript wird standardmäßig als lokales System
ausgeführt. Für UNIX sind die Anmeldedaten erforderlich.
Für Windows ist der standardmäßige Speicherort des Skripts %ProgramData%\EMC
\AppSync\scripts\ auf dem Anwendungshost.
Für UNIX muss im Feld Datei der vollständige Pfad zu den auszuführenden Skripten
angegeben werden.
doppelte Anführungszeichen gesetzt werden. Diese Phase kann aktiviert oder deaktiviert
werden. Für diesen Vorgang ist die Rolle Serviceplanadministrator in AppSync
erforderlich.
eine zuvor gemountete Kopie durch. Eine Ausnahme ist eine Kopie, die nach Bedarf und
nicht durch den Serviceplan gemountet wurde. In diesem Fall wird kein Unmount-Vorgang
für die nach Bedarf gemountete Kopie vorgenommen.
aktiviert bzw. deaktiviert werden.
Kopie mounten
In der Phase „Mount copy“ wird die Kopie gemountet. Diese Phase kann aktiviert oder
deaktiviert werden.
188
Feld
Beschreibung
Mount on
Server
Der Server, auf dem die Kopie gemountet werden soll. Zur Auswahl
stehen nur die Nodes der Cluster- oder eigenständigen Hosts.
Mount with
access
Typ des Zugriffs, mit dem die Kopie gemountet werden soll.
Mount path
Der Default Mount Path ist %SystemDrive%\AppSyncMounts\%
%ProdServerName%%. Um den Wert von einer WindowsUmgebungsvariable im Mount-Pfad anzugeben, begrenzen Sie den
Variablennamen mit einem Prozentzeichen (%). Der Standardpfad
enthält auch eine AppSync-Variable (ProdServerName), die mit zwei
Prozentzeichen (%) begrenzt ist. Die folgenden Zeichen sind im Pfad
Feld
Beschreibung
nicht zulässig: < > : " / | ? * . Der Mount-Pfad kann auch Same as
Original Path sein. Diese Option ist jedoch nicht verfügbar, wenn der
Mount-Host mit dem Produktionshost identisch ist.
Desired SLO
(nur VMAX 3)
Image access
mode (during
RecoverPoint
mount)
Use Dedicated
Storage Group
Wählen Sie die gewünschten SLO für die Ziel-LUN. Wenn eine
Speichergruppe für den Mount-Host mit der gewünschten SLO
vorhanden ist, wird die LUN der Speichergruppe hinzugefügt. Wenn
sie nicht vorhanden ist, fügt AppSync sie einer Speichergruppe hinzu,
die für den Host maskiert ist.
l
l
Rollback wird mit RP-VMAX und RP-XtremIO nicht unterstützt.
l
Diese Option ist nicht für die Verarbeitung von Prozessen mit
hoher Auslastung vorgesehen. Virtueller Zugriff mit RPVMAX und
l
l
Standardmäßig aktiviert. Wenn diese Option aktiviert ist, kann
AppSync eine dedizierte VMAX- oder VNX-Speichergruppe für ein
Mounten erzwingen. (Eine dedizierte VMAX- oder VNXSpeichergruppe enthält nur den ausgewählten Mount-Host). Das
Mounten schlägt fehl, wenn Sie auf einen Node eines Clusters
mounten, der sich in einer Speichergruppe befindet, die mit
anderen Nodes gemeinsam verwendet wird.
Hinweis
Verwenden Sie diese Option, um die Kopie auf einen Node zur
Validierung der Kopie oder zum Sichern auf Band zu mounten. In
diesem Szenario benötigen Sie zwei Speichergruppen. Eine
verwendet wird, dediziert und die andere Speichergruppe ist für
den Rest der Nodes im Cluster vorgesehen. Beide
Speichergruppen enthalten den gemeinsamen Speicher für das
Cluster.
l
Mounten nicht.
Kopie mounten
189
Mount-Einstellungen in einem Serviceplan außer Kraft setzen
Wenn es mehrere Dateisysteme gibt, für die der gleiche Plan abonniert wurde, können Sie
verschiedene Mount-Einstellungen für jedes Dateisystem auswählen und damit die
allgemeinen Mount-Einstellungen außer Kraft setzen.
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Service Plans > FileSystems und klicken Sie auf einen der Pläne in
der Liste.
Die Liste der Dateisysteme enthält alle Dateisysteme, für die dieser Plan abonniert
wurde. In den Mount-Einstellungen werden die Standardeinstellungen angezeigt.
4. Wählen Sie das Dateisystem aus, dessen Einstellungen Sie außer Kraft setzen
Halten Sie zur Auswahl mehrerer Dateisysteme die Umschalt- oder Strg-Taste
gedrückt.
5. Wählen Sie im Dialogfeld Mount Copy Overrides die Optionen nur für jene
Einstellungen aus, die Sie außer Kraft setzen möchten.
Wenn Sie beispielsweise eine Kopie auf dem Produktionshost mounten möchten,
würden Sie Use new signature aus der Drop-down-Liste Mount Signature auswählen.
In der ersten Spalte der Zeile des Dateisystems, dessen Standard-MountEinstellungen Sie geändert haben, wird ein Bleistiftsymbol angezeigt.
7. Wählen Sie die Dateisysteme aus und klicken Sie auf Use Default Settings, um die
Systeme auf die Standardeinstellungen zurückzusetzen.
Post-mount script
auszuführen.
190
Mounten einer Kopie mit dem Assistenten für das Mounten von
Dateisystemen
Verwenden Sie den Assistenten für das Mounten von Dateisystemen, um Point-in-TimeMounts für RecoverPoint-Kopien zu erstellen.
Bevor Sie beginnen
Für diese Aufgabe ist die Datenadministratorrolle in AppSync erforderlich.
Bei UNIX sollte das Feld File einen vollständigen Pfad zu den Skripten enthalten, die
ausgeführt werden sollen. Sie benötigen die Benutzeranmeldedaten zur Ausführung des
Skripts.
Führen Sie die folgenden Schritte aus:
Vorgehensweise
1. Navigieren Sie auf der AppSync-Konsole zu File systems > Copies, um die verfügbaren
Kopien anzuzeigen.
2. Wählen Sie eine zu mountende Kopie aus und klicken Sie dann auf Mount.
Die Seite Select Copy to Mount des Assistenten für das Mounten von Dateisystemen
wird gestartet.
Sie können eine Kopie auswählen, die gemountet werden soll. Standardmäßig wird
die Kopie hervorgehoben, die Sie vor der Auswahl von Mount ausgewählt haben. Die
anderen Kopie-Instanzen werden jedoch ebenfalls angezeigt.
3. Wählen Sie die Kopie aus, die Sie mounten möchten, und klicken Sie auf Next.
Die Seite Specify Mount Settings wird gestartet, auf der Sie die Option Mount on Host
(Drop-down-Menü für das Mounten auf Host) und einen Speicherort des Mount-Pfads
mit der Option To original path oderMount to alternate path (Drop-down-Menü)
auswählen können. Der Mount-Pfad ist der Speicherort, an dem die Kopie auf dem
Mount-Host gemountet wird. AppSync zeigt standardmäßig den Pfad des
ausgewählten Mount-Host an. Sie können die Kopie auch bearbeiten und an einem
benutzerdefinierten Speicherort mounten.
Außerdem können Sie Mount-Optionen auswählen, einschließlich Mount with
access(schreibgeschützt oder Lese-/Schreibzugriff) und Image access mode (Dropdown-Menü). Mit dem Image-Zugriffsmodus können Sie das Dateisystem mit dem
geeigneten Zugriffsmodus für den Fall mounten, dass die ausgewählte Kopie ein
RecoverPoint-Lesezeichen ist.
Bei VMAX 3-Arrays wird eine SLO-Drop-down-Liste angezeigt. Sie können das Service
Level-Ziel (Service Level Objective, SLO) für die Mount-Kopie auswählen. Wenn eine
Speichergruppe für den Mount-Host mit der gewünschten SLO vorhanden ist, fügt
AppSync die LUN zur Speichergruppe hinzu. Wenn diese Speichergruppe nicht
vorhanden ist, fügt AppSync die LUN einer Speichergruppe hinzu, die für den Host
maskiert ist. Wenn eine Speichergruppe zur Auswahl von Zielgeräten konfiguriert ist,
entfernt AppSync die Geräte aus der Speichergruppe zum Zeitpunkt des MountVorgangs und fügt sie der Speichergruppe für den Mount-Host hinzu. Die Geräte
werden der ursprünglichen Speichergruppe hinzugefügt, wenn die Kopie abgelaufen
ist.
4. Geben Sie die Informationen zum Mount-Speicherort und Mount-Optionen ein, und
klicken Sie auf Next.
Die Seite Summary wird gestartet.
5. Prüfen Sie, ob die Mount-Angaben korrekt sind, und klicken Sie auf Finish.
Mounten einer Kopie mit dem Assistenten für das Mounten von Dateisystemen
191
Die Seite Results mit Informationen zum Mount-Ergebnis wird gestartet.
Ändern des Mount-Punkts für ein betroffenes Dateisystem
Führen Sie dieses Verfahren aus, um den Mount-Punkt für ein betroffenes Dateisystem
manuell zu ändern.
Angenommen, VG1 ist die Quell-Volume-Gruppe.
Vorgehensweise
1. Rufen Sie die Liste der LVs mithilfe des Befehls lsvg -l VG1 ab und prüfen Sie,
welche Dateisysteme einen Mount-Punkt im Verzeichnis /tmp/EMCAppsync **
anzeigen.
2. Führen Sie den Befehl chfs -m <Original MT Pt> /tmp/
EMCAppsync6922/vg1_logs dort aus, wo <Original Mt Pt> der Mount-Punkt
ist, auf dem das Dateisystem ursprünglich gemountet wurde.
3. Führen Sie fsck auf dem logischen Quell-Volume fsck -y /dev/fslv01 aus.
4. Führen Sie den Mount-Befehl mit dem logischen Protokoll-Volume aus und
vergewissern Sie sich, ob die Quelle erfolgreich gemountet wurde mount -v jfs2
-o rw,log=/dev/loglv00 /dev/fslv01 <Orig Mt Pt>.
Unmounten einer Dateisystemkopie
Bevor Sie beginnen
Sie können eine Kopie nur aus einer Liste von Kopien unmounten, die für ein Dateisystem
erstellt wurde.
Vorgehensweise
1. Navigieren Sie von den Seiten Copy Management oder Service Plan zur Seite Copies:
l
Copy Management > FileSystems> Wählen Sie den Server aus, der das Dateisystem
hostet, das Sie unmounten möchten, und wählen Sie dann das Dateisystem mit
der Kopie aus, die Sie unmounten möchten.
l
Service Plans > File systems> Wählen Sie einen Serviceplan aus und dann die
Registerkarte Copies.
2. Wählen Sie aus der Liste der Kopien die Kopie aus und klicken Sie auf Unmount über
die Schaltfläche im unteren Teil der Seite.
Das Dialogfeld Unmount Confirmation zeigt die Kopien von anderen Dateisystemen
an, die zusammen mit der ausgewählten Kopie gemountet wurden, die Sie
unmounten möchten.
angezeigt werden.
Auf der Seite Unmount wird der Fortschritt des Unmount-Vorgangs angezeigt. Der
zugeordnet sind.
192
Wenn es mehrere Dateisysteme gibt, für die der gleiche Plan abonniert wurde, können Sie
verschiedene Mount-Einstellungen für jedes Dateisystem auswählen und damit die
allgemeinen Mount-Einstellungen außer Kraft setzen.
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Service Plans > FileSystems und klicken Sie auf einen der Pläne in
der Liste.
Die Liste der Dateisysteme enthält alle Dateisysteme, für die dieser Plan abonniert
wurde. In den Mount-Einstellungen werden die Standardeinstellungen angezeigt.
4. Wählen Sie das Dateisystem aus, dessen Einstellungen Sie außer Kraft setzen
Halten Sie zur Auswahl mehrerer Dateisysteme die Umschalt- oder Strg-Taste
gedrückt.
5. Wählen Sie im Dialogfeld Mount Copy Overrides die Optionen nur für jene
Einstellungen aus, die Sie außer Kraft setzen möchten.
In der ersten Spalte der Zeile des Dateisystems, dessen Standard-MountEinstellungen Sie geändert haben, wird ein Bleistiftsymbol angezeigt.
7. Wählen Sie die Dateisysteme aus und klicken Sie auf Use Default Settings, um die
Systeme auf die Standardeinstellungen zurückzusetzen.
Wiederherstellen eines Dateisystems
Verwenden Sie den Assistenten zur Wiederherstellung von Dateisystemen, um eine
vorhandene Dateisystemkopie wiederherzustellen.
Vorgehensweise
1. Navigieren Sie auf der AppSync-Konsole zu Copy Management > File systems.
Die Seite Hosts des Dateisystems startet und zeigt die verfügbaren Server an.
2. Wählen Sie den Server aus, auf dem die Dateisysteme für die Wiederherstellung
enthalten sind, um die Seite File Systems zu starten.
3. Wählen Sie das Dateisystem aus, das Sie wiederherstellen möchten (die Option
Select Allwird unten links auf der Seite angezeigt) und klicken Sie dann im Menü
Recover im unteren linken Bereich der Seite File System auf Restore.
Damit wird der Assistent zur Wiederherstellung von Dateisystemen gestartet. Alle
geschützten Kopien werden im Assistenten aufgeführt. Sie können jeweils immer nur
eine Dateisystemkopie zur Wiederherstellung auswählen. Das Datum der Kopie, der
193
Name des Dateisystems, der Name des Servers, der Serviceplan sowie der Kopietyp
werden für jede Kopie angezeigt.
4. Wählen Sie die wiederherzustellende Dateisystemkopie aus und klicken Sie auf Next.
Die Seite Restore Warnings wird gestartet. Die Seite Restore Warnings zeigt das
Dateisystem an, das zur selben Consistency Group oder Volume-Gruppe gehört, in der
die Kopie wiederhergestellt wird. Wenn dieses Dateisystem sowie die ausgewählte
Dateisystemkopie geschützt sind, wird dieses Dateisystem überschrieben.
Auf der Seite Restore Warnings werden zudem alle Anwendungen angezeigt, die im
wiederherzustellenden Dateisystem installiert sind.
5. Lesen Sie sich die Warnungen durch und klicken Sie auf das Kontrollkästchen "I have
read warnings". Klicken Sie dann auf Next, um mit der Wiederherstellung fortzufahren.
Durch diese Aktion wird die Seite Summary des Assistenten gestartet.
6. Wenn die Informationen auf der Seite Summary korrekt sind, klicken Sie auf Finish.
Die Seite Results wird geladen, auf der Sie die Wiederherstellungsergebnisse
anzeigen können.
Die automatische Wiederherstellung einer XtremIO 4.0-Kopie (Mindestversion) mit
AppSync 2.2.2 und höher wird unterstützt. In diesem Abschnitt wird erläutert, wie Sie
eine Kopie auf einer XtremIO-Version, die niedriger als 4.0 ist, mit AppSync 2.2 bis 2.2.1
manuell wiederherstellen können.
Bevor Sie beginnen
Weitere Informationen zur automatischen Wiederherstellung finden Sie unter
Wiederherstellen einer Dateisystemkopie auf Seite 193.
Zum Erzielen einer manuellen, granularen Wiederherstellung von Dateien und Ordnern in
einem Dateisystem, zum Mounten einer Kopie des Dateiystems sowie zum Verwenden
von selektiven Datei-/Ordnerkopien benötigen Sie die folgende Konfiguration:
l
Hostdateisystem, das sich auf XtremIO-Speicher befindet
l
AppSync-Serviceplan, mit dem das Dateisystem repliziert wird
Vorgehensweise
1. Wählen Sie auf der AppSync-Konsole die Option Service Plans > Filesystem sowie den
gewünschten Serviceplan aus, z. B.Bronze.
2. Deaktivieren Sie alle Servicepläne, deren Ausführung geplant ist, einschließlich des
Dateisystems, das Sie wiederherstellen möchten.
Durch diese Aktion wird verhindert, dass eine Kopie während des
Wiederherstellungsverfahrens erstellt wird.
3. Klicken Sie auf mount to default location, um die Kopie zu mounten, die Sie zur
Wiederherstellung auf dem Produktionshost verwenden möchten.
Mounten der Kopie mit Lese-/Schreibzugriff.
4. Führen Sie je nach Betriebssystem einen der folgenden Schritte aus:
a. Unter Windows: Notieren Sie sich die NAA-Kennung für das Produktions-Volume
und den gemounteten Snapshot, und entfernen Sie dann den
Laufwerksbuchstaben des Produktionsgeräts auf dem Produktionshost.
b. Linux/AIX: Unmounten Sie das Dateisystem.
194
5. Weisen Sie den Laufwerksbuchstaben der gemounteten Snapshot-Kopie auf dem
Produktionshost zu (Windows) oder mounten Sie das Dateisystem (Linux/AIX) erneut.
6. Wählen Sie Remove für die gemountete Kopie aus.
Durch diese Aktion wird die Kopie aus der AppSync-Datenbank ohne Änderung des
Snapshots auf dem Mount-Host oder dem XtremIO-Speicherarray entfernt. Das
System zeigt eine Meldung an, in der diese Aktion erläutert wird.
7. Wenn der Produktionshost eine virtuelle Maschine ist, verwenden Sie die NAAKennung, die Sie sich zuvor notiert haben, um die alte Produktions-LUN aus dem
Bestand des Hosts zu entfernen.
Durch diese Aktion wird das Volume vom Host entfernt (erneutes Scannen des
Hostgeräts kann erforderlich sein). Auf dem Produktionshost ist keine weitere Aktion
erforderlich.
Abbildung 26 Virtuelle Maschine: Entfernen Sie alte Produktions-LUN
8. Entfernen Sie die alte Produktions-LUN aus der Initiatorgruppe.
9. Verschieben Sie den gemounteten Snapshot aus dem /AppSyncSnapshots-Ordner
zum Ordner der Produktions-LUN, die Sie ersetzen.
Verschieben Sie den Snapshot, der gemountet wurde (den Snapshot, der derzeit für
die Initiatorgruppe des Produktionshosts oder die ESX-Initiatorgruppe maskiert ist).
Nachdem Sie den Vorgang abgeschlossen haben, werden die Produktions-LUN und
der Snapshot angezeigt.
195
Abbildung 27 Produktions-LUN und Snapshot
Das eine ist ein Snapshot. Das andere ist ein Volume.
Abbildung 28 Ein Snapshot und ein Volume
10. Entfernen Sie das Volume, das Sie ersetzen möchten.
Aus dem Snapshot wird ein Volume.
Abbildung 29 Aus Snapshot wird Volume
11. Benennen Sie den Snapshot (jetzt ein Volume) auf den Namen des Volume um, das
Sie ersetzt haben, und führen Sie dann den Dateisystem-Serviceplan zur Erstellung
eines Snapshot des „wiederhergestellten“ Dateisystems aus.
196
KAPITEL 9
l
l
l
l
l
l
Konfigurationsvoraussetzungen ......................................................................... 198
Erkennen von Rechenzentren ............................................................................. 201
Überlegungen zum Mounten einer VMFS-Kopie ...................................................211
Wiederherstellen eines Datenspeichers aus einer Kopie......................................214
Wiederherstellen einer virtuellen Maschine aus einer Kopie................................ 218
Wiederherstellung von Dateien und Ordnern mit VMFS- oder NFS-Datenspeichern
........................................................................................................................... 222
197
Konfigurationsvoraussetzungen
Mit AppSync können Sie Kopien in VMware vStorage VMFS und NFSDatenspeicherkonfigurationen erstellen, mounten und wiederherstellen. Das Erfüllen der
Konfigurationsvoraussetzungen ist für das Einbinden von AppSync im VMware vStorage
VMFS-Schutz erforderlich. Konfigurieren Sie RecoverPoint und VMware gemäß der
Produktdokumentation.
VMware-Konfigurationsvoraussetzungen
l
Vmwarevcenter-Server muss in der Umgebung verwendet werden.
l
AppSync unterstützt bei VMware die Verwendung von VSS mit VM-Snapshots, wenn
eine unterstützte Version von vSphere installiert und die VMware Tools-Einrichtung
auf der virtuellen Maschine auf dem VMFS vorhanden ist, die Sie replizieren.
Informationen hinsichtlich der auf VSS-bezogenen Eigenschaften in einer AppSyncKopie finden Sie in der VMware-Dokumentation. Wenden Sie sich an VMware
bezüglich aller Fragen, die sich auf VSS in dieser Konfiguration beziehen.
l
Wenn eine Konfigurationsänderung auf dem vCenter Server vorliegt, führen Sie eine
Erkennung von Rechenzentren im vCenter Server auf der AppSync-Konsole aus, bevor
Sie einen Datenspeicher schützen. Sorgen Sie dafür, dass die VMFS-UUID im Bestand
des virtuellen Zentrums aller Rechenzentren eindeutig ist.
Hinweis
Sie können auch Kopien von VMware-Datenspeichern mit dem VSI for VMware vSphere
Web Client erstellen und managen. Das Plug-in ist als separater Download auf der
AppSync-Onlinesupportseite unter support.EMC.com verfügbar.
RecoverPoint-Konfigurationsvoraussetzungen
l
Konfigurieren Sie den RecoverPoint-Schutz (CDP/CRR/CLR) für die Produktions-LUNs
vor der Bereitstellung von AppSync. Informationen zum Erstellen von Consistency
Groups und Definieren von Replikationssätzen finden Sie in der RecoverPointDokumentation.
l
In einem ESX-Cluster sollten Ziel-LUNs für alle ESX-Hosts im Cluster sichtbar gemacht
werden.
l
Der AppSync-Server muss über das Netzwerk eine Verbindung zur RPA aufbauen.
VMware vStorage VMFS-Anforderungen
Einige Überlegungen gelten, wenn AppSync in eine VMware-Umgebung für den Schutz
von VMware-Datenspeichern eingeführt wird.
Alle VMware-spezifischen Vorgänge erfolgen über Vmware vCenter Server.
AppSync kann so konfiguriert werden, dass vCenter Server-Anmeldedaten erforderlich
sind, um den Schutz eines bestimmten VMFS aus Sicherheitsgründen zu ermöglichen.
Wenn Sie AppSync nicht anweisen, diese Funktion zu unterlassen, nimmt AppSync ein
VMware-Snapshot für jede virtuelle Maschine auf, die online ist und sich vor dem Schutz
auf dem VMFS befindet. Diese Aktion stellt die Betriebssystem-Konsistenz für das
resultierende Replikat sicher. Die folgenden Benutzerrollen für einen VirtualCenter-ESXCluster sind mit AppSync zulässig:
198
l
Administrator
l
VM-Poweruser
l
VM-Benutzer
l
Ressourcenadministrator
l
VMware-Benutzer für konsolidierte Backups
l
Datenspeicherverbraucher
l
Netzwerkadministrator
Der folgende Screenshot von „Edit Role“ zeigt die Berechtigungen, die Sie für Rollen
auswählen müssen.
VMware vStorage VMFS-Anforderungen
199
Abbildung 30 Berechtigungen für VC-Rollen für AppSync
200
AppSync unterstützt die VSS-Verwendung von VMware mit VM-Snapshots, wenn eine
unterstützte Version von vSphere installiert und VMware-Tools auf der virtuellen
Maschine auf dem VMFS, das Sie schützen möchten, vorhanden ist. Weitere
Informationen finden Sie in der VMware-Dokumentation für die Verwendung der VSSbezogenen Merkmale in der AppSync-Kopie. Wenden Sie sich an VMware bezüglich
Überlegungen, die sich in dieser Konfiguration auf VSS beziehen.
Wenn für virtuelle Maschinen im Datenspeicher RDMs oder iSCSI-LUNs sichtbar sind,
enthält die resultierende Kopie keine dieser LUNs. Wenn sich bei der virtuellen Maschine
andere virtuelle Laufwerke als das Startlaufwerk in anderen Datenspeichern befinden, ist
es möglich, diese Laufwerke zu erfassen, indem Sie den Serviceplan so konfigurieren,
dass er die Laufwerke virtueller Maschinen umfasst.
Erkennen von Rechenzentren
Führen Sie bei einer Änderung in der Konfiguration des vCenter Servers eine Erkennung
von Rechenzentren auf dem Vmware vCenter Server aus, um AppSync auf dem neuesten
Stand zu halten.
Bevor Sie beginnen
l
l
Es muss mindestens ein vCenter Server zu AppSync hinzugefügt werden.
Vorgehensweise
1. Navigieren Sie zu Copy Management > VMware Datacenters.
2. Klicken Sie auf der Seite VMware Datacenters auf Discover Datacenters > On Virtual
Center und wählen Sie einen vCenter Server aus, um ein Erkennen seiner
Rechenzentren auszuführen.
Optional können Sie auch einen vCenter Server durch Klicken auf Add vCenter Server
hinzufügen. Weitere Details dazu finden Sie unter Hinzufügen eines vCenter
Servers auf Seite 202.
Liste der Rechenzentren
Die oberste Ebene auf der VMware Datacenters-Seite zeigt alle Rechenzentren an, die bei
AppSync registriert sind.
Spalte
Schutzstatus des
Rechenzentrums
Beschreibung
l
Grün: Aktuelle Kopien von allen Datenspeichern im
Rechenzentrum werden erfolgreich geschützt
l
Gelb: Eine oder mehrere der aktuellen Datenspeicherkopien
im Rechenzentrum wurden mit Fehlern abgeschlossen
l
Rot: Eine oder mehrere der aktuellen Datenspeicherkopien
im Rechenzentrum wurden nicht abgeschlossen
l
"i"-Symbol: Für ein oder mehrere Datenspeicher im
Rechenzentrum wird entweder kein Serviceplan abonniert
oder Kopien werden diesen nicht zugeordnet
Name
Name des Rechenzentrums auf dem vCenter Server.
vCenter Server
Name des vCenter Servers, auf dem die Datenbank gehostet
wird.
Erkennen von Rechenzentren
201
Spalte
Beschreibung
Neueste Erkennung
Zeit, wann eine Erkennung auf dem vCenter Server zuletzt
durchgeführt wurde.
Empfänger von
Warnmeldungen
Liste der E-Mail-Aliasnamen, die E-Mail-Warnmeldungen
erhalten sollen.
Durch Klicken auf den Namen eines Rechenzentrums werden die Datenspeicher
angezeigt.
Hinzufügen eines VMware vCenter Servers
Fügen Sie einen VMware vCenter Server in AppSync hinzu, wenn eine virtuelle Maschine
als Mount-Host für eine VNX-Snapshot-Kopie verwendet wird.
Bevor Sie beginnen
l
l
Stellen Sie sicher, dass Sie die Anmeldedaten für ein Konto mit Administratorrechten
auf dem vCenter Server kennen.
Vorgehensweise
1. Wählen Sie Settings > VMware vCenter Servers.
2. Klicken Sie auf Add.
3. Geben Sie den Namen des vCenter Servers ein.
4. Geben Sie die Anmeldedaten für ein Konto ein, das über Administratorrechte auf dem
vCenter Server verfügt.
Liste der VMware-Datenspeicher
Die Liste enthält VMware-Datenspeicher, die erkannt und in der AppSync-Datenbank
gespeichert wurden.
Durch Klicken auf den Datenspeichernamen werden die Kopien des Datenspeichers
angezeigt.
Die Spalte „Service Plan“ zeigt die Pläne, die der Datenspeicher abonniert. Weitere
Details umfassen den Typ des Datenspeichers (VMFS oder NFS) und den Namen des ESXServers.
Schutz eines VMware-Datenspeichers
Sie können einen VMware-Datenspeicher schützen, indem Sie einen AppSync-VMwareServiceplan dafür abonnieren.
Der Schutzmechanismus von AppSync für Datenspeicher erfolgt über Servicepläne. Sie
können einen Serviceplan für einen Datenspeicher abonnieren und den Serviceplan
sofort ausführen oder die Ausführung zu einem späteren Zeitpunkt planen.
202
l
Wählen Sie Subscribe to Plan and Run aus, wenn Sie die ausgewählten
Datenspeicher sofort schützen möchten. Der Serviceplan wird nur für die
Datenspeicher ausgeführt.
l
planen möchten. Der Schutz für Datenspeicher, die Teil des Serviceplans sind, wird
zur geplanten Zeit ausgeführt.
l
Wählen Sie einen geeigneten Serviceplan unter Create a copy using auf der
Datenspeicherseite Copies aus.
l
Wählen Sie auf der Serviceplan-Seite für die VMware-Rechenzentren die Option Run
aus, um den gesamten Plan sofort auszuführen.
Abonnieren eines Serviceplans für VMware-Datenspeicher
Mit dem Vorgang Subscribe to Plan wird der Schutz für einen späteren Zeitpunkt geplant.
Der Schutz aller Datenspeicher, die Teil des Serviceplans sind, wird zur geplanten Zeit
ausgeführt.
Bevor Sie beginnen
Vorgehensweise
2. Klicken Sie auf ein Rechenzentrum, um dessen Datenspeicher anzuzeigen.
3. Wählen Sie aus dieser Liste den zu schützenden Datenspeicher aus.
Halten Sie zur Auswahl mehrerer Datenspeicher die Umschalt- oder Strg-Taste auf
Ihrer Tastatur gedrückt.
Plan aus.
Der ausgewählte Plan wird in der Spalte Service Plan für den Datenspeicher angezeigt.
Sofortiger Schutz von VMware-Datenspeichern
Durch den Vorgang Subscribe to Plan and Run werden einem bestehenden Serviceplan
Datenspeicher hinzugefügt und der Serviceplan wird sofort lediglich für die ausgewählten
Datenspeicher ausgeführt.
Bevor Sie beginnen
Vorgehensweise
3. Wählen Sie aus dieser Liste den zu schützenden Datenspeicher aus.
Plan and Run aus.
Das Dialogfeld Subscribe to Plan and Run wird angezeigt, in dem der Fortschritt über
die verschiedenen Phasen anzeigt wird.
Liste der geschützten virtuellen Maschinen
Die Liste enthält die virtuellen Maschinen, die zu den Datenspeichern gehören, die als
Teil einer Serviceplanausführung geschützt werden.
Klicken Sie auf den Namen der virtuellen Maschine, um die Kopien der virtuellen
Maschine anzuzeigen. Um einen Wiederherstellungsvorgang durchzuführen, wählen Sie
eine virtuelle Maschine und klicken auf Restore.
Weitere Details umfassen die Betriebssystem-Plattform auf der virtuellen Maschine, die
Version der virtuellen Maschine, den ESX-Host, auf dem sich die virtuelle Maschine
203
befindet, sowie den Pfad zur Datei der virtuellen Maschine. Im Pfad befindet sich der
Name des Datenspeichers, auf dem sich die virtuelle Maschine befindet, innerhalb der
Klammern [].
Beenden des Abonnements eines Serviceplans für Datenspeicher
Sie können das Abonnement eines Serviceplans oder aller Servicepläne beenden, die für
die Datenspeicher abonniert wurden.
Bevor Sie beginnen
Vorgehensweise
3. Wählen Sie aus dieser Liste den Datenspeicher aus, der aus einem Serviceplan
entfernt werden soll.
Sie können mehrere Datenspeicher auswählen, wenn für sie der gleiche Serviceplan
abonniert wurde. Halten Sie zur Auswahl mehrerer Datenspeicher die Umschalt- oder
Strg-Taste auf Ihrer Tastatur gedrückt.
4. Wählen Sie in der Liste Protect einen Serviceplan unter Unsubscribe from Plan aus
oder wählen Sie All aus, um die Datenspeicher aus allen Plänen zu entfernen.
Der Name des Serviceplans wird aus der Spalte Service Plan der Datenspeicher
entfernt.
VMware-Snapshots
Wenn die VM-Konsistenzoption ausgewählt ist, erstellt AppSync Snapshots aller
virtuellen Maschinen, die sich im eingeschalteten Status befinden, während der
Datenspeicher repliziert wird.
AppSync erstellt einen stillgelegten Snapshot der virtuellen Maschinen, die sich im
eingeschalteten Status befinden. VMware Tools wird verwendet, um das Dateisystem in
der virtuellen Maschine stillzulegen. Das Stilllegen eines Dateisystems ist ein Prozess,
der die Daten auf dem Laufwerk eines physischen oder virtuellen Computers in einen für
Backups geeigneten Zustand bringt. Dieser Prozess kann Vorgänge wie das Leeren von
fehlerhaften Puffern vom speicherinternen Cache des Betriebssystems auf die Festplatte
oder andere übergeordneten anwendungsspezifische Aufgaben umfassen. Wenn die VMKonsistenzoption nicht festgelegt ist, überspringt AppSync den Prozess der Erstellung
von Snapshots virtueller Maschinen.
Anzeigen von Datenspeicherkopien
Die Kopien erhalten ihren Namen anhand der Uhrzeit, zu der sie erstellt wurden.
Bevor Sie beginnen
Vorgehensweise
2. Wählen Sie ein Rechenzentrum und dann einen Datenspeicher aus, um dessen
Kopien anzuzeigen.
Sie können weitere Details zur Kopie wie Kopietyp, Mount-Status, den Status der VMKonsistenz sowie den Serviceplan im Zusammenhang mit der Kopie sehen.
204
3. Wählen Sie im Bereich Details eine Kopie zur Anzeige weiterer Details aus.
l
Registerkarte Virtual Machines: Zeigt die virtuellen Maschinen an, die Teil der
ausgewählten Datenspeicherkopie sind.
l
Registerkarte Virtual Disks: Zeigt die virtuellen Laufwerke an, die Teil der
ausgewählten Datenspeicherkopie sind.
l
Registerkarte Events: Zeigt die Events an, die aufgetreten sind, als die
Datenspeicherkopie erstellt wurde.
Anzeigen von virtuellen VM-Kopien
Sie können die Liste der Kopien für eine virtuelle Maschine basierend auf der Uhrzeit
anzeigen, zu der sie erstellt wurden.
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Copy Management > VMware Datacenter.
2. Wählen Sie ein Rechenzentrum aus und dann die Registerkarte Protected Virtual
Machines.
3. Wählen Sie eine virtuelle Maschine in der Liste aus, um deren Kopien anzuzeigen.
Die Details der Kopie, wie z. B. Größe der Kopie, Speicherplatz auf der Festplatte,
Modus der Festplatte usw., werden angezeigt.
4. Wählen Sie im Bereich Details eine Kopie zur Anzeige zusätzlicher Details aus.
l
Registerkarte Virtual Disks: Zeigt die virtuellen Laufwerke an, die Teil der
ausgewählten Kopie der virtuellen Maschine sind.
l
Registerkarte Events: Zeigt die Events an, die aufgetreten sind, als die Kopie der
virtuellen Maschine erstellt wurde.
Erstellen einer Datenspeicherkopie auf der Seite Copies
Erstellen Sie eine Kopie eines Datenspeichers durch Abonnieren eines AppSync-VMwareServiceplans für den Datenspeicher auf der Seite Copies.
Bevor Sie beginnen
Vorgehensweise
3. Klicken Sie in dieser Liste auf den Datenspeicher, um dessen Kopien anzuzeigen.
4. Wählen Sie aus der Liste Create a copy using den entsprechenden Serviceplan aus.
Der Serviceplan wird sofort für den Datenspeicher ausgeführt.
Ablaufen lassen einer Datenspeicherkopie nach Bedarf
Beim Ablaufen lassen einer Kopie wird diese aus der AppSync-Datenbank entfernt und
dadurch kann je nach Replikationstechnologie und Kopiestatus Speicherplatz freigesetzt
werden.
Bevor Sie beginnen
205
Vorgehensweise
1. Wählen Sie die Optionen Copy Management > VMware Datacenters aus.
3. Klicken Sie auf den Datenspeicher, dessen Kopien Sie ablaufen lassen möchten.
lassen möchten.
Darüber hinaus können Sie diese Aktion unter der Registerkarte Copies des
Serviceplans ausführen.
5. Wählen Sie Expire aus.
6. Überprüfen Sie, ob Sie die Kopie, die Sie ausgewählt haben, und alle zugehörigen
aufgeführten Kopien ablaufen lassen möchten, und bestätigen Sie dies.
Servicezeitplan
l
l
l
l
n
n
n
n
n
n
n
werden
n
ist Mitternacht.
n
n
n
Sie können verschiedene Planungen für einzelne Datenspeicher, für die ein Serviceplan
abonniert wurde, durch außer Kraft setzen der allgemeinen Wiederholungseinstellungen
festlegen.
Bevor Sie beginnen
206
Vorgehensweise
3. Notieren Sie sich im Bereich Plan Startup Defaults auf der rechten Seite den
Sie können die Liste aller Datenspeicher anzeigen, für die der Plan abonniert wurde.
5. Wählen Sie einen oder mehrere Datenspeicher aus und klicken Sie auf Override
Schedule.
6. Legen Sie im Dialogfeld Override Schedule die auf Ihren Anforderungen basierende
Planung fest und klicken Sie auf OK.
ausgewählt wurde und die Regeleinstellung Run at 12:00 AM am 1st day of every
month festgelegt wurde, können Sie die Uhrzeit und den Tag für die einzelnen
Datenspeicher außer Kraft setzen.
gesetzt wurden.
Anwendungserkennung
Vor der Erstellung der Kopie führt AppSync eine Erkennung auf den ausgewählten
Datenspeichern durch und aktualisiert die AppSync-Datenbank, wenn Änderungen in der
Konfiguration des vCenter Server vorhanden sind.
deaktiviert werden.
Anwendungszuordnung
deaktiviert werden.
Kopie erstellen
Die Phase „Create Copy“ erstellt eine Kopie basierend auf dem vom Benutzer
angegebenen bevorzugten Speichertyp.
Diese Phase gibt den Typ der vorzunehmenden Datenspeicherkopie und die
Speichereinstellungen für die Kopien an. Die Kopiephase erstellt eine lokale Kopie, eine
Remote-Kopie oder eine lokale und eine Remote-Kopie je nachdem, ob Sie den Bronze-,
Silber- oder Gold-Serviceplan ausgewählt haben.
Weitere Informationen zu den Serviceplankopien finden Sie unter Übersicht:
Serviceplan auf Seite 10.
207
Datenspeicherkopie-Optionen
Wählen Sie den Kopietyp, die virtuellen Maschinen, die für Snapshots ignoriert werden
sollen, die Speichervoreinstellungen und die Anzahl der Snapshot-Kopien, die
aufbewahrt werden sollen.
l
Konsistenz beim Kopieren
VM Consistent erstellt eine Kopie der Datenspeicher im Serviceplan,
einschließlich ausgeführter Programme, Prozesse und sogar Fenster, die zum
Zeitpunkt des Snapshot geöffnet waren. Maximum Simultaneous VM
Snapshots ist die Anzahl der gleichzeitigen Snapshots aller vorhandenen VMs.
Der Standardwert ist vier Snapshots.
Crash Consistent erstellt eine Kopie der Datenspeicher im Serviceplan.
Absturzkonsistente Kopien beinhalten alles mit Ausnahme der Daten, die zum
Zeitpunkt der Erstellung des Snapshots im Arbeitsspeicher waren.
Über den Ignore VM Snapshots for VMs-Link können Sie virtuelle
Maschinen vom Dataspeicher wählen, der dem Serviceplan hinzugefügt wurde.
Die ausgewählten VMs werden bei der Aufnahme von VMware-Snapshots
während der Ausführung des Serviceplans ignoriert.
Include Virtual Machine Disk enthält alle Datenspeicher, die den
virtuellen Maschinen zugeordnet sind, die auf den geschützten Datenspeichern
ausgeführt werden. Beispielsweise abonniert Datastore DS1 den Serviceplan. Die
virtuelle Maschine VM1, die Teil von DS1 ist, hat virtuelle Laufwerke in den
Datenspeichern DS2 und DS3. Wenn der Serviceplan ausgeführt wird, werden die
Datenspeicher DS2 und DS3 zusammen mit DS1 geschützt. Die Datenspeicher
DS2 und DS3 abonnieren den Serviceplan jedoch nicht.
l
Storage Ordered Preference: die gewünschte Reihenfolge der Speichertechnologie,
die bei der Erstellung von Kopien zu verwenden ist. Verwenden Sie die Schaltflächen
Move Up und Move Down. Wenn möglich werden Kopien unter Verwendung der
ersten Technologievoreinstellung erstellt. Wenn die Bedingungen so sind, dass die
erste Technologie nicht mehr verwendet werden kann, werden alle verbleibenden
Kopien stattdessen in der nächsten Voreinstellung verarbeitet. Wenn die erste
Voreinstellung beispielsweise ein Lesezeichen war, aber nicht alle Anwendungsdaten
im Serviceplan RecoverPoint zugeordnet werden konnten, dann verwendet AppSync
stattdessen VNX-Snapshots.
Hinweis
Ein einzelner Serviceplan kann eine Mischung aus VNX Block-, VNX File- und
RecoverPoint-Replikationsobjekten enthalten. Wenn Sie beispielsweise über einen
Bronze-Serviceplan für VMware verfügen, können die Datenspeicher eine Mischung
von RecoverPoint-, VNX File- und VNX Block-Replikation sein.
l
Expiration: die maximale gewünschte Anzahl von RecoverPoint-, VNX- und VNX-FileSnapshot-Kopien, die gleichzeitig vorhanden sein können.
Automatischer Ablauf von RecoverPoint-, XtremIO-, VNX- und VNX File-, VMAX-, undViPR
Controller-Snapshot-Kopien
maximale Anzahl der Snapshot-Kopien an, die gleichzeitig vorhanden sein können.
Wenn der Wert „Always keep x copies“ erreicht wird, laufen ältere Kopien ab, um freien
Speicher für die nächste Kopie in der Rotation zu gewinnen. Fehlgeschlagene Kopien
werden dabei nicht gezählt. AppSync lässt die älteste Kopie erst ablaufen, wenn der
Ersatz erfolgreich erstellt wurde. Wenn beispielsweise die Anzahl der aufzubewahrenden
Kopien 3 beträgt, lässt AppSync die älteste Kopie nicht ablaufen, bis die vierte Kopie
erfolgreich erstellt wurde.
208
Diese Einstellung ist unabhängig von den VNX Pool Policy-Einstellungen in Unisphere
zum automatischen Löschen der ältesten Snapshots. Der Serviceplanadministrator sollte
mit dem Speicheradministrator zusammenarbeiten, um sicherzustellen, dass in den VNX
Pool Policy-Einstellungen die Unterstützung für die angegebene Anzahl von SnapshotKopien für die Anwendung aktiviert ist, die sich in diesem Pool befindet.
l
l
Eine Kopie, die das einzige Replikat eines Datenspeichers enthält, läuft nicht ab.
Hinweis
werden beibehalten, bis die Lesezeichen aus der RecoverPoint-Appliance ablaufen.
statt durch den Serviceplan gemountet wurde. Ein Unmount-Vorgang wird für die nach
Bedarf gemountete Kopie nicht durchgeführt.
Keine Benutzereinstellungen sind mit dieser Phase verknüpft und diese Phase kann
aktiviert oder deaktiviert werden.
Kopie mounten
In der Phase „Mount Copy“ werden alle Datenspeicherkopien gemountet, die durch diese
Ausführung des Serviceplans erstellt wurden.
Die Einstellungen Mount Copy Defaults für die Kopie, die gemountet werden soll, hängen
vom Serviceplan ab. Andere Mount-Einstellungen bestimmen den Mount-Host, den
Zugriffsmodus und die Mount-Signatur.
Diese Phase kann entweder aktiviert oder deaktiviert werden.
Allgemeine Einstellungen:
l
Mount on host: Führt alle ESX-Server auf, die in den registrierten vCenter Servers
erkannt wurden.
l
Mount Signature: Listet Use original signature und Use new signature zur Auswahl.
Wenn Use new signature ausgewählt ist, führt AppSync nach dem Mounten einen
erneuten Signaturvorgang für das VMFS-Volume durch. Dies gilt nur für VMwareVMFS-Datenspeicher.
l
Cluster Mount: Wählen Sie „Yes“ oder „No“.
RecoverPoint Settings:
l
Image access mode (beim Mounten von RecoverPoint):
l
Logged Access:
Verwenden Sie diese Mount-Option, wenn die Integritätsprüfung das Scannen von
großen Bereichen der replizierten Volumes umfasst.
l
Virtual Access with Roll:
Stellt nahezu sofortigen Zugriff auf die Kopie bereit, aktualisiert jedoch auch das
replizierte Volume im Hintergrund. Wenn die replizierten Volumes am angeforderten
Point-in-Time liegen, wechselt die RPA transparent zum direkten Replikat-VolumeZugriff, wodurch die Verarbeitung von Prozessen mit hoher Auslastung ermöglicht
wird.
209
l
Virtual Access:
l
Desired Service Level Objective (SLO): Gibt die erforderlichen VMAX 3 Service-LevelZiele an. SLO definiert den Betriebsbereich für die Servicezeit einer Speichergruppe.
VNX File-Einstellungen: Diese Option ist nur für VMware VNXFile-Datenspeicher
verfügbar.
l
Mount Copy with access: Wählen Sie den Zugriffstyp aus, mit dem die Kopie
gemountet werden soll – Lese-/Schreib- oder nur Schreibzugriff.
Wenn es mehrere VMware-Datenspeicher gibt, für die der gleiche Plan abonniert wurde,
können Sie verschiedene Mount-Einstellungen für jeden Datenspeicher auswählen und
damit die allgemeinen Mount-Einstellungen außer Kraft setzen.
Bevor Sie beginnen
Vorgehensweise
1. Navigieren Sie zu Service Plans > VMware Datacenters und klicken Sie auf einen der
Pläne aus der Liste.
Die Liste der Rechenzentren enthält alle vCenter-Rechenzentren, für deren
Datenspeicher dieser Plan abonniert wurde. In den Mount-Einstellungen werden die
Standardeinstellungen angezeigt. Darüber hinaus wird bei VMAX v3-Datenspeichern
SLO-Service-Level-Ziel als weitere Option angezeigt.
4. Wählen Sie den Datenspeicher aus, dessen Einstellungen Sie außer Kraft setzen
5. Wählen Sie im Dialogfeld Mount Copy Overrides die Optionen nur für jene MountEinstellungen aus, die Sie außer Kraft setzen möchten.
In der ersten Spalte der Zeile des Datenspeichers, dessen Standard-MountEinstellungen Sie geändert haben, wird ein Bleistiftsymbol angezeigt.
7. Um die Datenspeicher auf die Standardeinstellungen zurückzusetzen, wählen Sie die
Datenspeicher aus und klicken Sie auf Use Default Settings.
Kopie unmounten
Die finale Phase im Serviceplan führt einen Unmount-Vorgang für die Kopie durch.
Diese Phase wird deaktiviert, wenn die Phase Unmount previous copy aktiviert ist. Es
sind keine Benutzereinstellungen mit dieser Phase verknüpft.
210
Überlegungen zum Mounten einer VMFS-Kopie
Wenn Sie eine VMFS-Kopie auf einen alternativen ESX-Server mounten, führt AppSync
alle notwendigen Aufgaben durch, um VMFS zum ESX-Server sichtbar zu machen.
l
Nachdem diese Aufgaben abgeschlossen sind, müssen weitere
Administrationsaufgaben wie das Neustarten der virtuellen Maschinen und
Anwendungen von Skripten oder durch manuelles Eingreifen durchgeführt werden.
l
Für das Mounten von Datenspeichern und virtuellen Laufwerken in ESXi 5.x- und
RecoverPoint 4.0-Umgebungen, deaktivieren Sie die Hardwarebeschleunigung, um
sicherzustellen, dass das Mounten mit virtuellen Zugriffstypen erfolgreich ist. Weitere
Informationen finden Sie im Knowledgebase-Artikel 2006858.
Mounten einen Datenspeicherkopie nach Bedarf
Sie können einen Mount-Vorgang nach Bedarf für eine Datenspeicherkopie auf der Seite
Copies des Datenspeichers, unter der Registerkarte Copies des Serviceplans oder auf der
Seite Datastore eines Rechenzentrums starten.
Bevor Sie beginnen
Vorgehensweise
1. Wählen Sie in der Pop-up-Schaltfläche Recover auf der Seite Datastore oder der Seite
Copies oder unter der Registerkarte Copies des Serviceplans die Option Mount a Copy
aus.
2. Verwenden Sie die Filter Copies oder Service Plan, um die entsprechende Kopie zum
Mounten auszuwählen.
3. Wählen Sie die Kopie aus, die gemountet werden soll.
in AppSync vor dem von Ihnen ausgewählten Zeitpunkt verfügbar sein.
Zeitstempel auszuwählen, und wählen den Speicherort der Kopie aus (remote oder
lokal). Wählen Sie Remote aus, um eine Remote-Kopie zu mounten oder local, um
eine lokale Kopie zu mounten. Bei der hier angezeigten Zeit handelt es sich um die
Uhrzeit der AppSync-Konsole. Wenn sich die Konsole in einer anderen Zeitzone als die
Kopien aus, die Sie mounten möchten. Die hier aufgeführten Kopien gehören zu
anderen Datenspeichern, die zur selben Zeit geschützt waren und sich im selben
Rechenzentrum wie die von Ihnen im vorherigen Schritt ausgewählte Kopie befinden.
5. Gehen Sie auf der Seite Select Mount Settings folgendermaßen vor:
a. Wählen Sie aus der Liste Mount on Host den Host aus, auf dem die Kopie
gemountet werden soll.
Alle ESX-Server unter dem vCenter-Server, die in AppSync registriert sind, werden
als Kandidaten für mögliche Mount-Hosts aufgeführt. Wenn ein ausgewählter ESX
zu einem ESX-Cluster gehört, wird ein weiteres Feld, und zwar Cluster Mount,
angezeigt, für das Yes oder No festgelegt werden kann. Wenn der ESX-Server zu
Überlegungen zum Mounten einer VMFS-Kopie
211
einem Cluster gehört, haben Sie auch die Möglichkeit, ihn auf allen Nodes des
Clusters oder nur auf dem von Ihnen ausgewählten Mount-Host zu mounten.
b. Wählen Sie aus der Liste Mount Signature eine dieser Optionen aus: Use new
signature Use original signature. Dies gilt nur für VMware VMFS-Datenspeicher.
c. Wählen Sie im Falle einer RecoverPoint-Kopie aus der Liste Image Access Options
eine dieser Optionen aus:
l
Integritätsprüfung das Scannen von großen Bereichen der replizierten Volumes
umfasst. Protokollierter Zugriff ist die einzige verfügbare Option, wenn Sie auf
den Produktionshost mounten.
l
Virtual access with roll: Bietet nahezu sofortigen Zugriff auf die Kopie,
aktualisiert jedoch auch das replizierte Volume im Hintergrund. Wenn die
replizierten Volumes am angeforderten Point-in-Time liegen, wechselt die RPA
transparent zum direkten Replikat-Volume-Zugriff, wodurch die Verarbeitung
von Prozessen mit hoher Auslastung ermöglicht wird. Virtueller Zugriff mit
l
Virtual access: Bietet nahezu sofortigen Zugriff auf das Image. Virtueller Zugriff
ist für die Verarbeitung von Prozessen mit hoher Auslastung nicht vorgesehen.
Virtueller Zugriff mit RP VMAX und RP XtremIO wird nicht unterstützt.
d. Wählen Sie aus der Drop-down-Liste Mount copy with access den Zugriffstyp aus,
mit dem die Kopie gemountet werden soll: Read-only oder Read-write. Dies gilt nur
für VMware VNXFile-Datenspeicher.
e. Bei VMAX 3-Arrays wird ein SLO-Drop-down-Menü angezeigt. Sie können das
gewünschten Service Level-Ziel (Service Level Objective, SLO) für die Mount-Kopie
auswählen.
Falls eine Speichergruppe für den Mount-Host mit der gewünschten SLO
vorhanden ist, fügt AppSync die LUN zur Speichergruppe hinzu. Wenn diese
Speichergruppe nicht vorhanden ist, fügt AppSyncdie LUN zu einer
Speichergruppe hinzu, die gegenüber dem Host maskiert ist. Wenn eine
Speichergruppe zur Auswahl von Zielgeräten konfiguriert ist, entfernt AppSync die
Geräte aus der Speichergruppe zum Zeitpunkt des Mountens und fügt sie der
Speichergruppe hinzugefügt, wenn die Kopie abgelaufen ist. Nachfolgend finden
Sie ein Beispiel für das Menü Desired SLO:
212
Abbildung 31 Für VMAX 3 das gewünschte SLO auswählen
6. Überprüfen Sie auf der Seite Summary die Kopier- und Mount-Einstellungen, die Sie
auf den vorherigen Seiten festgelegt haben, und klicken Sie auf Finish, um die Kopie
zu mounten.
7. Klicken Sie auf der Seite Results auf den Link Details, um den Fortschritt der
verschiedenen Phasen mitzuverfolgen, die zum Mounten einer Kopie gehören.
Die zuletzt abgeschlossene Phase wird unten in der Liste der Phasen angezeigt.
Unmounten einer VMware-Datastore-Kopie
Bevor Sie beginnen
Sie können eine Kopie nur aus einer Liste von Kopien unmounten, die für einen
Datenspeicher erstellt wurde.
Vorgehensweise
1. Navigieren Sie von den Seiten Protection oder Service Plan zur Seite Copies:
l
Copy Management > VMware Datacenters > Wählen Sie das VMwareRechenzentrum aus, in dem der Datenspeicher gehostet ist, und wählen Sie dann
den Datenspeicher mit der Kopie aus, die Sie unmounten möchten.
l
Service Plans > VMware Datacenters > Wählen Sie einen Serviceplan aus und
wählen Sie dann die Registerkarte Copies aus.
2. Wählen Sie aus der Liste der Kopien die Datenspeicherkopie aus, und klicken Sie auf
Unmount in der Schaltfläche unten.
Das Dialogfeld Unmount Confirmation zeigt alle Kopien von anderen Datenspeichern
an, die zusammen mit der ausgewählten Kopie gemountet wurden, die Sie
unmounten möchten.
Unmounten einer VMware-Datastore-Kopie
213
angezeigt werden.
Im Fenster Unmount wird der Fortschritt des Unmount-Vorgangs angezeigt. Der
Unmount-Vorgang wird bei allen Kopien ausgeführt, die zusammen mit der
ausgewählten Kopie gemountet wurden.
Wiederherstellen eines Datenspeichers aus einer Kopie
Sie können die Wiederherstellung einer Kopie des Datenspeichers auf der Seite Copies
der Datenspeicher, unter der Registerkarte Copies der Servicepläne oder auf der Seite
Datastore eines Rechenzentrums ausführen.
Bevor Sie beginnen
l
l
Es wird empfohlen, vor der Wiederherstellung eines Datenspeichers die VMs im
Datenspeicher abzuschalten.
Vorgehensweise
1. Wählen Sie auf der Seite Datastore oder Copies oder unter der Registerkarte Service
Plan Copies die Optionen Recover > Restore aus.
Der Datenspeicher-Wiederherstellungs-Assistent wird gestartet.
Verwenden Sie die Filter Copies oder Service Plan, um die entsprechende
Uhrzeit der Konsole. Wenn sich die Konsole in einer anderen Zeitzone als der RPA
befindet, geben Sie die Uhrzeit gemäß der Serverzeitzone ein, um die Kopie
wiederherzustellen.
Wenn die ausgewählte Kopie betroffene Entitäten aufweist, wird die Seite Restore
Warnings angezeigt.
4. Lesen Sie sich die Warnmeldungen für die betroffenen Datenspeicher durch.
Aktivieren Sie das Kontrollkästchen, um Ihr Einverständnis zu erklären, dass die
anderen Entitäten zusammen mit der Kopie wiederhergestellt werden.
Sie können die zu überschreibenden Datenspeicher vor der Wiederherstellung
manuell unmounten.
Nur die RecoverPoint-Kopien weisen betroffene Entitäten auf.
5. Wählen Sie im Schritt Virtual Machine Operations die entsprechenden Aktionen aus,
die AppSync vor und nach der Wiederherstellung ausführen soll. Weitere
Informationen finden Sie unter Virtual Machine Operations auf Seite 215.
6. Überprüfen Sie auf der Seite Summary die Einstellungen, die Sie auf den vorherigen
Seiten ausgewählt haben, und klicken Sie auf Finish, um die Wiederherstellung
auszuführen.
214
VM-Vorgänge während der Wiederherstellung
AppSync kann Vorgänge auf den virtuellen Maschinen ausführen, die den zur
Wiederherstellung ausgewählten Datenspeichern zugeordnet sind.
Tabelle 21 VM-Vorgänge
VM-Vorgang
Beschreibung
VMs, die zu Beginn der
Wiederherstellung
vorhanden sind
Power down VMs at start of restore: Wenn die virtuellen
Ausführen von VMVorgängen nach der
Wiederherstellung
Maschinen zu Beginn der Wiederherstellung vorhanden sind, fährt
AppSync diese vor Beginn der Wiederherstellung herunter. Dies ist
wichtig für eine erfolgreiche Wiederherstellung.
l
Return VMs back to state found at start of restore: Nach
der Wiederherstellung startet AppSync die virtuellen
Maschinen und setzt sie wieder auf den gleichen Status wie
vor der Wiederherstellung zurück.
l
Register all virtual machines: Nach der Wiederherstellung
registriert AppSync alle virtuellen Maschinen im vCenterBestand.
l
Register and power up all virtual machines: Nach der
Wiederherstellung startet AppSync die virtuellen Maschinen
und registriert sie im vCenter-Bestand.
Sie können lediglich eine dieser Optionen auswählen.
VMs zu Beginn der
Wiederherstellung nicht
vorhanden. Ausführen von
VM-Vorgängen nach der
Wiederherstellung.
l
Register all virtual machines: Nach der Wiederherstellung
registriert AppSync alle virtuellen Maschinen im vCenterBestand.
l
Register and power up all virtual machines:AppSync
startet die virtuellen Maschinen und registriert sie im vCenterBestand.
Betroffene Datenspeicherentitäten während der Wiederherstellung
Wenn Sie einen Datenspeicher wiederherstellen, berechnet AppSync die betroffenen
Entitäten für andere Datenspeicher, die den gleichen Speicher gemeinsam nutzen.
Eine betroffene Entität sind Daten, die sich auf Ihrem ESX-Server befinden und
unbeabsichtigterweise zu einem Teil eines Replikats werden, weil sie sich in der Nähe
von Daten befinden, die Sie schützen möchten. Sie können Situationen mit betroffenen
Entitäten vermeiden, indem Sie Ihr Datenlayout ordnungsgemäß planen.
Bei RecoverPoint oder ViPR-Controller ist die Granularität auf der Ebene der Consistency
Group (CG). Wenn die Consistency Group für die Wiederherstellung ausgewählt ist,
identifiziert AppSync andere Datenspeicher, die sich in derselben Consistency Group
befinden und die auch mitgeschützt wurden, und stellt diese wieder her. Wenn die
betroffene Entität nicht geschützt wurde, kann AppSync diese nicht ordnungsgemäß
wiederherstellen. Dies wird als eine Warnung im Assistenten zum Wiederherstellen
angezeigt.
VM-Vorgänge während der Wiederherstellung
215
Es gibt keine betroffenen Entitäten für VNX, da mehrere Datenspeicher nicht dieselbe LUN
umfassen und auch nicht auf demselben Dateisystem gehostet werden können.
Wenn betroffene Entitäten in der zugrunde liegenden Speicherkonfiguration vorhanden
sind, werden Sie vom Wiederherstellungsassistenten über diese Elemente benachrichtigt
und Sie müssen bestätigen, dass zusätzliche Elemente wiederhergestellt werden.
Wiederherstellen einer VMware-Datastore-Kopie aus XtremIO
Erfahren Sie, wie Sie eine Kopie des Datenspeichers auf XtremIO mit AppSync manuell
wiederherstellen. Automatisierte Wiederherstellung ist bei der AppSync Version 2.2.2
und höher sowie bei XtremIO 4.0 und höher verfügbar.
Bevor Sie beginnen
Weitere Informationen zur automatisierten Wiederherstellung finden Sie unter
Wiederherstellen einer Datenspeicherkopie mithilfe des
Wiederherstellungsassistenten auf Seite 218.
Sorgen Sie bei einer manuellen Wiederherstellung dafür, dass die folgenden
Voraussetzungen erfüllt sind, und führen Sie dann die folgenden Schritte aus:
l
VMware-Datastore-Kopie befindet sich auf einem XtremIO-Array.
l
Ein AppSync-Serviceplan, mit dem der Datenspeicher repliziert wird.
Vorgehensweise
1. Wählen Sie auf der AppSync- Konsole die Option Service Plans > VMware Datacenters
aus und klicken Sie dann auf den gewünschten Serviceplan, zum Beispiel Bronze.
2. Wählen Sie die Kopie Mount aus, um sie auf dem ESX-Produktionsserver
wiederherzustellen.
Abbildung 32 Dialogfeld Select Mount Settings
3. Stoppen Sie alle virtuellen Maschinen aus dem Datenspeicher, die wiederhergestellt
werden.
Wenn eine virtuellen Maschine nicht wiederhergestellt werden soll, verwenden Sie
VMware vMotion, um diese in einen anderen Datenspeicher zu verschieben.
4. Entfernen Sie die virtuellen Maschinen auf dem Datenspeicher, die Sie aus dem
vCenter-Bestand wiederherstellen.
5. Unmounten Sie den Datenspeicher, den Sie wiederherstellen.
216
Abbildung 33 Datenspeicher unmounten
6. Löschen Sie den Datenspeicher, den Sie wiederherstellen.
7. Benennen Sie den Datenspeicher, der durch AppSync gemountet wurde, auf den
Namen des Produktionsdatenspeichers um.
8. Wählen Sie für die gemountete Kopie die Aktion Remove aus.
Durch diese Aktion wird die Kopie aus der AppSync-Datenbank entfernt, ohne den
Snapshot auf dem Mount-Host oder auf dem XtremIO-Array zu entfernen. Es wird eine
Meldung angezeigt, in der die Aktion Remove erläutert wird. Wenn der Serviceplan
mehrere Datenspeicher enthält, verbleibt der Speicher für alle Datenspeicher im
Serviceplan auf dem XtremIO-Speicherarray.
9. Entfernen Sie die alten Produktions-LUNs aus der Initiatorgruppe für ESX.
10. Verschieben Sie den gemounteten Snapshot aus dem /AppSyncSnapshots-Ordner
zum Ordner, in dem sich die zu ersetzende Produktions-LUN befindet.
Verschieben Sie den Snapshot, der gemountet wurde (d. h., den Snapshot, der derzeit
für die ESX-Initiatorgruppe maskiert ist). Nachdem Sie den Vorgang abgeschlossen
haben, werden die Produktions-LUN und der Snapshot im gleichen Ordner angezeigt.
Abbildung 34 Gemounteten Snapshot verschieben
Nach dem Verschieben wird aus einem Datenspeicher ein Snapshot, aus dem
anderen ein Volume.
Wiederherstellen einer VMware-Datastore-Kopie aus XtremIO
217
Abbildung 35 Snapshot und Volume
11. Entfernen Sie das Volume, das Sie durch den Snapshot ersetzen möchten.
Aus dem Snapshot wird ein Volume.
Abbildung 36 Aus Snapshot wird Volume
Hinweis
Aus allen anderen Snapshots im /AppSyncSnapshots-Ordner für das
Datenspeicher-XtremIO-Volume, das Sie gerade entfernt haben, sind ebenfalls
Volumes geworden.
12. Benennen Sie den Snapshot (jetzt ein Volume) auf den Namen des Volume um, dass
Sie ersetzt haben, und führen Sie dann alle erforderlichen VM-Aktionen für den
„wiederhergestellten“ Datenspeicher aus, wie z. B. VMware vMotion oder Hinzufügen
zum Bestand.
13. Starten Sie alle virtuellen Maschinen im Datenspeicher, die Sie ausführen möchten.
Der wiederhergestellte Datenspeicher verfügt in vCenter über eine neue
Datenspeicher-ID.
14. Beenden Sie das Abonnement des Serviceplans für den alten Datenspeicher,
abonnieren Sie den Serviceplan für den neuen Datenspeicher und führen Sie dann
den Datenspeicher-Serviceplan zur Erstellung eines Snapshot des
„wiederhergestellten“ Datenspeichers aus.
Wiederherstellen einer virtuellen Maschine aus einer Kopie
Sie können die Wiederherstellung einer virtuellen Maschine unter der Registerkarte
Protected Virtual Machines oder auf der Seite Copies der virtuellen Maschine ausführen.
Bevor Sie beginnen
218
l
l
Sie müssen dazu vSphere Enterprise Edition verwenden.
l
Alle von der virtuellen Maschine verwendeten Datenspeicher müssen durch Auswahl
der Option Include Virtual Machine Disk in der Phase Create copy des Serviceplans
geschützt werden.
l
Die virtuelle Maschine darf über keine bereits vorhandenen Snapshots verfügen.
l
Virtuelle Maschinen mit RDMS können nicht wiederhergestellt werden.
Vorgehensweise
1. Wählen Sie unter der Registerkarte Protected Virtual Machines oder auf der Seite
Copies der virtuellen Maschine die Option Restore aus.
Der Assistent für das Wiederherstellen von virtuellen Maschinen wird angezeigt.
Verwenden Sie die Filter Copies oder Service Plan, um die wiederherzustellende Kopie
auszuwählen. Die Liste der Kopien wird basierend auf den ausgewählten Filtern
aktualisiert.
Uhrzeit der Konsole. Wenn sich die Konsole in einer anderen Zeitzone als der RPA
befindet, geben Sie die Uhrzeit gemäß der Serverzeitzone ein, um die Kopie
wiederherzustellen.
Wenn andere VMs ebenfalls mit der ausgewählten virtuellen Maschine geschützt
wurden, wird die Seite Multiple VM Restore angezeigt.
Wählen Sie eine der folgenden Optionen:
l
Continue to restore only one virtual machine
l
View and/or select the other VMs for restore
4. Treffen Sie die Auswahl auf der Seite Select Restore Location. Weitere Informationen
finden Sie unter Optionen zur Wiederherstellung von virtuellen Maschinen auf Seite
220.
5. Gehen Sie auf der Seite Select Mount Hostfolgendermaßen vor:
a. Wählen Sie den Mount-ESX aus.
Wenn sich die Produktionsdaten im RecoverPoint-Speicher befinden, sollten die
Zielgeräte für den ausgewählten Mount-Host sichtbar sein. Im Falle von VNX muss
der Mount-Host auf dem VNX registriert werden.
b. Wählen Sie den RecoverPoint-Image-Zugriffsmodus aus der Liste aus - Logged
Access, Virtual Access oder Virtual Access with Roll.
c. Klicken Sie auf Next.
Hinweis
AppSync nutzt die VMware vMotion-Technologie, um die virtuelle Maschine vom
Mount-Host zum Wiederherstellungsspeicherort zu verschieben. Aus diesem Grund
müssen der Mount-Host und der Host am Wiederherstellungspeicherort die VMware
vMotion-Voraussetzungen, wie beispielsweise die Netzwerkanforderung, erfüllen.
Wiederherstellen einer virtuellen Maschine aus einer Kopie
219
Auf der Seite Choose Instante Restore können Sie nur dann eine Auswahl treffen,
wenn eine der folgenden Bedingungen erfüllt ist:
l
Die Mount- und Wiederherstellungshosts sind identisch.
l
Die Mount- und Wiederherstellungshosts sind zwar verschieden, jedoch Nodes
desselben ESX-Clusters.
6. Wählen Sie basierend darauf, ob Sie eine sofortige Wiederherstellung ausführen
möchten, auf der Seite Choose Instant Restore entweder Yes oder No für die Option
Do you want to perform an instant restore option aus.
Während der sofortigen Wiederherstellung können Sie weiterhin die virtuelle
Maschine verwenden. Obwohl die virtuelle Maschine eingeschaltet ist, werden die
VMs im Hintergrund wiederhergestellt.
Wenn Sie No auswählen und im Schritt 2 dieses Assistenten die Wiederherstellung
mehrerer virtueller Maschinen ausgewählt haben, geben Sie eine Zahl im Feld
Maximum number of simultaneous virtual machines to be restored ein. Die Anzahl
beträgt standardmäßig 2.
Hinweis
Wenn Sie mehrere virtuelle Maschinen wiederherstellen möchten, die zu einer vApp
gehören, legen Sie für Maximum number of simultaneous virtual machines to be
restored den Wert 1 fest.
Wenn die Quellgeräte „think“ sind, steht die Option für eine sofortige
Wiederherstellung bei VMAX-Kopien nicht zur Verfügung.
Seiten ausgewählt haben, und klicken Sie auf Finish, um die Wiederherstellung
auszuführen.
verschiedenen Phasen mitzuverfolgen, die zur Wiederherstellung einer virtuellen
Maschine gehören.
Wiederherstellungsoptionen für virtuelle Maschinen
Sie können den Wiederherstellungsspeicherort sowie die Wiederherstellungsvorgänge
auswählen.
Tabelle 22 Wiederherstellungsoptionen für virtuelle Maschinen
Wiederherstellungsoption
Beschreibung
Original location
Wiederherstellung am Speicherort, an dem die virtuelle
Maschine zum Zeitpunkt des Schutzes vorhanden war.
Hinweis
Bei einer RecoverPoint-Kopie wird die Wiederherstellung am
ursprünglichen Speicherort nicht empfohlen. AppSync zeigt
eine entsprechende Warnung an, wenn Sie diese Option
auswählen.
220
Tabelle 22 Wiederherstellungsoptionen für virtuelle Maschinen (Fortsetzung)
Wiederherstellungsoption
Beschreibung
Alternate location
Wiederherstellung an einem Speicherort, der aus den
folgenden Optionen ausgewählt wurde. Es müssen alle
Optionen festgelegt werden.
Optionen für den Fall, dass die
wiederherzustellende VM bereits
am
Wiederherstellungsspeicherort
vorhanden ist
l
vCenter Server: Sie können entweder denselben vCenter
Server, auf dem sich der Datenspeicher mit der virtuellen
Maschine zum Zeitpunkt des Schutzes befand, oder einen
anderen Server auswählen.
l
Rechenzentrum
l
Host
l
Datastore
l
Fail the restore: AppSync prüft das Vorhandensein der
virtuellen Maschinen am Wiederherstellungsspeicherort.
Für jene virtuellen Maschinen, die am
Wiederherstellungsspeicherort vorhanden sind, wird der
Wiederherstellungsvorgang abgebrochen. Für die anderen
virtuellen Maschinen wird der Wiederherstellungsvorgang
fortgesetzt. Hierbei handelt es sich um eine
Vorsichtsmaßnahme.
l
Create a new virtual machine: AppSync erstellt vor der
Wiederherstellung eine neue virtuelle Maschine.
l
Unregister the virtual machine: Wenn die zur
Wiederherstellung ausgewählten virtuellen Maschinen am
Wiederherstellungsspeicherort vorhanden sind, hebt
AppSync vor der Wiederherstellung die Registrierung
dieser Maschinen im Bestand auf.
l
Delete from disk before performing restore: Wenn die
wiederherzustellenden virtuellen Maschinen am
Wiederherstellungsspeicherort vorhanden sind, werden
sie von AppSync vor der Wiederherstellung gelöscht.
Hinweis
Es wird empfohlen, ein Backup der virtuellen Maschine vor
dem Fortsetzen des Wiederherstellungsvorgangs
auszuführen.
l
Delete from disk after performing restore: Wenn die
wiederherzustellenden virtuellen Maschinen am
Wiederherstellungsspeicherort vorhanden sind, werden
sie von AppSync nach der Wiederherstellung gelöscht.
Wiederherstellungsoptionen für virtuelle Maschinen
221
Wiederherstellung von Dateien und Ordnern mit VMFS- oder NFSDatenspeichern
Mit AppSync können Dateien oder Ordner, die auf virtuellen Laufwerken auf einer
virtuellen Maschine in VMFS- und NFS-Datenspeichern gespeichert sind,
wiederhergestellt werden.
Die virtuellen Laufwerke, die in einem VMFS- oder NFS-Datenspeicher gespeichert werden
und durch einen AppSync-Serviceplan geschützt werden, können für die
Wiederherstellung auf Datei- oder Ordnerebene verwendet werden, indem Sie den
Speicherort für das Mounten der Kopie des virtuellen Laufwerks angeben.
Mit AppSync ist die Wiederherstellung auf Datei- oder Ordnerebene ein dreistufiger
Prozess: Um die Wiederherstellung abzuschließen, wird der letzte Schritt manuell
außerhalb von AppSync durchgeführt. Sie müssen die Dateien bzw. Ordner aus dem
Speicherort, an dem das virtuelle Laufwerk gemountet ist, an einen Speicherort Ihrer
Wahl kopieren.
1. AppSync mountet die Datenspeicher-Snapshots auf dem ESX-Server, auf dem sich
die virtuelle Maschine mit dem AppSync-Agent befindet.
2. VCenter Server fügt die virtuellen Laufwerke aus den Datenspeicher-Snapshots der
Mount-VM hinzu, ohne die Stromversorgung für die virtuelle Maschine
auszuschalten.
3. Der AppSync-Agent führt ein Mounten des Dateisystems zur Mount-VM durch.
Die Wiederherstellung von Dateien oder Ordnern von virtuellen Laufwerken mit mehreren
Partitionen wird unterstützt.
Wenn der ESX-Server Version 5.0 oder höher ist, kann die ursprüngliche VM auch die
Mount-VM sein.
Beschränkungen
l
Die Wiederherstellung auf Datei- oder Ordnerebene ist auf dynamischen Laufwerken
nicht möglich.
l
Virtuelle Laufwerke, die zum gleichen Phase Pit gehören, können nicht auf derselben
virtuellen Maschine gemountet werden, selbst wenn sie mit dem Gold-Serviceplan
erstellt wurden. Mit anderen Worten, wenn ein virtuelles Laufwerk aus einer lokalen
Kopie gemountet wird, dann kann dasselbe virtuelle Laufwerk nicht aus einer
Remote-Kopie gemountet werden.
l
Um eine APiT-Dateiwiederherstellung (Any-Point-in-Time) durchzuführen, müssen Sie
zunächst ein APiT-Mounten des Datenspeichers durchführen und dann den
Assistenten zur granulären Dateiwiederherstellung aus der APiT-Kopie starten.
Wiederherstellen einer Datei oder eines Ordners aus einem virtuellen Laufwerk
Sie können die Wiederherstellung einer Datei oder des Ordners eines virtuellen
Laufwerks unter der Registerkarte Protected Virtual Machines oder auf der
Seite Copies der virtuellen Maschine ausführen.
Bevor Sie beginnen
222
l
l
Sie müssen dazu vSphere Enterprise Edition verwenden.
l
Die virtuelle Maschine, auf der die Kopie gemountet und wiederhergestellt wird, muss
64 Bit bei Windows 2008 oder Windows 2012 als Betriebssystem aufweisen. Das
AppSync-Host-Plug-in muss darauf installiert und mit dem AppSync-Server registriert
werden.
Vorgehensweise
1. Wählen Sie unter der RegisterkarteProtected Virtual Machines oder auf der Seite
Copies die OptionRestore > File aus.
Der Assistent zur granularen Wiederherstellung von Dateien wird gestartet.
Verwenden Sie die Filter Copies oder Service Plan, um die entsprechende
Die Seite Select Virtual Disk wird angezeigt, auf der die virtuellen Laufwerke in der
ausgewählten virtuellen Maschine angezeigt werden.
4. Wählen Sie die virtuellen Laufwerke aus, deren Dateien oder Ordner wiederhergestellt
werden müssen, und klicken Sie auf Next.
5. Gehen Sie auf der Seite Select Host folgendermaßen vor:
a. Wählen Sie die virtuelle Maschine aus, auf der die Kopie gemountet werden muss.
Legen Sie darüber hinaus den Speicherort auf der ausgewählten virtuellen
Maschine fest, auf der das Laufwerk wiederhergestellt werden muss.
Standardmäßig werden die Dateien am folgenden Speicherort wiederhergestellt:
%system drive%\AppSyncMounts\<VM_name>\<copy_id>\Hard
disk# Hierbei gilt:
l
%system drive% ist das Systemlaufwerk der ausgewählten virtuellen
Maschine, auf der die Kopie gemountet werden soll.
l
<VM_name> ist der Name der virtuellen Maschine, deren virtuelle Laufwerke
wiederhergestellt werden sollen.
l
<copy_id> ist eine von AppSync erzeugte ID.
l
Hard disk# ist die Nummer der Festplatte in der virtuellen Maschine. Diese
Nummer ist dieselbe wie auf der ursprünglichen virtuellen Maschine.
b. Wählen Sie den RecoverPoint-Image-Zugriffsmodus aus der Liste aus - Logged
Access, Virtual Access oder Virtual Access with Roll.
Seiten ausgewählt haben, und klicken Sie auf Finish, um die Wiederherstellung des
Laufwerks zu starten.
verschiedenen Phasen mitzuverfolgen, die zur Wiederherstellung eines virtuellen
Laufwerks gehören.
8. Führen Sie anschließend den manuellen Schritt zum Kopieren der erforderlichen
Dateien oder Ordner aus dem Mount-Speicherort in einen Speicherort Ihrer Wahl aus.
9. Unmounten Sie gegebenenfalls den Datenspeicher. Unmounten einer Kopie des
Datenspeichers auf Seite 213.
Wiederherstellen einer Datei oder eines Ordners aus einem virtuellen Laufwerk
223
224
KAPITEL 10
l
l
l
l
Konzepte und Best Practices für RPO................................................................... 226
Warnmeldungen und zugehörige Ereignisse........................................................ 227
Senden von Warnmeldungen per E-Mail.............................................................. 229
Repurpose Monitor..............................................................................................230
225
Konzepte und Best Practices für RPO
Ein Recovery Point Objective (RPO) ist eine von mehreren Planungsoptionen, die im
Rahmen der Phase Plan Startup eines Serviceplans ausgewählt werden können.
Wenn Sie für ein Objekt (z. B. eine Exchange-Datenbank) einen Serviceplan abonnieren,
der RPO als aktuellen Wiederholungstyp verwendet, übernimmt das Objekt das im
Serviceplan angegebene Recovery Point Objective.
Da Sie für ein Objekt mehr als einen Serviceplan abonnieren können, ist es möglich, dass
ein Objekt mehr als ein Recovery Point Objective hat. Wenn ein Objekt mehr als einen
RPO hat, wird der Serviceplan mit der höchsten RPO-Häufigkeit (d. h. mit dem niedrigsten
RPO-Stundenwert) für Berechnungen und Berichte verwendet.
Als Best Practice sollten Sie für ein Objekt nur einen RPO-fähigen Serviceplan
abonnieren. Wenn Sie für ein Objekt zusätzliche Servicepläne abonnieren, sollten diese
nicht den RPO-Wiederholungstyp verwenden.
Bericht zur Recovery Point-Compliance
Der Bericht zur Recovery Point-Compliance zeigt die Wiederherstellbarkeit für alle
Objekte, für die Servicepläne mit einem RPO-Wiederholungstyp abonniert sind. Sie finden
den Bericht unter Monitoring > Recovery Point Compliance Report.
Tabelle 23 Bericht zur Recovery Point-Compliance
Spalte
Beschreibung
Server
Hostlevelobjekt, z. B. ein Microsoft Exchange-Postfachserver
Anwendung
Name des geschützten Objekts, z. B. eine Microsoft Exchange-Datenbank.
Klicken Sie auf den Namen, um die Liste der Kopien für das Objekt
aufzurufen.
Recovery Point
Objective
Das in der Phase Start des zugehörigen Serviceplans definierte Recovery
Point Objective.
Zeit seit dem letzten Zeitraum seitdem die letzte Kopie oder das letzte Lesezeichen durch den
Recovery-Punkt
zugehörigen Serviceplan erstellt wurde. Ein grünes Symbol gibt an, dass
die Kopie RPO-vorgabenkonform ist. Ein rotes Symbol gibt an, dass sie
nicht vorgabenkonform ist.
Serviceplan
Der Name des Serviceplans. Klicken Sie auf den Namen, um die
Serviceplandefinition aufzurufen.
Exportieren eines RPO-Compliance-Berichts in CSV-Datei
Sie können einen Recovery Point Objective (RPO)-Compliance-Bericht im CSV-Format
(Comma-separated Value) erstellen.
Bevor Sie beginnen
Für diesen Vorgang ist keine bestimmte AppSync-Rolle erforderlich.
Vorgehensweise
1. Navigieren Sie zu Monitoring > Recovery Point Compliance Report.
2. Sortieren und ordnen Sie die Spalten für den Bericht nach Bedarf an.
226
3. Klicken Sie auf Export, um den Exportassistenten auszuführen.
Sie haben die Möglichkeit, Tabellenüberschriften einzubeziehen und nur ausgewählte
Zeilen zu exportieren. Der Standarddateiname lautet “Recovery Point
Objectives_mmddyyyyhhmmss.csv“.
Überblick über die RPO-Compliance
Der Überblick über die Recovery Point Objectives (RPO) auf dem Dashboard zeigt den
Prozentsatz der über alle Objekte erfüllten RPOs an, die für RPO-fähige Servicepläne
abonniert sind.
Warnmeldungen und zugehörige Ereignisse
AppSync generiert eine Warnmeldung, wenn eine Serviceplanphase fehlschlägt, wenn ein
Recovery Point Objective (RPO) nicht erfüllt wird oder wenn ein Mount- oder
Wiederherstellungsvorgang fehlschlägt.
Warnmeldungen zu Serviceplanausfällen werden sofort beim Ausfall einer
Serviceplanphase generiert. Wenn eine Anwendung keine RPO-Compliance mehr
aufweist, wird die zugehörige Warnmeldung innerhalb von einer Stunde generiert.
Weitere Informationen finden Sie unter Bestätigen von Warnmeldungssymbolen bei der
Ausführung von Serviceplänen bei Datenbanken, Dateisystemen und Datenspeichern auf
Seite 228.
AppSync zeigt Warnmeldungen in der Konsole unter Monitoring > Alerts an.
Tabelle 24 Details zu Warnmeldungen
Spalte
Beschreibung
Alert (!)
Ebene der Warnmeldung
Time
Datum und Uhrzeit der Warnmeldung
Server
Anwendungsserver, z. B. ein Microsoft Exchange-Server.
Application
Repliziertes Objekt, z. B. eine Microsoft Exchange-Datenbank.
Category
Phasenausfall, RPO
Service Plan Der Serviceplan, der bei Generierung der Warnmeldung ausgeführt wurde, oder der
Serviceplan, mit dem die Kopie erstellt wurde, deren Mount- oder
Wiederherstellungsvorgang fehlerhaft war.
Message
Beschreibt die Ursache der Warnmeldung.
Sie können Warnmeldungen nach der Zeit filtern, zu der sie generiert wurden, und nach
dem zugehörigen Serviceplan.
Zeigen Sie die zugehörigen Ereignisse an, die zu der Warnmeldung geführt haben, indem
Sie auf die Warnmeldung klicken. Erweitern Sie die Top-Level-Ereignisse, um weitere
Details anzuzeigen. Sie können die zugehörigen Ereignisse nach einer beliebigen Spalte
filtern.
Bestätigen von Warnmeldungen
Mit AppSync Version 2.2.2 und höher können Sie Warnmeldungen bestätigen. Weitere
Informationen finden Sie unter Bestätigen von Warnmeldungen auf Seite 228 und
Überblick über die RPO-Compliance
227
Bestätigen von Warnmeldungssymbolen bei der Ausführung von Serviceplänen bei
Datenbanken, Dateisystemen und Datenspeichern auf Seite 228.
Bestätigen von Warnmeldungen
In diesen Schritten wird erläutert, wie Warnmeldungen für das Monitoring bestätigt
werden.
Sie können festlegen, in der Konsole angezeigte Warnmeldungen zu bestätigen:
Monitoring > Alerts. Auf der Seite Alerts wird eine Spalte für Alert Acknowledged
dargestellt.
Der Standardwert lautet No. Wenn Sie eine Warnmeldung bestätigen, ändert sich der
Wert der Warnmeldung vom Standardwert NO auf YES.
Vorgehensweise
1. Navigieren Sie zu Monitoring > Alerts und wählen Sie eine Warnmeldung aus der
Tabelle der Warnmeldungen mit dem aktuellen Wert NOin der Spalte Alert
Acknowledged aus.
2. Klicken Sie auf Acknowledge Alert.
Ergebnisse
Die Warnmeldung zeigt einen Wert von YES in der Spalte Alert Acknowledged der Tabelle
der Alert an.
Bestätigen von Warnmeldungssymbolen bei der Ausführung von Serviceplänen bei Datenbanken,
Dateisystemen und Datenspeichern
Sie können ein Warnmeldungssymbol in der AppSync-Konsole für Oracle- und SQLDatenbanken, Dateisysteme und Datenspeicher bestätigen.
Ein Warnmeldungssymbol zeigt den Status des zuletzt ausgeführten Serviceplans an. Das
Symbol wird neben einer Datenbank, einem Dateisystem oder Datenspeicher nach der
Ausführung angezeigt.
Nachdem Sie das Symbol in der Spalte Acknowledge bestätigt haben, wird es von
AppSync auf ein Informationssymbol gewechselt. Darüber hinaus können Sie die
Warnmeldung nach jeder Serviceplanausführung bestätigen. Es gibt keine
Einschränkungen im Hinblick darauf, dass eine Warnmeldung nur einmal bestätigt
werden kann.
Hinweis
Wenn ein Löschvorgang ausstehend ist, wird die Schaltfläche Acknowledge für die
Datenbank, das Dateisystem oder den Datenspeicher deaktiviert.
Im folgenden Verfahren wird erläutert, wie die Warnmeldung anzuzeigen und zu
bestätigen ist.
Vorgehensweise
1. Wählen Sie eine Warnmeldung aus der Datenbank-, Dateisystem- oder
Datenspeichertabelle aus, die ein Warnmeldungssymbol aufweist, welches der letzten
Ausführung des Serviceplans zugeordnet ist.
2. Klicken Sie auf die Schaltfläche Acknowledge Alert, die sich unter der Datenbank-,
Dateisystem-, oder Datenspeichertabelle befindet.
Das Warnmeldungssymbol wechselt auf ein Informationssymbol.
228
3. Falls erforderlich, führen Sie den Serviceplan erneut bei derselben Datenbank,
demselben Dateisystem oder Datenspeicher aus, um das Warnmeldungssymbol für
diese Ausführung anzuzeigen.
Senden von Warnmeldungen per E-Mail
Sie können AppSync so konfigurieren, dass Fehlermeldungen per E-Mail an eine Liste von
Empfängern gesendet werden.
Sie aktivieren E-Mail-Benachrichtigungen und fügen Empfänger pro Anwendungsinstanz
hinzu, z. B. einen Exchange-Mailbox-Server.
Hinweis
Sie können AppSync auch so konfigurieren, dass nach dem erfolgreichen Abschluss
eines Serviceplans eine E-Mail gesendet wird. Dies ist standardmäßig deaktiviert. Wenn
diese Funktion aktiviert werden soll, wenden Sie sich an den Customer Service.
Konfigurieren der Servereinstellungen für E-Mail-Benachrichtigungen
Konfigurieren Sie die SMTP-Services auf einem Rechner, auf den der AppSync-Server
zugreifen kann.
Bevor Sie beginnen
Das Konfigurationsverfahren finden Sie in der SMTP-Dokumentation.
Vorgehensweise
1. Wählen Sie Settings > AppSync Server Settings.
2. Geben Sie unter Send Mail Werte für SMTP-Server, Port und Absender ein.
Verwenden Sie Test, um die Einstellungen zu validieren. Geben Sie die Adresse des
Empfängers ein und prüfen Sie den Posteingang des Empfängers. Sie können auch
Insert Default Values auswählen.
3. Klicken Sie auf Apply.
Festlegen der Empfänger von E-Mail-Warnmeldungen
Konfigurieren Sie E-Mail-Warnmeldungen pro Anwendungsinstanzebene.
Bevor Sie beginnen
l
l
SMTP-Services müssen auf einer Maschine konfiguriert werden, auf die der AppSyncServer zugreifen kann. Siehe Konfigurieren der Servereinstellungen für E-MailBenachrichtigungen auf Seite 229.
Vorgehensweise
1. Wählen Sie Copy Management > Application (select application) aus.
2. Wählen Sie das Anwendungsobjekt aus, für das Warnmeldungseinstellungen festlegt
werden sollen.
3. Wählen Sie Alert Settings aus.
4. Geben Sie einen oder mehrere E-Mail-Empfänger durch Kommas (,) getrennt ein und
klicken Sie auf OK.
Senden von Warnmeldungen per E-Mail
229
Eine Test-E-Mail wird zur Überprüfung an die Empfänger gesendet.
Repurpose Monitor
In diesem Thema wird der Repurpose Monitor beschrieben.
Der Repurpose Monitor zeigt alle laufenden Prozesse für Neuverwendung und
Aktualisierung an. Er ermöglicht Ihnen das Anzeigen der derzeit ausgeführten
Neuverwendungsaktivitäten und das Überwachen ihres Fortschritts. Er zeigt die aktuelle
Kopie an, die neu verwendet wird (Erstellung eines Snapshots einer Snapshot-Kopie),
sowie die entsprechenden Kopiebezeichnungen wie 1st Gen (Generation) Copy oder 2nd
Gen Copy.
Der Repurpose Monitor wird in der Regel für länger andauernde
Neuverwendungsaktivitäten verwendet (z. B. die Synchronisation von VMAX Clones).
Wenn Sie diesen Monitor auswählen, werden alle Neuverwendungsaktivitäten aufgeführt.
Wählen Sie eine beliebige Neuverwendungsaktivität aus und wählen Sie dann Monitor
aus, um ein Dialogfeld anzuzeigen, in dem Sie den Fortschritt für die ausgewählte
Aktivität direkt anzeigen können.
So starten Sie den Repurpose Monitor:
1. Wählen Sie auf der AppSync-Konsole die Option Monitoring aus.
2. Wählen Sie auf der Seite Monitoring die Option Repurpose Monitor aus, um den
Repurpose Monitor zu starten.
230
Copyright © 2015 EMC Corporation. All rights reserved. Published in USA.
EMC believes the information in this publication is accurate as of its publication date. The information is
subject to change without notice.
The information in this publication is provided as is. EMC Corporation makes no representations or
warranties of any kind with respect to the information in this publication, and specifically disclaims
implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution
of any EMC software described in this publication requires an applicable software license.
EMC², EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the
United States and other countries.
All other trademarks used herein are the property of their respective owners.
For the most up-to-date regulatory document for your product line, go to EMC Online Support
(https://support.emc.com).

EMC® AppSync™ 2.2.2 Benutzer- und

Transcription

Similar documents

Cecil B. DeMille (Filmmuseum Berlin – Deutsche Kinemathek)

modelljahr2012 - Ducati Motorräder Österreich