Versionshinweise zu vSphere Data Protection 5.8.3

|
Versionshinweise zu vSphere Data Protection 5.8.3 | 12. Januar 2016

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 und Einschränkungen

Im Folgenden sind die bekannten Probleme und Einschränkungen in der vorliegenden Version von vSphere Data Protection aufgeführt:

Probleme bei VMware

  • Der Snapshot konnte auch dann nicht entfernt werden, wenn die Aufgabe "Snapshot erstellen" einen gültigen Snapshot zurückgegeben hatte. (59450)

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

    Problemumgehung:

    Entfernen Sie den Snapshot manuell unter Verwendung des Snapshot-Managers aus der virtuellen Maschine und führen Sie anschließend die Sicherungsaufgabe erneut aus.

  • Die Image-Sicherung schlägt für eine eingeschaltete virtuelle Maschine fehl, die auf einem Virtual SAN-Datenspeicher ausgeführt wird. (1281041)

    Eine Image-Sicherung schlägt für eingeschaltete virtuelle Maschinen fehl, die auf einem Virtual SAN-Datenspeicher ausgeführt wird, auf welchem sowohl die vSphere Data Protection-Appliance als auch die virtuelle Maschine auf demselben Virtual SAN-Datenspeicher ausgeführt, aber von unterschiedlichen vSphere-Hosts verwaltet und eingeschaltet werden. Dieses Problem tritt nur auf, wenn sich die virtuelle Maschine in einem eingeschalteten Zustand befindet.

  • Unterstützung für NAT / Firewall / IDS / TSNR mit Router zwischen der vSphere Data Protection-Appliance und vCenter Server. (1292848)

    Wenn Sie das Netzwerk für die vSphere Data Protection-Appliance und vCenter Server konfigurieren, wird die Änderung von Netzwerkadressinformationen über NAT oder andere Konfigurationsmethoden (z. B. Firewall, IDS oder TSNR) nicht unterstützt. Wenn diese Tools als Teil des virtuellen Netzwerks bereitgestellt werden, funktionieren einige vSphere Data Protection-Funktionen möglicherweise nicht wie vorgesehen.

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

    Dieses Problem ist ein Nebeneffekt der erhöhten VDDK-Sicherheit zum Schutz vor OpenSSL-Man-in-the-Middle-Angriffen. Wenn vCenter Server nicht den standardmäßigen Webservice-Port (443) verwendet und vSphere Data Protection 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.

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

    Fehler 1293852 und 1294581 stehen mit der Aktivierung des sicheren Modus in Zusammenhang. Auf der Benutzeroberfläche der vSphere Data Protection-Appliance empfehlen wir derzeit, dass Benutzer, die ihre Bereitstellung sichern möchten, die SSL-Hostüberprüfung aktiviert haben sollten (standardmäßig ist diese deaktiviert). Zuvor war diese Option nicht vorhanden.

  • Bei Version 5.8 war die Root-Anmeldung deaktiviert, da es sich nicht um eine empfohlene Vorgehensweise handelt. (1309755)

    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 Konsolen-Zeitlimitwert mit dem Hardening-Skript hinzufügen. Beispiel:

    TMOUT = 900

    export TMOUT

  • Die Berechtigung "vApp > Importieren", die während der vCenter Server-Registrierung validiert wird, fehlt im Administratorhandbuch für vSphere Data Protection. (197864)

    Die Berechtigung "vApp > Importieren" ist im Administratorhandbuch für vSphere Data Protection nicht dokumentiert. Die Berechtigung „vApp > Importieren“ wird bei der ersten Bereitstellung benötigt, wenn vCenter Server auf der Konfigurations-Benutzeroberfläche von vSphere Data Protection hinzugefügt oder geändert wird. Die fehlende Berechtigung zeigt sich wie folgt:

    • Die Appliance kann keinen externen Proxy hinzufügen und die folgenden Fehler werden angezeigt: "CIM-Service konnte nicht auf VM-Image-Proxy gefunden werden" und "Es konnte kein neuer VM-Image-Proxy installiert werden."
    • In der vCenter Server-Bestandsliste wird keine neue Proxy-VM erstellt.
    • Die Appliance kann keine OVF-Datei aus dem VMware Web Client bereitstellen, solange die Anmeldung als Benutzer, der zum Registrieren von vCenter Server mit der vSphere Data Protection-Appliance verwendet wurde, aktiv ist.

    Problemumgehung:

    Bearbeiten Sie die Rolle, die zur Verwendung mit der vSphere Data Protection-Appliance angepasst wurde, und fügen Sie die Berechtigung „vApp > Importieren“ mithilfe der Informationen im folgenden VMware-Link hinzu:

    http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.hostclient.doc/GUID-6465FB18-7A57-40DB-B160-636DC2324A04.html

    Beim Bearbeiten einer Rolle können Sie die für diese Rolle ausgewählten Berechtigungen ändern. Anschließend werden diese Berechtigungen auf alle Benutzer oder Gruppen angewendet, die der bearbeiteten Rolle zugeordnet sind.

