Funktionen | Dokumentation | Knowledgebase | Communitys

Data Recovery | 10. Juni 2010 | Build 260251

Letzte Dokumentaktualisierung: 10. Juni 2010

Überprüfen Sie regelmäßig, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Dieses Dokument enthält die folgenden Abschnitte:

Vorteile und Funktionen

Informationen über die Vorteile und Funktionen dieses Produkts finden Sie unter VMware Data Recovery Overview - VMware. Zusätzliche Informationen zu bekannten und behobenen Problemen finden Sie unter:

Upgrade auf Data Recovery 1.2

Frühere Data Recovery-Installationen verfügen wahrscheinlich über vorhandene Wiederherstellungspunkte, die beibehalten werden sollten. Um sicherzustellen, dass diese Wiederherstellungspunkte beibehalten werden, sollten Sie auf jeden Fall die folgenden, in diesem Abschnitt beschriebenen Prozesse anwenden.

Starten Sie den Upgrade-Prozess, indem Sie das neueste Data Recovery-Plug-In für den vSphere-Client installieren.

So installieren Sie das neueste Data Recovery-Plug-In

  1. Schließen Sie den vSphere-Client.
  2. Verwenden Sie das Dienstprogramm "Software" in der Systemsteuerung zum Deinstallieren vorheriger Versionen des VMware Data Recovery-Plug-Ins.
  3. Starten Sie die neueste Windows Installer-Datei (.msi) für das Data Recovery-Plug-In, um dieses zu installieren.

Danach müssen Sie die neue Data Recovery-Appliance bereitstellen, ohne dass dabei vorhandene Wiederherstellungspunkte gelöscht werden. Wenn das Zielvolume für den Deduplizierungsspeicher eine virtuelle Festplatte ist, löschen Sie die Appliance nicht. Beim Löschen der Appliance werden nämlich auch die mit ihr verbundenen Festplatten gelöscht. Dies würde dazu führen, dass die im Deduplizierungsspeicher abgelegten Sicherungsdaten gelöscht würden. Um dies zu verhindern, gehen Sie wie folgt vor:

So aktualisieren Sie Data Recovery-Appliances mit virtuellen Festplatten oder RDMs

  1. WICHTIG: Stellen Sie vor dem Upgrade auf VMware Data Recovery 1.2 sicher, dass alle Vorgänge in Ihrer aktuellen 1.1-Umgebung abgeschlossen wurden, bevor Sie die Appliance herunterfahren und das Upgrade starten. Wenn eine Integritätsprüfung oder ein Zurückgewinnungsvorgang läuft, warten Sie auf deren bzw. dessen Abschluss. Brechen Sie diese Vorgänge nicht ab.
  2. Wenn keine Vorgänge ausgeführt werden, unmounten Sie die Zielfestplatte und fahren Sie die Data Recovery-Appliance herunter.
  3. Wenn Sie die vorhandene Data Recovery-Appliance sichern möchten, benennen Sie sie um. Beispielsweise können Sie die Appliance VMware Data Recovery in VMware Data Recovery - ALT umbenennen.
  4. Stellen Sie die neue Appliance bereit.
  5. Verschieben Sie mit dem Datenspeicherbrowser die Festplatte, die den Deduplizierungsspeicher enthält, an den Speicherort, an dem sich die neue Appliance befindet.
  6. Bearbeiten Sie die Einstellungen der neuen Appliance:
    1. Wählen Sie Hinzufügen > Festplatte.
    2. Wählen Sie Vorhandene virtuelle Festplatte verwenden.
    3. Wechseln Sie zum Datenspeicher und wählen Sie die virtuelle Festplatte als Ziel aus, die mit der älteren Appliance verbunden ist.
    4. Wählen Sie die SCSI-Adresse aus.
    5. Wählen Sie Beenden.
  7. Schalten Sie die neue Appliance ein.
  8. Bearbeiten Sie die Einstellungen der älteren Appliance:
    1. Wählen Sie die Festplatte aus, die zum Speichern des Deduplizierungsspeichers verwendet wird.
    2. Wählen Sie Entfernen und ändern Sie nicht die Standardoption für "Von der virtuellen Maschine entfernen". Wählen Sie NICHT "Von der virtuellen Maschine entfernen" und löschen Sie keine Dateien von der Festplatte.
    3. Klicken Sie auf OK.
  9. Konfigurieren Sie die Vernetzung der neuen Appliance.
  10. Stellen Sie mit dem Data Recovery vSphere-Plug-In eine Verbindung zur Backup-Appliance her.
  11. Führen Sie die Schritte des Assistenten für erste Schritte aus. Beachten Sie, dass Sie die gewünschte Festplatte mounten müssen, aber nicht formatieren sollen. Durch das Formatieren der Festplatte werden alle Daten des Deduplizierungsspeichers gelöscht. Die zu verwendende Festplatte zeigt möglicherweise nicht den erwarteten Namen an. Der korrekte Name wird dann angezeigt, wenn der Assistent beendet wurde.
  12. Sie werden dazu aufgefordert, die Konfiguration aus dem Deduplizierungsspeicher wiederherzustellen. Wählen Sie Ja, wenn Sie die Aufgaben, die Sicherungsereignisse und den Verlauf wiederherstellen möchten.
  13. Der Client trennt die Verbindung zur Appliance, nachdem die Konfiguration wiederhergestellt wurde, und stellt die Verbindung anschließend wieder her. Dies kann einige Minuten dauern.
  14. Sobald der Client eine erneute Verbindung herstellt, überprüfen Sie, ob eine Integritätsprüfung oder ein Zurückgewinnungsvorgang gestartet wurde. Ist dies der Fall, BEENDEN Sie den Vorgang.
  15. Klicken Sie sofort auf Konfigurieren > Ziele und führen Sie eine Integritätsprüfung für alle gemounteten Ziele durch.
  16. Überprüfen Sie die Konfiguration der Sicherungsaufgabe.
  17. Entfernen Sie die ältere VMware Data Recovery-Appliance aus der Bestandsliste.

