Versionshinweise zu vSphere Data Protection 6.0.5

|
Versionshinweise zu vSphere Data Protection 6.0.5 | 6. Juni 2017

Diese Versionshinweise decken die folgenden Themen ab:

Vorteile und Funktionen

Das Administratorhandbuch für vSphere Data Protection 6.0 bietet Informationen zu den Vorteilen und Funktionen von vSphere Data Protection.

Unterstützte Umgebungen

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

Hinweis: vSphere Data Protection 6.0.5 unterstützt vCenter Server 6.0 Update 3 und bietet keine Unterstützung für vCenter Server 6.5.x.

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

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

    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 Routing/NAT/Firewall/IDS/TSNR zwischen der vSphere Data Protection-Appliance und vCenter Server (1292848)

    Wenn Sie das Netzwerk für die vSphere Data Protection-Appliance und vCenter Server konfiguriert wird, 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.

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

  • Root-Anmeldung bei vSphere Data Protection 5.8 ist deaktiviert (1309755)

    Die Root-Anmeldung bei vSphere Data Protection 5.8 ist deaktiviert, da dies keine Best Practice ist. Es ist eine Option zum Aktivieren der ssh-Root-Anmeldung erforderlich. Wenn keine Aktivität in der Shell stattfindet, kommt es nach 15 Minuten zu einer Zeitüberschreitung. 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, und führen Sie dann mit dem Befehl "sudo" Root-Funktionen aus.

    Wenn keine Aktivität in der Bash-Shell stattfindet, kommt es nach 15 Minuten zu einer Zeitüberschreitung (im Verzeichnis "/etc/profile"). Sie können den Zeitüberschreitungswert für die Konsole mithilfe des Hardening-Skripts hinzufügen. Beispiel:

    TMOUT = 900

    export TMOUT

  • Das Einschalten einer virtuellen Maschine schlägt fehl, wenn die gesicherte VM mit dem DVS verbunden war und auf einem anderen ESXi-Host wiederhergestellt wurde (222475)

    Wenn eine virtuelle Maschine nach der Wiederherstellung eingeschaltet wird, gibt vCenter Server einen PowerOnFailure-Fehler ähnlich dem folgenden zurück:

    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 auf einem ESXi-Host wieder her, der Teil eines DRS-Clusters (Distributed Resource Scheduler) 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.

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

Upgrade-Probleme

  • Für das Upgrade von vSphere Data Protection-Appliance von 5.5.10, 5.8.2, 6.0.2 oder 6.0.3 auf 6.0.4 ist ein Upgrade des Kernels erforderlich (244133)

    Führen Sie vor dem Upgrade der vSphere Data Protection-Appliance von 5.5.10, 5.8.2, 6.0.2 oder 6.0.3 auf 6.0.4 ein Upgrade des Kernels der vSphere Data Protection-Appliance durch, die Sie aktualisieren möchten. Andernfalls schlägt das Upgrade fehl.

    Problemumgehung:

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

    1. Kopieren Sie aus dem vSphere Data Protection 6.0.4-Installationspaket auf der vSphere Data Protection-Appliance, die Sie aktualisieren möchten, die Datei <vSphereDataProtectionHotfix_KernelUpgrade>. tar.gz in ein beliebiges Verzeichnis, z. B. /root auf derselben vSphere Data Protection-Appliance.
    2. Extrahieren Sie die Datei <vSphereDataProtectionHotfix_KernelUpgrade>. tar.gz Datei durch Ausführen des folgenden Befehls:

      tar -zxvf <vSphereDataProtectionHotfix_KernelUpgrade>.tar.gz

    3. Wechseln Sie in das Verzeichnis <vSphereDataProtectionHotfix_KernelUpgrade>.
    4. Fügen Sie die Berechtigungen zum Ausführen der Datei <vSphereDataProtectionHotfix_KernelUpgrade>.sh durch Ausführen des folgenden Befehls hinzu:

      chmod a+x <vSphereDataProtectionHotfix_KernelUpgrade>.sh

    5. Führen Sie die Datei <vSphereDataProtectionHotfix_KernelUpgrade>.sh aus:

      ./<vSphereDataProtectionHotfix_KernelUpgrade>.sh

      Die vSphere Data Protection-Appliance wird neu gestartet.

      Das Upgrade des Kernels wird durchgeführt.

    6. Führen Sie ein Upgrade der vSphere Data Protection-Appliance mithilfe des ISO-Images von vSphere Data Protection 6.0.4 durch.

VMDK-Probleme

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

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