Dokumentationsprobleme

  • Die folgenden brandaktuellen Aktualisierungen wurden im Administratorhandbuch für vSphere Data Protection 5.8 vorgenommen. Beachten Sie bitte die folgenden Textkorrekturen: (198175)

    • Die folgende Einschränkung ist auf Seite 20 des Administratorhandbuchs für vSphere Data Protection dokumentiert:

      Die Sicherung von VMs, die größer als 2 TB sind, wird auf Windows-Betriebssystemen nicht unterstützt. Diese Einschränkung gilt nicht für Linux-Betriebssysteme.

      Diese Einschränkung existiert nicht mehr.

    • Die folgenden Versionen von Avamar wurden der Tabelle 15.4, Replizierungsquellenmatrix, auf Seite 130 des Administratorhandbuchs für vSphere Data Protection hinzugefügt:

      Mit diesem Produkt erstellte Sicherungen... können in diese Ziele repliziert werden ...
      Avamar SP2 (6.1.2.47) Avamar 7.0.0.427 Avamar SP1 7.0.1.56
      vSphere Data Protection 5.1.x I I I
      vSphere Data Protection 5.5.1.x Y Y Y
      vSphere Data Protection 5.5.5.x Y J (nicht empfohlen) Y
      vSphere Data Protection Advanced 5.5.5.x Y J (nicht empfohlen) Y
      vSphere Data Protection Advanced 5.5.5.x + DD Y J (nicht empfohlen) J (nicht empfohlen)
      vSphere Data Protection 5.5.6.x Y J (nicht empfohlen) Y
      vSphere Data Protection Advanced 5.5.6.x Y J (nicht empfohlen) J (nicht empfohlen)
      vSphere Data Protection Advanced 5.5.6.x + DD J (nicht empfohlen) J (nicht empfohlen) J (nicht empfohlen)
      vSphere Data Protection 5.8.x Y Y Y
      vSphere Data Protection Advanced 5.8.x Y Y Y
      vSphere Data Protection Advanced 5.8.x + DD J (nicht empfohlen) J (nicht empfohlen) Y
      RTI 5.8.x Y Y Y
      RTI 5.8.x + DD J (nicht empfohlen) J (nicht empfohlen) J (nicht empfohlen)

  • VMware Proxy-Appliances sind anfällig für Man-in-the-Middle-Angriffe. (222547)

  • 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 "(Optional) Konfigurieren der Proxy-Zertifikat-Authentifizierung" auf Seite 6970 im Administratorhandbuch für vSphere Data Protection 5.8 aktualisiert werden. Im Folgenden finden Sie eine Übersicht über den aktualisierten Text:

    • Ein zusätzlicher Schritt nach dem Schritt 3 auf Seite 69 zur Ausführung des folgenden Befehls: openssl x509 -in vcenter-1.crt -fingerprint | grep Finger.
    • Änderung an Schritt 5 durch Hinzufügen des folgenden Befehls: --ssl_server_cert_thumbprint="thumbprint"
    • Ersetzen von "vcenter-1.crt" durch "rui-ca-cert.pem" in den Schritten 5 und 9.
    • Zusätzliche Schritte 11, 12 und 13 zum Bearbeiten von "/etc/vmware/config".

    Die folgende Vorgehensweise beinhaltet alle erforderlichen Änderungen. Verwenden Sie diese Vorgehensweise anstelle der Vorgehensweise auf den Seiten 69-70:

    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 einen Linux vCenter Server:

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

        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 Server 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 Server-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 Server-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
       
  • Installieren von SSL-Zertifikaten über vCenter Server Appliance. (225859)

    Gehen Sie wie folgt vor, um das Standard-SSL-Zertifikat zu installieren, das in vCenter Server Appliance für die vSphere Data Protection-Appliance verwendet wird.

    Zunächst müssen Sie eine einzelne PEM-Datei erstellen, die das vCenter Server Appliance-Zertifikat und das vCenter Server Appliance-CA-Zertifikat enthält.

    1. Melden Sie sich mithilfe von SSH oder Putty bei der vCenter Server Appliance als Root-Benutzer an:

      ssh root@vcsa

    2. Navigieren Sie zum Verzeichnis "/etc/vmware-vpx/ssl":

      cd /etc/vmware-vpx/ssl

    3. Verketten Sie das standardmäßige vCenter Server Appliance-Zertifikat (rui.crt) und das vCenter Server Appliance-CA-Zertifikat (rui-ca-cert.pem) zu einer einzigen Datei mit dem Namen "chain.pem":

      cat rui.crt rui-ca-cert.pem > /tmp/chain.pem

    4. Kopieren Sie die Datei chain.pem file in die vSphere Data Protection-Appliance und speichern Sie sie im Verzeichnis /usr/local/avamarclient/bin:

      scp /tmp/chain.pem root@ :/usr/local/avamarclient/bin

    5. Für die nächsten Schritte müssen Sie sich mithilfe von SSH oder Putty bei der vSphere Data Protection-Appliance anmelden und zum Root-Benutzer wechseln:

      ssh admin@VDP
      su - root

      Geben Sie für beide Konten die entsprechenden Anmeldedaten ein.

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

      chmod 600 /usr/local/avamarclient/bin/chain.pem

    7. Navigieren Sie zum Verzeichnis "/usr/local/avamarclient/var":

      cd /usr/local/avamarclient/var

    8. Bestimmen Sie den Fingerabdruck des SSL-Zertifikats, bevor Sie die nächste Datei bearbeiten:

      openssl x509 -in /usr/local/avamarclient/bin/chain.pem -fingerprint noout

      Die Ausgabe sollte so oder ähnlich aussehen:

      SHA1Fingerprint=76:D9:44:E0:5C:6B:32:A1:B3:B8:81:15:93:37:07:5A:8D:A4:AD:EE

    9. Öffnen Sie "avvcbimageAll.cmd" in einem UNIX-Texteditor:

      vi avvcbimageAll.cmd

    10. Fügen Sie den folgenden Eintrag am Ende der Datei hinzu:

      --ssl_server_authentication_file=/usr/local/avamarclient/bin/chain.pem

    11. Fügen Sie den folgenden Eintrag am Ende der Datei hinzu, um den SSL-Fingerabdruck in der Datei anzuhängen:

      --ssl_server_cert_thumbprint="thumbprint"

      Dabei ist thumbprint der SHA1-Fingerabdruckwert aus Schritt 8.

      Der Eintrag sollte so oder ähnlich aussehen:

      ssl_server_cert_thumbprint="76:D9:44:E0:5C:6B:32:A1:B3:B8:81:15:93:37:07:5A:8D:A4:AD:EE"

    12. Schließen Sie die Datei "/usr/local/avamarclient/var/avvcbimageAll.cmd" und speichern Sie Ihre Änderungen.
       
    13. Öffnen Sie die Datei "/usr/local/avamarclient/var/avvmwfileAll.cmd" in einem UNIX-Texteditor:

      vi avvmwfileAll.cmd

    14. Fügen Sie den folgenden Eintrag am Ende der Datei hinzu:

      --ssl_server_authentication_file=/usr/local/avamarclient/bin/chain.pem

    15. Schließen Sie die Datei "/usr/local/avamarclient/var/avvmwfileAll.cmd" und speichern Sie Ihre Änderung.
       
    16. Öffnen Sie "/etc/vmware/config" in einem UNIX-Texteditor.

      vi /etc/vmware/config

    17. Fügen Sie die folgenden Zeilen am Ende der Datei hinzu:

      vix.enableSslCertificateCheck = "true"
      vix.sslCertificateFile = "/usr/local/avamarclient/bin/chain.pem"

    18. Schließen Sie "/etc/vmware/config" und speichern Sie Ihre Änderungen.
       
    19. Öffnen Sie die Datei "/usr/local/avamarclient/var/vddkconfig.ini" in einem UNIX-Texteditor:

      vi vddkconfig.ini

    20. Suchen Sie nach dem Eintrag "vixDiskLib.linuxSSL.verifyCertificates=0".
       
    21. Ändern Sie den Eintrag "vixDiskLib.linuxSSL.verifyCertificates=0" in "1".

      Der geänderte Wert sollte wie folgt aussehen: vixDiskLib.linuxSSL.verifyCertificates=1

    22. Schließen Sie die Datei "/usr/local/avamarclient/var/vddkconfig.ini" und speichern Sie Ihre Änderungen.
       
    23. Stellen Sie sicher, dass auf dem System keine Sicherungs- oder Wiederherstellungsaufträge ausgeführt werden: 

      mccli activity show --active

    24. Falls Aufträge ausgeführt werden, starten Sie die Dienste "avagent" und "vmwareflr" neu, indem Sie die folgenden Befehle eingeben:

      service avagent-vmware restart
      service vmwareflr restart