Beachten Sie, dass beschädigte Wiederherstellungspunkte dazu führen können, dass das Upgrade fehlschlägt. Wenn Sie die Meldung Die Konfiguration der Data Recovery-Appliance kann nicht wiederhergestellt werden erhalten, fügen Sie das Ziel neu zur ursprünglichen Data Recovery-Appliance hinzu und führen Sie anschließend eine Integritätsprüfung durch, um beschädigte Wiederherstellungspunkte zu beseitigen. Wiederholen Sie nach dem erfolgreichen Abschluss der Integritätsprüfung den Upgrade-Prozess.

Wenn die Zielvolumes für den Deduplizierungsspeicher CIFS-Freigaben oder RDMs sind, gehen Sie wie folgt vor:

So aktualisieren Sie Data Recovery-Appliances mit CIFS-Freigaben

  1. WICHTIG: Stellen Sie vor dem Upgrade auf VMware Data Recovery 1.2 sicher, dass alle Vorgänge in Ihrer aktuellen 1.1-Umgebung abgeschlossen wurden, bevor Sie die Appliance herunterfahren und das Upgrade starten. Wenn eine Integritätsprüfung oder ein Zurückgewinnungsvorgang läuft, warten Sie auf deren bzw. dessen Abschluss. Brechen Sie diese Vorgänge nicht ab.
  2. Wenn keine Vorgänge ausgeführt werden, unmounten Sie die Zielfestplatte und fahren Sie die Data Recovery-Appliance herunter.
  3. Wenn Sie die vorhandene Data Recovery-Appliance sichern möchten, benennen Sie sie um. Beispielsweise können Sie die Appliance VMware Data Recovery in VMware Data Recovery - ALT umbenennen.
  4. Löschen Sie die ältere Data Recovery-Appliance.
  5. Stellen Sie die neue Appliance bereit.
  6. Schalten Sie die neue Appliance ein.
  7. Konfigurieren Sie die Vernetzung der neuen Appliance.
  8. Stellen Sie mit dem Data Recovery vSphere-Plug-In eine Verbindung zur Backup-Appliance her.
  9. Führen Sie die Schritte des Assistenten für erste Schritte aus. Klicken Sie auf der Seite "Sicherungsziel" auf den Link Netzwerkfreigabe hinzufügen und geben Sie die entsprechenden Informationen für Ihre spezifische CIFS-Freigabe ein.
  10. Sie werden dazu aufgefordert, die Konfiguration aus dem Deduplizierungsspeicher wiederherzustellen. Wählen Sie Ja, wenn Sie die Aufgaben, die Sicherungsereignisse und den Verlauf wiederherstellen möchten.
  11. Der Client trennt die Verbindung zur Appliance, nachdem die Konfiguration wiederhergestellt wurde, und stellt die Verbindung anschließend wieder her. Dies kann einige Minuten dauern.
  12. Sobald der Client eine erneute Verbindung herstellt, überprüfen Sie, ob eine Integritätsprüfung oder ein Zurückgewinnungsvorgang gestartet wurde. Ist dies der Fall, BEENDEN Sie den Vorgang.
  13. Klicken Sie sofort auf Konfigurieren > Ziele und führen Sie eine Integritätsprüfung für alle gemounteten Ziele durch.
  14. Überprüfen Sie die Konfiguration der Sicherungsaufgabe.
  15. Entfernen Sie die ältere VMware Data Recovery-Appliance aus der Bestandsliste.

Beachten Sie, dass beschädigte Wiederherstellungspunkte dazu führen können, dass das Upgrade fehlschlägt. Wenn Sie die Meldung Die Konfiguration der Data Recovery-Appliance kann nicht wiederhergestellt werden erhalten, fügen Sie das Ziel neu zur ursprünglichen Data Recovery-Appliance hinzu und führen Sie anschließend eine Integritätsprüfung durch, um beschädigte Wiederherstellungspunkte zu beseitigen. Wiederholen Sie nach dem erfolgreichen Abschluss der Integritätsprüfung den Upgrade-Prozess.

Verbesserungen

Folgende Verbesserungen wurden in dieser Version von Data Recovery implementiert.

  • File Level Restore (FLR) ist nun zur Verwendung mit Linux verfügbar.
  • Jede vCenter Server-Instanz unterstützt bis zu zehn Backup-Appliances von Data Recovery.
  • Das vSphere-Client-Plug-In unterstützt den schnellen Wechsel zwischen Backup-Appliances von Data Recovery.
  • Zu den verschiedenen Verbesserungen der vSphere-Client-Plug-In-Benutzerschnittstelle gehören:
    • Die Möglichkeit, während deren Erstellung Namen für Sicherungsaufgaben zu vergeben.
    • Zusätzliche Informationen zum aktuellen Status der Zielfestplatten einschließlich des Status und dem durch die Optimierungen des Deduplizierungsspeichers eingesparten Anteil an Speicherplatz.
    • Informationen zum Datenspeicher, von dem virtuelle Festplatten gesichert werden.

Behobene Probleme

