Infos zu hostbasierter VM-Sicherung

Wenn Sie die Sicherung einer Hyper-V-Cluster-VM ausführen, die auf einem Storage Spaces Direct(S2D)-Cluster ausgeführt wird, zeigt das Aktivitätsprotokoll die folgende falsche Meldung an:
Die VM wird im eigenständigen Modus gesichert.

Während des Backup kann kein einfrierender Snapshot von Windows Server 2019 VM gemacht werden.
Problem
Beim Sichern von Windows 2019 VM sehen Sie möglicherweise eine Fehlermeldung im Aktivitätsprotokoll des Sicherungsjobs, wie unten angegeben.
Es konnte kein Snapshot des virtuellen Rechners gemacht werden. ESX Server/vCenter-Server melden den folgenden Fehler: während des Einfrierens des virtuellen Rechners ist ein Fehler aufgetreten. Details finden Sie im Ereignisprotokoll des virtuellen Rechners.
Hinweis: Wenn die Option Snapshots erstellen, ohne den Gast stillzulegen, wenn der Snapshot einer stillgelegten VM fehlschlägt im Sicherungsplan ausgewählt wurde, ignoriert der Sicherungsjob den Fehler und fährt mit dem Snapshot fort, ohne die VM einzufrieren. Allerdings ist in diesem Fall einer Sicherung bei Absturz die Integrität der gesicherten Daten nicht garantiert.
Lösung
Dieses Problem bezieht sich auf VMware. Für dieses Problem gibt es keine Abhilfe. Weitere Informationen finden Sie unter dem Link VMware KB.

Die Option workingDir geht verloren, nachdem die VM wiederhergestellt wurde und VMDK immer noch an dem unter wokingDir festgelegten Speicherort wiederhergestellt wird.
Problem
Wenn eine VM mit einem anderen als dem standardmäßigen workingDir konfiguriert wird (derselbe Speicherort der VM), geht das konfigurierte workingDir nach der VM-Wiederherstellung verloren. VMDK und VM werden aber immer noch an dem Speicherort abgelegt, der in dem originalen workingDir festgelegt wurde. Dieses Problem tritt nur dann auf, wenn Folgendes gegeben ist:

Die Option „Am ursprünglichen Speicherort wiederherstellen“ wird verwendet.
Vor dem Sichern erstellt der Benutzer einen manuell Snapshot in der VM.

Lösung
Die Option workingDir geht nach der Wiederherstellung der VM verloren.
Arcserve UDP sichert die Konfigurierungsdatei der VMs (.vmx) nicht direkt. Stattdessen werden die Konfigurierungsinformationen für die VMs über vSphere API bezogen. Da die Option workingDir allerdings nicht von vSphere API bezogen wird, kann Arcserve UDP die Informationen zu den WorkingDir Konfigurierungsinformationen nicht sichern. Wenn erforderlich, stellen Sie die Option workingDir manuell ein, nachdem die VM wiederhergestellt wurde.
VMDK wird an dem Speicherort wiederhergestellt, der in workingDir festgelegt wurde
Nachdem der Nutzer manuell einen Snapshot erstellt hat, wird am Speicherort von workingDir ein Delta-VMDK erstellt. Das Delta VMDK wird also zum aktiven Datenträger dieser VMDK. Wenn Arcserve UDP die VM sichert, wird der Speicherort des workingDir im Wiederherstellungspunkt als Teil der VMDK-Informationen aufgezeichnet. Folglich wird die Arcserve UDP bei der Wiederherstellung der VM standardmäßig an diesem Speicherort wiederhergestellt (workingDir). Als Abhilfe können Sie die Option "An einem alternativen Speicherort wiederherstellen" in UDP verwenden und manuell den Speicherort festlegen, an dem VMDK wiederhergestellt wird.

Die Sicherung ohne Agenten in vSphere VM sichert korrupte Daten, wenn VM auf SEsparse Snapshot läuft.
Problem

Während der Sicherung einer VM ohne Agenten, von der ein manueller Snapshot erzeugt wurde, können die gesicherten Daten fehlerhaft sein, wenn auf die virtuelle Festplatte auf der VM Folgendes zutrifft:

Sie befindet sich in einem VMFS-5 Datenspeicher oder NFS- Datenspeichern und hat eine Größe von 2 TB oder mehr
Sie befindet sich in einem VMFS-6 Datenspeicher

Eine solche Situation kann im UDP zu folgenden Problemen führen:

Der Katalogjob schlägt fehl
Die Prüfung des Wiederherstellungspunktes schlägt fehl
Der Assured Recovery Job schlägt fehl
Die wiederhergestellte VM kann nicht hochgefahren werden

Lösung
Dieses bekannte Problem von vSphere wurde bei der vSphere-6.7 U1 behoben Weitere Informationen zur Umgehung dieses Problems unter Nutzung anderer vSphere-Versionen finden Sie in der VMware-KB Artikel.

Die Sicherungssitzung kann nicht geladen werden.
Problem
Die Sicherungssitzung wurde nicht geladen.
Lösung
Das Problem tritt auf, wenn auf VM virtuellen Datenträgern Datenkorruption vorliegt. Um dieses Problem zu umgehen, fahren Sie die VM ordnungsgemäß herunter, schalten die VM danach ein, führen eine Sicherung durch und laden die letzte Sitzung.

