DFS-Replikation gestartet, Staging zu klein, angepasst und trotzdem kein Start sowie weiterhin Fehlermeldungen

Guten Morgen,

vielen Dank für deine Antwort!

Noch einmal in der Kürze was genau passiert ist (nachdem schon Einiges vorher erfolgreich repliziert worden ist).

FS=File-Server (alte phys. Maschine)
CFS=ClusterFileServer (zwei neue Knoten, soll den alten FS ersetzen)

1. Replikation gestartet (FS ist natürlich als Master ausgewählt)
2. Replikation ist bei ca. 40% angehalten (ca. 320 GB Gesamtgröße), Staging-Ordner ist gegen die Wand gefahren.
Leider ist das Ordnerziel des neuen Servers vergessen worden herauszunehmen. Dadurch wurde nicht auf dem alten FS gesichert bzw. vom CFS wurde mangels belegtem Staging-Ordner nicht mehr "zurück" repliziert.
3. Staging-Ordner auf 16 GB vergrößert, später ca. 7 GB belegt, daher auf 64 GB aktuell gesetzt.
4. Somit liegen für einen Zeitraum von ca. 1-2 Tagen geänderte Daten auf dem neuen CFS, die nicht repliziert worden sind.

Mittlerweile sieht es aber besser aus, da er immer mal wieder repliziert bzw. ich viele Ereignis-IDs 4412 sehen kann. Leider aber in einer sehr geringen Geschwindigkeit. Zumindest läuft es richtig (vom CFS zum SF), wenn es heißt:

Ursprünglicher Dateipfad: H:\home\"username"\Documents\Default.rdp
Neuer Name im Konfliktordner: Default-{1CC56DCC-D084-4BCA-ABAC-2EB469255623}-v4697.rdp
Stamm des replizierten Ordners: H:\home
Datei-ID: {AB991D4E-2559-48FE-A9DD-1838AA54D4F6}-v19818528
Name des replizierten Ordners: Home

So sind es wenigstens seit gestern Abend ca. 5 GB an Replikationsmasse hinzugekommen. Nur benötigen die User am besten jetzt die zuletzt bearbeiteten Dateien. Wenn ich aber die Replikation deaktiviere, neu erstell' und den CFS als Master nehme, dann überschreibt er doch den FS. Oder liege ich hier falsch?

Edit: Ist es möglich vom CFS die Sache zu beschleunigen, so dass ich den alten SF als Master wieder konsistent habe?
Edit2: Ist es schädlich die Staging Größe auf 64 GB beim FS und CFS zu belassen? Aktuell sehe ich noch viele Dateien auf dem alten FS, die noch nicht gestaged worden sind. Oder dauert es seine Zeit?

Wie ich herausgefunden habe, halten sich die Änderungen in Grenzen. Die Replikation funktioniert für aktuelle und alte Daten. Zumindest sehe ich es an den Logs und den Zielen, dass was passiert. Ich denke, hier ist es am besten einen Diagnosebericht abzuwarten und dann zu sehen, bei welchem Benutzer samt Daten es zu Inkonsistenz gekommen ist.

Ist diese Meldung "normal" und gehört zum Thema "kann passieren"?
Der DFS-Replikationsdienst wurde wiederholt daran gehindert, eine Datei zu replizieren. Der Grund besteht in fortdauernden Freigabeverletzungen für die Datei. Der Dienst konnte das Staging für eine Datei für die Replikation aufgrund einer Freigabeverletzung nicht durchführen.

Hier handelt es sich häufig um .URL- und .temp-Dateien.

Gibt es noch wichtige cmdlets wie eine Replikation neugestartet werden kann? Oder reicht es den Replikations-Dienst zu beenden, so dass der zweite Knoten (vom Cluster) einspringt und dann den Dienst "frisch" (neu) ausführt. Oder bringt das nichts?

Der heutige Stand sieht so aus.

- Eigenschaften/Größe beider Ziele sehen so gut wie gleich aus... hier sind nur ein paar hundert Dateien die fehlen... vermutlich .tmp usw.
- Die Staging-Size hatte ich zwischenzeitlich auf 64 GB gesetzt, da ich eine Meldung über 23 GB an Nutzung des Staging-Ordners bekommen habe.

Trotzdem gibt es noch folgendes. In der "ConflictAndDeletedManifest.xml" kann ich die Konflikte und Änderungen genau herausfinden. Leider nur bis zum 21.12. Hier war wohl der Ordner nicht groß genug gewählt, so dass er das älteste gelöscht hat, richtig?

CFS:
- Staging-Ordner steht bei 11 GB, Ordner mit Erstelldatum vom 19.12., jedoch mit Änderungsdatum von heute (27.12.) - Werden Staging-Dateien (.frx) aktualisiert, wenn sie nicht verschoben werden können, und daher mit neuem Timestamp gesetzt?
- ConflictAndDeleted steht bei 12,2 GB

FS:
- Staging-Ordner steht bei 8,7 GB und "ConflictAndDeleted" bei 0 GB.

Edit: Kann man hier im Staging noch auf einen "grünen Pfad" kommen, also kann ich noch damit rechnen, dass hier gestaged wird oder war's das?


In anderen Ordnern, auf dem alten FS wo die Staging-Size nicht ausgereizt worden ist, sehe ich noch Dateien datiert vom 1.12. Passiert hier noch was oder liegen die solange bis gelöscht?

Wenn ich mir die Profile der User ansehe, die sich am nächsten Tag gemeldet hatten, gibt es bis heute kein Staging von neu zu alt. Darauf zu hoffen kann ich wohl vergessen, außer ich mach den CFS unsinnig zum Master, nur dann sind alle wieder geänderten Daten auf dem SF wieder nicht richtig.

Also ist die einzige Lösung alles Geänderte suchen von/bis und es per robocopy in das alte Verzeichnis, sofern möglich händisch zu verschieben!?!?

Auf dem CFS sind bereits neue Dateien. Wenn ich mir die Größen ansehe, ist die Initialreplikation längst durch. Vor Weihnachten war sie noch bei 40%.


Und das sollte ersichtlich sein, wenn beide Staging-Ordner (so gut wie) leer sind bzw. der Konflikt-Ordner größer wird, da er wohl möglich diese Dateien umbenennen wird und darin ablegt?

Okay, der Pfad ist als einziger nicht dabei, der (erfolgreich) abgeschlossen worden ist. Also abwarten und nichts tun?

Gibt es irgendwo ein Log, wo ich live sehen kann, wieweit er ist? Oder ist die Diagnose mit dem Zählen der Daten das Einzige Mittel?

Edit: Hast du vielleicht noch andere Tipps, außer der Staging-Size, wie ich die Replikation beschleunigen kann? Denn auf den Kosten ist nichts zu sehen. Das SAN langweilt sich auch eher, als das dort was passiert.