Die folgenden Probleme wurden seit der letzten Version von Data Recovery behoben. Die nachfolgende Liste der behobenen Probleme gilt nur für diese Version von Data Recovery.

  • Starke DRS- oder vMotion-Aktivitäten auf geschützten virtuellen Maschinen verursachen unnötig hohe CPU-Nutzung

    Wenn eine Backup-Appliance virtuelle Maschinen schützte, die stark von vMotion oder DRS beeinträchtigt wurden, kam es zu einer großen Anzahl von Data Recovery-Objekten im Arbeitsspeicher, was zu einer hohen CPU-Nutzung führte. Dies passierte, weil Data Recovery die Ergebnisse von vMotion- oder DRS-Vorgängen als eine Vermehrung von Objekten interpretierte anstatt als eine Verschiebung von Objekten. Dieses Problem ist nun behoben.

  • Wenn vCenter Server nicht verfügbar ist, verliert Data Recovery dauerhaft die Verbindung

    Wenn vCenter Server neu gestartet wurde oder die Netzwerkverbindung verloren ging, während Data Recovery Sicherungen erstellte, konnte Data Recovery die Verbindung mit vCenter Server erst dann wiederherstellen, wenn alle aktuell ausgeführten Sicherungsaufgaben abgeschlossen wurden. Dadurch schlugen alle neuen Sicherungsvorgänge fehl und das vSphere-Client-Plug-In konnte während dieser Zeit keine Verbindung zur Engine herstellen. Data Recovery versucht nun, in regelmäßigen Intervallen eine neue Verbindung zu vCenter Server herzustellen. Dies findet statt, während Sicherungen ausgeführt werden, wodurch potenzielle Ausfälle minimiert werden.

  • Bei Sicherungen von Data Recovery findet am Anfang der Aufgabe möglicherweise kein Fortschritt statt

    Bei inkrementellen Sicherungen einer virtuellen Maschine findet bei Data Recovery kein Fortschritt statt und für die Backup-Appliance wird 100 % CPU-Nutzung angezeigt. Dieses Problem bleibt so lange bestehen, bis die Appliance neu gestartet wird. Selbst nach einem Neustart der Backup-Appliance wurde kein weiterer Fortschritt bei der inkrementellen Sicherung festgestellt. Die Ursache liegt darin, wie die Backup-Appliance Informationen über die letzte Sicherung verwendete, um eine neue Sicherung zu erstellen.

  • Die Backup-Appliance stürzt ab, wenn bestimmte Festplattenkonfigurationen gesichert werden

    Virtuelle Maschinen können über Festplatten verfügen, die kein Vielfaches ganzer Megabyte sind. Beispielsweise ist es möglich, eine Festplatte zu erstellen, die 100,5 MB groß ist. Normalerweise sind Festplatten, die unter Verwendung von vSphere-Client erstellt wurden, immer ein Vielfaches von einem MB. Einige virtuelle Maschinen, die über Festplatten verfügen, deren Größe kein Vielfaches von einem MB ist, verursachten einen Absturz der Backup-Appliance. Diese Festplattengrößen werden nun korrekt gehandhabt.

  • Data Recovery führt nicht ordnungsgemäß Protokoll über die einzelnen zu sichernden Festplatten

    Data Recovery unterstützt das Sichern eines Teils der Festplatten einer virtuellen Maschine. Aufgrund der Art, wie über einzelne zu sichernde Festplatten Protokoll geführt wird, treten Probleme auf, wenn der Name der Festplatte durch einen Snapshot geändert wurde. In solch einem Fall hat Data Recovery die Festplatte nicht mit der in der Sicherungsaufgabe ausgewählten Festplatte abgestimmt, zeigte die Festplatte als ausgewählt an und hat sie nicht gesichert. Dieses Problem tritt nicht mehr auf.

  • Data Recovery überprüft die Kompatibilität beim Hinzufügen von Festplatten im laufenden Betrieb nicht und führt nach Fehlschlägen keine Bereinigung durch

    Data Recovery versucht, die Festplatten der virtuellen Maschine im laufenden Betrieb hinzuzufügen, die auf die Backup-Appliance gesichert wurden. Es ist möglich, dass die Datenspeicher-Blockgröße des Datenspeichers, der die Client-Festplatten hostet, größer ist als die Datenspeicher-Blockgröße der Appliance. Falls dies der Fall war und falls die Größe der Festplatte der virtuellen Maschine größer war als die von der Appliance unterstützte Größe, schlug das Hinzufügen im laufenden Betrieb fehl. Dieses Problem konnte nach einem erfolgreichen Hinzufügen einiger Festplatten im laufenden Betrieb auftreten. In solch einem Fall hat Data Recovery die erfolgreich zur virtuellen Maschine hinzugefügten Festplatten nicht im laufenden Betrieb entfernt. Data Recovery überprüft nun die Blockgrößen und Festplattengrößen des Datenspeichers, um sicherzustellen, dass Hinzufügevorgänge im laufenden Betrieb erfolgreich abgeschlossen werden, bevor ein erneutes Hinzufügen versucht wird.

  • Data Recovery unterstützt keine längeren CIFS-Kennwörter

    Data Recovery 1.1 hat CIFS-Kennwörter mit mehr als 16 Zeichen nicht unterstützt. In dieser Version unterstützt VDR CIFS-Kennwörter mit bis zu 64 Zeichen Länge.

  • Die Backup-Appliance stürzt ab, wenn die Festplatte voll ist

    In einigen Fällen stürzte Data Recovery ab, wenn bei einer Sicherung die maximale Kapazität der Zielfestplatten erreicht wurde. Dies ist nicht mehr der Fall.

  • Für die letzte Ausführung wird ein falscher Zeitstempel für abgeschlossene Aufgaben angezeigt

    Auf der Registerkarte "Sicherung" werden Informationen zu Sicherungen angezeigt einschließlich der letzten Zeit, zu der eine Sicherungsaufgabe abgeschlossen wurde. Das angezeigte Datum und die angezeigte Uhrzeit, zu der diese Aufgaben zuletzt ausgeführt wurden, waren falsch. Dies wurde behoben.

  • Das vSphere-Client-Plug-In von Data Recovery konnte keine Verbindung zu vCenter Server herstellen

    Versuche des vSphere-Client-Plug-Ins zum Herstellen einer Verbindung mit der Backup-Appliance schlugen fehl, wenn die Bestandsliste von vSphere Server eine große Anzahl an virtuellen Maschinen enthielt. Dieses Problem trat in der Regel auf, wenn die Bestandsliste mehr als 1000 virtuelle Maschinen enthielt. Dieses Problem wurde behoben.

  • Das Hinzufügen virtueller Festplatten verursacht Probleme mit Snapshots und nachfolgenden Sicherungen

    Wenn für eine virtuelle Maschine ein Snapshot vorhanden war und zur virtuellen Maschine eine neue virtuelle Festplatte hinzugefügt wurde, verlief die nächste Sicherung erfolgreich, aber der Snapshot blieb bestehen. Dieser Snapshot verursachte das Fehlschlagen nachfolgender Sicherungen. Dieses Problem wurde behoben.

  • Sicherungen konnten nicht wie erwartet abgeschlossen werden

    In bestimmten Situationen konnten Sicherungen nicht wie erwartet abgeschlossen werden und es wurden keine nachfolgenden Sicherungen ausgeführt. Dieses Problem wurde behoben.

  • Der Wiederherstellungsassistent setzt die Auswahl gültiger Datenspeicher nicht durch

    Unter Verwendung des Wiederherstellungsassistenten war es möglich, für die Wiederherstellung von virtuellen Maschinen ungültige Datenspeicher anzugeben. Beispielsweise, wenn:

    • Ein Datenspeicher wurde umbenannt oder gelöscht. Die alten Informationen wurden beibehalten, sodass ein veralteter Name oder ein nicht existierender Speicher ausgewählt werden konnte.
    • Wenn eine virtuelle Maschine in einem Cluster wiederhergestellt wurde, konnten Datenspeicher, die sich nicht im gemeinsam genutzten Speicher befanden, ausgewählt werden.

    Die Assistenten wurden entsprechend geändert, damit nur gültige Auswahlmöglichkeiten angeboten werden.

  • File Level Restore (FLR) im Admin-Modus behandelt einige Kennwortzeichen falsch

    FLR schlug im Admin-Modus fehl, wenn das Kennwort "/" enthielt. Dies trat auf, weil FLR das Zeichen "/" als Trennzeichen verwendet. Deshalb führte die Verwendung von "/" zu unvollständigen Kennwörtern, die zur Authentifizierung an vCenter Server gesendet wurden. FLR behandelt nun "/" in Kennwörtern ordnungsgemäß.

  • FLR kann aufgrund eines Verbindungstrennzeichens keine virtuellen Festplatten mounten

    In einigen Fällen schlug das Mounten einer virtuellen Festplatte über den FLR-Client aufgrund eines Verbindungstrennzeichens fehl. Dies wurde behoben.

  • Windows FLR kann mehrere Festplatten mit demselben Namen nicht mounten

    Es ist möglich, eine virtuelle Maschine mit mehreren Festplatten mit demselben Namen zu sichern. In solch einem Fall wird jeder Festplatte eine VMDK zugewiesen, die sich auf einem anderen Datenspeicher befindet. Beim Versuch, diese Festplatten anhand des Windows FLR-Clients zu mounten, wurde nur eine der virtuellen Festplatten gemountet. Dies wurde behoben. Nun werden alle Festplatten gemountet.

