Versionshinweise zu vSphere Data Protection (VDP) 6.0

|

Versionshinweise zu vSphere Data Protection (VDP) 6.0 | 9 März 2015
Letzte Aktualisierung: 25. März 2015

Diese Versionshinweise decken die folgenden Themen ab:

Vorteile und Funktionen

Informationen über die Vorteile und Funktionen dieses Produkts finden Sie unter folgenden Links:

Unterstützte Umgebungen

Informationen zu den unterstützten Umgebungen finden Sie in der VMware-Interoperabilitätsmatrix.

Bekannte Probleme in vSphere Data Protection 6,0

Die folgenden bekannten Probleme wurden durch intensives Testen entdeckt. Die Probleme beziehen sich auf vSphere Data Protection (VDP) 6,0.

Probleme bei VMware

  • VDP stürzt beim Erstellen/Ausführen von Sicherungsaufträgen ab.

    Nach einer erfolgreichen Sicherung von 32 virtuellen Maschinen mit VMware Virtual Machine File System (VMFS) führen Sicherungsaufträge weiterer Gruppen von virtuellen Maschinen dazu, dass die Benutzeroberfläche von vSphere Data Protection nicht mehr reagiert. Dies geschieht, wenn der Benutzer inkrementelle Sicherungen von 8er-Gruppen virtueller Maschinen (z. B. 8, 16 oder 32) ausführt.

    Problemumgehung:

    Führen Sie eine der folgenden Aufgaben aus:

    • Starten Sie die VDP-Appliance neu. Dies hat sich als die erfolgreichste Problemumgehung herausgestellt.
    • Melden Sie sich beim Next Generation Client (NGC) ab und anschließend wieder an.
    • Starten Sie den NGC-UI-Client neu.
  • Die Image-Sicherung schlägt für eine eingeschaltete virtuelle Maschine fehl, die auf einem VSAN-Datenspeicher ausgeführt wird.

    Eine Image-Sicherung schlägt für eingeschaltete virtuelle Maschinen fehl, die auf einem VSAN-Datenspeicher ausgeführt werden, wenn sowohl die VDP-Appliance als auch die virtuelle Maschine auf demselben VSAN-Datenspeicher ausgeführt, aber von unterschiedlichen vSphere-Hosts gehostet und mit Strom versorgt werden. Dieses Problem tritt nur auf, wenn sich die virtuelle Maschine in einem eingeschalteten Zustand befindet.

  • Unterstützung für Routing/NAT/Firewall/IDS/TSNR zwischen der VDP-Appliance und vCenter

    Beim Konfigurieren des Netzwerks für die VDP-Appliance und das vCenter wird das Modifizieren von Netzwerkadressdaten mit NAT oder anderen Konfigurationsmethoden (zum Beispiel Firewall, IDS oder TSNR) nicht unterstützt. Wenn solche Tools als Teil des virtuellen Netzwerks bereitgestellt werden, arbeiten einige VDP-Funktionen eventuell nicht wie vorgesehen.

  • Bei Verwendung des sicheren Modus können Benutzer vorherige fehlgeschlagene Sicherungen, in denen sich noch Artefakte befinden, nicht bereinigen.

    Fehler 1293852 und 1294581 stehen mit der Aktivierung des sicheren Modus in Zusammenhang. Derzeit wird Benutzern, die ihre Installation in der VDP-Appliance-Benutzeroberfläche sichern möchten, empfohlen, bei der Ausführung die standardmäßig deaktivierte SSL-Hostprüfung zu aktivieren. Zuvor war diese Option nicht vorhanden.

  • Bei 5.8 war die Root-Anmeldung deaktiviert.

    Bei Version 5.8 war die Root-Anmeldung deaktiviert, da es sich nicht um eine empfohlene Vorgehensweise handelt. Es ist eine Option zum Aktivieren der ssh-Root-Anmeldung erforderlich. Darüber hinaus wird die Zeitüberschreitung der Shell auf 15 Minuten festgelegt, wenn keine Aktivität darin stattfindet. Es ist eine Option zum Deaktivieren der Shell-Zeitüberschreitung erforderlich. Diese Verbesserungen machen die Erfahrung mit dem Kunden-Support während der Fehlerbehebung und bei der Verwendung der Shell angenehmer.

    Problemumgehung: Melden Sie sich mit dem Administratorkonto an. Verwenden Sie dann den sudo-Befehl, um Root-Funktionen auszuführen.

    Falls keine Aktivität in der Shell stattfindet, ist die Bash-Shell (im Verzeichnis /etc/profile) auf eine Zeitüberschreitung von 15 Minuten festgelegt. Sie können den Zeitüberschreitungswert für die Konsole mithilfe des Hardening-Skripts hinzufügen. Beispiel:

    TMOUT = 900

    export TMOUT

Kompatibilitätsprobleme

  • VDP-Versionen vor 6.0 sind nicht mit vCenter 6.0 kompatibel

    Ältere Versionen von VDP (5.8.x, 5.5.x und 5.1.x) sind aus folgenden Gründen nicht mit vCenter 6.0 kompatibel:

    1. Das VDP-Plug-In wird unabhängig von der Version nur in der Benutzeroberfläche von vSphere 6.0 angezeigt, wenn VDP 6.x in der Umgebung vorhanden ist.
    2. VDP 5.5.x kann keine Verbindung zur Benutzeroberfläche von vSphere 6.0 herstellen.
    3. Wenn VDP 6.0 und VDP 5.8.x in derselben vCenter-Instanz vorhanden sind, können Sie eine Verbindung zum VDP-Plug-In für VDP 5.8 herstellen, können aber keine Hot-Add-Sicherungen durchführen.

    Dies sind bekannte Probleme, für die es keine Problemumgehungen gibt. Sie müssen ein Upgrade auf Version 6.0 durchführen, damit niedrigere Versionen mit VDP 6.0 kompatibel sind.

