Data Domain: Fehler im DDFSY-Dateisystem, wenn die MTREE-Replikation für die Veeam DDBOOST-Speichereinheit konfiguriert ist

Wenn VEEAM oder eine andere Backupanwendung, die BOOST zum Durchführen von Backups verwendet, die Funktion Virtual Synthetics verwendet, werden neue Backups von vorhandenen erstellt, indem Teile der vorherigen Backups auf der DD zusammengefügt und dann die Unterschiede hinzugefügt werden. Die früheren Backups, die für das Zusammenfügen verwendet werden, werden als "Basisdateien" bezeichnet.

Die meisten Backupanwendungen lesen, ändern jedoch nicht die Basisdateien, die für die Erstellung neuer Backup-Images verwendet werden. VEEAM funktioniert jedoch anders, wenn Backups durchgeführt werden, überschreibt es Teile der Basisdateien, die sich bereits auf der Festplatte befinden.

Wenn die ausgehende MTree-Replikation für diesen VEEAM-LSU/MTree konfiguriert ist, ist es möglich, dass eine replizierte Backupdatei von BOOST während der Erstellung neuer Backupdateien geändert wird. Wenn auf dem Quell-DD DDOS 6.x ausgeführt wird und die Replikation aktiviert ist (eine Geschwindigkeits-/Leistungsoptimierungsoption in DDOS 6.x und höher), kann dies dazu führen, dass falsche Prüfsummen auf dem Ziel-DD eingehen, was dazu führen kann, dass das Dateisystem wiederholt fehlschlägt, mit Meldungen wie den folgenden:

27. Februar, 04:05:19 mtree-repl-dd.example.com ddfs[10654]: ERROR: MSG-INTRNL-00001: PANIC: ddr/repl/mrepl_replica.c: mrepl_finish_file_transfer_common: 3712: ! (orig_chksum == repl_chksum).

Die Art und Weise, wie VEEAM neue Backups von vorhandenen wiederherstellen kann, kann es zu Überschreibungen einiger Teile der zu replizierenden Dateien kommen, wenn sie als Basisdatei für die Erstellung neuer Backup-Images verwendet werden. Dies führt zu Verwirrung bei der Replikation, wenn die VEEAM-Speichereinheit auch so konfiguriert ist, dass sie als Teil der MTree-Replikation verwendet wird, was möglicherweise dazu führt, dass die Ziel-DD einen FEHLER verursacht.

Beachten Sie, dass dieser Fehler nur für das Zielende für die MTree-Replikation gilt, wenn die Quelle:

• Ausführen von DDOS 6.0.1.0 oder früher (z. B. alle DDOS 6.0.0.x wären betroffen)
• Ausführen von DDOS 6.x vor DDOS 6.0.2.0 oder 6.1.1.1
• Ausführen von VEEAM-Backups auf einem LSU/MTree, und derselbe MTree wird mithilfe der MTree-Replikation auf das Ziel repliziert
• BOOST-Backups mit aktivierten virtuellen synthetischen Backups werden auf demselben LSU/MTree durchgeführt.
•  Wenn dieser Fehler auftritt, kann dies dazu führen, dass der replizierte Ziel-MTree bei mehreren Neustarts des Dateisystemprozesses nicht mehr verfügbar ist. Diejenigen, die dieses Setup verwenden oder planen, ihre Systeme auf diese Weise zu konfigurieren, sollten entweder den unten erläuterten Workaround verwenden oder ein Upgrade auf DDOS 6.0.2.0 oder 6.1.1.1 (oder eine spätere Version) durchführen.

Hinweis: Es ist möglich, dass dieselbe PANIC-Zeichenfolge am Zielende für die MTree-Replikation bei anderen Problemen als diesem auftreten kann, da der Fehler lediglich darauf hinweist, dass eine Prüfsumme im MTree-Replikations-Snapshot nicht übereinstimmt. Wenden Sie sich bei Zweifeln an dem hier beschriebenen Problem oder der Umgehung eines Problems an Ihren vertraglich vereinbarten Supportanbieter und verweisen Sie auf diese KB-Artikelnummer 491049.

DD Engineering hat die Ursache für die FS NODES auf dem Ziel-Node identifiziert und eine Korrektur in den folgenden Versionen bestätigt:

• DDOS 6.0.2.0 und höher
• DDOS 6.1.1.1 und höher

Jeder, der von diesem Fehler betroffen ist oder eine ähnliche Konfiguration einrichten möchte, wird empfohlen, das Quell-DD so bald wie möglich auf die genannten Versionen zu aktualisieren.

Für diejenigen, die kein Upgrade durchführen möchten oder die mit dem Problem konfrontiert sind, bevor die behobene Version verfügbar wird, gibt es einen Workaround.
Sie besteht darin, die Optimierung der Replikation auf dem DDOS 6.x-Quellsystem zu deaktivieren.
Diese Optimierung ist nur in DDOS 6.x und höher vorhanden. Der einzige Nachteil der Deaktivierung ist, dass die Replikationsgeschwindigkeiten niedriger als die von DDOS 5.7 wären.

Vor der Bereitstellung sollten Sie zunächst bestätigen, ob dieser Workaround für das aktuelle Setup gilt:

1. Überprüfen Sie, ob auf dem Quell-DD DDOS 6.x vor der Version ausgeführt wird, die dieses Problem behoben hat (Fehler behoben in DDOS 6.0.2.0 und 6.1.1.1)
2. Vergewissern Sie sich, dass die für VEEAM-Backups konfigurierte DD auch für die MTree-Replikation für den Betreff LSU/MTree als Quelle konfiguriert ist (die Überprüfung eines aktuellen ASUP wäre beispielsweise die einfachste Möglichkeit, dies zu bestätigen):

CTX: 20-Modus: Quellziel: mtree://destination-dd.example.com/data/col1/destination_MTree Aktiviert: ja

 Wenn alle oben genannten Bedingungen zutreffen, kann dieses System den oben genannten Fehlern unterliegen und dazu führen, dass das Zielreplikations-FS schließlich abstürzt.

Um den Workaround anzuwenden, muss zunächst sichergestellt werden, dass keine Replikations- oder BOOST-Backups ausgeführt werden, und dann die Registrierungseinstellung ändern, was keine Ausfallzeiten erfordert. Bevor Sie mit diesem Prozess beginnen, lesen Sie bitte die Vorsichtshinweis unter dem letzten Schritt dieses Verfahrens.

1. Stellen Sie sicher, dass die DD-zu-DD-Replikation auf dem Quell-DD mit DDOS 6.x deaktiviert ist:

# Replikation deaktiviert alle

2. Stellen Sie außerdem sicher, dass keine laufenden BOOST-Backups oder BOOST MFR auf oder vom potenziell schädlichen VEEAM-LSU/MTree vorhanden sind, bevor Sie die Registrierungseinstellung anwenden. Falls erforderlich, deaktivieren Sie Backups und MFR zu oder von diesem LSU vorübergehend:

# ddboost file-replication show active all
# ddboost file-replication show stats

3. Diese Registrierungsänderung erfordert SE-Modus-Berechtigungen.

4. Ändern Sie im SE-Modus die Registrierungseinstellung, um die Verwendung der Replikation zu deaktivieren:

# se sysparam set RECIPE_REPL_ENABLED=FALSE

5. Bestätigen Sie, dass der Systemparameter korrekt festgelegt wurde und als "FALSE" (deaktiviert) angezeigt wird.

# se sysparam show RECIPE_REPL_ENABLED
Namensbeschreibung Aktuelle Standardüberschreibung
-------------------   ------------------------------------------------   -------   -------   --------
RECIPE_REPL_ENABLED "Enable recipe replication" (nur auf Quelle anwenden) FALSE TRUE RPC
-------------------   ------------------------------------------------   -------   -------   --------

6. Sie können jetzt die DD-zu-DD-Replikation erneut aktivieren und BOOST-Backups und BOOST MFR zum oder vom LSU wiederaufnehmen:

# Replikation aktiviert alle

VORSICHTSHINWEIS: Wenn die Verarbeitung der Formel auf einem Data Domain-Quellsystem deaktiviert wurde, das auch als Zielende für die Replikation konfiguriert ist, müssen die Quellsystem(en) für diese Kontexte auch den oben genannten Prozess durchführen lassen (die Replikation nach der Replikation ist deaktiviert).

Beachten Sie außerdem, dass nach dem Upgrade auf eine feste Version (DDOS 6.0.2.0 oder 6.1.1.1) die Einstellung wiederhergestellt werden muss, damit die replikationsbasierte Replikation genutzt werden kann. Durch das Upgrade wird der Registrierungsschlüssel nicht zurückgesetzt. Nachdem Sie das Upgrade abgeschlossen haben, aktivieren Sie die Replikation nach der Wiederherstellung, indem Sie sich bei DD anmelden, in den SE-Berechtigungsmodus wechseln und folgende Schritte ausführen:

  # se sysparam reset RECIPE_REPL_ENABLED

Wenn Sie sich nicht sicher über den oben beschriebenen Prozess sind, wenden Sie sich an Ihren vertraglich vereinbarten Supportanbieter und verweisen Sie auf diesen Wissensdatenbank-artikel 491049 .

Es besteht immer die Möglichkeit, dass die NODES auf ein anderes Problem zurückzuführen sind, und der angewendete Workaround funktioniert möglicherweise nicht, während FS PANIC auf dem Ziel-DD fortgesetzt wird.

In einem solchen Fall wird empfohlen, sowohl die Quell- als auch die Ziel-DDs auf sicheren Code (oben genannte DDOS-Versionen) zu aktualisieren und zu gewährleisten, dass die fehlerhaften Replikationskontexte unterbrochen (nicht konfiguriert), vorhandene Snapshots abgelaufen sind und die Replikationskontexte erneut hinzugefügt und neu initialisiert werden. Da dies ein potenziell zeitaufwendiger Prozess ist und es mehrere Replikationskontexte geben kann, die die Ursache für das Problem sein können, wenden Sie sich an Ihren vertraglich vereinbarten Supportanbieter und verweisen Sie auf diese KB-Artikelnummer und alle bisher durchgeführten Maßnahmen, um Unterstützung zu erhalten.