Bekannte Probleme

Die folgenden bekannten Probleme wurden durch intensives Testen entdeckt. Die nachfolgende Liste der Probleme gilt nur für diese Version von Data Recovery.

  • OVF-Datei für Backup-Appliances zeigt kein Herausgeberzertifikat an

    Die OVF-Datei, die die Backup-Appliance enthält, verfügt über keine Informationen zum Herausgeber der Appliance oder dessen Herausgeberzertifikat. Das Fehlen dieser Informationen ist in den Einzelheiten zur OVF-Vorlage sichtbar, die beim Bereitstellen der Backup-Appliance angezeigt werden.

  • Größe der schnell bereitgestellten Festplatte der Backup-Appliance nicht angegeben

    In den neueren Versionen des OVF-Bereitstellungsassistenten werden zusätzliche Informationen angezeigt, die in früheren Versionen nicht angezeigt wurden. Auf der Seite "Festplattenformat" des Assistenten zum Bereitstellen von OVF-Vorlagen gibt es eine Option zum Speichern der Appliance in einem Format für die schnelle Bereitstellung. Die Größe der schnell bereitgestellten Festplatte im Backup-Appliance-OVF ist für die Backup-Appliance-Vorlage nicht festgelegt, aber dieses Format kann dennoch verwendet werden, ohne dass die Appliance-Funktionalität beeinträchtigt wird.

  • ESX Server mit aktiviertem VMware HA listet Datenspeicher möglicherweise zweimal auf

    Beim Wiederherstellen virtueller Maschinen auf ESX Server mit aktiviertem VMware HA wird im Wiederherstellungsassistenten als Speicherort der Wiederherstellung möglicherweise derselbe Datenspeichername zweimal angezeigt. ESX Server können so konfiguriert werden, dass gemeinsam genutzter Speicher und lokaler Speicher verwendet werden. Es ist möglich, dass mehrere Server denselben gemeinsam genutzten Speicher verwenden, und es ist zudem möglich, dass die Namen lokaler Speicher auf verschiedenen Servern identisch sind. Beispielsweise können mehrere Server auf "SharedStorage1" verweisen und mehrere Server können einen lokalen Speicher mit dem Namen "DataStore1" haben. Dies ist besonders dann problematisch, wenn Benutzer Speicherorte für Festplattendateien und Konfigurationsdateien auswählen, die sich auf separaten Servern befinden, da dies zu einer ungültigen Konfiguration führt. Anhand der Namen der Speicherziele ist die Möglichkeit einer Fehlkonfiguration nicht sofort ersichtlich, aber ein Fehler identifiziert solch ein Problem. Wenn solch ein Fehler auftritt, probieren Sie verschiedene Kombinationen von Speicherzielen aus, bis Sie ein passendes Paar gefunden haben.

  • Importierte Sicherungsaufgaben sichern alle Festplatten

    Es ist möglich, Sicherungsaufgaben zu erstellen, die einen Teil der Festplatten einer virtuellen Quellmaschine sichern. Wenn solch eine Sicherungsaufgabe in Data Recovery 1.2 importiert wird, ändert sich das Verhalten der Sicherungsaufgabe und alle Festplatten werden gesichert. Um dieses Problem zu beheben, ändern Sie die Sicherungsaufgaben und stellen Sie die ursprünglichen Einstellungen wieder her.

  • Auf der Registerkarte "Wiederherstellen" werden die neuesten Wiederherstellungspunkte möglicherweise nicht angezeigt

    Nach Ausführung der Sicherungsaufgaben werden die daraus resultierenden Wiederherstellungspunkte auf der Registerkarte "Wiederherstellen" manchmal nicht aktualisiert. Um dieses Problem zu beheben, trennen Sie die Verbindung zum vSphere-Client-Plug-In von Data Recovery und stellen Sie die Verbindung wieder her, indem Sie auf Trennen und anschließend auf Verbinden klicken. Die Wiederherstellungspunkte sind nun auf der Registerkarte "Wiederherstellen" sichtbar.

  • Das Starten von Sicherungsaufgaben schlägt unbemerkt fehl, wenn vCenter Server nicht verfügbar ist

    Wenn vCenter Server nicht verfügbar ist, wenn die Backup-Appliance startet, werden die Sicherungsaufgaben möglicherweise nicht wie erwartet gestartet und keine Warnungen angezeigt. Sicherungen, die durch Klicken auf Jetzt sichern manuell gestartet wurden, werden wie erwartet abgeschlossen. Starten Sie zum Beheben dieses Problems die Backup-Appliance neu.

  • Kommentare zum Deduplizierungsspeicher werden anfänglich nicht angezeigt

    Informationen zum Deduplizierungsspeicher werden im Kommentarfeld nicht immer angezeigt. Um auf Kommentare zu prüfen, klicken Sie auf das Feld, damit der Feldinhalt aktualisiert wird.

  • Einschränkungen bei Data Recovery in Bezug auf das Wiederherstellen virtueller Maschinen mit RDMs im physischen Kompatibilitätsmodus

    RDMs im physischen Kompatibilitätsmodus können von Data Recovery nicht geschützt werden, aber andere Komponenten der virtuellen Maschine können gesichert und wiederhergestellt werden. Zu diesen gehören die Konfiguration, VMDKs und RDMs im virtuellen Kompatibilitätsmodus. Ein Wiederherstellungsvorgang, der diese unterstützten Komponenten auf der virtuellen Quellmaschine überschreibt, wird erfolgreich abgeschlossen. Allerdings schlägt ein Wiederherstellungsvorgang, der eine neue virtuelle Maschine erstellt oder eine gelöschte virtuelle Maschine ersetzt, dann fehl, wenn die gesicherte virtuelle Maschine eine RDM im physischen Kompatibilitätsmodus enthält. Dies ist selbst dann der Fall, wenn die RDM im physischen Kompatibilitätsmodus nicht in der Sicherungsaufgabe enthalten ist.

  • In der Dokumentation wird fälschlicherweise ausgeführt, dass SUSE unterstützt wird

    Im Administratorhandbuch für VMware Data Recovery wird ausgeführt, dass FLR SUSE Linux Enterprise Server 11.2 unterstützt. SUSE wird in dieser Version nicht unterstützt.

  • FLR kann LVM-Volumes nicht mounten, die sich nicht in einer Volume-Gruppe befinden

    FLR kann Volumes des Logical Volume Manager (LVM) nicht an Wiederherstellungspunkten mounten, wenn diese LVM-Volumes nicht Teil einer Volume-Gruppe sind. Damit FLR LVM-Volumes an einem Wiederherstellungspunkt mounten kann, müssen vor dem Erstellen der Sicherung die LVM-Volumes zu einer vorhandenen Volume-Gruppe hinzugefügt oder zum Erstellen einer neuen Volume-Gruppe verwendet worden sein.

  • Fehlgeschlagene LVM-Mounts von FLR können dazu führen, dass die Redhat LVM GUI Systemfestplatten fälschlicherweise als "nicht initialisiert" anzeigt

    Wenn das Mounten einer LVM-Festplatte durch FLR fehlschlägt, zeigt der LVM-Manager der Redhat GUI möglicherweise Systemfestplatten falsch als "nicht initialisiert" an. Versuchen Sie nicht, dieses Problem zu beheben, indem Sie diese Volumes initialisieren. Beim Initialisieren dieser Volumes werden alle Daten entfernt. Die Volumes sind voll funktionsfähig und können in der virtuellen Maschine wie erwartet verwendet werden. Um das Problem in Redhat zu beheben, starten Sie die virtuelle Maschine neu oder führen Sie den Befehl vgmknodes <Name der Volume-Gruppe>aus.

  • SELinux verhindert die Ausführung von vdrFileRestore

    SELinux verhindert, dass vdrFileRestore die benötigte Bibliothek libvmacore.so.1.0 lädt. Um dieses Problem zu beheben, verwenden Sie eine der folgenden drei Lösungen:

    • Führen Sie den Befehl chcon -t textrel_shlib_t /usr/lib/vmware/vmacore/libvmacore.so.1.0aus
    • Ändern Sie die SELinux-Richtlinie in "permissive"
    • Deaktivieren Sie SELinux
  • Linux FLR benötigt möglicherweise zusätzliche Loop-Geräte

    Linux FLR verwendet ein Loop-Gerät für jede VMDK-Datei in einem Wiederherstellungspunkt und für jedes erkannte physische LVM-Volume. Für die meisten Systeme sind acht Loop-Geräte konfiguriert. FLR kann nicht auf weitere Wiederherstellungspunkte zugreifen, wenn keine freien Loopback-Geräte verfügbar sind, um zusätzliche VMDK-Dateien und physische LVM-Volumes aufzunehmen. Erhöhen Sie die Anzahl verfügbarer Loopback-Geräte, um diese Einschränkung zu beseitigen. Der spezifische Vorgang des Änderns der Anzahl verfügbarer Loopback-Geräte variiert je nach Betriebssystem. Fügen Sie beispielsweise auf einigen Redhat-Systemen die folgende Zeile in die Datei modprobe.confein:

    options loop max_loop=64

    Nach dem Neustart des Systems stehen 64 Loopback-Geräte zur Verfügung.

  • File Level Restore gibt an, dass einige Registrierungsdaten möglicherweise verlorengegangen sind

    Data Recovery kann Wiederherstellungspunkte für falsch konfigurierte virtuelle Maschinen erstellen. File Level Restore kann solche Wiederherstellungspunkte mounten. Dies kann allerdings dazu führen, dass Registrierungsfehlermeldungen angezeigt werden. Der Fehler lautet folgendermaßen: Registrierungsstruktur (Datei): C:\DOCUME~1\ADMINI~1\LOCALS~1|Temps\Administrator\vixmntapi3 war beschädigt und wurde wiederhergestellt. Möglicherweise gingen einige Daten verloren. Diese Fehler können bedenkenlos ignoriert werden.

  • Veraltete Sperren des Deduplizierungsspeichers verhindern FLR-Zugriff

    Wenn FLR keinen Wiederherstellungspunkt mounten kann und die Ausgabe im ausführlichen Modus (-v oder --verbose) zu Fehler 1315 in der Protokollausgabe führt, kann dies an einer veralteten Sperre des Deduplizierungsspeichers liegen. Der Mangel an Informationen darüber, wodurch das Mounten verhindert wird, ist möglicherweise verwirrend. Fehler 1315 kann auch auf anderen Ursachen beruhen, aber er deutet in der Regel auf eine Sperre des Deduplizierungsspeichers hin.

    Warten Sie im Normalfall, bis die Data Recovery-Vorgänge abgeschlossen sind. An deren Ende wird die Sperre des Deduplizierungsspeichers automatisch entfernt. Wenn die Sperre veraltet ist und nicht normal entfernt wird, können Sie sie manuell entfernen. Löschen Sie dazu die folgende Sperrdatei aus dem Deduplizierungsspeicher:

     

    /<dedupe root>/VMwareDataRecovery/BackupStore/store.lck
                      
  • Quellfestplatten werden möglicherweise als nicht für die Sicherung ausgewählt angezeigt

    Quellen, die zuvor für die Sicherung ausgewählt wurden, werden möglicherweise als nicht ausgewählt angezeigt. Dies ist der Fall, wenn die Zuweisung von Festplatten zur virtuellen Maschine aus kosmetischen Gründen bzw. vorübergehend aufgehoben wird. Dies hat keine Auswirkungen auf die Sicherung. Alle zuvor ausgewählten Quellen werden ordnungsgemäß gesichert. Nach einer Sicherung werden die Quellen wieder als ausgewählt angezeigt. Um dieses kosmetische Problem zu lösen, erweitern Sie im Sicherungsassistenten den Knoten der virtuellen Maschine in der Bestandslistenstruktur oder in der Quellauswahlstruktur. Die Festplatten der virtuellen Maschine werden nach ungefähr einer Minute wieder angezeigt und die Quellen werden wieder als ausgewählt dargestellt.

  • Das Sichern einer einzelnen virtuellen Maschine unter Verwendung mehrerer Backup-Appliances verursacht Fehler

    Data Recovery unterstützt die Verwaltung mehrerer Backup-Appliances mit einer einzelnen vCenter Server-Instanz. In solch einem Fall sollte nur eine Backup-Appliance zum Sichern einer virtuellen Maschine konfiguriert werden. Administratoren müssen sicherstellen, dass keine virtuellen Maschinen von mehreren Backup-Appliances gesichert werden. Wenn mehrere Backup-Appliances zum Sichern einer einzelnen virtuellen Maschine konfiguriert sind, kann unerwünschtes Verhalten wie z. B. Fehler beim Erstellen und Löschen von Snapshots auftreten.