Dokumentationsprobleme

  • Im Handbuch für vSphere Data Protection (Version 6.x) wird fälschlicherweise auf die Unterstützung von vCenter 5.1 und vSphere Host 5.0 verwiesen
  • Das Handbuch für vSphere Data Protection wurde für die nächste veröffentlichte Version aktualisiert. Beachten Sie in der Zwischenzeit Folgendes:

    Seite 17, „Architektur von vSphere Data Protection“, VDP setzt sich aus den folgenden Komponenten zusammen:

    Der derzeitige Text lautet wie folgt:

    • vCenter Server 5.1 oder höher (5.5 oder höher empfohlen)
    • Virtuelle VDP-Appliance (installiert auf vSphere-Hosts; Versionen 5.0, 5.1 und 5.5 unterstützt)

    Der Text sollte wie folgt lauten:

    • vCenter Server 5.5u2 bis 6.x
    • Virtuelle VDP-Appliance (installiert auf vSphere-Hosts; Versionen 5.1 bis 6.x unterstützt)

    Seite 20, „Softwareanforderungen“

    Der derzeitige Text lautet wie folgt:

    Für VDP 6.0 ist folgende Software erforderlich:

    • Es ist mindestens vCenter Server 5.1 erforderlich, vCenter Server 5.5 oder höher wird jedoch empfohlen.

      Hinweis: VDP 5.1 ist mit vCenter 5.5 oder höher nicht kompatibel.

    • vSphere-Hostversionen 5.0, 5.1 oder 5.5

    Der Text sollte wie folgt lauten:

    • Es ist mindestens vCenter Server 5.5u2 erforderlich, vCenter Server 6.x oder höher wird jedoch empfohlen.
    • vSphere-Hostversionen 5.1 bis 6.x

    Seite 25, „Bereitstellen der OVF-Vorlage“

    Der derzeitige Text lautet wie folgt:

    • Für die VDP-Appliance ist eine der folgenden vSphere-Hostversionen erforderlich: 5.0, 5.1 oder 5.5.
    • Es ist mindestens vCenter Server 5.1 erforderlich. vCenter Server 5.5u2 oder höher wird jedoch empfohlen.

    Der Text sollte wie folgt lauten:

    • Für die VDP-Appliance ist eine der folgenden vSphere-Hostversionen erforderlich: 5.1 bis 6.x.
    • Es ist mindestens vCenter Server 5.5 erforderlich.
  • Der Abschnitt zu SQL Server 2005 im Kapitel "VDP-Anwendungsunterstützung" des vSphere Data Protection-Handbuchs (Versionen 5.8 und 6.0) fordert fälschlicherweise Unterstützung für "x64"
  • Der derzeitige Text lautet wie folgt:

    SQL Server 2005 SP3 x64 unter:

    • Windows Server 2003 SP1 oder höher, x86/x64
    • Windows Server 2003 R2, SP2 oder höher, x86/x64
    • Windows Server 2008 SP1 oder höher, x86/x64
    • Windows Server 2008 R2, x64

    Beachten Sie, dass der SQL Server-Text wie folgt lauten sollte: "SQL Server 2005 SP3" (ohne "x64"). Die Listenpunkte sind korrekt.

  • Die VM kann nicht eingeschaltet werden, wenn die gesicherte VM mit DVS verbunden war und in einem anderen ESX wiederhergestellt wurde.

    Wenn nach der Wiederherstellung einer VM diese eingeschaltet wird, zeigt vCenter einen PowerOnFailure-Fehler ähnlich dem Folgenden an:

    DRS kann keinen Host zum Einschalten oder Migrieren der virtuellen Maschine finden. Netzwerkschnittstelle 'Netzwerkadapter 1' verwendet Netzwerk '77 d3 02 50 5f 76 ca d7-Db-f9 42 6c 0f 6f 87 1f', auf das nicht zugegriffen werden kann

    Diese Fehlermeldung tritt auf, wenn die Umgebung, in der die virtuelle Maschine wiederhergestellt wird, nicht über die zu dem Zeitpunkt, als Sie die virtuelle Maschine gesichert haben, vorhandene Netzwerkverbindung verfügt. Ein Benutzer sichert beispielsweise eine virtuelle Maschine, die mit einem verteilten vSwitch verbunden ist. Dann stellt der Benutzer die VM in einem ESX-Host wieder her, der Teil eines Distributed Resource Scheduler (DRS)-Clusters ist. Der vSwitch ist nicht im DRS-Cluster vorhanden. Daher schlägt das Einschalten der virtuellen Maschine fehl.

    Um dieses Problem zu umgehen, bearbeiten Sie die Einstellungen für die VM und legen Sie die Netzwerkverbindung auf den Netzwerkadapter fest. Schalten Sie anschließend die VM ein.

  • VMware Proxys-Appliance sind für Man-in-the-Middle-Angriffe anfällig.

    Proxys validieren standardmäßig keine SSL-Zertifikate beim Herstellen der Verbindung mit vCenter Server. Dadurch wird vCenter Server möglicherweise für einen Man-in-the-Middle-Angriff anfällig, der zu nicht autorisierten Zugriffen auf vCenter Server führen kann. Konfigurieren Sie beim Herstellen der Verbindung mit vCenter Server für jeden Proxy die Verwendung der Authentifizierung mit einem SSL-Zertifikat, um diese Schwachstelle zu beseitigen.

    Aufgrund des Bugs 222547 muss das Thema zur sicheren Kommunikation des externen Proxys mit vCenter auf Seite 53-54 im Administratorhandbuch für vSphere Data Protection 6.0 aktualisiert werden. Die folgende Vorgehensweise umfasst diese Updates. Verwenden Sie diese Vorgehensweise anstelle der Vorgehensweise auf den Seiten 53-54:

    1. Öffnen Sie eine Befehlsshell und melden Sie sich als Root-Benutzer bei dem Proxy an.
       
    2. Kopieren Sie das vCenter Server-Zertifikat in das Verzeichnis "/usr/local/avamarclient/bin" auf dem Proxy:
       
      • Für Linux vCenter Appliance:

        Kopieren Sie die Dateien „/etc/vmware-vpx/ssl/rui.crt“ und „/etc/vmware-vpx/ssl/rui-ca-cert.pem“ mithilfe von SCP von der vCenter Appliance in das Verzeichnis „/usr/local/avamarclient/bin“ auf dem Proxy.
         
      • Für Windows vCenter:

        Kopieren Sie die Dateien "c:\ProgramData\VMware\VMware VirtualCenter\SSL\rui.crt" und "c:\ProgramData\VMware\VMware VirtualCenter\SSL\cacert.pem" mithilfe von SCP in das Verzeichnis "/usr/local/avamarclient/bin" auf dem Proxy.  
      • HINWEIS: Wenn ein verkettetes SSL-Zertifikat für vCenter verwendet wird, kopieren Sie die Datei "chain.pem", die alle Zertifikate in der Zertifikatskette enthält, in das Verzeichnis "/usr/local/avamarclient/bin" auf dem Proxy.

    3. Legen Sie die entsprechenden Betriebssystemberechtigungen für das Zertifikat fest, indem Sie Folgendes eingeben:

      chmod 600 /usr/local/avamarclient/bin/rui.crt

      Dabei ist "rui.crt" der Zertifikatsname.

    4. Führen Sie den folgenden Befehl für die Datei "rui.crt" aus, um den SSL-Zertifikatfingerabdruck zu erfassen:

      openssl x509 -in rui.crt -fingerprint | grep Finger

      Die Ausgabe sollte so oder ähnlich aussehen:

      SHA1 Fingerprint=C7:35:19:95:9C:3F:56:1D:73:35:52:41:F3:02:46:A3:B9:46:4F:D9

    5. Öffnen Sie die Datei "/usr/local/avamarclient/var/avvcbimageAll.cmd" in einem UNIX-Texteditor.
       
    6. Fügen Sie die folgenden Einträge am Ende der Datei hinzu:

      --ssl_server_cert_thumbprint="thumbprint of rui.crt"
      --ssl_server_authentication_file=/usr/local/avamarclient/bin/rui-ca-cert.pem

      Dabei ist "rui.cert" der Zertifikatsname und "thumbprint" ist der Fingerabdruck für vCenter Server. Die Ausgabe sollte so oder ähnlich aussehen:

      --ssl_server_cert_thumbprint="C7:35:19:95:9C:3F:56:1D:73:35:52:41:F3:02:46:A3:B9:46:4F:D9"

      HINWEIS: Verwenden Sie "chain.pem" für verkettete vCenter-SSL-Zertifikate.

    7. Speichern Sie die Änderungen und schließen Sie die Datei "avvcbimageAll.cmd".
       
    8. Öffnen Sie /usr/local/avamarclient/var/avvmwfileAll.cmd in einem UNIX-Texteditor.
       
    9. Fügen Sie den folgenden Eintrag am Ende der Datei hinzu:

      --ssl_server_authentication_file=/usr/local/avamarclient/bin/rui-ca-cert.pem

      Dabei ist "rui-ca-cert.pem" der Zertifikatsname.

      HINWEIS: Verwenden Sie "chain.pem" für verkettete vCenter-SSL-Zertifikate.

    10. Speichern Sie die Änderungen und schließen Sie die Datei "avvmwfileAll.cmd".
       
    11. Öffnen Sie "/etc/vmware/config" in einem UNIX-Texteditor.
       
    12. Fügen Sie die folgenden Zeilen am Ende der Datei hinzu:

      vix.enableSslCertificateCheck = "true"

      vix.sslCertificateFile = "/usr/local/avamarclient/bin/rui-ca-cert.pem"
    13. Speichern Sie die Änderungen und schließen Sie "/etc/vmware/config".
       
    14. Öffnen Sie die Datei "/usr/local/avamarclient/var/vddkconfig.ini" in einem UNIX-Texteditor.
       
    15. Suchen Sie nach dem Eintrag "vixDiskLib.linuxSSL.verifyCertificates=0".
       
    16. Ändern Sie den Eintrag "vixDiskLib.linuxSSL.verifyCertificates=0" in "1":

      vixDiskLib.linuxSSL.verifyCertificates=1
       
    17. Speichern Sie die Änderungen und schließen Sie die Datei "vddkconfig.ini".
       
    18. Stellen Sie sicher, dass auf diesem Proxy keine Sicherungs- oder Wiederherstellungsaufträge ausgeführt werden.
       
    19. Starten Sie die Dienste "avagent" und "vmwareflr" neu, indem Sie die folgenden Befehle eingeben:

      service avagent-vmware restart
      service vmwareflr restart
  • Die Schaltflächen „Dienst beenden/starten“ sind auf der Konfigurationsseite nicht mehr verfügbar, wenn Sie „emwebapp.sh --restart“ in CLI ausführen.

    Problemumgehung: Sie müssen „emwebapp.sh“ in einer sudo-Anmeldungs-Shell (sudo -i) oder als Root-Benutzer (su - root) ausführen. Andernfalls ist es möglich, dass die Dienste-Schaltflächen auf der Konfigurationsseite nicht mehr verfügbar sind.

    Das Administratorhandbuch für vSphere Data Protection referenziert das emwebapp.sh-Skript dreimal:

    • Auf Seite 32 in „Best Practices“ – hier gibt es eine Referenz zu emwebapp.sh --start.
    • Auf Seite 36 in „Freigeben von Datenspeicher für das Upgrade“ – hier gibt es zwei Referenzen. Schritt 3 enthält emwebapp.sh --stop und Schritt 9 emwebapp.sh --start.
  • VMDK-Sicherungsaufgabe schlägt unbemerkt fehl, wenn eine einzelne VMDK auf einen anderen Datenspeicher migriert wird.

    Bei einer Migration einer individuellen VMDK aus einem Datenspeicher auf einen anderen versucht VDP, alle Sicherungsaufgaben zu aktualisieren, die die migrierte Festplatte enthalten. In einigen Fällen kann VDP nicht genau bestimmen, auf welchen Speicherort die durch die Sicherungsaufgabe referenzierte Festplatte migriert wurde. In diesem Fall wird die Sicherungsaufgabe nicht aktualisiert. Ein Aspekt dieses Problems ist, wenn sich der Name des Festplattenordners im neuen Datenspeicher von dem des Ordners im ursprünglichen Datenspeicher unterscheidet. Wenn VDP nicht bestimmen kann, auf welchen Speicherort die VMDK migriert wurde, sendet VDP eine vCenter-Warnung, dass die Sicherungsaufgabe möglicherweise nicht mehr genau ist.

    Wenn die VDP-Appliance heruntergefahren wird oder der emwebapp.sh-Dienst zum Zeitpunkt der VMDK-Migration beendet wird, kann VDP die Migration nicht erkennen. Die Sicherungsaufgaben werden nicht aktualisiert. Wenn die Sicherungsaufgaben nicht synchronisiert sind, wird keine Warnung an vCenter gesendet. Wenn eine Sicherungsaufgabe nicht mit dem Speicherort der VMDK synchronisiert ist, wird die Sicherungsaufgabe weiterhin erfolgreich abgeschlossen, jedoch die migrierte Festplatte nicht mehr gesichert.

    Aktualisieren Sie zum Beheben dieses Problems die Sicherungsaufgabe. Fügen Sie anschließend die migrierte VMDK zur Sicherungsaufgabe mit dem VDP vCenter-Plug-In wieder hinzu.

  • Die Sicherungen einer Festplatte können gelöscht werden, obwohl im Administratorhandbuch fälschlicherweise angegeben ist, dass das Löschen von Festplattensicherungen nicht möglich ist.

    Die folgenden Abschnitte im Administratorhandbuch für vSphere Data Protection müssen korrigiert werden:

    • Abschnitt „Löschen eines Sicherungsauftrags“ auf Seite 118 – Die folgenden Angaben sind nicht gültig und werden in der nächsten Version dieses Handbuchs entfernt: „Sie können keine Sicherungen löschen, die auf einzelnen Festplatten ausgeführt werden. Sie können nur vollständige Image-Sicherungen löschen.“
       
    • „Löschen einer Sicherung über die Registerkarte „Wiederherstellen““ auf Seite 132 – Die Angabe „Sie können nur vollständige Image-Sicherungen löschen.“ muss wie folgt neu formuliert werden: „Sie können nur gelöscht werden, wenn auch die vollständigen Image-Sicherungen gelöscht werden.“
  • Fügen Sie die Dokumentation zum Administratorhandbuch hinzu, um anzuzeigen, dass VDP 6.0 VVOL nicht unterstützt.

    VDP 6.0 unterstützt nicht die Sicherung und Wiederherstellung von VMs auf virtuellen Volumen (VVOLs).

  • Vor der Wiederherstellung als neue virtuelle Maschine müssen Sie Storage DRS deaktivieren und auf „Manuell“ festlegen, da andernfalls der Wiederherstellungsvorgang fehlschlägt.

    Innerhalb des Sicherungsfensters und vor dem Ausführen einer Wiederherstellung in einem neuen Speicherort müssen Sie die vMotion-Funktion auf den VM- und Datenspeicherebenen deaktivieren.

    1. Greifen Sie mit einem Webbrowser auf den vSphere Web Client zu:

      https://<IP-Adresse_vCenter_Server>:9443/vsphere-client/
       
    2. Wählen Sie vCenter > Hosts und Cluster aus.
       
    3. Klicken Sie auf die Registerkarte DRS.
       
    4. Aktivieren Sie das Kontrollkästchen Manuell für alle im linken Menü aufgeführten DRS-Cluster.
       
    5. Wählen Sie Bestandsliste > Datenspeicher aus.
       
    6. Für jeden Datenspeicher, in dem VMs, Proxys und VDPs gespeichert sind, führen Sie die folgenden Schritte aus:
       
      1. Wählen Sie den Datenspeicher aus.
         
      2. Wählen Sie Einstellungen bearbeiten aus.
         
      3. Klicken Sie im linken Menü unter Allgemein auf SDRS-Automatisierung.
         
      4. Wählen Sie im rechten Bereich Keine Automatisierung (manuell) aus.
         
      5. Wählen Sie Einstellungen der VM.
         
      6. Stellen Sie sicher, dass unter SDRS-Automatisierung für alle VMs Deaktiviert oder Manuell angezeigt wird.
  • Importierte Image-Sicherungen können nicht repliziert werden.

    Bei importierten Sicherungen verschiebt der Importvorgang die Clients und Konten aus deren aktuellem Kontopfad zu /REPLICATE/VDP_IMPORTS/. Der Domänenname auf dieser Ebene enthält einen Zeitstempel, der am Ende des Namens angefügt wird. Der Importvorgang löscht auch alle Aufgaben. Um diese Sicherungen zu replizieren, müssen Sie die replizierten Sicherungen für diesen Typ auswählen und anschließend die importierten Sicherungen auswählen.

  • Das Programm zur Verbesserung der Benutzerfreundlichkeit (PhoneHome) wird in einer reinen IPv6 vSphere Data Protection-Umgebung nicht unterstützt.
  • VMDK-Probleme

    • Inkorrektes Verhalten der VDP-Appliance, wenn mehrere Festplatten zu denselben SCSI-Slots hinzugefügt werden.

      Die VDP-Appliance beginnt einen Wiederherstellungsvorgang mit denselben SCSI-IDs auf derselben bestehenden VM, die zwei unterschiedlichen Wiederherstellungspunkten zugewiesen wurde. Zusätzlich gibt die Seite "Übersicht" fälschlicherweise an, dass zwei neue virtuelle Festplatten hinzugefügt werden. Der Wiederherstellungsvorgang wird erfolgreich abgeschlossen, ohne dass der Benutzer informiert wird, dass nur die erste einzelne Festplatte hinzugefügt wurde und die zweite Festplatte einfach die erste Festplatte ersetzt hat.

    Allgemeine VDP-Appliance-Probleme

    • Die Änderung eines Kennworts auf einem konfigurierten vCenter Server ist auf der VDP-Appliance nicht zulässig, auch wenn das vCenter Server-Kennwort abgelaufen ist.

      Die VDP-Configure-Anwendung lässt die Änderung eines Kennworts für das konfigurierte vCenter nicht zu, wenn sich Sicherungen auf dem Server im ausgeführten Zustand befinden. Wenn das Benutzerkennwort auf dem konfigurierten vCenter bereits abgelaufen ist, werden keine Aufgaben auf der Aufgabenkonsole gepostet; folglich können die Aufgaben nicht abgebrochen werden.

      Problemumgehung: Führen Sie die folgenden Schritte aus:

      1. Warten Sie, bis alle Sicherungen und Aufgaben in der VDP-Appliance abgeschlossen sind, und ändern Sie dann das Kennwort.
      2. Starten Sie die VDP-Appliance im Wartungsfenster neu, melden Sie sich an der VDP-Configure-Benutzerschnittstelle an und ändern Sie dann das vCenter-Kennwort über die VDP-Configure-Benutzerschnittstelle.
    • Das PAT-Ergebnis (Performance Assessment Test) ändert sich in "Niemals ausgeführt", wenn der Datenspeichername geändert wird.

      In diesem Szenario öffnet der Benutzer die VDP-Configure-Benutzerschnittstelle, klickt auf die Registerkarte Speicher, wählt einen Datenspeicher und aktiviert das Kontrollkästchen Leistungsanalyse für Speicherkonfiguration ausführen. Der Leistungsanalysetest wird erfolgreich abgeschlossen, und die Ergebnisse der Leistungsanalyse werden korrekt angezeigt. Wenn der Benutzer den Namen des Datenspeichers ändert, wird in den Leistungsanalyseergebnissen jedoch fälschlicherweise angegeben, dass der Status "Niemals ausgeführt" lautet.

    • Der VDP-Server ist für Man-in-the-Middle-Angriffe anfällig.

      Nach dem Aktivieren der SSL-Konfiguration zum Herstellen einer sicheren Verbindung zwischen vCenter und VDP kann ein Benutzer die Verbindung nicht über das VDP-Plug-In herstellen. Deshalb wird der folgende Fehler im vdr-server.log angezeigt:

      javax.net.ssl.SSLHandshakeException:java.security.cert.CertificateException: Kein SAN (Subject Alternative Name) gefunden, der mit IP-Adresse x.x.x.x übereinstimmt

      Hauptursache:

      Der vCenter Server ist bei VDP mit einer vCenter IP-Adresse registriert. Es ist kein alternativer Antragstellername im vCenter-Zertifikat verfügbar.

      Um dieses Problem zu beheben, verwenden Sie eine der folgenden Umgehungen:

      • Generieren Sie das selbstsignierte vCenter-Zertifikat neu und fügen Sie den alternativen Antragstellernamen hinzu, um die IP-Adresse aufzunehmen.
      • Registrieren Sie vCenter mit VDP mit dem vollqualifizierten Hostnamen neu, der im vCenter-Zertifikat bereitgestellt wurde. Wenn Sie sich für die Neuregistrierung mithilfe eines vollqualifizierten Hostnamens entscheiden, werden alle Sicherungsaufträge und -richtlinien gelöscht. Sie müssen die Sicherungsaufträge und -richtlinien neu erstellen, nachdem Sie Änderungen an der Konfiguration vorgenommen haben. Wiederherstellungsaufträge und Backups sind nicht davon betroffen.

    Sicherungsprobleme

    • Falls eine große Sicherungsaufgabe (ungefähr 100 VMs) erstellt wird, kann es bis zu zehn Minuten dauern, bis die Sicherungsaufgabe erstellt wird.
    • Das Laden von Clients dauert sehr lang, wenn eine Sicherungsaufgabe bearbeitet oder geklont wird.

      Der Bearbeitungs- oder Klonvorgang eines Sicherungsauftrags für einen SharePoint-Server (aktualisiertes Plug-In) benötigt zum Laden von Clients 5 bis 10 Minuten. Zusätzlich tritt eine gewisse Verzögerung beim Laden von Clients für Microsoft Exchange- und SQL-Server ein, die vor einem Upgrade erstellt wurden.

      Dies ist ein bekanntes Problem, das in einer künftigen Version behoben wird.

    • Die Sicherung einer VM schlägt fehl, wenn ESX aus einem Datencenter in ein anderes innerhalb der gleichen vCenter-Bestandsliste verschoben wird.

      Nach dem Verschieben eines ESX-Hosts aus einem Datencenter (Datencenter A) in ein anderes (Datencenter B) und dem anschließenden Durchführen einer manuellen Sicherung eines VM-Clients im Datencenter B schlägt die Sicherung möglicherweise fehl. Im Fehlerprotokoll wird angezeigt, dass der Sicherungsauftrag nach wie vor auf Datencenter A anstatt auf Datencenter B verweist.

    • Um dieses Problem zu umgehen, führen Sie einen der folgenden Schritte aus, bevor Sie eine manuelle Sicherung der virtuellen Maschine ausführen:

      • Warten Sie 24 Stunden lang. Dadurch kann der Sicherungsauftrag das richtige Datencenter berücksichtigen.
      • Führen Sie den folgenden Befehl zur Synchronisierung des mccli-vmcache aus:

        mccli vmcache sync --name=vCenter_IP-Adresse --domain=/vCenter_IP-Adresse

    Wiederherstellungsprobleme

    • Wenn eine virtuelle Maschine während eines VDP-Wiederherstellungsvorgangs gelöscht wird, wird die virtuelle Maschine nicht ordnungsgemäß aus der VDP-Bestandsliste entfernt. Dies verursacht einen Fehler, wenn die Sicherungsaufträge, die die gelöschte virtuelle Maschine als Quelle enthalten haben, bearbeitet werden. Wenn zusätzlich eine virtuelle Maschine mit demselben Namen erstellt wird, schlagen Versuche, die virtuelle Maschine zu einem Sicherungsauftrag hinzuzufügen, fehl.

      Problemumgehung: Es wird empfohlen, virtuelle Maschinen während Wiederherstellungsvorgängen nicht zu löschen. Falls dieser Fehler auftritt, erstellen Sie die virtuelle Maschine unter einem neuen Namen und fügen Sie sie zu einem neuen Sicherungsauftrag hinzu.

    • Wiederherstellen auf Dateiebene (FLR): "Fehler 10007: Unbestimmter Fehler“ wird bei den meisten FLR-Fehlern angezeigt.

      Die Meldung "Fehler 10007: Sonstiger Fehler" wird für die meisten der FLR-Fehler angezeigt. Darüber hinaus zeigt FLR keine Fehlermeldung an, wenn ein Wiederherstellungsfehler aufgrund der Tatsache, dass die Festplatte voll ist, oder aufgrund eines langen Dateipfads auftritt. Aus diesem Grund ist es unmöglich, die Hauptursache des FLR-Fehlers zu ermitteln.

    • Gelöschte Festplatten werden bei der Wiederherstellung am ursprünglichen Speicherort übersprungen.

      Falls die Ziel-VM nicht mehr den gleichen Speicherbedarf hat wie die ursprüngliche VM, die gesichert wurde (wenn die Festplatten aus der VM entfernt oder gelöscht wurden), schlägt die Wiederherstellung der fehlenden Festplatte der VM unbemerkt fehl, wenn ein Vorgang des Typs "Am ursprünglichen Speicherort wiederherstellen" durchgeführt wird, nachdem ein Wiederherstellungspunkt-Zeitstempel im Bereich für die Wiederherstellung ausgewählt wurde.

      Problemumgehung: Stellen Sie die Festplatte am ursprünglichen Speicherort wieder her, nachdem Sie die fehlende Festplatte der VM manuell hinzugefügt haben. Stellen Sie sicher, dass die Festplatte genauso groß ist wie zum Zeitpunkt der Sicherung der VM. Wenn diese Umgehung fehlschlägt, stellen Sie die Festplatte an einem neuen Speicherort wieder her, um eine neue VM zu erstellen. Wenn die Wiederherstellungsaufgabe abgeschlossen ist, trennen Sie die wiederhergestellten Festplatten von der neuen VM und hängen Sie sie unter Verwendung der Informationen aus dem Abschnitt "Trennen und erneutes Anbinden von Speicher" im Administratorhandbuch für vSphere Data Protection an die erforderliche VM an.

    • In einer VSAN-Umgebung ist der Vorgang zur Wiederherstellung auf Imageebene am ursprünglichen Speicherort zulässig, aber der Vorgang zur Wiederherstellung auf Festplattenebene am ursprünglichen Speicherort wird abgeblendet dargestellt, nachdem die gesamte virtuelle Maschine zu einem anderen Datenspeicher migriert wurde.

      Problemumgehung: Stellen Sie entweder die gesamte VM mit einer Sicherung auf Imageebene wieder her oder stellen Sie die Sicherung auf Festplattenebene als neue Festplatte auf der ursprünglichen VM wieder her.

    • Wiederherstellen auf Dateiebene (FLR): Wenn die EXT4-Partitionsstruktur mit dem internen Proxy nicht geladen werden kann, wird keine Fehlermeldung angezeigt.

      Das Durchsuchen einer EXT4-Partition mit einem internen Proxy wird mit FLR nicht unterstützt. Wenn der Benutzer diese Aktion ausführt, wird keine ordnungsgemäße Fehlermeldung angezeigt.

    • Wiederherstellung der Sicherung eines sekundären Replikats ist fehlgeschlagen oder wurde mit einem Protokolllückenfehler abgebrochen.

      Bei der Wiederherstellung einer inkrementellen Sicherung eines sekundären Replikats hat die Wiederherstellung den Status Fehlgeschlagen/Abgebrochen zurückgegeben, und das Protokoll gibt den Protokolllückenfehler an, obwohl keine Protokolllücke in der Datenbank vorhanden ist. Beachten Sie, dass dieses Problem nicht bei der Wiederherstellung einer Sicherung eines primären Replikats beobachtet worden ist.

      Dieses Problem steht in Zusammenhang mit der Synchronisierung von AlwaysOn-Knoten und tritt während der Erstellung einer SQL-Metadatendatei im Sicherungs-Workflow auf, wenn die Sicherung für ein sekundäres AlwaysOn-Replikat durchgeführt wird.

      Dieses Problem führte zu Sicherungen mit einer beschädigten Metadatendatei, sodass Benutzer keine Protokollfragmentwiederherstellung durchführen konnten oder dass eine zusätzliche differenzielle/inkrementelle Sicherung nicht mit dieser Sicherungskette verknüpft werden konnte.

      Es tritt kein Datenverlust auf.

      Problemumgehung: Führen Sie eine vollständige Sicherung durch. Stellen Sie sicher, dass die Sicherungsoption "Inkrementelle Sicherung nach der vollständigen Sicherung erzwingen" deaktiviert ist.

    Replizierungsprobleme

    • Die Replikation replizierter Clients unter einem bestimmten Mandanten auf dem Zielserver schlägt fehl.

      Die Replizierung von replizierten Clients aus einer Quelle auf einem Zielserver unter einem bestimmten Mandantenkonto schlägt mit der folgenden Fehlermeldung fehl:

      Angegebenes Konto () liegt nicht innerhalb der aktuellen Autorisierungsdomäne.

      Zusätzlich tritt der Fehler mit den folgenden Quell-/Zielkombinationen auf:

      • Quellserver: VDP Advanced und Zielserver: VDP Advanced / Replizierungsziel-Identität (RTI)
      • Quellserver: RTI und Zielserver: RTI / VDP Advanced
    • Replizierungswiederherstellung: Replikationsprotokolle füllen die Root-Partition – es muss ein symbolischer Link zu einer anderen Partition erstellt werden.

      Die Replizierungsprotokolle werden zurzeit auf die /space-Partition geleitet und nicht auf die root-Partition.

      Problemumgehung: Verwalten Sie die Replizierungsprotokolle im Verzeichnis /usr/local/Avamar/var/client (die space-Partition).

    • Die Replikation ist erfolgreich, wenn keine Wiederherstellungspunkte vorhanden sind.

      Replizierungsaufträge werden erfolgreich aus- und zu Ende geführt, auch wenn die Wiederherstellungspunkte gelöscht wurden. Der Replizierungsauftrag repliziert jedoch nicht die Sicherungen. Das erwartete Verhalten ist ein Fehlschlagen des Auftrags, da es keine Wiederherstellungspunkte zum Replizieren gibt.

      Dies ist ein bekanntes Problem, das in einer künftigen Version behoben wird.

    Probleme bei Microsoft Application (MS App)

    • Auf Microsoft Exchange-Clients sind zahlreiche Warnmeldungen im avagent-Protokoll vorhanden, die häufig ausgegeben werden und die Protokolle füllen.

      Der Microsoft Exchange-Client ist noch bei zwei VDP Advanced-Appliances im vCenter registriert, wodurch das Problem verursacht wird.

    • Upgrade 2014: Der Benutzer des Backup-Agenten wird nach dem Aktualisieren des Client-Plug-Ins von Microsoft Exchange auf das lokale System zurückgesetzt.

      Beim Aktualisieren des Client-Plug-Ins von Microsoft Exchange von der Vorgängerversion der VDP Advanced-Appliance auf die aktuelle VDP Advanced-Appliance wird der Benutzer der Backup-Agentservice-Anmeldung auf Lokales System anstelle von Backup-Benutzer zurückgesetzt.

      Von VDP-Version 5.5.6 bis 5.8 setzt das System die Anmeldedaten auf Kenndaten des lokalen Systems, ohne nach einer Erlaubnis zu fragen, wodurch die Sicherungsaufgabe fehlschlägt.

      Problemumgehung: Um den Sicherungsauftrag für Microsoft Exchange zu bearbeiten oder einen neuen Sicherungsauftrag für Microsoft Exchange zu erstellen, muss der Benutzer den Backup-Agent-Dienst manuell konfigurieren. Dazu muss der Benutzer den Benutzernamen und das Kennwort mithilfe des Konfigurationsdienstprogramms für Sicherungsbenutzer eingeben.

    Probleme bei Automatic Backup Verification (ABV)

    • ABV: Überprüfungsaufgabe schlägt nach der Umbenennung der Datenbank fehl.

      Dieser Fehler kann auftreten, wenn Sie den Ziel-Datenspeicher umbenennen oder aus VDP heraus verschieben.

      Problemumgehung: Bearbeiten Sie den Überprüfungsauftrag und wählen Sie den umbenannten oder verschobenen Datenspeicher als neues Ziel aus. Anleitungen finden Sie unter "Bearbeiten eines Backupverifizierungsjobs" im Administratorhandbuch für vSphere Data Protection.

    • ABV: Initiierung der Überprüfungsaufgabe schlägt fehl, wenn der Zielpfad für den Host geändert wird.

      Problemumgehung: Bearbeiten Sie den Überprüfungsauftrag und wählen Sie den geeigneten Zielpfad aus, wenn Sie den Überprüfungsauftrag durchführen.

    • Wenn die Überprüfungsaufgabe aufgrund von Verbindungsproblemen fehlschlägt, die von Data Domain verursacht wurden, werden unpassende Fehlermeldungen angezeigt.

      Die Sicherung kann nicht wiederhergestellt werden, und die Überprüfungsaufgabe schlägt fehl, da die VDP-Appliance nicht mit Data Domain kommunizieren kann. Es wird erwartet, dass der Überprüfungsauftrag fehlschlägt, aber es wird nicht die korrekte Fehlermeldung angezeigt, und der Benutzer kennt die Ursache des Fehlers nicht.

    Behobene Probleme in vSphere Data Protection 6,0

    Die folgenden Probleme wurden seit der letzten Version von vSphere Data Protection behoben.

    • Wenn ein Thin-bereitgestellter VDP die Datenspeicherkapazität erreicht, treten selbst nach dem Freigeben von Datenspeicher und Erstellen von mehr Speicherplatz Integritätsprüffehler für den VDP auf.

      Auf einer schnell bereitgestellten (Thin Provisioning) VDP-Appliance mit einer VM-Größe von 100 GB oder mehr verursacht das Ausführen eines Sicherungsauftrags ein Problem mit der Datenintegrität, das zu einem schwerwiegenden Systemfehler führt. Der wahrscheinliche Grund für diesen Fehler ist, dass der Datenspeicher die Kapazitätsgrenze erreicht hat und die Integritätsprüfung verhindert. Selbst nach der Freigabe von Speicherplatz schlägt die Integritätsprüfung fehl.

      Um die Warnung zu deaktivieren, führen Sie entweder eine erfolgreiche, vollständige Validierung für den neuesten Prüfpunkt durch oder wenden Sie sich an den Kunden-Support, um einen Code zum Deaktivieren der Warnung zu erhalten.

    • Bei abgebrochenen Wiederherstellungsvorgängen ist eine Bereinigung erforderlich.

      Wenn ein Benutzer einen neuen Wiederherstellungsvorgang auf einer virtuellen Maschine erstellt und dann den Wiederherstellungsvorgang vor dem Abschluss abbricht, wird die neue virtuelle Maschine, die im vCenter erstellt wird, nicht bereinigt. Mit der aktuellen Implementierung wird der Snapshot der virtuellen Maschine, aber nicht die neu erstellte oder neu registrierte virtuelle Maschine entfernt.

      Dies ist so vorgesehen.

    • Die Verbindung der VDP-Appliance wird unterbrochen und in vielen Fällen tritt ein unerwarteter Fehler auf.

      Benutzer können gelegentlich die folgende Fehlermeldung erhalten: "Ein unerwarteter Verbindungsfehler ist aufgetreten und die Ursache konnte nicht bestimmt werden. Prüfen Sie zur Fehlerbehebung Ihren VDP-Konfigurationsbildschirm, oder wenden Sie sich an einen Administrator." Dies ist eine allgemeine Fehlermeldung und kann für irgendeinen unerwarteten Fehler angezeigt werden.

      HINWEIS: Die Meldung kann allerdings häufiger bei vCenter-Versionen der Reihe 5.5 (einschließlich Version 5.5u1b) auftreten.

      Wenn dieser Fehler auftritt und mit dem bekannten Problem zusammenhängt, sollte der Benutzer die Fehlermeldung schließen und den Schritt erneut versuchen. Wenn der Fehler weiterhin auftritt, wenden Sie sich an den technischen Support.

    • Wenn der Benutzer während der VDP-Installation auf dem vCenter Server-Registrierungsbildschirm auf Zurück klickt, ohne Werte einzugeben, wird das System nicht beim vCenter Server registriert, und die Installation schlägt fehl.

    •  
    • Während der Erstkonfiguration werden keine vCenter-Ereignisse erzeugt, wenn der Benutzer den VDP-Hostnamen oder die IP-Adresse ändert.
       
    • Die Wiederherstellung einer VM als Neugerät schlägt fehl, wenn der vorherige Name der umbenannten VM verwendet wird.

      Wenn der Benutzer eine Sicherungsaufgabe für eine VM erstellt, den Wiederherstellungspunkt auswählt und dann den alten Namen der umbenannten VM in das Feld "An neuem Speicherort wiederherstellen" eingibt, schlägt die Wiederherstellung fehl und die folgende Fehlermeldung wird angezeigt: VM kann nicht für Wiederherstellungspunkt wiederhergestellt werden. Der Datenspeicherpfad existiert bereits.

    • Keine korrekte Fehlerbehandlung beim Ausführen einer geplanten Sicherungsaufgabe für eine VMDK, die auf einen anderen Datenspeicher migriert wurde.

      Eine geplante Sicherungsaufgabe für eine VMDK wird fehlerfrei abgeschlossen, aber wenn der Datenspeicherort in einen anderen Datenspeicher geändert wird, tritt ein Fehler auf.

    • ABV: Eine Überprüfungsaufgabe bei Bedarf wird nicht initiiert, wenn die letzte Sicherung nicht erfolgreich war.

      Eine Fehlermeldung ähnlich der folgenden wird für eine ABV-Aufgabe angezeigt, wenn die letzte Sicherung nicht erfolgreich war:

      Fehler: "Unerwarteter Fehler OHNE Fehlercode, siehe Protokolle."

      Der Benutzer wird nicht auf das Problem hingewiesen, und die Protokolle enthalten keine hilfreichen Informationen.

    • Umgeleitete Microsoft SharePoint-Wiederherstellungsaufgabe schlägt für die Datenbank fehl, wenn die IP-Adresse anstelle des Servernamens als Alias verwendet wird.

      Die Sicherung am ursprünglichen Speicherort mit der Option "Überschreiben" funktioniert korrekt. Die Sicherung schlägt nur bei der Ausführung einer umgeleiteten Wiederherstellung fehl, wenn die IP-Adresse anstelle des Servernamens verwendet wird.

      Problemumgehung: Verwenden Sie den Servernamen, wenn Sie einen Alias erstellen.

    • Anmeldung bei vdp-configure nach dem ersten Neustart nicht möglich.

      Es sind periodische Instanzen vorhanden, sodass sich der Benutzer nach dem Bereitstellungs-/Neustartzyklus nicht bei vdp-configure anmelden kann. Im vdr-configure-Protokoll wird keine Fehlermeldung angezeigt. Das Problem wird durch Löschen des Browser-Caches oder Anmeldung mit anderen Browsern nicht behoben.

      Problemumgehung: Melden Sie sich über eine Konsolenverbindung bei der virtuellen VDP-Appliance an und verwenden Sie die folgenden Befehle, um die vdp-configure-Dienste manuell zu starten und zu stoppen:

      emwebapp.sh --restart

    • Eine umgeleitete Microsoft SharePoint-Wiederherstellungsaufgabe wird auch dann als erfolgreich angezeigt, wenn die Wiederherstellung einiger Datenbanken fehlschlägt.

      Beim Wiederherstellen einer großen Anzahl von Datenbanken oder einer ganzen SharePoint-Farm schlagen einige problematische Datenbanken möglicherweise fehl. Auch wenn einige Datenbanken fehlschlagen, meldet die Wiederherstellungsaufgabe, dass die Aufgabe erfolgreich war. Dadurch könnten Daten verloren gehen. Die Datenbanksicherung schlägt nur bei Ausführung einer umgeleiteten Wiederherstellung fehl, wenn bei der Erstellung eines SQL-Alias anstelle des Servernamens die IP-Adresse verwendet wird.

      Problemumgehung: Verwenden Sie den Servernamen, wenn Sie einen Alias erstellen.

    • Die VDP-Appliance stürzt ab und wird ausgeschaltet, wenn eine Thin-bereitgestellte virtuelle Maschine auf einem Datenspeicher mit unzureichendem Speicherplatz wiederhergestellt wird.

      Die Appliance stürzt ab, da die der Appliance bei laufendem Betrieb hinzugefügte Festplatte nicht über genügend Speicherplatz verfügt. Daher kann das Problem nicht behoben werden, indem die Appliance auf einem anderen Datenspeicher platziert wird.

      Es wird empfohlen, vor der Durchführung einer ABV- oder Wiederherstellungsaufgabe zu prüfen, ob genügend freier Speicherplatz auf dem Datenspeicher zur Verfügung steht.

    • Bei der Durchführung einer Granular Level Recovery (GLR) auf einem Microsoft Exchange-Server sollte das Feld für das Zielpostfach optional sein.
       
    • Veraltete Quellen für eine fehlgeschlagene oder abgebrochene Anwendungsdatenbanksicherung zeigen eine falsche Anzahl an.
       
    • Importieren der Festplatte: Der Erstkonfigurationsassistent weist standardmäßig stets 4 vCPUs und 4 GB RAM zu.
       
    • Der Snapshot konnte auch dann nicht entfernt werden, wenn die Aufgabe "Snapshot erstellen" einen gültigen Snapshot zurückgegeben hatte.

      Datensicherungen können gelegentlich mit dem Fehler "Entfernen des Snapshots fehlgeschlagen" fehlschlagen. Dies wird durch einen Fehler bei VMware verursacht, bei dem das Entfernen des Snapshots vom vCenter Server selbst dann verweigert wird, wenn die Snapshot-Erstellung erfolgreich war.

      Problemumgehung: Entfernen Sie den Snapshot von der virtuellen Maschine manuell über den Snapshot-Manager und führen Sie die Sicherungsaufgabe erneut aus.

    • Import von VDP-Festplatten im VSAN-Datenspeicher ist fehlgeschlagen.

    •  
    • Bei einer fehlgeschlagenen Replikationsaufgabe mit abgelaufenen oder geänderten Zielanmeldedaten sollte ein entsprechender Fehler angezeigt werden.

    •  
    • Die Verbindung der VDP-Appliance wird beim Auswählen irgendeiner Option im vSphere Web Client automatisch unterbrochen.

      Wenn der Benutzer im vSphere Web Client auf die Option "Ereignis" oder "Aufgabe" klickt und dann versucht, zum VDP-Appliance-Bildschirm zurückzukehren, wird die Verbindung unterbrochen. Der Benutzer muss die Verbindung mit der VDP-Appliance manuell wieder herstellen.

    • Benutzer können das Programm nicht sicher ausführen, wenn kein standardmäßiger vCenter Server-Port verwendet wird.

      Dieses Problem ist ein Nebeneffekt der erhöhten VDDK-Sicherheit zum Schutz vor OpenSSL-Man-in-the-Middle-Angriffen. Wenn das vCenter nicht den standardmäßigen Webservice-Port (443) verwendet und VDP in einer solchen Umgebung konfiguriert wird, dürfen Sie nicht das im Administratorhandbuch für vSphere Data Protection unter "Konfigurieren der Proxy-Zertifikat-Authentifizierung" beschriebene Verfahren verwenden, weil das Ergebnis nachteilig sein könnte.

      Problemumgehung: Verwenden Sie den standardmäßigen Webservice-Port (443) beim Konfigurieren der Proxy-Authentifizierung.

    • Lücken in Change Block Tracking (CBT)-Daten nach der Erweiterung der Festplatte auf 150 G.

      Um dieses Problem zu umgehen, lesen Sie den VMware-Knowledgebase-Artikel: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2090639

    • Berichte: Beim Aktualisieren werden die Filteroptionen nicht gelöscht.

    •  
    • Replizierter Arbeitsauftrag bei der VDP Advanced-Appliance der Quelle wird zeitweise in Warteschlange eingereiht.

      Beim ersten Auslösen einer Ad-hoc-Replikationsaufgabe in einer VDP Advanced-Appliance mit importierten Datenträgern wird der Replizierungs-Client in einen deaktivierten Zustand versetzt. Dadurch wird die Replizierung in die Warteschlange eingereiht. Der Auftrag wartet, bis der Replizierungs-Client wieder aktiviert oder das Zeitlimit des Auftrags überschritten wird.

      Problemumgehung: Deaktivieren Sie den Replizierungs-Client und aktivieren Sie ihn dann neu. Wenn der Replizierungs-Client schon deaktiviert ist, aktivieren Sie einfach den Client neu.

      Verwenden Sie als Admin-Benutzer die folgenden Befehle zum Deaktivieren und erneuten Aktivieren des Replizierungs-Clients:

      Verwenden Sie den folgenden Befehl, um den Replizierungs-Client zu suchen:

      mccli client show --recursive=true --domain=/MC_SYSTEM

      Um den Replizierungs-Client zu deaktivieren und neu zu aktivieren, ersetzen Sie durch den im vorherigen Befehl geladenen Clientnamen:

      mccli client edit --name=/MC_SYSTEM/ --enabled=false

      mccli client edit --name=/MC_SYSTEM/ --enabled=true

      Hinweis: Wenn der Replizierungs-Client schon deaktiviert ist, benötigen Sie nur den zweiten Befehl, um den Client erneut zu aktivieren.

    • Replizierungswiederherstellung: Wiederherstellungsprotokolle sollten anders als Ad-hoc-Replikationsprotokolle gekennzeichnet werden.

      Wiederherstellungsprotokolle und Elemente von Ad-hoc-Replikationsprotokollen werden durch Arbeitsauftragskennungen (WIDs) unterschieden, die eindeutige Kennungen für virtuelle Maschinen oder Clients sind, die wiederhergestellt oder repliziert wurden. Wenn ein Benutzer Replizierung und Wiederherstellung auf demselben VDP Advanced-Server ausführt, erfasst der Protokollbündler Protokolle für beide Aktionen im Verzeichnis /REPLICATE/Server_logs. Die Appliance kann Wiederherstellungsprotokolle nicht von Ad-hoc-Replikationsprotokollen unterscheiden und dies erschwert die Identifizierung und das Debuggen von Protokollen.

    • Multi-Tenant-Funktion: Im Wiederherstellungsassistenten sollten Informationen zum Replizierungsquellserver angegeben werden.

      Wenn dieselbe virtuelle Maschine oder eine virtuelle Maschine mit demselben Namen von zwei unterschiedlichen Quellservern unter demselben Mandantenknoten mit demselben Benutzerkonto repliziert wird, wird auf der Clients- und Sicherungenseite im Wiederherstellungsassistenten die virtuelle Maschine vom Ausgangsserver angezeigt, wie in der folgenden Multi-Tenant-Hierarchie gezeigt:

      /VDP Advanced-Ziel
      /Replizierung
       -Mandant
        -VDP Advanced-Quelle 1
          -VCSA
           -VM
             -Client 1
        -VDP Advanced-Quelle 2
         -VCSA
          -VM
           -Client 1

      Während der Wiederherstellung wird auf der Clients- und Sicherungenseite Client 1 von Quelle 1 und Quelle 2 mit den jeweiligen Sicherungen angezeigt. Mit Ausnahme des Datums- und Zeitstempels kann der Benutzer allerdings nicht zwischen den zwei Clients mit demselben Namen und Suffix unterscheiden.

    • Fehlermeldung beim Hinzufügen eines Datendomänensystems zur VDP-Appliance, wenn die Zeiten nicht synchronisiert sind, muss korrigiert werden.

      Die folgende Fehlermeldung wird angezeigt, wenn die Zeit des Datendomänensystems und die Zeit der VDP-Appliance nicht synchronisiert sind:

      Dem Datendomänensystem kann kein Trap-Host hinzugefügt werden

    • Replikationsaufgabe zeigt fälschlicherweise den Status 'fehlgeschlagen' anstelle von 'abgebrochen' an

      Wenn auf einer VDP Advanced-Appliance eine Replikationsaufgabe abgebrochen wird, wird die Ausführung des Auftrags fortgesetzt und nach einiger Zeit schlägt der Auftrag fehl, obwohl er eigentlich abgebrochen wurde.

      Die Abbruchanforderung erreicht die Quelle nicht, die Replikationsaufgaben werden also weiter auf der Replizierungsquelle (übergeordnetes Element) und dem Replizierungsziel (untergeordnetes Element) ausgeführt, auch wenn der Auftrag abgebrochen wurde.

      Dies ist ein bekanntes Problem, das in einer künftigen Version behoben wird.

    • Auf Microsoft Exchange-Clients wird das Zeitlimit überschritten und die Durchsuchfunktion funktioniert nicht.
       
    • Der Benutzer sollte beim Ausführen einer Sicherungsaufgabe aufgefordert werden, keinen externen Proxy bereitzustellen.

      Der Benutzer wird nicht vor der Bereitstellung eines externen Proxys gewarnt, während eine Sicherung ausgeführt wird. Wenn ein externer Proxy bei einem Sicherungsvorgang bereitgestellt wird, wird die Bereitstellung zwar fortgesetzt, aber der interne Proxy wird durch den Prozess automatisch deaktiviert. Dies kann dazu führen, dass aktuelle Sicherungsvorgänge fehlschlagen oder die Sicherungssitzung unerwarteterweise beendet wird.

      Hinweis: Wenn ein Benutzer versucht, einen internen Proxy bereitzustellen, wird die gerade ausgeführte Sicherungsaufgabe abgebrochen.

    • Wiederherstellung schlägt fehl oder wird abgebrochen, wenn der Datenbankname der Verfügbarkeitsgruppe ein Unicode-Zeichen enthält.
       
    • Aufgaben für die VDP Advanced-Appliance, deren Zeitlimit überschritten wurde, sollten im Bereich "Kürzlich bearbeitete Aufgaben" oder in den Fehlerprotokollen aufgelistet werden.

    •  
    • Beim Wiederherstellen einzelner VMDKs auf mehreren virtuellen Maschinen werden die VMDKs nur für eine der virtuellen Maschinen wiederhergestellt.
       
    • Während einer VDP- oder externen Proxy-Konfiguration kann die VDP-Appliance mithilfe des sekundären DNS (Domänennamensystem)-Diensts nicht aufgelöst werden.
       
    • Replizierungswiederherstellung: Der Authentifizierungsmechanismus des Wiederherstellungsassistenten beendet den Authentifizierungsprozess nicht ordnungsgemäß.

    •  
    • Berichte: Die Neuausführung eines fehlgeschlagenen Auftrags erfolgt für alle Clients in der Sicherungsaufgabe.

    •  
    • SQL-Clientkonfigurationen einer niedrigeren Version werden in vSphere-Versionen einer höheren Version nicht unterstützt.

      Wenn eine niedrigere Version eines SQL-Clients auf einer höheren Version einer VDP Advanced-Appliance installiert wird, kann der Benutzer den Client im vSphere Web Client nicht anzeigen oder durchsuchen. Clients einer niedrigeren Version werden in der VDP Advanced-Appliance nicht unterstützt.

      Dies ist ein bekanntes Problem. Da nicht beabsichtigt ist, SQL-Clients einer niedrigeren Version zu unterstützen, wird das Problem im Abschnitt zur Fehlerbehebung des Administratorhandbuchs für vSphere Data Protection dokumentiert.

    • Replizierungswiederherstellung: Aktionsprotokolle werden nicht vom Protokollbündler der VDP-Appliance der Quelle erfasst.

      Wiederherstellungsprotokolle, die unter einem Ausgangsserver eines lokalen Hosts erstellt werden, werden nicht durch den Protokoll-Collector erfasst.

      Dies ist ein bekanntes Problem, das in einer künftigen Version behoben wird.

    • Externer Proxy: Der interne Proxy wird nach einem Rollback zu einem vorherigen Prüfpunkt aktiviert.

      Die Konfiguration kann entweder aus externen oder internen Proxys bestehen; eine Kombination ist nicht zulässig.

      Wenn eine VDP Advanced-Appliance auf einen früheren Prüfpunkt zurückgesetzt wird, werden interne Proxys aktiviert und externe Proxys bleiben weiterhin aktiviert, aber in einem herabgestuften Zustand.

    • Verzögerung bei der Verfügbarkeit der VDP-Appliance im Webclient nach einem Upgrade von 2013 R2 U1.

      Auf der Startseite von vCenter Web Client (im Dropdown-Menü des Plug-Ins) ist die VDP-Appliance erst mit einer Verzögerung von mehr als einer Stunde verfügbar. (Die Appliance wird nach einigen Sekunden für das vCenter bereitgestellt; allerdings wird sie nicht gleichzeitig im Web Client angezeigt).

      Dieses Problem hängt mit der Aktualisierung des VMware vSphere-Plug-Ins und nicht mit dem Upgrade der VDP-Appliance zusammen.

    • VM-Sicherung ist fehlgeschlagen mit dem unbestimmten Fehler 10007: VM-Metadaten konnten nicht heruntergeladen werden.

      So ermitteln Sie die Ursache des unbestimmten Fehlers:

      1. Gehen Sie zur Registerkarte Berichte der VDP-Appliance.
      2. Klicken Sie auf den Link Protokoll anzeigen zum Anzeigen der Details für die fehlgeschlagene Sicherungsaufgabe.

      HINWEIS: Zum Prüfen der Fehler bei der virtuellen Maschine oder der Fehler bei den Metadaten der virtuellen Maschine können Sie den VM-Datenspeicher durchsuchen. Die Sicherungsaufgabe ist möglicherweise fehlgeschlagen, weil die Appliance eine VMX-Datei im falschen VM-Ordner gesucht hat.

      Problemumgehung:

      1. Konsolidieren Sie die VM-Dateien in einem einzelnen VM-Ordner

      2.   oder
      3. Speichern Sie die VM-Dateien in einem anderen VM-Ordner in verschiedenen Datenspeichern und migrieren Sie sie dann in unterschiedliche Datenspeicher (wenn die virtuellen Maschinen im selben Datenspeicher sind).
      4. Führen Sie die Sicherungsaufgabe neu aus.
    • Nach einer Prüfpunktwiederherstellung von einem Datendomänensystem kann die VDP-Appliance keine Replizierung ausführen.

      Dieses Problem wird verursacht, wenn cprestore den Prüfpunkt aus dem Datendomänensystem kopiert. Nach der Wiederherstellung des Prüfpunkts wird der wiederhergestellte Replikations-Agent bei der alten VDP-Appliance registriert. Deshalb muss der Replikations-Agent bei der neuen (wiederhergestellten) VDP-Appliance neu registriert werden.

      Problemumgehung: Durch die folgenden Schritte wird dieses Problem behoben:

      1. Konfigurieren Sie eine neue VDP-Appliance, die verwendet wird, um den Prüfpunkt wiederherzustellen, der sich im Datendomänensystem befindet.
         
      2. Geben Sie den folgenden Befehl ein, um den Prüfpunkt aus dem Datendomänensystem im VDP wiederherzustellen:

        /usr/local/avamar/bin/cprestore --hfscreatetime=avamar_ID --ddr-server=data_domain_system --ddr-user=dd_boost_user_name --cptag=checkpoint_name

        Befehlsbeispiel:

        /usr/local/avamar/bin/cprestore --hfscreatetime=1400081761 --ddr-server=10.7.92.156 --ddr- user=sysadmin --cptag=cp.20140519205933
         
      3. Kopieren Sie einen Prüfpunkt aus dem Datendomänensystem in VDP.
         
      4. Geben Sie die folgenden Befehle ein, um einen Rollback auf den Wiederherstellungsprüfpunkt durchzuführen:

        dpnctl stop
        dpnctl start --force_rollback

      5. Setzen Sie den Replizierungs-avagent durch Ausführen der folgenden Schritte zurück:
         
        • Starten Sie VDP neu.
           
        • Führen Sie folgende Befehle aus:

          service avagent-replicate stop
          service avagent-replicate unregister
          mccli client edit --domain=/mc_system --name=vdp_hostname --activated=false
          service avagent-replicate register 127.0.0.1 /MC_SYSTEM
           
      6. Nach Abschluss der Wiederherstellung stellen Sie eine Verbindung zur VDP-Appliance her.
         
      7. Starten Sie den internen Proxy neu.
         
    • Wiederherstellen auf Dateiebene (FLR): Es wurde der folgende Fehler beobachtet: 'Fehler beim Abrufen der Datenträger: Durchsuchen ist nicht möglich, da Proxys nicht verfügbar sind

    •  
    • Die Berechtigung „vApp > Importieren“, die während der vCenter-Registrierung validiert wird, fehlt im Administratorhandbuch für vSphere Data Protection.
    • Festplattenerweiterung für Datenträger schlägt im VSAN-Datenspeicher fehl, wenn der VDP-Startdatenträger des Betriebssystems mit einer Größe von 100 GB in einem Nicht-VSAN-Datenspeicher gespeichert ist.

      Wenn Sie eine Festplattenerweiterung in einem VSAN-Datenspeicher durchführen, schlägt der Erweiterungsvorgang fehl und eine entsprechende Fehlermeldung wird angezeigt. Die folgenden Fehler werden in der Datei vdr-configure.log angezeigt:

      Eine VDP-Umgebung, die Sie in einem Nicht-VSAN-Datenspeicher bereitstellen, unterstützt nicht die Erweiterung eines Datenträgers, den Sie in einem VSAN-Datenspeicher bereitstellen. VMware lässt keine manuelle Änderung der Festplattengröße oder der Zuteilung aus vCenter zu. Da VDP den Erweiterungsvorgang ausführt, kann VDP die VM nicht herunterfahren, ohne auch die VDP-Software herunterzufahren.

      Um dieses Problem zu umgehen, migrieren Sie alle VDP-Festplatten, einschließlich des Startdatenträgers des Betriebssystems und der Datenträger, auf den gleichen Datenspeichertyp. Beispiel: Stellen Sie sicher, dass alle Festplatten entweder in einem VSAN-Datenspeicher oder in einem Nicht-VSAN-Datenspeicher gespeichert sind. Versuchen Sie, die Festplattenerweiterung erneut nach der Speichermigration durchzuführen.

    • Exchange 2013 GLR hängt die Datenbank ein, aber durchsucht sie nicht, die Sicherungen sind im Datendomänensystem gespeichert.

      Bei Benutzern, die eine Sicherung der Exchange-Server durchführen und ein Datendomänensystem für die Sicherung anzielen, durchsucht Exchange GLR möglicherweise nicht die Datenbank bei Wiederherstellungsversuchen.

    • Englischsprachige Nachrichten werden möglicherweise in Französisch oder Koreanisch im vSphere Web Client angezeigt.

      Der vSphere Web Client zeigt möglicherweise einige Fehlermeldungen in Französisch oder Koreanisch an, selbst wenn der Webbrowser in einem Gebietsschema für Englisch ausgeführt wird.

      Dies ist ein bekanntes Problem, das in einer künftigen Version behoben wird.

    • Ändern Sie die Häufigkeit der Prüfung der VDP-Appliances-Anzahl in vCenter.

      Wenn Sie mehrere VDPs in einem Virtual Center bereitstellen, das eine große Infrastruktur verwaltet, wird die Arbeitsspeichernutzung des Virtual Center möglicherweise erreicht und führt dazu, dass Virtual Center nicht mehr antwortet.

      Problemumgehung: Verringern Sie die Anzahl der bereitgestellten VDPs.

      Dies ist ein bekanntes Problem, das in einer künftigen Version behoben wird.