Eine Agent-lose Sicherung einer SUSE Linux Enterprise Server 12-VM in Hyper-V schlägt fehl, und das Gastbetriebssystem der VM hängt nach der Sicherung.
Problem
Wenn als Hyper-V-Host Windows 2012 R2 und als VM-Gastbetriebssystem SUSE Linux Enterprise Server (SLES) 12 mit Runlevel 5 (mit grafischer Benutzeroberfläche) verwendet wird, reagiert das Gastbetriebssystem der VM aufgrund einer Einschränkung in Windows nicht mehr.
Lösung
Das gleiche Problem tritt auf, wenn Sie einen VSS-Snapshot mit dem Befehl „diskshadow“ auf dem Hyper-V-Host erstellen. Das Kompatibilitätsproblem besteht bei der Kombination von Windows mit SUSE.
Hinweis: Das Problem liegt nicht an Arcserve UDP .
Führen Sie diese Schritte aus, um das Problem zu überprüfen:

Melden Sie sich am Hyper-V-Server an.
Öffnen Sie die Windows-Befehlszeile als Administrator.
Führen Sie die folgenden Schritte aus:

Geben Sie diskshadow ein, und drücken Sie die Eingabetaste.
Geben Sie add Volume X: ein, und drücken Sie die Eingabetaste.
Hinweis: X: ist das Volume, auf dem sich die virtuellen Datenträgerdateien und die Konfigurationsdatei der VM befinden. Wenn sich die Konfigurationsdatei oder die Datenträgerdateien auf unterschiedlichen Volumes befinden, wiederholen Sie diesen Befehl, um alle Volumes hinzuzufügen.
Geben Sie create ein, und drücken Sie die Eingabetaste.
Geben Sie nach Abschluss die Snapshot-Erstellung end backup ein, und drücken Sie die Eingabetaste.
Geben Sie exit ein, und drücken Sie die Eingabetaste.

Überprüfen Sie, ob das VM-Gastbetriebssystem hängt.
Wenn das VM-Gastbetriebssystem nicht reagiert, überprüfen Sie das Windows-Ereignisprotokoll, die Anwendungs- und Dienstprotokolle, Microsoft, Hyper-V VMMS, Admin. Es gibt keine Möglichkeit, den Fehler zu umgehen, wenn in einem Fehlerprotokoll aufgeführt wird, dass die VM während der Snapshot-Erstellung fehlgeschlagen ist. Wir empfehlen Ihnen, sich an Microsoft zu wenden, um die Fehlerursache zu beheben. Sie können auch versuchen Sie, das Runlevel von SLES 12 von 5 auf 3 (ohne Benutzeroberfläche) zu ändern. Es kann jedoch nicht garantiert werden, dass das Problem hierdurch behoben werden kann.

Beim Pre-Flight Check (PFC) wird die Meldung „Fehler beim Zugriff auf den virtuellen Rechner“ für die VMware-VM ausgegeben.
Problem
Bei VMware-VMs gibt der Pre-Flight Check (PFC) die folgende Warnmeldung in Bezug auf die Konsistenz der Daten aus:
Nicht überprüft, da die Anwendung nicht auf den virtuellen Rechner zugreifen konnte. Stellen Sie sicher, dass die Benutzeranmeldeinformationen korrekt sind und mit Administratorberechtigungen verknüpft sind.
Überprüfen Sie, ob die richtigen Anmeldeinformationen angegeben wurden.
Lösung
Das Problem tritt nur beim PFC in VMware-VMs auf. Andere Funktionen wie die Sicherung sind nicht betroffen. Um dieses Problem zu umgehen, installieren Sie den Arcserve UDP -Agent auf dem Rechner, auf dem die Arcserve UDP -Konsole installiert ist. (Der Agent-Service muss nicht gestartet werden.)

Die Sicherung und Wiederherstellung mithilfe des SAN-Transports schlägt fehl, und es wird wieder ein Nicht-SAN-Transportmodus verwendet, wenn die bereitgestellte Größe des virtuellen Datenträgers der VMs 4 TB oder ein Vielfaches von 4 TB beträgt
Problem
Auch wenn der SAN-Transportmodus möglich ist, verwenden Sicherungs- oder Wiederherstellungsjobs dennoch den Transportmodus „HotAdd“, „NBD“ oder „NBDSSL“.
Lösung
Das Problem wird als ein bekanntes Problem bei VMware geführt.
Nachfolgend sind die von VMware veröffentlichten Patches aufgeführt:

Für ESXi 5.5: Patch-Version ESXi550-201504001 (2112672)
Für ESXi 6.0: Patch-Version ESXi600-201505001 (2116125)

Um das Problem zu umgehen, vermeiden Sie die Verwendung einer bereitgestellten Größe, die ein Vielfaches von 4 TB beträgt. Verwenden Sie zum Beispiel nicht 4 bzw. 8 TB. Verwenden Sie stattdessen 3,9 bzw. 8,1 TB.