Wiederherstellung bei nicht ordnungsgemäß abgeschlossenen Unmounts von Linux FLR

Es ist möglich, dass Linux FLR entweder unerwartet beendet wird oder die Aufgaben beim Herunterfahren nicht vollständig ausgeführt wurden. Falls dies der Fall ist, verbleiben Reste von FLR auf der virtuellen Linux-Maschine, auf der es ausgeführt wurde. Solch ein Szenario sollte keinerlei Probleme innerhalb des Systems verursachen. Es verbleiben aber einige Loop-Geräte, Ordner, Dateien und Vorgänge auf dem System, die bei einem geregelten Herunterfahren von Linux FLR entfernt worden wären. Obwohl diese residenten Ressourcen in der Regel wenig oder keine Auswirkungen auf die Funktionsfähigkeit der betroffenen virtuellen Linux-Maschine haben, können Sie sie entfernen.

Die häufigste Ursache dafür, dass das geregelte Schließen von Linux FLR fehlschlägt, besteht darin, dass einer der Mounts verwendet wird. Beispielsweise kann das fehlgeschlagene Unmounten eines Mounts zur folgenden Ausgabe führen:

 

Restore point has been mounted...

/EG VC Server/EG Datacenter/host/example-esx.eng.example.com/Resources/Red Hat 5.4 Two LVM Groups"