Interoperabilitätsprobleme

  • In einer Virtual SAN-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. (58839)

    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.
     

  • Fehler beim Importieren von vSphere Data Protection-Festplatten, die im Virtual SAN-Datenspeicher gespeichert sind. (60306)

    In einer Virtual SAN-Umgebung erstellt VMware zwei Ordner im Virtual SAN-Datenspeicher für jede VM. Einer ist nach dem Namen der virtuellen Maschine und der andere nach der UUID der virtuellen Maschine benannt. Alle VM-Dateien werden im UUID-Ordner gespeichert. Im Ordner mit dem Namen der VM zeigen symbolische Links auf die Dateien im UUID-Ordner. Wenn Sie versuchen, über die symbolischen Links im Ordner mit dem Namen der VM vSphere Data Protection-Festplatten aus einer alten Appliance zu importieren, tritt ein Fehler auf.

    Problemumgehung:

    Verwenden Sie Storage vMotion, um die Festplatten aus dem Virtual SAN-Datenspeicher in einem gewöhnlichen Datenspeicher zu speichern.

Installationsprobleme

  • Wenn Sie während der Installation von vSphere Data Protection auf der vCenter Server-Registrierungsseite auf Zurück klicken, ohne Werte einzugeben, wird das System nicht beim vCenter Server registriert und die Installation schlägt fehl. (52385)

    Problemumgehung:

    Installieren Sie vSphere Data Protection anhand der Anleitungen aus dem Kapitel „Installation und Konfiguration von VDP“ im Administratorhandbuch für vSphere Data Protection neu.

Upgrade-Probleme

  • Fehler beim Upgrade der vSphere Data Protection-Appliance von 5.5.10 oder 5.8.2 auf 5.8.3. (244133)

    Das Upgrade der vSphere Data Protection-Appliance aus 5.5.10 oder 5.8.2 auf 5.8.3 schlägt fehl, da die RPM-Installation des vSphere Data Protection-Proxys aufgrund einer Zeitüberschreitung fehlgeschlagen ist.

    Problemumgehung:

    Aktualisieren Sie vor dem Upgrade der vSphere Data Protection-Appliance den vSphere Data Protection-Appliance-Kernel.

    Führen Sie die folgenden Schritte aus, um ein Upgrade des vSphere Data Protection-Appliance-Kernels durchzuführen:

    1. Kopieren Sie aus dem Installationspaket für vSphere Data Protection 5.8.3 in der vSphere Data Protection-Appliance, die Sie aktualisieren möchten, die Datei VDP_KernelUpgrade.tar.gz in ein beliebiges Verhältnis, beispielsweise /root in derselben vSphere Data Protection-Appliance.
    2. Extrahieren Sie die Datei VDP_KernelUpgrade.tar.gz, indem Sie den folgenden Befehl ausführen:

      tar -zxvf VDP_KernelUpgrade.tar.gz

    3. Gewähren Sie der Datei VDPHotfix_KernelUpgrade.sh die Ausführungsberechtigung, indem Sie den folgenden Befehl ausführen:

      chmod a+x VDPHotfix_KernelUpgrade.sh

    4. Führen Sie die Datei VDPHotfix_KernelUpgrade.sh aus:

      ./VDPHotfix_KernelUpgrade.sh

      Die vSphere Data Protection-Appliance wird neu gestartet.

      Für den Kernel wird ein Upgrade auf 2.6.32.59-0.19.1.8590.0.PTF-default #1 SMP 2015-05-28 13:06:16 +0200 x86_64 x86_64 x86_64 durchgeführt.

    5. Aktualisieren Sie die vSphere Data Protection-Appliance unter Verwendung des vSphere Data Protection 5.8.3.13-ISO-Images.