Wenn die Stilllegungsmethode für VMware-Snapshots von VMware Tools verwendet wird, wird bei einer agentenlosen Sicherung von VMware-Systemen ein beschädigter Snapshot gesichert.
Problem
Wenn Sie eine VMware-VM mithilfe von VM-Ware-Tools stilllegen, enthält der Snapshot beschädigte Daten. Die Sicherung liest Daten vom Snapshot, sodass auch die gesicherten Daten beschädigt werden. Weitere Informationen zu diesem Problem finden Sie in folgendem VMware-KB-Artikel:
Hinweis: Dieses Problem kann bei allen VMware ESXi-Versionen und auf VMs mit Windows 2008 R2 SP1 und Windows 2012 als Gastbetriebssystem auftreten. Arcserve UDP kann das Datenbeschädigungsproblem nicht erkennen, da VMware keinen Fehler zurückgibt. Das Problem tritt möglicherweise nur dann auf, wenn Sie die Daten wiederherstellen.
Lösung
Führen Sie die folgenden Tasks aus, um dieses Problem zu erkennen und zu beheben:

Prüfung des Wiederherstellungspunktes – Mounten Sie die Volumes vom Wiederherstellungspunkt und überprüfen Sie die Datenkonsistenz, indem Sie am Ende des Sicherungsjobs das Microsoft-Tool CHKDSK ausführen. Die Ausführung des Tools "chkdsk" dauert einige Zeit. Um diese zu umgehen, aktivieren Sie die Option für wöchentliche oder monatliche Sicherungsjobs.
Problematische Writer im Gast-BS der VM deaktivieren – Falls bei der Überprüfung des Wiederherstellungspunkts ein Problem erkannt wird, führen Sie die im Arcserve-KB-Artikel Überprüfen Sie, ob Sie von diesem Fehler betroffen sind beschriebenen Schritte durch. Die von VMware vorgeschlagene Umgehungslösung besteht darin, die VSS-Writer MSSearch Service Writer (ignorieren, wenn nicht installiert) und Shadow Copy Optimization Writer (in der Regel auf allen Windows-VMs vorhanden) auf dem Gastbetriebssystem des virtuellen Rechners zu deaktivieren. Sie können manuell gemäß VMware KB-Artikelvorgehen. Arcserve UDP bietet auch eine einfache Möglichkeit, die problematischen Writer während einer Sicherung zu deaktivieren. Weitere Informationen finden Sie unter link.

Die Stilllegungsmethode für Snapshots „Microsoft-VSS innerhalb der VM“ führt möglicherweise zu einer inkonsistenten Sicherung.
Problem
Wenn Sie die Stilllegungsmethode für Snapshots "Microsoft-VSS innerhalb der VM" verwenden, um eine VMware-VM zu sichern, ist die Sicherung möglicherweise nicht konsistent. Das gilt insbesondere für die Sicherung von VMs mit installierten Anwendungen (wie z. B. Microsoft Exchange).
Lösung
Die Umgehungslösung besteht darin, die Stilllegungsmethode für VMware-Snapshots der VMware-Tools zu nutzen und gleichzeitig die VSS-Writer MSSearch Service Writer und Shadow Copy Optimization Writer im Gast-BS der VM zu deaktivieren, bevor das Problem behoben wird.

Nach der Wiederherstellung einer geclusterten VM im ursprünglichen Hyper-V-Cluster kann der Netzwerkadapter keine Verbindung mit dem virtuellen Schalter herstellen, und im Aktivitätsprotokoll wird die folgende Warnmeldung angezeigt:
Es kann keine Verbindung vom Netzwerkadapter <<Adaptername>> zum virtuellen Switch hergestellt werden.
Problem
Beim Sichern einer VM wird vor dem Erstellen eines Snapshot ein Failover für die geclusterte VM durchgeführt. Aufgrund des Failover ist der in der Sicherungssitzung aufgezeichnete Hyper-V-Host nicht mit der VM-Konfiguration konsistent.
Lösung
Sie können den Netzwerkadapter manuell mit einem virtuellen Schalter auf dem dazugehörigen Hyper-V-Host verbinden oder die Option „An einem alternativen Speicherort wiederherstellen“ verwenden, mit der Sie die Wiederherstellungskonfiguration für die VM festlegen können.

Aufgrund eines bekannten VMware-Problems (wenn der Speicher-DRS aktiviert ist und Storage vMotion verwendet wird, während der Sicherungsjob in Bearbeitung ist) schlägt der Sicherungsjob fehl. Die folgende Meldung wird im Aktivitätsprotokoll angezeigt:
VMDK-Datei kann nicht geöffnet werden.
Problem
VMware zeigt folgende Fehlermeldung an:
Eine Datei wurde nicht gefunden
Lösung
Stellen Sie sicher, dass Sie den Sicherungsjob erneut ausführen, sobald die Speicherübertragung abgeschlossen ist.