root mount point -> "/root/2010-02-19-22.12.10"

Please input "unmount" to terminate application and remove mount point

unmount

USER PID ACCESS COMMAND

/root/2010-02-19-22.12.10/Mount1:

root 4137 ..c.. bash

Busy mounts detected, unmount aborted. Please unbusy mounts per list above.

Note, future unmounts can be forced by using "force" as input but will cause

unclean unmounts which may require you to manually clean up.

Restore point has been mounted...

"/EG VC Server/EG Datacenter/host/example-esx.eng.example.com/Resources/Red Hat 5.4 Two LVM Groups"

root mount point -> "/root/2010-02-19-22.12.10"

Please input "unmount" to terminate application and remove mount point

In solch einem Fall ist es möglich, Linux FLR sauber zu schließen, indem Sie zuerst die Verwendung des Mounts beenden und anschließend den Befehl unmountausführen. Alternativ kann das Unmounten mithilfe des force-Befehls abgeschlossen werden. Die Verwendung des force-Befehls produziert eine Ausgabe ähnlich der Folgenden:

 

Please input "unmount" to terminate application and remove mount point

force

Removed "/root/2010-02-19-22.12.10/Mount2"

Removed "/root/2010-02-19-22.12.10/Mount3"

Removed "/root/2010-02-19-22.12.10/Mount1"