Probleme bei vSphere Data Protection

  • Die Änderung eines Kennworts auf einer konfigurierten vCenter Server-Instanz 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 die Aufgabenkonsole gepostet; daher können Sie die Aufgaben auch nicht abbrechen.

    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 über das vSphere Data Protection-Konfigurationsdienstprogramm.

  • 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 das vSphere Data Protection-Konfigurationsdienstprogramm, klickt auf die Registerkarte Speicher, wählt einen Datenspeicher aus 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.

  • vSphere Data Protection-Server ist anfällig für Man-in-the-Middle-Angriffe (197873)

    Nach der Aktivierung der SSL-Konfiguration zur Sicherung einer Verbindung zwischen vCenter Server und vSphere Data Protection ist ein Benutzer nicht in der Lage, eine Verbindung über das vSphere Data Protection-Plug-In herzustellen. Dies führt dazu, dass der folgende Fehler in der Datei vdr-server.log angezeigt wird:

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

    Hauptursache

    vCenter Server ist über eine vCenter Server-IP-Adresse für vSphere Data Protection registriert. Es steht kein SAN (Subject Alternative Name) im vCenter Server-Zertifikat zur Verfügung.

    Problemumgehung:

    Verwenden Sie eine der folgenden Problemumgehungen:

    • Generieren Sie das selbstsignierte vCenter Server-Zertifikat neu und fügen Sie den SAN hinzu, der die IP-Adresse enthalten soll.
    • Registrieren Sie vCenter Server mit vSphere Data Protection neu, indem Sie den vollqualifizierten Hostnamen verwenden, der im vCenter Server-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.
  • Auch wenn die ABV-Aufträge (Automatic Backup Verification) erfolgreich ausgeführt werden, zeigt vSphere Data Protection die ABV-Aufträge immer in der Spalte "Abgeschlossen" auf der Registerkarte "Berichte" oder "Sicherungsüberprüfung" als "nie" an (233385)
  • Problemumgehung:

    Starten Sie den Dienst emwebapp.sh neu, indem Sie folgenden Befehl ausführen:

    emwebapp.sh -restart

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 virtuellen Maschine schlägt fehl, wenn der ESXi-Host innerhalb derselben vCenter Server-Bestandsliste von einem Datencenter zu einem anderen verschoben wird (207375)

    Nachdem Sie einen ESXi-Host von einem Datencenter (Datencenter A) zu einem anderen (Datencenter B) verschoben haben, und danach eine manuelle Sicherung eines VM-Clients in Datencenter B durchführen, 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=IP-Adresse_vCenter_Server --domain=/IP-Adresse_vCenter_Server

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

    • 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: 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 beim Gastbetriebssystem

Probleme bei Microsoft-Anwendungen

  • 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 Backup-Agent-Benutzer wird nach dem Upgrade des Microsoft Exchange-Client-Plug-Ins 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.

    Von vSphere Data Protection Version 5.5.6 bis Version 5.8 setzt das System die Anmeldedaten auf lokale Systemanmeldeinformationen zurück, ohne die entsprechende Berechtigung einzuholen, wodurch der Sicherungsauftrag 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.

  • Virtuelle SharePoint-Verzeichnisse werden nicht wiederhergestellt (248324)

    Beim Durchführen einer vollständigen Sicherung einer Webanwendung werden die virtuellen SharePoint-Verzeichnisse nicht gesichert. Wenn Sie also die Quell-Webanwendung und die virtuellen SharePoint-Verzeichnisse löschen und die gesicherte Webanwendung wiederherstellen, werden die virtuellen SharePoint-Verzeichnisse nicht wiederhergestellt. Sie können die Sites, die sich unter der Webanwendung befinden, nicht öffnen.

    Problemumgehung:

    1. Sichern Sie das vollständige Image der virtuelle Maschine.
    2. Um die erforderlichen virtuellen Verzeichnisse wiederherzustellen, führen Sie eine Wiederherstellung auf Dateiebene des gesicherten VM-Images durch.

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 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: 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 der Überprüfungsauftrag schlägt fehl, da die vSphere Data Protection-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

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

Fehlernummer Beschreibung
268134 Replizierungswiederherstellungsaufgabe wird veröffentlicht, wobei der Quellserver unbekannt ist.
265470 Die FLR-Benutzeroberfläche zeigt eine irreführende Fehlermeldung an, die angibt, dass die Benutzeroberfläche keine virtuelle Maschine durchsuchen kann, da die Proxys nicht verfügbar sind.
273171 Die von Kunden gemeldeten Sicherheitslücken wurden behoben.
265938 Die Probleme mit dem manipulierten privaten SSH-Schlüssel und bezüglich der Unsicherheit der gespeicherten vCenter Server-Anmeldedaten, die in vSphere Data Protection 6.1.2 und früheren Versionen anzutreffen waren, wurden behoben.
280874 Das Java-Deserialisierungsproblem wurde behoben.
280697 Das OS-Rollup des 4. Quartals 2016 wurde zu vSphere Data Protection 6.0.5 hinzugefügt, um Sicherheitslücken zu schließen.
282558 Die Java-Version wurde für vSphere Data Protection 6.0.5 aktualisiert.