Die Wiederherstellung einer VM mit VMDK, die größer als 2 TB ist, schlägt fehl, da die VM keinen Snapshot erstellen konnte.
Problem
Die VM der Sicherungsquelle hat VMDKs, die größer sind als 2 TB, und der ESX/ESX(i)-Server mit einer niedrigeren Version als 5.5 kann nur einen virtuellen Datenträger mit bis zu 2 TB-Größe unterstützen. Während der VM-Wiederherstellung werden jedoch folgende Fehlermeldungen angezeigt:

Im vSphere-Client:
- Create virtual machine snapshot VIRTUALMACHINE File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>'.
- File is larger than the maximum size supported by datastore.
In der Protokolldatei „hostd“ für ESX/ESXi 4.x:
- Snapshot guest failed: The file is too big for the file system.
In der Protokolldatei „hostd“ für ESXi 5.0/5.1:
- Failed to do snapshot op: Error: (21) The file is too big for the datastore.

Lösung
Aufgrund einer VMware-Einschränkung beträgt die größtmögliche Größe, die der VMware ESX/ESX(i)-Server mit einer niedrigeren Version als 5.5 unterstützt, 2 T-16 GB. (Dies entspricht 2032 GB.)
Es wird empfohlen, VMware ESX(i)-Server 5.5 als Ziel zu verwenden, um eine Konvertierung mit einem großen Datenträger auszuführen.
Weitere Informationen finden Sie im VMware-KB-Artikel 1012384.

Die Snapshot-Erstellung schlägt fehl, wenn für eine Windows-VM, die auf einem ESXi-Server ausgeführt wird, mehr als sieben Datenträger an einen einzelnen SCSI (Small Computer System Interface)-Controller angehängt werden.
Problem
Wenn Sie einen Sicherungsjob auf einem virtuellen Rechner ausführen, der einen SCSI-Controller mit mehr als 7 VMDKs enthält, schlägt der Sicherungsjob fehl. Der Job schlägt fehl, weil VMware auf einem bestimmten SCSI-Controller eine bestimmte Höchstanzahl von freien Slots für VMDKs benötigt, um einen Snapshot zu erstellen. Ein SCSI-Controller kann höchsten 15 Slots haben. Wenn ein SCSI-Controller beispielsweise 7 VMDKs hat, wird für jeden VMDK ein Snapshot erstellt. Insgesamt werden 14 Slots mit einem freien Slot verwendet. Wenn ein SCSI-Controller über 8 VMDKs verfügt, schlägt der Sicherungsjob fehl, da der Snapshot aufgrund von nur 15 verfügbaren Slots nicht erstellt werden kann.
- Hinweis: Die manuelle Erstellung eines Snapshot schlägt ebenfalls fehl.
Lösung
Führen Sie für virtuelle Rechner mit mehr als sieben Datenträgern auf einem einzelnen SCSI-Controller folgende Schritte aus:
1. Fahren Sie den virtuellen Rechner herunter.
2. Fügen Sie einen oder mehrere SCSI-Controller durch das Bearbeiten der VM im Web-Client hinzu. Wenn Sie den VI-Client verwenden, können Sie SCSI-Controller nicht direkt hinzufügen. Stattdessen wird ein zusätzlicher Controller erstellt, wenn ein weiterer virtueller Datenträger hinzugefügt wird und nicht vorhandene Nummern von virtuellen Geräteknoten angegeben werden.
3. Verteilen Sie die vorhandenen Datenträger auf mehrere SCSI-Controller.
4. Starten Sie den virtuellen Rechner.
Sie können nun Snapshots für jede VMDK erstellen.
Weitere Details finden Sie unter dem Link.

Eine VMware-VM zeigt möglicherweise durch einen violetten Bildschirm einen Absturz an, wenn ein Arcserve UDP -Job ausgeführt wird.
Problem
Dies ist ein bekanntes VMware-Problem mit Auswirkungen auf virtuelle Rechner, die als Adapter für virtuelle Netzwerke E1000 oder E1000e verwenden.
Lösung
Wechseln Sie zu einem VMXNET3-Adapter. Weitere Informationen finden Sie in Artikel 2059053 der VMware-KB.

Wenn der virtuelle Rechner von Hyper-V bei der Wiederherstellung untergeordnete virtuelle Datenträger hat, werden die Daten auf den untergeordneten virtuellen Datenträgern mit dem entsprechenden übergeordneten Datenträger durch Erstellen eines einzigen Images zusammengefasst. Die Über-/Unterordnungsbeziehung ist nach der VM-Wiederherstellung nicht mehr vorhanden. Infolgedessen geht die Konfiguration unterschiedlicher Datenträger verloren, aber Sie können die Daten des übergeordneten Datenträgers wiederherstellen. In diesem Prozess kommt es zu keinem Datenverlust, da Sie Daten auch nach der VM-Wiederherstellung aus dem einzelnen zusammengeführten Datenträger abrufen können.
Hinweis: Bei einer agentenlosen Sicherung können Sie die differenzierenden Datenträger nach einer erfolgreichen VM-Wiederherstellung manuell konfigurieren.

Importierte VMs schlagen fehl, wenn duplizierte UUIDs von VM-Instanzen vorliegen.
Problem
Wenn eine VM in die Knotenansicht importiert wird, schlägt sie fehl, wenn bereits eine andere VM mit derselben VM-Instanzen-UUID zur Knotenansicht hinzugefügt wurde.