Removed "/root/2010-02-19-22.12.10"

umount: /tmp/vmware-root/8027465182774010399_1: device is busy

umount: /tmp/vmware-root/8027465182774010399_1: device is busy

umount: /tmp/vmware-root/8027465182774010399_1: device is busy

umount: /tmp/vmware-root/8027465182774010399_1: device is busy

terminate called after throwing an instance of 'std::exception'

what(): St9exception

Aborted

 

Einige Prozesse im Rahmen des Schließens von Linux FLR wurden wie erwartet abgeschlossen, andere nicht. FLR hat den Root-Mount-Punkt unter /root/sowie die untergeordneten Elemente dieses Mount-Punkts erfolgreich entfernt. Linux FLR konnte, wie in der Ausgabe ersichtlich,

<codeph>/tmp/vmware-root/8027465182774010399_1</codeph>

nicht entfernen. Dieser Mount-Punkt bedient weiterhin Mounts.

Beispielsweise können Dateien weiterhin aufgelistet und von diesem Pfad kopiert werden, wie in folgendem Beispiel dargestellt:

 

[root@office ~]# ll /tmp/vmware-root/8027465182774010399_1

-rw-r--r-- 1 root root 68663 Aug 18 2009 config-2.6.18-164.el5

drwxr-xr-x 2 root root 1024 Dec 17 06:00 grub

-rw------- 1 root root 3307695 Dec 17 06:10 initrd-2.6.18-164.el5.img

drwx------ 2 root root 12288 Dec 17 05:43 lost+found

-rw-r--r-- 1 root root 107405 Aug 18 2009 symvers-2.6.18-164.el5.gz

-rw-r--r-- 1 root root 954947 Aug 18 2009 System.map-2.6.18-164.el5

-rw-r--r-- 1 root root 1855956 Aug 18 2009 vmlinuz-2.6.18-164.el5

Da dieser Mount-Punkt weiterhin funktioniert, müssen die folgenden Ressourcen verfügbar und aktiv sein:

  • Fuse-Mount der Partitionen
  • Loop-Gerät, das den lokalen fuse-Mount der vmdk-Flat-Datei bedient
  • Gegabelte FLR-Engine, die E/A zum und vom Mount verarbeitet
  • Redo-Protokolle

Um sich dieser verbleibenden Ressourcen anzunehmen, müssen mehrere Schritte durchgeführt werden, einschließlich:

  • Unmounten der Fuse-gemounteten Partition
  • Entfernen des veralteten Mounts
  • Abschießen laufender vdrFileRestore-Prozesse
  • Entfernen der verbliebenen veralteten Redo-Protokolle

