How-To: Manually Repair a VMware Replica created by Veeam

Dieser Artikel geht darauf ein, wie man das Replikat zu dessen Basisdatenträgern manuell zurückkehren kann, was ermöglicht, dem Replication Job das Replikat neu zuzuordnen und das für Replica Seeding einzusetzen, wenn ein Snapshot des Replikats corrupt gegangen ist.
 
HINWEIS: Die hier beschriebenen Schritte sind nie auf einem Produktionsserver zu unternehmen, weil es zu einem Datenverlust führen kann. Diese Schritte sind nur auf dem Replikat zu unternehmen, denn Veeam hat die Fähigkeit, das Replikat auf den neuesten Stand zu bringen.
 
Folgende Fehlermeldungen weisen darauf hin, dass man zu diesem KB-Artikel greifen kann:

• Der Replication Job kann auf einen solchen Fehler laufen wie “Unable to repair replica VM.”
• Wenn der Replication Job versucht, ein Snapshot auf dem Replikat zu erstellen, schlägt er fehl: “File or folder already exists.” Am meisten gibt es in diesem Fall einen lockeren File, der genauso wie Snapshot benannt ist, aber mit dem Replikat nicht verknüpft ist. Z.B. der File heißt “DC01-0000001.VMDK”. Wenn VMware das erste Snapshot auf dem Replikat anstoßt, schlägt der Prozess fehl, weil der File mit einem solchen Namen schon existiert.
• Der Replication Job schlägt mit folgender Meldung fehl: “Invalid Snapshot Configuration” und man stellt anhand Tasks & Events des Replikats fest, dass der Fehler vom Replikat kommt.
• Der Replication Job scheitert: “CID mismatch error: The parent virtual disk has been modified since the child was created” und man stellt anhand Tasks & Events des Replikats fest, dass der Fehler vom Replikat kommt.

Ein altes oder verwaistes Snapshot steht im Zusammenhang mit der .vmx-Datei und ein neues Snapshot versucht, diesen Dateinamen zu verwenden.

Bitte beachten Sie, dass Sie erst eine Alternative zu den unten vorgeschlagenen Schritten versuchen können, indem Sie das defekte Replikat in VMWare klonen. Wenn das Klonen gut klappt, können Sie weiter diesem Klon des Replikats den Replication Job neu zuweisen.
 
Hinweis: Vor Beginn:

• Stoppen Sie alle Replication Jobs auf Zielstandort des betreffenden Replikats.
• Gehen Sie sicher, dass keiner der Target Proxy Server per HotAdd angebundene hängengebliebene Disks der Replikate hat. (Überlegen Sie sich, für Target Proxy Server auf Netzwerk als Transport Modus umzusteigen, wenn die per HotAdd angebundenen Disks der Replikate beim Target Proxy hängen bleiben). Weitere Infos siehe im KB-Artikel KB1775.

I. Informationen sammeln

1. Editieren Sie das Replikat
2. Merken Sie sich, welche Disks welchen SCSI ID-Nummern ensprechen.

II. Das Replikat vorbereiten

1. Öffnen Sie den VMWare Snapshot-Manager und vom ältesten Snapshot angefangen löschen Sie die Snapshots ein nach dem anderen. Das Ziel hier wäre, möglichst mehr Informationen über Basisfestplatten zu bekommen. An einem Punkt wird es ein Snapshot geben, das nicht gelöscht werden kann.
2. Wenn einige Snapshots im Snapshot-Manager übrig geblieben sind, versuchen Sie die mithilfe der Option „Alle löschen“ zu entfernen.
3. Greifen Sie zu der Option “Konsolidieren”, um die verwaisten Snapshots zu konsolidieren.

Merken Sie sich, dass es zu erwarten wäre, dass Sie an einem der Schritte fehlschlagen. Wann Sie einen Fehler bekommen, gehen Sie einfach zu dem nächsten Schritt.

III. Veeam Backup & Replication vorbereiten

In der Veeam Console unter Replicas finden Sie das Replikat, das Sie reparieren möchten, klicken Sie auf dieses Replikat mit der rechten Maustaste und wählen Sie aus dem Kontextmenu Remove from replicas… (Remove from configuration) aus
Die Option “Remove from replicas…” ("Remove from configuration") entfernt auch die VM aus der Liste der VMs im Replication Job.
Sie müssen deswegen die VM in diese Liste im Replication Job erneut hinzufügen

1. Editieren Sie im vSphere-Client das Replikat, wählen Sie jede der Festplatten aus und klicken Sie auf Festplatte entfernen. Die Festplatte wird danach als durchgestrichen markiert und die entsprechende Meldung könnte gesehen werden.
2. Nachdem Sie alle Festplatten zum Entfernen ausgewählt haben, klicken Sie auf OK.
3. Editieren Sie das Replikat erneut, diesmals fügen Sie die Basisfestplatten dem Replikat hinzu, wählen Sie Vorhandene Festplatte aus und navigieren Sie zum Speicherort der vorhandenen Festplattendatei des Replikats. Weisen Sie die Festplatten denselben SCSI-Knoten zu, die sie früher hatten.
 
Wenn Sie im vSphere-Web-Client auf eine Festplatte stoßen, wo Festplattengröße mit dem Wert “0” angezeigt ist, kann das Ihnen die Festplatte nicht entfernen lassen. Um die Festplatte entfernen zu können, muss man die Festplattengröße etwas erhöhen. Der Wert, den Sie da eintippen, spielt keine Rolle. Wichtig ist nur sicherzugehen, dass die Festplattengröße weiter nicht mit dem Wert „0“ angezeigt ist. An dieser Stelle können Sie die Festplatte problemlos entfernen.

Das oben erwähnte gilt nicht für vSphere-Thick-Client, wo es schon möglich ist, die Festplatte zu entfernen, dafür die Größe “0” angezeigt ist.

V. Datenspeicher bereinigen

1. Mithilfe des Datenspeicherbrowsers gehen Sie zu dem Ordner des Replikats.
2. Höchstwahrscheinlich gibt es da viele Dateien. Beachten Sie bitte, dass die einzigen Dateien, die man benötigte, sind:

• VMX
• VMXF
• NVRAM
• VMDK für jede Festplatte.

Folgende Dateien können davon entfernt werden:

Man lässt VMX, VMXF, NVRAM und VMDK für jede Festplatte unbetroffen und löscht alle damit verbundenen Snapshot-Dateien, die man weiter nicht benötigt.

VI. Das Replikat testen

1. Lassen Sie für das Replikat ein Snapshot im Snapshot-Manager erstellen.

2. Lassen Sie dieses Snapshot via Snapshot-Manager danach löschen.

3. Wenn keiner Fehler inzwischen auftritt, ordnen Sie das existierende Replikat dem Replication Job (Reiter Seeding, Replica mapping –> Map replicas to existing VMs) zu. Starten Sie den Replication Job, um abzutesten, wie der Job nach den unternommenen Schritten läuft.