Ein hostbasierter VM-Sicherungsplan wird gespeichert. Der Plan schlägt fehl, wenn der ausgewählte Proxy-Rechner eine Installation von Arcserve D2D r16.5 enthält.
Problem
Wenn ein hostbasierter VM-Sicherungsplan einen Proxy-Rechner enthält, auf dem eine Vorgängerversion von Arcserve D2D (zum Beispiel r16.5) installiert ist, wird die folgende Fehlermeldung angezeigt, wenn der Plan gespeichert wird.
Cannot find dispatch method
Lösung
Dieses Problem tritt auf, da die API der aktuellen Version nicht mit der API der Vorgängerversion von Arcserve D2D kompatibel ist. Als Umgehungslösung können Sie ein manuelles Upgrade von Arcserve D2D auf die aktuelle Version von Arcserve UDP Agent (Windows) durchführen.

Der hostbasierte VM-Sicherungsjob kann für VMs in der Phase Sicherung wird gestartet hängen bleiben.
Problem
Der hostbasierte VM-Sicherungsjob hängt stundenlang und kann nicht fortgesetzt werden.
Lösung
Beenden Sie „afbackend.exe“ für die Prozess-ID im Aktivitätsprotokoll, entfernen Sie, sofern vorhanden, den VM-Snapshot, und übergeben Sie den Sicherungsjob erneut.

Nach der Durchführung eines Wiederherstellungsjobs für eine hostbasierte VM und Sicherung einer Hyper-V-VM befinden sich alle Datenträger auf dem wiederhergestellten virtuellen Rechner mit Ausnahme der Startdatenträger im Offline-Status.
Problem
Das Verhalten des Betriebssystems erstellt den Offline-Status standardmäßig.
Die SAN-Richtlinie wurde in Windows Server 2008 eingeführt, um freigegebene Datenträger zu schützen, auf die über mehrere Server zugegriffen wird. Die standardmäßige SAN-Richtlinie der Quell-VM ist für alle SAN-Datenträger außer dem Startdatenträger „Offline - Freigegeben“. Wenn die Richtlinie auf Offline gesetzt ist, sind die SAN-Datenträger beim Start im Offline-Zustand. Nach der Wiederherstellung wird ein neuer Datenträger für die VM erstellt. Die Datenträgerdatei der VM wird als SAN-Datenträger behandelt und vom Betriebssystem als offline betrachtet. Nachdem der Offline-Datenträger wieder online gestellt wird, bleibt er auch nach Systemneustart im Online-Zustand.
Lösung
Geben Sie als Übergangslösung vor der Sicherung die Einstellung „SAN POLICY=OnlineAll“ des Befehls „DISKPART.exe“ für die Quell-VM an, da die Datenträger für andere Server freigegeben sind und Daten beschädigt werden können. Sie müssen die richtige SAN-Richtlinie verwenden, um die Daten zu schützen.
DISKPART.exe-Befehlszeile
SAN-Richtlinie abfragen:
DISKPART > san
SAN Policy: Offline - Freigegeben
SAN-Richtlinie ändern:
DISKPART > san policy=OnlineAll
DISKPART ändert die SAN-Richtlinie für das aktuelle Betriebssystem erfolgreich.

Der Sicherungsjob für Linux-VM bleibt während der Erstellung des Snapshot hängen.
Problem
Bei der Sicherung bestimmter Linux-basierter VMs (z. B. RedHat oder SUSE), die sich auf vSphere befinden, bleibt der Sicherungsjob in der Phase der Snapshot-Erstellung hängen.
Lösung
Legen Sie auf der Basis des VM den folgenden Registrierungswert im Sicherungs-Proxy-Rechner so fest, dass der nicht stillgelegte Snapshot für die Sicherung aufgenommen wird:

Für einen bestimmten VM:
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine\AFBackupDll\<vm-instance-uuid>]
DisableTakeQuiescenceSnapshot"=dword:00000001
Hinweis: Ersetzen Sie <vm-instance-uuid> durch die tatsächliche VM-Instanz-UUID, die in der URL nach dem Agent-Login zu finden ist.
Für alle VMs, die durch den Proxy-Rechner geschützt werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine\AFBackupDll\]
DisableTakeQuiescenceSnapshot"=dword:00000001

Agentenlose Arcserve UDP -Sicherungen versuchen immer, einen Stilllegungs-Snapshot aufzunehmen. Bestimmte Linux Kernel-Versionen haben jedoch ein bekanntes Problem mit dem vmsync-Treiber, das zu einem Deadlock führt, wenn derselbe Kernel bei der Erstellung eines VMware-Snapshot mit aktivierter Stilllegungsoption verwendet wird. Weitere Informationen finden Sie im relevanten KB-Artikel.

Der „Kopie auf Band“-Job schlägt für den ersten Wiederherstellungspunkt fehl, wenn die VM erkannt und durch Auto-VM-Schutz geschützt wird.
Problem
Führen Sie diese Schritte aus, um das Problem zu überprüfen:

Erstellen Sie einen agentenlosen Sicherungsplan, und fügen Sie ein Containerobjekt in der vSphere Hierarchie (z. B. einen Ressourcenpool) zum Plan hinzu. Legen Sie einen lokalen Ordner oder freigegebenen Ordner als Sicherungsziel fest, und fügen Sie eine „Kopie auf Band“-Aufgabe für den gleichen Plan hinzu.
Sicherungsjobs für diese VMs unter dem Containerobjekt sollten laut Ablaufplan ausgeführt werden, und nach jedem Sicherungsjob wird der „Kopie auf Band“-Job ausgelöst, um die Wiederherstellungspunkte auf Band zu kopieren.
Fügen Sie eine neue VM unter diesem Containerobjekt hinzu, oder verschieben Sie eine vorhandene VM in diesen Container.
Während des nächsten geplanten Ablaufs wird der erste Sicherungsjob für die neu hinzugefügte VM automatisch ausgeführt. Ein „Kopie auf Band“-Job wird jedoch nach dem Abschluss des ersten Sicherungsjobs nicht ausgelöst, sodass der erste Wiederherstellungspunkt nicht kopiert wird. Ein „Kopie auf Band“-Job kann nach dem Abschluss des zweiter Sicherungsjobs erfolgreich ausgelöst werden.

Hinweis: Dieses Problem tritt nur auf, wenn das Sicherungsziel ein lokaler/freigegebener Ordner oder RPS ist.

Arcserve UDP wechselt in den NBD/NBDSSL-Modus anstatt in den SAN -Transportmodus.
Problem
Wenn der Name des ESXi-Datenspeichers das Zeichen @ enthält, wird der SAN-Transportmodus aufgrund einer VMware-Einschränkung nicht verwendet. Arcserve UDP wechselt dann zu NBD/NBDSSL.
Lösung
Um den SAN-Transportmodus verwenden zu können, benennen Sie den ESXi-Datenspeicher um, und entfernen Sie das @-Zeichen.

Die Wiederherstellung auf Dateiebene, BMR, Virtual Standby, Instant VM oder Assured Recovery-Test für ein mit BitLocker verschlüsseltes Volume schlagen möglicherweise fehl.
Problem
Wenn eine agentenlose UDP-Sicherung für die Gast-VM mit einem mit BitLocker verschlüsselten Volume durchgeführt wird, wird dieses Volume als FAT32-Volume im Aktivitätsprotokoll beschrieben und kann keine Wiederherstellung auf Dateiebene, keine BMR, kein Virtual Standby, keine Instant VM oder kein Assured Recovery-Test für das mit BitLocker verschlüsselte Volume durchführen.
Lösung
Sie können das mit BitLocker verschlüsselte Volume durch Recovery der gesamten Gast-VM wiederherstellen.

Die EFI- oder BIOS-Einstellungen in der VM gehen verloren, wenn Sie die VM aus der wiederhergestellten Vorlage bereitstellen.

Problem

Wenn Sie die VM aus der wiederhergestellten Vorlage bereitstellen, geht die benutzerdefinierte EFI- oder BIOS-Firmware verloren.

Lösung

Legen Sie die EFI/BIOS-Firmware-Einstellungen manuell erneut fest.

Wiederhergestellte Linux-VM kann nicht gestartet werden.

Symptom 1:

Nach dem Wiederherstellen einer Generation 2-VM mit Linux-Gastbetriebssystem auf dem Hyper-V-Server kann die VM nicht hochgefahren werden, und es wird eine der folgenden Fehlermeldungen angezeigt:

Start fehlgeschlagen. EFI SCSI Device.

Oder

Kein Betriebssystem geladen. Drücken Sie eine beliebige Taste, um die Startsequenz zu wiederholen...

Oder

Fehler beim Öffnen von \EFI\BOOT\grubx64.efi – Nicht gefunden

Fehler beim Laden von Bild \EFI\BOOT\grubx64.efi – Nicht gefunden

start_image() gab „Nicht gefunden“ zurück

Symptom 2:

Nach der Wiederherstellung einer VM der Generation 2 mit Linux-Gast-BS auf dem Hyper-V Server fehlte der Dateistarteintrag Datei in den wiederhergestellten VM-Einstellungen für die Firmware-Ebene im Hyper-V-Manager.

Lösung

Verwenden Sie als Übergangslösung die Instant VM-Funktion, um die VM wiederherzustellen oder den EFI-Boot-Loader auf dem Gastbetriebssystem der VM manuell festzulegen.

Befolgen Sie diese Schritte:

Hängen Sie das Betriebssystem(BS)-ISO an das CD/DVD-Gerät der VM an, und starten Sie die VM im Sicherungsmodus.
Hinweis: Andere Linux-Distributionen und -Versionen haben möglicherweise eigene Methoden zum Starten im Sicherungsmodus. Weitere Informationen finden Sie in den Dokumenten der entsprechenden Distribution/Version.
(Optional) Melden Sie sich als Root an, wenn Sie dazu aufgefordert werden.
Geben Sie in der Eingabeaufforderung den folgenden Befehl ein:
efibootmgr --create --label <boot loader label> --disk <disk device> --loader <boot loader>
Boot-Loader-Bezeichnung – bezieht sich auf eine beliebige Zeichenfolge, wie CentOS
Festplattengerät – bezieht sich auf die Festplatte mit EFI System Partition (ESP), wie /dev/sda
-Bootloader – bezieht sich auf den Pfad und Namen des Boot-Loader gespeichert in EFI System Partition (ESP), wie \EFI\ubuntu\shimx64.efi.
Hinweis: Andere Linux-Distributionen und -Versionen haben möglicherweise andere Pfade und Namen (wie unten beschrieben).