VMDK-Probleme

  • Inkorrektes Verhalten der vSphere Data Protection Advanced-Appliance, wenn mehrere Festplatten zu denselben SCSI-Slots hinzugefügt werden. (59774)

    Die vSphere Data Protection Advanced-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 Sie informiert werden, dass nur die erste einzelne Festplatte hinzugefügt wurde und die zweite Festplatte einfach die erste Festplatte ersetzt hat.
     

  • Beim Wiederherstellen einzelner VMDKs auf mehreren virtuellen Maschinen werden die VMDKs nur für eine der virtuellen Maschinen wiederhergestellt. (194209)

    Beim Wiederherstellen einzelner VMDKs auf mehreren VMs wird der Vorgang nur für eine VM durchgeführt. Die Wiederherstellung für die anderen VMs wird nicht initiiert. Dieses Problem tritt nicht auf, wenn die VMDK am ursprünglichen Speicherort wiederhergestellt wird.

    Problemumgehung:

    Versuchen Sie nicht, einzelne VMDKs auf mehreren virtuellen Maschinen wiederherzustellen. Stellen Sie jeweils eine VMDK auf einer einzelnen virtuellen Maschine wieder her.

Probleme bei vSphere Data Protection

  • Wenn eine Thin-bereitgestellter vSphere Data Protection-Appliance die Datenspeicherkapazität erreicht, treten selbst nach dem Freigeben von Datenspeicher und Erstellen von mehr Speicherplatz Integritätsprüffehler für die vSphere Data Protection-Appliance auf. (41005)
     
  • Die Verbindung der vSphere Data Protection-Appliance wird unterbrochen und in vielen Fällen tritt ein unerwarteter Fehler auf. (49566)

    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 wird häufiger im Fall von vCenter Server 5.5.x (einschließlich Version 5.5u1b) angezeigt.

    Problemumgehung:

    Schließen Sie die Fehlermeldung und führen Sie die Aufgabe aus. Wenn der Fehler weiterhin auftritt, wenden Sie sich an den technischen Support.
     

  • Während der Erstkonfiguration werden keine vCenter Server-Ereignisse erzeugt, wenn der Benutzer den vSphere Data Protection-Hostnamen oder die IP-Adresse ändert. (52677)

    Problemumgehung:

    Überwachen Sie die Neukonfigurationsereignisse auf der Konsole der vSphere Data Protection-Appliance.
     

  • Anmeldung beim Konfigurationsdienstprogramm für vSphere Data Protection nach dem ersten Neustart nicht möglich. (56351)

    Es gibt periodische Instanzen, bei denen Sie sich nicht bei dem vSphere Data Protection-Konfigurationsdienstprogramm nach dem Bereitstellungs-Neustart-Zyklus anmelden können. 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 vSphere Data Protection-Appliance an und verwenden Sie die folgenden Befehle, um die Dienste des vSphere Data Protection-Konfigurationsdienstprogramms manuell zu starten und zu stoppen:

    emwebapp.sh --restart
     

  • Die vSphere Data Protection-Appliance stürzt ab und wird ausgeschaltet, wenn eine Thin-bereitgestellte virtuelle Maschine auf einem Datenspeicher mit unzureichendem Speicherplatz wiederhergestellt wird. (56386)

    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.
     

  • Importieren der Festplatte: Der Erstkonfigurationsassistent weist standardmäßig stets 4 vCPUs und 4 GB RAM zu. (56534)

    Unabhängig von der importierten Kapazität, die für vSphere Data Protection Advanced 2 TB, 4 TB, 6 TB oder 8 TB betragen kann, weist der Assistent standardmäßig stets nur 4 vCPUs und 4 GB RAM zu. Der Importvorgang wird erfolgreich abgeschlossen und die vSphere Data Protection Advanced-Appliance wird ausgeführt, was später Probleme in Form einer unzureichenden Ausstattung mit Arbeitsspeicher verursachen kann. Der Erstkonfigurationsassistent sollte die Mindestarbeitsspeichergröße basierend auf der importierten Kapazität als Standard festlegen, was beispielsweise bei einer Neuinstallation von vSphere Data Protection Advanced der Fall ist.

    Passen Sie die Größe des zugewiesenen Arbeitsspeichers basierend auf den unten angegebenen Informationen an. Die Mindestarbeitsspeichergröße pro VM richtet sich nach der Kapazität.

    • 2 TB Kapazität – 6 GB Arbeitsspeicher
    • 4 TB Kapazität – 8 GB Arbeitsspeicher
    • 6 TB Kapazität – 10 GB Arbeitsspeicher
    • 8 TB Kapazität – 12 GB Arbeitsspeicher
       
  • Die Vorgänge "Sicherungen", "Am ursprünglichen Speicherort wiederherstellen" und "An neuem Speicherort wiederherstellen" funktionieren auf Datenspeichern mit chinesischen Namen wie erwartet. Wenn sich jedoch eine Ziel-VM als neue Festplatte auf diesem Datenspeicher befindet, schlägt der Vorgang "An neuem Speicherort wiederherstellen" auf Datenspeichern mit chinesischen Namen fehl. (56877)

    Dies ist ein bekanntes Image-Proxy-Problem und wird in einer künftigen Version behoben.
     

  • Die Änderung eines Kennworts auf einem konfigurierten vCenter Server ist auf der vSphere Data Protection-Appliance nicht zulässig, auch wenn das vCenter Server-Kennwort abgelaufen ist. (59497)

    Das vSphere Data Protection-Konfigurationsdienstprogramm lässt keine Änderung des Kennworts für die konfigurierte vCenter Server-Instanz zu, wenn sich Sicherungen im ausgeführten Zustand auf dem Server befinden. Wenn das Benutzerkennwort auf der konfigurierten vCenter Server-Instanz 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 vSphere Data Protection-Appliance abgeschlossen sind, und ändern Sie dann das Kennwort.
       
    2. Starten Sie die vSphere Data Protection-Appliance im Wartungsfenster neu und melden Sie sich dann beim vSphere Data Protection-Konfigurationsdienstprogramm an und ändern Sie das vCenter Server-Kennwort.
       

  • Das PAT-Ergebnis (Performance Assessment Test) ändert sich in "Niemals ausgeführt", wenn der Datenspeichername geändert wird. (59784)

    In diesem Szenario öffnen Sie das vSphere Data Protection-Konfigurationsdienstprogramm, klicken Sie auf die Registerkarte Speicher und wählen Sie einen Datenspeicher und anschließend Leistungsanalyse für Speicherkonfiguration ausführen aus. Der Leistungsanalysetest wird erfolgreich abgeschlossen, und die Ergebnisse der Leistungsanalyse werden korrekt angezeigt. Wenn Sie den Namen des Datenspeichers ändern, wird in den Leistungsanalyseergebnissen fälschlicherweise angegeben, dass der Status „Niemals ausgeführt“ lautet.
     

  • Die Verbindung der vSphere Data Protection-Appliance wird beim Auswählen irgendeiner Option im vSphere Web Client automatisch unterbrochen. (61093)

    Wenn Sie im vSphere Web Client auf die Optionen für Ereignis oder Aufgabe klicken und versuchen, zur vSphere Data Protection-Benutzeroberfläche zurückzukehren, wird die Verbindung unterbrochen. Sie müssen eine manuelle Verbindung zur vSphere Data Protection-Appliance herstellen.
     

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

    Sie können zum Aktualisieren der Daten jederzeit auf die Schaltfläche „Aktualisieren“ klicken. Beim Klicken auf die Schaltfläche „Aktualisieren“ wird die Tabelle mit neuen Zeilen aktualisiert, aber die Filteroptionen werden nicht gelöscht.

    Dieser Fehler tritt nur auf der Registerkarte Berichte auf.

    Problemumgehung (p>Löschen Sie die Filteroptionen manuell.
     

  • Aufgaben für die vSphere Data Protection Advanced-Appliance, deren Zeitlimit überschritten wurde, sollten im Bereich „Kürzlich bearbeitete Aufgaben“ oder in den Fehlerprotokollen aufgelistet werden. (194115)

    Dies ist ein allgemeiner Programmfehler, der alle Zeitüberschreitungsszenarien für verschiedene Arten von Aufgaben abdeckt, einschließlich Replizierung, Sicherung, Verifizierung, Wiederherstellung und Replizierungswiederherstellung, die die vSphere Data Protection Advanced-Appliance durchführt. Die Zeitüberschreitung von Aufgaben kann darauf zurückzuführen sein, dass kein Proxy oder Agent zum Durchführen der vorgegebenen Aufgaben verfügbar ist. Es wird erwartet, dass die Zeitüberschreitung verschiedener Aufgaben, Fehlerprotokolle oder die Fehlerursache im Ansichtsbereich "Kürzlich bearbeitete Aufgaben" oder im Ereignisprotokoll aufgelistet sind. Dies ist aber nicht der Fall.

    Dies sind bekannte Probleme, die in einer künftigen Version behoben werden.
     

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

    Wenn Neu ausführen mit der Aktion Berichte > Aktionen-Neu ausführen ausgelöst wird und die Sicherungsaufgabe nur einen Clientfehler enthält, führt das System die Sicherung aller Clients in der Sicherungsaufgabe aus. Die Sicherung sollte nur für fehlgeschlagene Clients neu ausgeführt werden.

    Problemumgehung:

    Wählen Sie zum Neuausführen der Sicherung nur für fehlgeschlagene Clients Nur veraltete Quelle sichern unter Jetzt sichern zum Ausführen der Sicherung für alle fehlgeschlagenen Clients auf der Registerkarte Sicherung aus.
     

  • Verzögerung bei der Verfügbarkeit der vSphere Data Protection-Appliance im Webclient nach einem Upgrade von 2013 R2 U1. (196727)

    Auf der Startseite von vCenter Server Web Client (im Dropdown-Menü des Plug-Ins) ist die vSphere Data Protection-Appliance erst mit einer Verzögerung von mehr als einer Stunde verfügbar. (Die Appliance wird nach einigen Sekunden für vCenter Server 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 vSphere Data Protection-Appliance zusammen.

Sicherungsprobleme

  • Falls eine große Sicherungsaufgabe (ungefähr 100 VMs) erstellt wird, kann es bis zu zehn Minuten dauern, bis die Sicherungsaufgabe erstellt wird. (39456)

  •  

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

    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.
     

  • Das Laden von Clients dauert sehr lang, wenn eine Sicherungsaufgabe bearbeitet oder geklont wird. (60249)

    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.
     

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

    So ermitteln Sie die Ursache des unbestimmten Fehlers:

    1. Gehen Sie zur Registerkarte Berichte der vSphere Data Protection-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.

  • Die vSphere Data Protection-Sicherung schlägt fehl und der Fehlercode 31037 wird auf der Benutzeroberfläche angezeigt. Der Fehlercode zeigt an, dass die ausgewählten Festplatten für die Sicherung ungültig sind. (Eskalation 24278)

    Problemumgehung:

    1. Stellen Sie die VM aus der Vorlage bereit und benennen Sie sie entsprechend der Konvention Ihrer Site um.
    2. Migrieren Sie unter Verwendung des Migrationsassistenten die bereitgestellte VM in einen anderen Datenspeicher. Der VM-Name und der VMDK-Name werden synchronisiert.
    3. Konfigurieren Sie die Sicherung für die migrierte VM mit dem geänderten Namen oder konfigurieren Sie sie neu.

Wiederherstellungsprobleme

  • Wenn eine virtuelle Maschine während eines Wiederherstellungsvorgangs für vSphere Data Protection gelöscht wird, wird die virtuelle Maschine nicht ordnungsgemäß aus der vSphere Data Protection-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. (35110)

    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. (45699)

    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.
     

  • Bei abgebrochenen Wiederherstellungsvorgängen ist eine Bereinigung erforderlich. (46162)

    Wenn Sie einen Wiederherstellungsvorgang auf einer virtuellen Maschine starten und dann den Wiederherstellungsvorgang vor dem Abschluss abbrechen, wird die neue virtuelle Maschine, die im vCenter Server 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.
     

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

    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.
     

  • Die Wiederherstellung einer VM als Neugerät schlägt fehl, wenn der vorherige Name der umbenannten VM verwendet wird. (53712)

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

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

    Das Durchsuchen einer EXT4-Partition mit einem internen Proxy wird mit FLR nicht unterstützt. Wenn Sie diese Aufgabe ausführen, wird keine Fehlermeldung angezeigt.
     

  • Wiederherstellung schlägt fehl oder wird abgebrochen, wenn der Datenbankname der Verfügbarkeitsgruppe ein Unicode-Zeichen enthält. (193319)

    Der Datenbankname der Verfügbarkeitsgruppe darf keine Unicode-Zeichen (zum Beispiel Apostroph) enthalten. Die Datenbank kann nicht mit der festgelegten Verfügbarkeitsgruppe verbunden werden und der Wiederherstellungsvorgang schlägt fehl oder wird mit einem Fehler aufgrund einer falschen Syntax abgebrochen.

    Umgehung

    1. Problemumgehung: Verwenden Sie im Namen Ihrer SQL-Datenbank keine Unicode-Zeichen.
       
    2. Wenn der Fehler auftritt, entfernen Sie die Datenbank aus der Verfügbarkeitsgruppe und führen Sie eine vollständige Sicherung durch. Stellen Sie sicher, dass alle Daten gesichert sind, und führen Sie dann eine umgeleitete Wiederherstellung vom Client der Verfügbarkeitsgruppe zum SQL-Client aus.
       

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

    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.
     

  • 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'. (197462)

    Wenn bei einer FLR-Operation die folgende Fehlermeldung beim Durchsuchen des Dateisystems angezeigt wird:

    Fehler beim Abrufen der Datenträger: Durchsuchen ist nicht möglich, da Proxys nicht verfügbar sind.

    Melden Sie sich ab und wieder an und versuchen Sie es erneut.

    Wenn der Fehler weiterhin auftritt, wenden Sie sich an den technischen Support.

Replizierungsprobleme

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

    Bei einem Replizierungsauftragsfehler mit abgelaufenen oder geänderten Benutzeranmeldedaten bzw. -kennwortdaten zeigt die vSphere Data Protection Advanced-Appliance keinen entsprechenden Fehler in Bezug auf die Benutzeranmeldedaten an. Stattdessen meldet die Appliance den folgenden Fehler:

    Die folgenden Aufträge konnten nicht initiiert werden: <Name der Replikationsaufgabe>. Auf dem vCenter-Ereignis-Bildschirm werden weitere Informationen angezeigt.

    Ziel "<Zielserver-IP/Hostname>" von Replikationsaufgabe "<Name der Replikationsaufgabe>" ist nicht verfügbar. Auf das Replizierungsziel kann nicht zugegriffen werden, Sie verfügen nicht über die erforderlichen Anmelderechte, für den festgelegten Benutzer ist kein Benutzerkonto vorhanden oder der Benutzername und/oder das Kennwort wurden falsch eingegeben.

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

  • Replizierter Arbeitsauftrag bei der vSphere Data Protection Advanced-Appliance der Quelle wird zeitweise in Warteschlange eingereiht. (187198)

    Beim ersten Auslösen einer Ad-hoc-Replikationsaufgabe in einer vSphere Data Protection Advanced-Appliance mit importierten Festplatten 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. (190490)

    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 Sie Replizierung und Wiederherstellung auf demselben vSphere Data Protection Advanced-Server ausführen, 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 Ihnen die Identifizierung und das Debuggen von Protokollen.
     

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

    Wenn entweder dieselbe virtuelle Maschine oder eine virtuelle Maschine mit demselben Namen aus zwei unterschiedlichen Quellservern unter demselben Mandantenknoten mit demselben Benutzerkonto repliziert wird, wird auf der Clients- und Sicherungenseite im Wiederherstellungsassistenten die virtuelle Maschine aus dem Quellserver 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 können Sie allerdings nicht zwischen den zwei Clients mit demselben Namen und Suffix unterscheiden.
     

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

    Selbst wenn auf einer vSphere Data Protection Advanced-Appliance eine Replikationsaufgabe abgebrochen wird, wird die Ausführung des Auftrags für einige Zeit fortgesetzt, und schließlich schlägt der Auftrag fehl, anstatt dass er abgebrochen wird.

    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.
     

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

    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:

    • Ausgangsserver: vSphere Data Protection Advanced und Ziel-Server: vSphere Data Protection Advanced / Replizierungszielidentität (RTI)
    • Quellserver: RTI und Zielserver: RTI/vSphere Data Protection Advanced
       

  • Replizierungswiederherstellung: Replikationsprotokolle füllen die Root-Partition – es muss ein symbolischer Link zu einer anderen Partition erstellt werden. (195196)

    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).
     

  • Replizierungswiederherstellung: Der Authentifizierungsmechanismus des Wiederherstellungsassistenten beendet den Authentifizierungsprozess nicht ordnungsgemäß. (195235)

    Wenn der Benutzer im Wiederherstellungsassistenten zur Registerkarte Wiederherstellen wechselt und auf Replizierte Sicherungen wiederherstellen klickt, wird das Dialogfeld Ziel angezeigt. Wenn Sie durch Ändern des Werts im Feld Port die Portnummer ändern und dann auf Authentifizierung prüfen klicken, wird eine Informationsmeldung angezeigt, und Sie müssen auf Abbrechen klicken, um den Authentifizierungsvorgang manuell zu beenden.

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

  • Replizierungswiederherstellung: Aktionsprotokolle werden nicht unter dem Protokollbündler der vSphere Data Protection-Quell-Appliance erfasst. (195548)

    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.
     

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

    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.
     

  • Nach einer Prüfpunktwiederherstellung von einem Datendomänensystem kann die vSphere Data Protection-Appliance keine Replizierung ausführen. (197306)

    Problemumgehung:

    Um den Replizierungsvorgang manuell auszuführen, führen Sie die folgenden Schritte über die Befehlszeile auf der vSphere Data Protection Advanced 5.8-Appliance aus:

    1. Geben Sie die folgenden Befehle ein:

      service avagent-replicate stop

      service avagent-replicate unregister 127.0.0.1 /MC_SYSTEM

      root@lava92239:/usr/local/avamar/var/client/#: ls -ltr
      total 192
      lrwxrwxrwx 1 root root    29 Jul 30 10:03 avamar.cmd -> /data01/avamar/var/avamar.cmd
      -rw------- 1 root root    74 Aug 1 14:24 cid.bin
       

    2. Vergleichen Sie CID MCGUI mit MCDB.
       

    3. Geben Sie den folgenden Befehl ein:

      rm -rf cid.bin
       

    4. Wechseln Sie auf der MCGUI zu Clients > MC_System > bearbeiten. Deaktivieren Sie das Kontrollkästchen Aktiviert.
       

    5. Geben Sie die folgenden Befehle ein:

      service avagent-replicate register 127.0.0.1 /MC_SYSTEM

      service avagent-replicate restart - Kontrollkästchen sollte jetzt aktiviert sein.
       

    6. Beachten Sie die Zeit und CID für die Replizierung avagent auf der MCGUI.
       

    7. Der Replizierungsvorgang sollte jetzt für Sicherungen von vSphere Data Protection und des Datendomänensystems funktionieren.

Probleme bei Microsoft Application (MS App)

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

    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.
     

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

    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.
     

  • Veraltete Quellen für eine fehlgeschlagene oder abgebrochene Anwendungsdatenbanksicherung zeigen eine falsche Anzahl an. (56503)

    Der Unterschied zwischen der Anzahl der Quellen und der Anzahl der veralteten Quellen tritt bei Microsoft SQL- und Exchange-Anwendungsdatenbanksicherungen häufiger auf.
     

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

    Der Microsoft Exchange-Client ist noch bei zwei vSphere Data Protection Advanced-Appliances im vCenter Server 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. (191795)

    Beim Upgrade des Microsoft Exchange-Client-Plug-Ins von der vorherigen Version der vSphere Data Protection Advanced-Appliance auf die aktuelle vSphere Data Protection Advanced-Appliance wird der Benutzer der Anmeldung beim Backup-Agent-Dienst auf Lokales System anstatt auf Sicherungsbenutzer zurückgesetzt.

    Aus vSphere Data Protection 5.5.6 bis 5.8 setzt das System die Anmeldedaten auf Anmeldedaten des lokalen Systems zurück, ohne nach einer Erlaubnis zu fragen, wodurch die Sicherungsaufgabe fehlschlägt.

    Problemumgehung:

    Um die Microsoft Exchange-Sicherungsaufgabe zu bearbeiten oder eine neue Microsoft Exchange-Sicherungsaufgabe zu erstellen, müssen Sie den Backup-Agentservice manuell konfigurieren. Geben Sie dazu den Benutzernamen und das Kennwort über das Benutzerkonfigurationsdienstprogramm der Sicherung ein.
     

  • Auf Microsoft Exchange-Clients wird das Zeitlimit überschritten und die Durchsuchfunktion funktioniert nicht. (193074)

    Der Microsoft Exchange-Client kann die Datenbanken im Assistenten für Sicherungsaufgaben nicht durchsuchen, und Sie werden zur Eingabe der Anmeldedaten aufgefordert, obwohl die Dienste bereits unter einem gültigen Benutzerkonto ausgeführt werden. Dies ist ein Problem mit dem MSFT-Zeitlimit.

    Problemumgehung:

    Warten Sie einige Minuten und aktualisieren Sie das System oder starten Sie die vSphere Data Protection-Dienste auf dem Client neu.
     

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

    Wenn eine niedrigere Version eines SQL-Clients auf einer höheren Version einer vSphere Data Protection Advanced-Appliance installiert ist, können Sie den Client im vSphere Web Client nicht anzeigen oder durchsuchen. Clients einer niedrigeren Version werden in der vSphere Data Protection 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.

Probleme bei Automatic Backup Verification (ABV)

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

    Dieser Fehler kann auftreten, wenn Sie den Ziel-Datenspeicher umbenennen oder aus vSphere Data Protection 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. (55795)

    Problemumgehung:

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

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

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

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

    Sie werden nicht auf das Problem hingewiesen, und die Protokolle enthalten keine hilfreichen Informationen.
     

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

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

Probleme bei Granular Level Recovery (GLR)

  • Bei der Durchführung einer Granular Level Recovery (GLR) auf einem Microsoft Exchange-Server sollte das Feld für das Zielpostfach optional sein. (56439)

    Wenn Sie ein einzelnes Postfach wiederherstellen, lautet der Standardwert „Am ursprünglichen Speicherort wiederherstellen“. Auf der Benutzeroberfläche ist ein leerer Wert für dieses Feld unzulässig. Wenn Sie An einem anderen Speicherort wiederherstellen auswählen, wird jedes Postfach dieser Sicherung in einem einzelnen Postfach wiederhergestellt.

    Die Wiederherstellung eines Postfachs an seinem ursprünglichen Speicherort und die Wiederherstellung des ursprünglichen Pfads auf einem anderen Client werden unterstützt und funktionieren wie vorgesehen. Dass die Wiederherstellung mehrerer Postfächer an ihren ursprünglichen Speicherorten nicht möglich ist, ist ein bekanntes Problem.

Probleme bei Data Domain

  • Fehlermeldung beim Hinzufügen eines Datendomänensystems zur vSphere Data Protection-Appliance, wenn die Zeiten nicht synchronisiert sind, muss korrigiert werden. (192821)

    Die folgende Fehlermeldung wird angezeigt, wenn die Uhrzeit des Datendomänensystems und die Uhrzeit der vSphere Data Protection-Appliance nicht synchronisiert sind:

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

Proxy-Probleme

  • Sie sollten beim Ausführen einer Sicherungsaufgabe aufgefordert werden, keinen externen Proxy bereitzustellen. (193143)

    Sie werden 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 Sie versuchen, einen internen Proxy bereitzustellen, wird die gerade ausgeführte Sicherungsaufgabe abgebrochen.
     

  • Während einer vSphere Data Protection- oder externen Proxy-Konfiguration kann die vSphere Data Protection-Appliance mithilfe des sekundären DNS (Domänennamensystem)-Diensts nicht aufgelöst werden. (195132)

    Wenn Sie die primären und sekundären DNS-Dienste konfiguriert haben, werden in der Regel alle Einträge auf der primären und sekundären Seite dupliziert, und wenn das primäre DNS nicht antwortet, geben die Suchbefehle die richtigen Informationen aus dem sekundären DNS zurück.

    Wenn Sie das Produkt installieren und versuchen, das Produkt mithilfe des vSphere Data Protection-Konfigurationsdienstprogramms durch Bereitstellung der primären und sekundären Details zu konfigurieren, schlägt die Suche fehl, weil das primäre DNS nicht erreichbar ist. Es wird erwartet, dass die Appliance die Konfiguration unter Verwendung des sekundären DNS auflöst, was aber nicht geschieht.

    Problemumgehung:

    Geben Sie die sekundären DNS-Daten an, wenn Sie aufgefordert werden, die primären DNS-Daten anzugeben.
     

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

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

    Wenn eine vSphere Data Protection 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.

Behobene Probleme

Die folgende Tabelle enthält die Probleme, die in der vorliegenden Version von vSphere Data Protection behoben wurden:

Fehlernummer Beschreibung

242848

Die folgenden Probleme wurden für diesen Fehler behoben:

  • Poodle (SSL v3 entfernen)

  • Skip-tls-Problem/CVE-2014-6593

  • Entfernen von DHE Key Exchange (Seite für Konfiguration/FLR von vSphere Data Protection wird in den neuesten Versionen von Chrome und Firefox nicht angezeigt.)

  • Java-Sicherheitslücken (Upgrade auf JRE 8u60)

    • Mehrere Oracle Java SE-Sicherheitslücken (April 2014 CPU) (Unix)
    • Kritisch (10.0) 76533 Mehrere Oracle Java SE-Sicherheitslücken (Juli 2014 CPU) (Unix)
    • Kritisch (10.0) 78482 Mehrere Oracle Java SE-Sicherheitslücken (Oktober 2014 CPU) (Unix)
    • Kritisch (10.0) 80907 Mehrere Oracle Java SE-Sicherheitslücken (Januar 2015 CPU) (POODLE) (Unix)
    • Kritisch (10.0) 82821 Mehrere Oracle Java SE-Sicherheitslücken (April 2015 CPU) (FREAK) (Unix)
    • Kritisch (10.0) 84825 Mehrere Oracle Java SE-Sicherheitslücken (Juli 2015 CPU) (Unix)
  • SUSE-Sicherheitslücken

    • Hoch (7.8) 83705 Sicherheits-Update für SUSE SLES11: glibc (SUSE-SU-2015:0551-1)
    • Hoch (7.8) 83708 Sicherheits-Update für SUSE SLES11: kernel (SUSE-SU-2015:0652-1)
    • Hoch (7.8) 85151 Sicherheits-Update für SUSE SLES11: bind (SUSE-SU-2015:1316-1)
  • Aktivieren von TLS 1.2 und Deaktivieren von TLS 1.0 für Zugriff auf externen Port