Bereinigung nach nicht ordnungsgemäß abgeschlossenen Unmounts von Linux FLR

  1. Suchen Sie verbleibende Mount-Punkte. Beispielsweise können Sie dazu den Befehl llverwenden, wobei Sie eine Ausgabe ähnlich der Folgenden erhalten:
        [root@office ~]# ll /root/2010-02-19-22.12.10/
        drwxr-xr-x 3 root root 1024 Feb 2 13:17 Mount2
        drwxr-xr-x 25 root root 4096 Feb 19 22:06 Mount3
                    
  2. Entfernen Sie die gefundenen Mount-Punkte. Wenn Sie Mount-Punkte entfernen, dürfen Sie sich nicht mit einem Terminalfenster in einem der Mount-Verzeichnisse befinden, da ansonsten der Befehl fehlschlägt. Dieser Befehl würde ähnlich dem Folgenden lauten:
  3.     [root@office ~]# umount /root/2010-02-19-22.12.10/Mount2
        [root@office ~]# umount /root/2010-02-19-22.12.10/Mount3
        
                    
  4. Entfernen Sie den FLR-Root-Mount und dessen untergeordnete Elemente. Dieser Befehl würde ähnlich dem Folgenden lauten:
        [root@office ~]# rm -rf /root/2010-02-19-22.12.10/
                    
  5. Deaktivieren Sie alle Linux FLR LVM-Gruppen.

    Wenn keine FLR Volume-Gruppen angezeigt werden, können Sie alle Schritte überspringen, die sich auf LVM beziehen. Beachten Sie, dass sich FLR LVM-Gruppen durch ihre eindeutige Benennung unterscheiden. Deaktivieren Sie nur FLR Volume-Gruppen. Deaktivieren Sie keine System-Volume-Gruppen. Beachten Sie, dass FLR-Gruppen "FLR" als Namensbestandteil haben.

    • Führen Sie den Befehl lvm vgdisplayaus. Nachfolgend finden Sie ein Beispiel zur Verwendung dieses Befehls:
    •      [root@office ~]# lvm vgdisplay
           --- Volume group ---
           VG Name EG_TEST
      
           --- Volume group ---
           VG Name EG_TEST-flr-4030-rG64au
      
           --- Volume group ---
           VG Name VolGroup00
      
           --- Volume group ---
           VG Name VolGroup00-flr-4030-7Ms42G
              
                        
    • Führen Sie den Befehl vgchangeaus. Nachfolgend finden Sie ein Beispiel zur Verwendung dieses Befehls:
    •  
           [root@office ~]# vgchange -a n VolGroup00-flr-4030-7Ms42G EG_TEST-flr-4030-rG64au
           0 logical volume(s) in volume group "VolGroup00-flr-4030-7Ms42G" now active
           0 logical volume(s) in volume group "EG_TEST-flr-4030-rG64au" now active
              
                        
    • Suchen Sie nach allen Loop-Geräten, einschließlich denen, die von Linux FLR LVM Volume-Gruppen verwendet werden, indem Sie den Befehl <cmdname>lvm pvscan</cmdname> ausführen. Nachfolgend finden Sie ein Beispiel zur Verwendung dieses Befehls:
    •      [root@office ~]# lvm pvscan
           PV /dev/sdc1 VG EG_TEST lvm2 [1020.00 MB / 520.00 MB free]
           PV /dev/loop3 VG EG_TEST-flr-4030-rG64au lvm2 [1020.00 MB / 520.00 MB free]
           PV /dev/sda2 VG VolGroup00 lvm2 [7.88 GB / 0 free]
           PV /dev/sdb1 VG VolGroup00 lvm2 [992.00 MB / 992.00 MB free]
           PV /dev/loop1 VG VolGroup00-flr-4030-7Ms42G lvm2 [7.88 GB / 0 free]
           PV /dev/loop2 VG VolGroup00-flr-4030-7Ms42G lvm2 [992.00 MB / 992.00 MB free]
           Total: 6 [19.68 GB] / in use: 6 [19.68 GB] / in no VG: 0 [0 ]
                        
  6. Entfernen Sie die Loop-Geräte, die von Linux FLR verwendet werden, mithilfe des Befehls <cmdname>losetup</cmdname> . Im vorherigen Beispiel werden <cmdname>/dev/loop1</cmdname> , <cmdname>/dev/loop2</cmdname> und <cmdname>/dev/loop3</cmdname> von FLR LVM Volume-Gruppen verwendet. Der Befehl zum Entfernen der Loop-Geräte würde für das vorherige Beispiel wie folgt lauten:
        [root@office ~]# losetup -d /dev/loop1
        [root@office ~]# losetup -d /dev/loop2
        [root@office ~]# losetup -d /dev/loop3
                    
  7. Entfernen Sie alle fuse-Mounts. Der Befehl würde ähnlich dem Folgenden lauten:
        [root@office ~]# fusermount -u -z /tmp/vmware-<user name|root>/<fuse mount object>
        [root@office ~]# rm -rf /tmp/vmware-<user name|root>/<fuse mount object>
                    
  8. Beachten Sie, dass vmware-<user name|root>ein Platzhalter für den Ort ist, von dem fuse das Volume gemountet hat. Beachten Sie zudem, dass <fuse mount object>ein Platzhalter für jedes Element ist, das in diesem Verzeichnis gefunden wird.

  9. Entfernen Sie alle veralteten Redo-Protokolle. Der Befehl würde ähnlich dem Folgenden lauten:
        [root@office ~]# rm -rf /tmp/flr*
                    
  10. Schießen Sie FLR-Prozesse unter Verwendung eines Befehls ähnlich dem Folgenden ab:
        [root@office ~]# killall *drFileRestore