Fragensteller
DFS Replikation funktioniert nicht nach Baremetal Recovery der Volumes die mit wbadmin gesichert werden - W2K8r2Sp1

Allgemeine Diskussion
-
Hallo allerseits!
Unser Setup:
Alle Server W2K8r2Sp1, Patchlevel Juni 2017.
Standort A und Standort B sind mit VPN 256Kbit verbunden.
Standort A: 1x DC, 1x RDP und Dateiserver mit DFS
Standort B: 1x DC, 1x RDP und Dateiserver mit DFSEs werden Namespaces in beide Richtungen repliziert, wobei das Replikat immer nur Read Only hat.
Am Wochenende führen wir mit WBadmin ein vollständiges Backup beider DFS Server durch.
Danach steht zum Beispiel im Ereignisprotokoll folgender Eintrag:
Protokollname: DFS Replication Quelle: DFSR Datum: 06.08.2017 15:30:26 Ereignis-ID: 4102 Aufgabenkategorie:Keine Ebene: Warnung Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: IT1FS1.intranet.stella-packaging.de Beschreibung: Der DFS-Replikationsdienst hat den replizierten Ordner unter dem lokalen Pfad "F:\Produktionsmittel1\Maschinen" initialisiert und ist für die erste Replikation bereit. Der replizierte Ordner verbleibt in diesem Zustand, bis er replizierte Daten direkt oder indirekt vom zugewiesenen primären Mitglied empfangen hat. Weitere Informationen: Name des replizierten Ordners: Maschinen ID des replizierten Ordners: 2C52A4E3-6E80-44C8-872F-DCBF291F1B63 Replikationsgruppenname: intranet.stella-packaging.de\produktionsmittel\maschinen Replikationsgruppen-ID: 50BAE832-9BA8-457A-8D95-D679D3844E40 Mitglieds-ID: E587242F-250E-4ED9-AC3E-65027F451349 Ereignis-XML: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="DFSR" /> <EventID Qualifiers="32768">4102</EventID> <Level>3</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2017-08-06T13:30:26.000000000Z" /> <EventRecordID>85303</EventRecordID> <Channel>DFS Replication</Channel> <Computer>IT1FS1.intranet.stella-packaging.de</Computer> <Security /> </System> <EventData> <Data>2C52A4E3-6E80-44C8-872F-DCBF291F1B63</Data> <Data>F:\Produktionsmittel1\Maschinen</Data> <Data>Maschinen</Data> <Data>intranet.stella-packaging.de\produktionsmittel\maschinen</Data> <Data>50BAE832-9BA8-457A-8D95-D679D3844E40</Data> <Data>E587242F-250E-4ED9-AC3E-65027F451349</Data> </EventData> </Event>
Das gilt für alle Replikate und beide Server. Eine Replikation findet nicht statt. Auch ein Neustart des Dienstes ändert daran nichts. Durchgeführte Maßnahmen:
Letzte Woche habe ich manuell für jeden replizierten Ordner mit DFSadmin den Parameter
IsPrimary:True
gesetzt. Damit startete die Replikation und nach einigen Tagen waren alle Ordner auf beiden Servern repliziert und neue Dateien waren sofort am Remotestandort sichtbar. (RO)
Die Abfrage
wmic /namespace:\\root\microsoftdfs path DfsrReplicatedFolderInfo get replicatedFolderName, State
ergab für alle Ordner auf beiden Servern den Status 4, soweit so gut.
Heute, nach dem Wochenendbackup ist wieder der gleiche Status, es findet keine Replikation statt und im Debug Log steht:
20170807 13:02:28.600 5920 INCO 1042 [WARN] SessionTask::Step (Ignored) Failed, should have already been processed. Error: + [Error:9027(0x2343) InConnection::EstablishSession inconnection.cpp:6172 5920 C Der Remotepartner hat einen Fehler gemeldet.] + [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4200 5920 C Der Remotepartner hat einen Fehler gemeldet.] + [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 5920 C Der Remotepartner hat einen Fehler gemeldet.] + [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 5920 C Der Inhaltssatz ist nicht bereit.] 20170807 13:02:28.600 5920 ISYN 68 InitialSyncManager::ReturnToken InitialSync sync step not finished yet. Wake up other session tasks.
Der Parameter "IsPrimary:True" ist auf keinem Server mehr vorhanden.
Ich habe keine Idee woran das liegen könnte?
Gruß
Andreas
- Typ geändert Mihaela ParedesMicrosoft contingent staff, Moderator Montag, 4. September 2017 14:08 Warten auf eine Rückmeldung
- Bearbeitet Ajmind Donnerstag, 21. September 2017 13:03
Alle Antworten
-
Hallo Andreas,
1. Frage: Was ist der Anlass beide DFS Replikate zu sichern?
Dadurch wird auf beiden Seiten das Archivbit verändert und das u.U. zwischen zwei Replikationszyklen. Gleichzeitig sichert Ihr den Datenbestand doppelt.
Sichert mal bitte nur eine Seite der Replikate.
2. Frage: wie sieht es dann aus?
Gruß Malte
-
Moin,
Malte hat Recht. Falls es unbeding auf beiden Seiten sein muss, macht auf einer Seite eine Kopiersicherung (die setzt das Archivbit nicht) oder schiebt sie zeitlich soweit auseinander, dass ein voller Replikationszyklus dazwischen absolviert werden kann. Da muss man aber experimentieren.
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com -
Hallo Malte,
zu 1: Bei beiden Servern handelt es sich auch um unseren zentralen Terminal- und Dateiserver. Es wird am Wochenende eine vollständiges Backup via wbadmin durchgeführt.
zu 2: Das kann ich ich nicht sagen, da wir unseren (einzigen) Terminal- und Dateiserver je Standort sichern müssen. Im Falle eines Totalausfalls können wir dann sehr schnell unsere Arbeitsumgebung wiederherstellen.
Als Workaround lasse ich jetzt nach dem Backup eine Batchdatei laufen die für jedes Replikat erneut den Parameter "IsPrimary:True" setzt.
Gruß Andreas
-
So die Wochenenddatensicherung ist erzeugt, offensichtlich hat der zeitliche Abstand zwischen den beiden Serversicherungen nicht ausgereicht, es fehlen auf einer Seite komplette Ordner mit mehren 1.000 Dateien.
Frage zu der "Kopiersicherung":
sind außer dass das Archivbit nicht gesetzt wird irgendwelche Nachteile damit verbunden?
Was wäre denn die richtige Methode die beiden Server zu sichern?
Gruß Andreas
-
Frage zu der "Kopiersicherung":
sind außer dass das Archivbit nicht gesetzt wird irgendwelche Nachteile damit verbunden?
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com -
Naja, es wird halt kein Archivbit gesetzt, daher kannst Du ausgehend von einer Kopiersicherung keine Differenzialsicherung anfertigen. Wenn Du es nicht brauchst, entstehen keine Nachteile.
Okay, werde ich am nächsten WE machen. Bis dahin danke für die freundliche Unterstützung :-)
-
Hallo Andreas,
Na ja Terminalserver und DFS Replikation auf einem System ist nicht ganz optimal. Du wirst sicher Gründe dafür haben.
Ich würde den Ansatz von Evgenij verfolgen. auf einer Seite machst Du ein "normales Backup" auf der anderen Seite eine "Kopie Sicherung". Dadurch veränderst Du nur das Archiv Flag auf einer Seite. Beide Sicherungen würde ich zeitlich versetzt durchführen.
Wie sieht den die Auslastung der Stage Bereiche aus? Stichwort Event IDs DFSR 4202 & DFSR 4204.
Gruß Malte
-
Hallo Malte,
als KMU müssen halt drei Systeme pro Standort reichen, (1xDC, 1x EX2K10SP3, 1xRest=Datei,-Druck, RDP).
Die erzeugte Last der User ist eher gering, wir produzieren halt.
Am kommenden Wochenende werde ich euren Rat umsetzen und berichten.
Der Stagingbereich ist großzügig bemessen, es kommt nur selten zu einem Event 4202 & 4204.
Gruß Andreas
-
So, die Wochenendsicherung ist gelaufen, das Problem bleibt bestehen.
Am Standort B wurde die Sicherung am 19.08. um 15:30 Uhr gestartet und um 18:19 beendet.
Am Standort A wurde die Sicherung am 20.08. um 20:30 Uhr gestartet und um 22:29 beendet.
Der Sicherungslauf wurde mit folgendem Aufruf an beiden Standorten durchgeführt:
wbadmin start backup -backuptarget:\\WIN7PC\h\Woche1 -include:c:,e:,f: -systemstate -allcritical -vssCopy -user:xxxxxxxxxxxxx -password:yyyyyyyyyyyy -quiet
Trotzdem sind wieder viele tausend Dateien in dem Konfliktordner am Standort A gelandet, obwohl am Wochenende niemand einen Zugriff darauf hatte.
Bis auf weiteres habe die Replikation der betreffenden Ordnerziele gelöscht.
Ich habe jetzt testweise einen neuen Namespace nebst Replikat erzeugt und teste daran jetzt verschiedene Sicherungsparameter, da ich nicht weiß, ob unser vorgenannter Aufruf tatsächlich nicht doch das Archivbit setzt. Mir scheint es hat sich nichts geändert.
Falls jemand noch hilfreiche Tipps zur Fehleranalyse für mich hat, würde ich mich sehr freuen :-)
Gruß Andreas
-
Nach weiteren Recherchen bin ich vermutlich auf die Problemursache gestoßen:
Primär wird das Problem nicht durch wbadmin verursacht!
Zum Backup wird DSFR beendet und danach neu gestartet. Dabei wird in der Registry nachgeschaut, ob dort ein bestimmter Schlüssel hinterlegt ist. Dieser Schlüssel beinhaltet die Information, ob ein Volume Restore stattgefunden hat. Falls vorhanden wird eine Erstsynchronisation durchgeführt um zu bestätigen das die DB in einem konsistenten Status ist.
Dieser Registry Schlüssel wird aber nach einem erfolgreichen Restore nicht gelöscht, d.h. nach jedem normalen Backup wird dieser Initial Sync durchgeführt.
Bei uns stammen alle Servervolumes von einem "baremetal restore" ab, da wir letztes Jahr unseren VM Hypervisor gewechselt haben.
Hier der Link zu dem Originalthread:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/47582917-9086-46a3-8fd1-5440e0a9c10f/windows-backup-forcing-dfsr-to-reinitialize-replicated-folders?forum=winserverfiles
Ich werde das am kommenden Wochenende testen und dann hier das Ergebnis posten.
Bis dahin eine schöne Woche!
Gruß Andreas (der jetzt wieder Hoffnung in sich trägt)
- Bearbeitet Ajmind Mittwoch, 23. August 2017 13:57
-
Nach meinen Urlaub und drei erfolgreichen Datensicherungen am Wochenende kann ich bestätigten, dass das Problem gelöst ist.
Die Fehlerursache liegt tatsächlich an dem nicht entfernten Schlüssel der Registry. Also ein klassischer Bug!
Zu guter Letzt teste ich jetzt noch die Sicherung mit dem ursprünglich verwendeten Parameter -vssFull.
Gruß Andreas
-
So, abschließend kann ich bestätigen, dass der Sicherungsparameter -vssFull keinen Einfluss auf das geschilderte Problem hat. Die DFS Replikation läuft auch damit tadellos.
Letztendlich ist der Fehler nur durch die Datensicherung sichtbar geworden, die Ursache liegt in dem erwähnten Bug.
Daher ändere ich den Threadtitel entsprechend ab um andere Hilfesuchende nicht auf die falsche Fährte zu locken. :-)
Gruß Andreas