Ubuntu – Verwenden Sie immer \EFI\ubuntu\shimx64.efi
CentOS – Verwenden Sie \EFI\centos\shim.efi, wenn die Version von CentOS 7 oder höher ist. Suchen Sie andernfalls nach einer .efi-Datei in /boot/efi/EFI/centos, und geben Sie sie als Loader-Namen an.
Redhat – Verwenden Sie \EFI\redhat\shim.efi, wenn die Version von Redhat 7 oder höher ist. Suchen Sie andernfalls nach einer .efi-Datei wie \EFI\redhat\grub.efi in /boot/efi/EFI/redhat, und geben Sie sie als Loader-Namen an.
SUSE – Verwenden Sie \EFI\SuSE\shim.efi, wenn die Version von SUSE 7 oder höher ist. Suchen Sie andernfalls nach einer .efi-Datei wie \efi\SuSE\elilo.efi in /boot/efi/EFI/SuSE, und geben Sie sie als Loader-Namen an.

Überprüfen Sie den hinzugefügten Dateistarteintrag in der VM-Einstellung von Hyper-V.
Starten Sie das System neu.

Der Wiederherstellungsjob für die Hyper-V-VM, die zwei Laufwerke mit demselben Namen hat, schlägt fehl.
Problem
Beim Wiederherstellen einer Hyper-V-VM, die zwei Laufwerke mit demselben Namen in demselben Ordner hat, tritt beim Wiederherstellungsjob der folgende Fehler auf:
Fehler beim Erstellen des virtuellen Laufwerks [xxx],Fehler=[Die Datei existiert. (80)]
Lösung
Um das Problem zu umgehen, stellen Sie zwei virtuelle Laufwerke in unterschiedlichen Ordnern wieder her.

Das Window Small Business Server 2011-Gastbetriebssystem wird in der VMware-VM als Client-Version erkannt.
Problem
Wenn die VM über das Windows Small Business Server 2011-Gastbetriebssystem verfügt, zeigt der Pre-Flight Check (PFC) die folgende Warnung an:
VMware bietet keine Unterstützung für das anwendungskonsistente Stilllegen von VMs mit Clientversionen von Microsoft Windows-Betriebssystemen.
Die Eigenschaft guest.guestFullName der VM wird aufgrund eines bekannten Problems in VMware auf Microsoft Windows 7 (64-bit) gesetzt. Daher erkennt Arcserve UDP die VM als Clientversion von Windows.
Lösung
Um dieses Problem zu umgehen, stellen sicher, dass Arcserve UDP die VM-Eigenschaft config.guestFullName verwendet anstatt guest.guestFullName. Um die Änderung in der Arcserve UDP -Konsole und auf den Proxy-Rechnern vorzunehmen, müssen Sie den String-Wert VMwareVMUseConfiguredOS als 1 im folgenden Pfad hinzufügen:
HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine
Hinweis: Nach dem Hinzufügen des String-Werts müssen Sie den Arcserve UDP -Konsolendienst und -Agent-Dienst neu starten.

Nach der Durchführung des Agent-losen Arcserve UDP -Sicherungsjobs reagiert die Hyper-V-VM nur noch langsam.
Problem
Wenn Sie den agentenlosen Arcserve UDP -Sicherungsjob für die Hyper-V-VM durchführen, reagiert das Gastbetriebssystem der Hyper-V-VM nur noch sehr langsam, da der Sicherungsjob nicht für das Betriebssystem ausgeführt wird. Dieses Problem tritt auf, wenn die VM über einen einzelnen großen (einige TB) virtuellen Datenträger (VHD/VHDx) verfügt und die Lese-/Schreibvorgänge häufig innerhalb des Gastbetriebssystems ausgeführt werden.
Lösung
Um das Problem zu umgehen, entladen Sie den Arcserve UDP Hyper-V-CBT-Treiber von dem Volume, in dem die VHD-/VHDx-Datei vorhanden ist.
Um weitere Details oder den Patch für Ihre Arcserve UDP -Umgebung zu erhalten, wenden Sie sich an den Arcserve-Support.

Wenn Sie eine Sicherung für die VM ausführen, die sich auf ESXi 5.1 befindet, schlägt der Sicherungsjob fehl.
Problem
Wenn Sie eine Sicherung für die VM ausführen, die sich auf ESXi 5.1 mit Essential- oder Standard-Lizenz befindet, schlägt der Sicherungsjob fehl, und im Aktivitätsprotokoll wird die folgende Fehlermeldung angezeigt:
Unable to open VMDK file <VMDK file path and name>. VMware reported the following error: The host is not licensed for this feature. For more information, see the debug log <log file name>. Setzen Sie sich im Bedarfsfall mit dem Arcserve-Support in Verbindung.
Lösung

