Versionshinweise zu vSphere Data Protection (VDP) und VDP Advanced 5.8 (Update 1)

|

Versionshinweise zu vSphere Data Protection (VDP) und VDP Advanced 5.8 (Update 1) | 29. Januar 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 5.8

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

Probleme bei VMware

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

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

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

  • 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 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

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

    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 der vCenter Server auf der Konfigurations-Benutzeroberfläche von VDP 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-Bestandsliste wird keine neue virtuelle Proxy-Maschine erstellt.
    • Die Appliance kann keine OVF-Datei vom VMware-Webclient bereitstellen, solange die Anmeldung als Benutzer, der zum Registrieren des vCenter mit der VDP-Appliance verwendet wurde, aktiv ist.

    Problemumgehung:

    Bearbeiten Sie die Rolle, die zur Verwendung mit der VDP-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/index.jsp?topic=%2Fcom.vmware.vsphere.hostclient.doc%2FGUID-6465FB18-7A57-40DB-B160-636DC2324A04.html&resultof=%22%72%6f%6c%65%22%20

    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:
    • 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
      VDP 5.1.x I I I
      VDP 5.5.1.x Y Y Y
      VDP 5.5.5.x Y J (nicht empfohlen) Y
      VDP Advanced 5.5.5.x Y J (nicht empfohlen) Y
      VDP Advanced 5.5.5.x + DD Y J (nicht empfohlen) J (nicht empfohlen)
      VDP 5.5.6.x Y J (nicht empfohlen) Y
      VDP Advanced 5.5.6.x Y J (nicht empfohlen) J (nicht empfohlen)
      VDP Advanced 5.5.6.x + DD J (nicht empfohlen) J (nicht empfohlen) J (nicht empfohlen)
      VDP 5.8.x Y Y Y
      VDP Advanced 5.8.x Y Y Y
      VDP 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.

  • 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 69–70 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 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
     
  • Installieren von SSL-Zertifikaten über VCSA.

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

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

    1. Melden Sie sich mithilfe von SSH oder Putty bei vCenter VCSA 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 VCSA-Zertifikat (rui.crt) und das VCSA 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" in die VDP-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 VDP-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 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.
       

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

      In einer VSAN-Umgebung erstellt VMware zwei Ordner im vsanDatastore 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 ein Benutzer versucht, über die symbolischen Links im Ordner mit dem Namen der VM VDP-Festplatten von einer alten Appliance zu importieren, tritt ein Fehler auf.

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

    Installationsproblem

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

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

    Probleme mit einzelnen VMDKs

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

      Die VDP 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 der Benutzer informiert wird, 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

      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.

    Allgemeine VDP-Appliance-Probleme

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

    • Während der Erstkonfiguration werden keine vCenter-Ereignisse erzeugt, wenn der Benutzer den VDP-Hostnamen oder die IP-Adresse ändert.

      Problemumgehung: Überwachen Sie die Neukonfigurationsereignisse auf der Konsole der VDP-Appliance.
       

    • 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
       

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

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

      Unabhängig von der importierten Kapazität, die für VDP 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 VDP 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 VDP 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.

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

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

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

      Der Benutzer sollte zum Aktualisieren der Daten jederzeit auf die Schaltfläche "Aktualisieren" klicken können. 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: Löschen Sie die Filteroptionen manuell.
       

    • Aufgaben für die VDP Advanced-Appliance, deren Zeitlimit überschritten wurde, sollten im Bereich "Kürzlich bearbeitete Aufgaben" oder in den Fehlerprotokollen aufgelistet werden.

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

      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 aus, um die Sicherung für alle fehlgeschlagenen Clients auf der Registerkarte Sicherung auszuführen.
       

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

    Sicherungsprobleme

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

    •  

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

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

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

    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.
       

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

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

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

    • 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 schlägt fehl oder wird abgebrochen, wenn der Datenbankname der Verfügbarkeitsgruppe ein Unicode-Zeichen enthält.

      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.

      Umgehungen:

      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 einer sekundären Replik 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.
       

    • 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'.

      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.

      Bei einem Replizierungsauftragsfehler mit abgelaufenen oder geänderten Benutzeranmeldedaten bzw. -kennwortdaten zeigt die VDP 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, der Benutzer verfügt 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 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.
       

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

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

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

      Wenn der Benutzer im Wiederherstellungsassistenten zur Registerkarte Wiederherstellen wechselt und auf Replizierte Sicherungen wiederherstellen klickt, wird das Dialogfeld Ziel angezeigt. Wenn der Benutzer durch Ändern des Werts im Feld Port die Portnummer ändert und dann auf Authentifizierung prüfen klickt, wird zur Information eine Nachricht eingeblendet, und der Benutzer muss 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 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.
       

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

    • Nach einer Prüfpunktwiederherstellung von einem Datendomänensystem kann die VDP-Appliance keine Replizierung ausführen.

      Problemumgehung: Um die Replizierung manuell auszuführen, führen Sie die folgenden Schritte von der Befehlszeile auf der VDP 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. Die Replizierung sollte jetzt für VDP und Sicherungen 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.

      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.

      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.

      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.

      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.
       

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

      Der Microsoft Exchange-Client kann die Datenbanken im Assistenten für Sicherungsaufgaben nicht durchsuchen und der Benutzer wird zur Eingabe der Anmeldedaten aufgefordert, obwohl die Dienste schon 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 VDP-Dienste auf dem Client neu.
       

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

    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.
       

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

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

    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.

      Wenn der Benutzer an einem einzelnen Postfach wiederherstellt, lautet der Standardwert "Am ursprünglichen Speicherort wiederherstellen". Auf der Benutzeroberfläche ist ein leerer Wert für dieses Feld unzulässig. Wenn der Benutzer die Option zur Wiederherstellung an einem alternativen Speicherort auswählt, wird jedes Postfach dieser Sicherung an 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.

    Problem mit der Datendomäne

    • 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

    Proxy-Probleme

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

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

      Wenn ein Benutzer die primären und sekundären DNS-Dienste konfiguriert hat, werden in der Regel alle Einträge auf der primären und sekundären Seite dupliziert, und wenn der primäre DNS nicht antwortet, geben die Suchbefehle die richtigen Daten vom sekundären DNS zurück.

      Wenn der VDP-Benutzer das Produkt installiert und versucht, das Produkt mithilfe von VDP-Configure durch Bereitstellung der primären und sekundären Details zu konfigurieren, schlägt die Suche fehl, weil der primäre DNS nicht erreichbar ist. Es wird erwartet, dass die Appliance die Konfiguration mit dem sekundärem 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.

      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.

    Behobene Probleme in vSphere Data Protection 5.8

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

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

      Der VDP Advanced-Server verwendet den ViSDK auf Basis von SOAP, um Sicherungsvorgänge in vCenter Server zu verwalten. Die VDP-Appliance überprüft während der VCSA-Registrierung keine SSL-Zertifikate, die von vCenter präsentiert werden. Deshalb ist der Registrierungsvorgang für Man-in-the-Middle-Angriffe anfällig. Ein Angreifer kann sich die Anmeldedaten für vCenter Server aneignen. Durch den Zugriff auf VC-Benutzerinformationen kann der Angreifer Sicherungs- und Wiederherstellungsvorgänge durchführen, die gewöhnlich Lese- und Schreibzugriff auf die virtuelle Umgebung haben.

      Um die Kommunikation zwischen vCenter und der VDP-Webanwendung und den Verwaltungsdiensten zu sichern, führen Sie folgende Schritte durch:

      1. Laden Sie "vcenter-hostname.crt" vom vCenter Server oder vom Webbrowser auf die VDP-Appliance herunter:
         
        1. Um das Zertifikat über einen Browser herunterzuladen, geben Sie die folgende URL im Browser ein:

          https://vcenter-ip-address

          Dabei ist vcenter-ip-address die IP-Adresse von vCenter Server.
           

        2. Speichern Sie das Zertifikat "vcenter-hostname.crt".
           
      2. Melden Sie sich per SSH an einer VDP-Appliance als Root-Benutzer an.
         
      3. Erstellen Sie ein Verzeichnis in der VDP-Appliance im Root-Verzeichnis oder an einem anderen Speicherort:

        mkdir /root/verzeichnis
         

      4. Kopieren Sie das heruntergeladene Zertifikat „vcenter-hostname.crt“, oder übertragen Sie es per SFTP in das neue Verzeichnis /root/verzeichnis, das Sie in der VDP-Appliance erstellt haben.
         
      5. Importieren Sie das Zertifikat in „rmi_ssl_keystore“:
         
        1. Geben Sie den folgenden Befehl ein:

          /usr/java/latest/bin/keytool -import -file /root/vcentercertificate/vcenter-hostname.crt -alias vcenter-hostname -keystore /usr/local/avamar/lib/rmi_ssl_keystore

          Dabei ist vcenter-hostname der vCenter Server-Hostname.
           

        2. Wenn Sie nach dem Keystore-Kennwort gefragt werden, geben Sie changeme ein.
           
        3. Geben Sie „yes“ ein, um das Zertifikat akzeptieren, und drücken Sie dann die EINGABETASTE.
           
      6. Importieren Sie das Zertifikat in Tomcat /root/.keystore:
         
        1. Geben Sie den folgenden Befehl ein:

          /usr/java/latest/bin/keytool -import -file kava56022.dev.local.crt -alias kava56022 -keystore /root/.keystore
           

        2. Wenn Sie nach dem Keystore-Kennwort gefragt werden, geben Sie changeit ein.
           
        3. Geben Sie yes ein, um das Zertifikat akzeptieren, und drücken Sie dann die EINGABETASTE.
           
      7. Aktualisieren Sie die Verwaltungsdiensteinstellungsdatei:
         
        1. Öffnen Sie die Datei "mcserver.xml" im VI-Editor:

          vi /usr/local/avamar/var/mc/server_data/prefs/mcserver.xml
           

        2. Suchen Sie nach „ignore_vc_cert“ und ändern Sie den Wert in false.
           
        3. Speichern und schließen Sie die Datei.
           
      8. Aktualisieren Sie die vCenter Server-Konfigurationsdatei:
         
        1. Öffnen Sie die Datei "vcenterinfo.cfg" im VI-Editor:

          vi /usr/loca/vdr/etc/vcenterinfo.cfg
           

        2. Fügen Sie der Datei vcenter-ignore-cert=false hinzu.
           
        3. Speichern und schließen Sie die Datei.
           
      9. Starten Sie MCS neu, indem Sie die folgenden Befehle eingeben:

        su admin
        mcserver.sh --restart
        exit
         

      10. Starten Sie den Tomcat-Webanwendungsserver neu, indem Sie den folgenden Befehl eingeben:

        emwebpp.sh -restart