Versionshinweise zu vSphere Data Protection (VDP) 6.0.2

|

vSphere Data Protection (VDP) 6.0.2 | 2. Juli 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 und Einschränkungen

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

Probleme bei VMware

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

    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 (1292848)

    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.

  • Wenn der sichere Modus ausgeführt wird, kann es dazu kommen, dass Benutzer keine Bereinigung von früheren fehlgeschlagenen Sicherungen durchführen können, bei denen Artefakte zurückgeblieben sind (1294581)

    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 (1309755)

    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

Dokumentationsprobleme

  • Der Abschnitt zu SQL Server 2005 im Kapitel "VDP-Anwendungsunterstützung" des vSphere Data Protection-Handbuchs (Versionen 5.8 und 6.0) fordert fälschlicherweise Unterstützung für "x64"

    Der derzeitige Text lautet wie folgt:

    SQL Server 2005 SP3 x64 unter:

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

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

  • Das Einschalten der VM schlägt fehl, wenn die gesicherte VM mit DVS verbunden und auf einem anderen ESX-Host wiederhergestellt wurde (222475)

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

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

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

    Problemumgehung:

     Bearbeiten Sie die VM-Einstellungen, legen Sie die Netzwerkverbindung auf den Netzwerkadapter fest und schalten Sie die virtuelle Maschine ein.

  • VMware Proxys-Appliance sind für Man-in-the-Middle-Angriffe anfällig. (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 von Fehler 222547 muss der Abschnitt „Sichere externe Proxy-Kommunikation mit vCenter“ auf den Seiten 53 bis 54 im Administratorhandbuch für vSphere Data Protection 6.0 aktualisiert werden. Die folgende Vorgehensweise umfasst diese Updates. Verwenden Sie diese Vorgehensweise anstelle der Vorgehensweise auf den Seiten 53-54:

    1. Öffnen Sie eine Befehlsshell und melden Sie sich als Root-Benutzer bei dem Proxy an.
       
    2. Kopieren Sie das vCenter Server-Zertifikat in das Verzeichnis „usr/local/avamarclient/bin“ auf dem Proxy.

      HINWEIS: Wenn ein verkettetes SSL-Zertifikat für vCenter verwendet wird, kopieren Sie die Datei "chain.pem", die alle Zertifikate in der Zertifikatskette enthält, in das Verzeichnis "/usr/local/avamarclient/bin" auf dem Proxy.

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

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

      Dabei ist "rui.crt" der Zertifikatsname.

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

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

      Die Ausgabe sollte so oder ähnlich aussehen:

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

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

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

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

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

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

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

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

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

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

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

      vix.enableSslCertificateCheck = "true"

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

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

      service avagent-vmware restart
      service vmwareflr restart

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

    Problemumgehung:

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

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

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

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

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

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

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

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

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

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

  • Benutzer muss vMotion innerhalb des Sicherungsfensters und vor dem Ausführen einer Wiederherstellung in einem neuen Speicherort deaktivieren. (224181)

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

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

      https://<IP-Adresse_vCenter_Server>:9443/vsphere-client/
       

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

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

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

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

VMDK-Probleme

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

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

Allgemeine VDP-Appliance-Probleme

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

    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 (59784)

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

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

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

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

    Hauptursache:

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

    Problemumgehung:

    Verwenden Sie eine der folgenden Problemumgehungen:

    • Generieren Sie das selbstsignierte vCenter-Zertifikat neu und fügen Sie den alternativen Antragstellernamen hinzu, um die IP-Adresse aufzunehmen.
    • Registrieren Sie vCenter mit VDP mit dem vollqualifizierten Hostnamen neu, der im vCenter-Zertifikat bereitgestellt wurde. Wenn Sie sich für die Neuregistrierung mithilfe eines vollqualifizierten Hostnamens entscheiden, werden alle Sicherungsaufträge und -richtlinien gelöscht. Sie müssen die Sicherungsaufträge und -richtlinien neu erstellen, nachdem Sie Änderungen an der Konfiguration vorgenommen haben. Wiederherstellungsaufträge und Backups sind nicht davon betroffen.
  • Obwohl die Aufgaben von Automatic Backup Verification (ABV) erfolgreich ausgeführt werden, zeigt VDP für die ABV-Aufgaben auf der Registerkarte „Berichte“ oder „Sicherungsüberprüfung“ in der Spalte „Fertigstellung“ stets „nie“ an. (233385)

Problemumgehung:

Starten Sie den Dienst emwebapp.sh neu, indem Sie den Befehl emwebapp.sh -restart ausführen.

Sicherungsprobleme

  • Das Laden von Clients dauert sehr lange, wenn ein Sicherungsauftrag 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.

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

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

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

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

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

Wiederherstellungsprobleme

  • Wenn eine virtuelle Maschine während eines VDP-Wiederherstellungsvorgangs gelöscht wird, wird die virtuelle Maschine nicht ordnungsgemäß aus der VDP-Bestandsliste entfernt. Dies verursacht einen Fehler, wenn die Sicherungsaufträge, die die gelöschte virtuelle Maschine als Quelle enthalten haben, bearbeitet werden. Wenn zusätzlich eine virtuelle Maschine mit demselben Namen erstellt wird, schlagen Versuche, die virtuelle Maschine zu einem Sicherungsauftrag hinzuzufügen, fehl. (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: Sonstiger Fehler" wird für die meisten der FLR-Fehler 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.

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

  • Wiederherstellen auf Dateiebene (FLR): Es wird eine korrekte Fehlermeldung für Fehler beim Laden einer EXT4-Partitionsstruktur mit internem Proxy benötigt (191574)

    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.

  • Die Wiederherstellung von Sicherungen von sekundären Replikaten ist mit einem Protokolllückenfehler fehlgeschlagen oder abgebrochen worden (197652 KLON: 197437)

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

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

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

    Es tritt kein Datenverlust auf.

    Problemumgehung:

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

Replizierungsprobleme

  • Die Replizierung von replizierten 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:

    • Quellserver: VDP Advanced und Zielserver: VDP Advanced / Replizierungsziel-Identität (RTI)
    • Quellserver: RTI und Zielserver: RTI / VDP Advanced
  • Replizierungswiederherstellung: Replizierungsprotokolle belegen die Root-Partition - es muss eine symbolische Verknüpfung 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).

  • Die Replizierung verläuft 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.

Probleme bei Microsoft Application (MS App)

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

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

  • Upgrade 2014: Der Backup-Agent-Benutzer wird nach dem Upgrade des Microsoft Exchange-Client-Plug-Ins auf das lokale System zurückgesetzt (191795)

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

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

    Problemumgehung:

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

Probleme bei Automatic Backup Verification (ABV)

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

    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: Die Initiierung des Überprüfungsauftrags 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.

  • Wenn der Überprüfungsauftrag aufgrund von Verbindungsproblemen fehlschlägt, die von Data Domain verursacht wurden, werden unsachgemäße Fehlermeldungen angezeigt (56619)

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

Behobene Probleme

In der folgenden Tabelle sind die Probleme aufgeführt, die in dieser Version von VDP behoben wurden:

Fehlernummer Beschreibung
229809 Die Browser, die das Vertrauensverhältnis für SHA-1 SSL-Zertifikate für VDP beenden, erfordern eine Aktualisierung.
235851 Update für GNU-C-Bibliothek (GNU C Library, glibc) für VDP 6.0.2