Dieses Problem tritt aufgrund der Änderung des Mechanismus zur Lizenzüberprüfung in VDDK 5.5 auf. Um dieses Problem zu umgehen, müssen Sie VDDK 5.5 durch VDDK 6.0.2 ersetzen.

Befolgen Sie diese Schritte:

Laden Sie das VDDK 6.0.2-Paket von der VMware-Website herunter, und extrahieren Sie die Dateien in einen temporären Ordner.
Melden Sie sich bei dem Agent-losen Sicherungs-Proxy-Rechner an.
Navigieren Sie zum folgenden Pfad:
C:\Programme\Arcserve\Unified Data Protection\Engine\BIN\
Kopieren Sie den VDDK5.5-Ordner zu Sicherungszwecken auf VDDK5.5-org.
Löschen Sie den Ordner „bin“ unter folgendem Pfad:
Files\Arcserve\Unified Data Protection\Engine\BIN\VDDK5.5\BIN\VDDK64
Kopieren Sie den Ordner „bin“ aus dem heruntergeladenen VDDK 6.0.2-Paket an folgenden Speicherort:
C:\Programme\Arcserve\Unified DataProtection\Engine\BIN\VDDK5.5\BIN\VDDK64

Sie haben VDDK 5.5 erfolgreich durch VDDK 6.0.2 ersetzt.

Das Wiederherstellungs-Dialogfeld zeigt einen falschen Namen für das Laufwerks-Volume an.
Problem
Wenn Sie eine Wiederherstellung auf VM- oder Dateiebene von einem Wiederherstellungspunkt einer Hyper-V 2016-VM durchführen, wird der Volume-Name im Wiederherstellungs-Dialogfeld als Volume-GUID statt als Laufwerksbuchstabe angezeigt.
Lösung
Dieses Problem tritt aufgrund eines bekannten Microsoft-Problems auf. Weitere Informationen finden Sie im relevanten KB-Artikel.

Die agentenlose Sicherung schlägt fehl.
Problem
In vSphere v6.7 schlägt die agentenlose Sicherung für eine VM aufgrund der in der VM verfügbaren NVDIMM-Geräte fehl oder schlägt dann fehl, wenn sich die virtuellen Datenträger im PMem-Datenspeicher befinden.
Lösung
Führen Sie als Übergangslösung eine agentenbasierte Sicherung durch, um die VM zu schützen.

Fehler beim Konfigurieren der statischen IP-Adresse für das Gast-OS.
Problem
In Hyper-V 2016 und 2019 schlägt die Konfigurierung der statischen Sicherheitsadresse durch die wiederhergestellte VM nach dem Neustart der VM fehl. Dieses Problem tritt auf, wenn Sie die statische IP-Adresse in dem Gast-OS der VM konfigurieren, eine Sicherung ohne Agenten ausführen und die VM wiederherstellen.
Lösung
Konfigurieren Sie die statische IP-Adresse manuell in der wiederhergestellten VM, um dieses Problem zu umgehen.

Es werden zusätzliche virtuelle Laufwerke gesichert.
Problem
Wenn Sie einen Sicherungsjob für eine agentenlose Proxy-VM ausführen und gleichzeitig mithilfe des HotAdd-Transportmodus den Sicherungsjob für alle agentenlosen VMs ausführen, die der jeweiligen agentenlosen Proxy-VM zugeordnet sind, werden die Sicherungsdaten beider VMs zu den Sicherungsdaten der agentenlosen Proxy-VM hinzugefügt.
Lösung
Zur Umgehung des Problems können Sie eine der folgenden Lösungen verwenden:

Schützen Sie den agentenlosen Sicherungs-Proxy mit einer agentenbasierten Sicherung statt einer agentenlosen Sicherung.
Wenn Sie die agentenlose Sicherung für die Proxy-VM verwenden möchten, konfigurieren Sie in agentenlosen Sicherungsplänen, die die Sicherungs-Proxy-VM verwenden, den NBD/NBDSSL-Transportmodus vor dem HotAdd-Modus.
Wenn der agentenlose Sicherungsjob für die Proxy-VM geplant wird, stellen Sie sicher, dass in diesem Proxy keine weiteren agentenlosen Sicherungsjobs ausgeführt werden.

Die statische IP-Adresse einer Windows-VM, die auf einem Hyper-V unter Windows Server 2016 wiederhergestellt wird, kann nicht wiederhergestellt werden.
Problem

Wenn Sie die Windows-VM auf einem Hyper-V unter Windows Server 2016 wiederherstellen, gehen die statischen IP-Einstellungen auf der wiederhergestellten VM verloren, falls die VM über eine statische IP-Adresse verfügt.

Hinweis: Sie können die MAC-Adresse wiederherstellen. Allerdings können Sie die statische IP-Adresse nur wiederherstellen, wenn der Hyper-V-Server unter Windows Server 2012 oder Windows Server 2012 R2 ausgeführt wird.

Lösung

Nachdem die VM wiederhergestellt wurde, legen Sie die statische IP-Adresse manuell fest.