6
DFS Replikation alle Daten am Standort weg und syncronisiert neu vom anderen Standort
Hallo,
ich habe ein Problem mit der dfsr Replikation. Wir haben einen SBS 2011 mit addon 2008 R2 an zwei Standorten.
Bis zum 30.12.2015 12.00 hat der Dienst repliziert. Danach waren alle Daten auf dem SBS weg und er hat angefangen diese wieder vom 2. Standort(2008 R2) wieder zu replizieren.
Da bis zum 4.01. 2015 Urlaub war, hat keiner was bemerkt.
In der VSS 30.12.2015 12.00 (130GB) ist alles noch da, in der vom 31.12.2015 nur der Teil (25GB)welcher schon wieder neu repliziert wurde. Bis zum 04.01.2015 sind es nur 40GB
wieder hergestellt.
Die Ereignisanzeige hat keine Fehler oder Warnungen für den 30.12 oder 31.12. Nun habe ich vor den Inhalt auf dem SBS 2011 aus der Schattenkopie wieder herzustellen. Die DFS dienste Replikation und Namensspace werde ich zuvor deaktivieren.
dfsdiag /testdcs ok
dcdiag ok
(hatte im Ursprungspost noch die Fehler ohne ausführen als Administartor drin)
Ist mir dann aber wider eingefallen)
gruß
mejfoss
ich habe ein Problem mit der dfsr Replikation. Wir haben einen SBS 2011 mit addon 2008 R2 an zwei Standorten.
Bis zum 30.12.2015 12.00 hat der Dienst repliziert. Danach waren alle Daten auf dem SBS weg und er hat angefangen diese wieder vom 2. Standort(2008 R2) wieder zu replizieren.
Da bis zum 4.01. 2015 Urlaub war, hat keiner was bemerkt.
In der VSS 30.12.2015 12.00 (130GB) ist alles noch da, in der vom 31.12.2015 nur der Teil (25GB)welcher schon wieder neu repliziert wurde. Bis zum 04.01.2015 sind es nur 40GB
wieder hergestellt.
Die Ereignisanzeige hat keine Fehler oder Warnungen für den 30.12 oder 31.12. Nun habe ich vor den Inhalt auf dem SBS 2011 aus der Schattenkopie wieder herzustellen. Die DFS dienste Replikation und Namensspace werde ich zuvor deaktivieren.
dfsdiag /testdcs ok
dcdiag ok
(hatte im Ursprungspost noch die Fehler ohne ausführen als Administartor drin)
Ist mir dann aber wider eingefallen)
gruß
mejfoss
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 292187
Url: https://administrator.de/contentid/292187
Printed on: April 23, 2024 at 18:04 o'clock
6 Comments
Latest comment
Hi,
und welche Frage(n) hast Du nun dazu?
E.
und welche Frage(n) hast Du nun dazu?
E.
Hallo emeriks,
nun war meine Frage ob dies schon jemand bei der Replikation erlebt hat.
Ich habe den Ordner aus der letzten Datensicherung mit richtigem Daten-Bestand wieder hergestellt und die Replikation wieder angeschmissen.
Da ich weder Fehlermeldungen in den Logfiles oder bei DFSdiag mit den Standorten und DCdiag mit sysvol oder netlogon habe bin ich ziemlich ratlos.
Wie können über 100GB einfach verschwinden und sich neu Replizieren ohne einen einzigen Hinweis das etwas problematisches passiert ist.
Da ich mit den Windowskisten und der Replikation nicht so tief in der Materie stecke, kenn also den Aufbau der Datenbanken und den Zusammenhang mit den Stagingdateien nicht im Detail.
Hier wäre ein Hinweis schon super.
Immerhin müßte ich sonst viel Zeit in eine Technologie investieren die überholt ist.
Ich will einfach nur das es reibungslos funktioniert. Solange das AD in Ordnung ist und DNS richtig konfiguriert wurde habe ich zumeist keine Probleme mit Windows Servern
Auch scheint die Replikation nach dem Einspielen des Backups wieder zu funktionieren.
Es kann sich nur um ein exotisches Problem handeln.
Einzige Besonderheit. Der SBS wurde vor 4 Monaten von einer physikalischen Maschine in eine VM zurückgesichert.
Gruß m.
nun war meine Frage ob dies schon jemand bei der Replikation erlebt hat.
Ich habe den Ordner aus der letzten Datensicherung mit richtigem Daten-Bestand wieder hergestellt und die Replikation wieder angeschmissen.
Da ich weder Fehlermeldungen in den Logfiles oder bei DFSdiag mit den Standorten und DCdiag mit sysvol oder netlogon habe bin ich ziemlich ratlos.
Wie können über 100GB einfach verschwinden und sich neu Replizieren ohne einen einzigen Hinweis das etwas problematisches passiert ist.
Da ich mit den Windowskisten und der Replikation nicht so tief in der Materie stecke, kenn also den Aufbau der Datenbanken und den Zusammenhang mit den Stagingdateien nicht im Detail.
Hier wäre ein Hinweis schon super.
Immerhin müßte ich sonst viel Zeit in eine Technologie investieren die überholt ist.
Ich will einfach nur das es reibungslos funktioniert. Solange das AD in Ordnung ist und DNS richtig konfiguriert wurde habe ich zumeist keine Probleme mit Windows Servern
Auch scheint die Replikation nach dem Einspielen des Backups wieder zu funktionieren.
Es kann sich nur um ein exotisches Problem handeln.
Einzige Besonderheit. Der SBS wurde vor 4 Monaten von einer physikalischen Maschine in eine VM zurückgesichert.
Gruß m.
Ich will jetzt keine Halbwahrheiten verbreiten, schreibe aber mal, wie mir das in Erinnerung ist:
Dass alle Dateien eines Replikats "plötzlich weg" sind, kenne ich eigentlich nur im Zusammenhang mit der Replikation über NtFrs (Standard bis Win2003). Die sind da aber auch nicht einfach so weg, sondern wurden nur verschoben. Das tritt ein, wenn die NtFrs-Replkation längere Zeit nicht stattgefunden hat (wie lange?) und dann irgendwann - wie auch immer - wieder reaktiviert wurde. Die Dateien des "defekten" Replikats werden dabei in einen versteckten Ordner mit "NtFrs irgendwas" im Namen verschoben und allesamt erneut vom Partner repliziert.
Allerdings erscheinen da sehr wohl Einträge im EventLog. Und die Festplatte ist dann nicht einfach um die betreffenden GB leichter, da die Dateien ja nicht gelöscht sondern nur verschoben wurden. Wie ist das eigentlich bei Dir? Die 100 GB sind "weg". Hat die Platte nun auch 100 GB mehr Platz? Falls ja, wurden die Daten also tatsächlich gelöscht.
Bei Replikation über DFS-R habe ich das so noch nicht beobachtet - nicht bewusst jedenfalls. DFS-R würde meines Wissens einfach mit den Informationen aus seinen Staging-Ordner weitermachen und darüber die Replikation fortsetzen.
DFS-R funktioniert bei uns seit Jahren problemlos über mehrere Standorte hinweg, in mehreren Domänen und auch im Mischbetrieb der verschiedenen Windows Versionen. Sofern die Server und Leitungen stark genug sind ist das auch mit größeren Filesystemen (Millionen Dateien) mit "normaler" Änderungsrate kein Problem. Wenn das allerding Dateisysteme mit hoher Änderungrate sind, dann muss man testen, inwieweit das praktikabel ist.
Dass alle Dateien eines Replikats "plötzlich weg" sind, kenne ich eigentlich nur im Zusammenhang mit der Replikation über NtFrs (Standard bis Win2003). Die sind da aber auch nicht einfach so weg, sondern wurden nur verschoben. Das tritt ein, wenn die NtFrs-Replkation längere Zeit nicht stattgefunden hat (wie lange?) und dann irgendwann - wie auch immer - wieder reaktiviert wurde. Die Dateien des "defekten" Replikats werden dabei in einen versteckten Ordner mit "NtFrs irgendwas" im Namen verschoben und allesamt erneut vom Partner repliziert.
Allerdings erscheinen da sehr wohl Einträge im EventLog. Und die Festplatte ist dann nicht einfach um die betreffenden GB leichter, da die Dateien ja nicht gelöscht sondern nur verschoben wurden. Wie ist das eigentlich bei Dir? Die 100 GB sind "weg". Hat die Platte nun auch 100 GB mehr Platz? Falls ja, wurden die Daten also tatsächlich gelöscht.
Bei Replikation über DFS-R habe ich das so noch nicht beobachtet - nicht bewusst jedenfalls. DFS-R würde meines Wissens einfach mit den Informationen aus seinen Staging-Ordner weitermachen und darüber die Replikation fortsetzen.
Einzige Besonderheit. Der SBS wurde vor 4 Monaten von einer physikalischen Maschine in eine VM zurückgesichert.
Wenn es dabei zu keinem "Zeitsprung" in die Vergangenheit kam ...DFS-R funktioniert bei uns seit Jahren problemlos über mehrere Standorte hinweg, in mehreren Domänen und auch im Mischbetrieb der verschiedenen Windows Versionen. Sofern die Server und Leitungen stark genug sind ist das auch mit größeren Filesystemen (Millionen Dateien) mit "normaler" Änderungsrate kein Problem. Wenn das allerding Dateisysteme mit hoher Änderungrate sind, dann muss man testen, inwieweit das praktikabel ist.
Hallo,
nachdem die Daten auf dem sekundären Mitglied wiederhergestellt wurde, hat dieser die Daten auf den primären Replikationspartner ordnungsgemäß bis Menge X repliziert.
Dann am Morgen waren die Dateien an beiden Standorten wieder bei der niedriegen Menge X.
Im Eventlog des nicht primären Partners sind die
Ereignisse 4102 DFS-Replikation initialisiert
als Warnung und
4104 beendet als Information vorhanden.
leider hatte ich die 4102 übersehen da hier die Meldung über einen anderen Ordner, welcher nicht mehr vorhanden ist, aber noch nicht aus der Gruppe gelöscht wurde regelmässig kommt.
Soweit ich es kenne treten diese Ereignisse nur bei der Erst-Replikation auf.
Nun tritt dieses täglich auf.
Da der upload beim primären Mitglied sehr gering ist, wurden die Daten im sekundären Mitglied wieder hergestellt. hier wird auch solange korrekt repliziert bis die neu Initialisierung vom System ausgelöst wird.
Es werden alle Dateien in den DFSPrivate\PreExisting Ordner verschoben. Dann beginnt DFSR den Datenbestand X, welcher bis dato auf den primären Server repliziert wurde als neuer Anfangsbestand des primären Mitglieds repliziert.
Somit wächst der DFSPrivate\PreExisting Ordner jetzt täglich an. Und der Datenbestand wird immer geringer.Leider sind die Dateinamen ab Stelle XY durch {xxxx.xxxx} ersetzt und die Ordnerstrukturen nicht hirachisch. So das es sehr mühsam wird die geänderten Dateien, welche nicht mehr in der letzten Datensicherung enthalten sind wieder herzustellen. So muß immer ein älteres Backup herhalten.
Die Frage ist warum initialisiert der DFSR Dienst täglich neu?
Die Standortreplikation im dssite funktioniert fehlerfrei. Beide Server sind über VPN/WAN verbunden.
Es handelt sich um einen SBS 2011 und den addon 2008 R2 Std.
Es läuft MS Dynamics und Exchange auf dem SBS 2011
Sharepoint wird nicht genutzt.
Ich habe jetzt eine Wiederherstellung in einen neuen Ordner gemacht und würde gerne den SBS zum primären Replikationsserver einer neuen REPLGruppe machen. Bis zur Aufklärung lasse ich die Mitarbeiter nur remote auf den SBS primär zugreifen. Erst dann würde ich die Replikation wieder aktivieren.
Aber ohne eine Erklärung für das bisherige Verhalten kann ich weder ausschliessen das der Server wieder täglich neu initialisiert.
Also warum initialisiert der DFSR jeden Tag den Ordner neu ?
Gruß
nachdem die Daten auf dem sekundären Mitglied wiederhergestellt wurde, hat dieser die Daten auf den primären Replikationspartner ordnungsgemäß bis Menge X repliziert.
Dann am Morgen waren die Dateien an beiden Standorten wieder bei der niedriegen Menge X.
Im Eventlog des nicht primären Partners sind die
Ereignisse 4102 DFS-Replikation initialisiert
als Warnung und
4104 beendet als Information vorhanden.
leider hatte ich die 4102 übersehen da hier die Meldung über einen anderen Ordner, welcher nicht mehr vorhanden ist, aber noch nicht aus der Gruppe gelöscht wurde regelmässig kommt.
Soweit ich es kenne treten diese Ereignisse nur bei der Erst-Replikation auf.
Nun tritt dieses täglich auf.
Da der upload beim primären Mitglied sehr gering ist, wurden die Daten im sekundären Mitglied wieder hergestellt. hier wird auch solange korrekt repliziert bis die neu Initialisierung vom System ausgelöst wird.
Es werden alle Dateien in den DFSPrivate\PreExisting Ordner verschoben. Dann beginnt DFSR den Datenbestand X, welcher bis dato auf den primären Server repliziert wurde als neuer Anfangsbestand des primären Mitglieds repliziert.
Somit wächst der DFSPrivate\PreExisting Ordner jetzt täglich an. Und der Datenbestand wird immer geringer.Leider sind die Dateinamen ab Stelle XY durch {xxxx.xxxx} ersetzt und die Ordnerstrukturen nicht hirachisch. So das es sehr mühsam wird die geänderten Dateien, welche nicht mehr in der letzten Datensicherung enthalten sind wieder herzustellen. So muß immer ein älteres Backup herhalten.
Die Frage ist warum initialisiert der DFSR Dienst täglich neu?
Die Standortreplikation im dssite funktioniert fehlerfrei. Beide Server sind über VPN/WAN verbunden.
Es handelt sich um einen SBS 2011 und den addon 2008 R2 Std.
Es läuft MS Dynamics und Exchange auf dem SBS 2011
Sharepoint wird nicht genutzt.
Ich habe jetzt eine Wiederherstellung in einen neuen Ordner gemacht und würde gerne den SBS zum primären Replikationsserver einer neuen REPLGruppe machen. Bis zur Aufklärung lasse ich die Mitarbeiter nur remote auf den SBS primär zugreifen. Erst dann würde ich die Replikation wieder aktivieren.
Aber ohne eine Erklärung für das bisherige Verhalten kann ich weder ausschliessen das der Server wieder täglich neu initialisiert.
Also warum initialisiert der DFSR jeden Tag den Ordner neu ?
Gruß
Ich würde die alte Replikationsgruppe löschen. Wenn beide Server das bestätigt haben (Eventlog) dann die zugehörigen Staging-Ordner bereinigen. Dann die Ordnerstrukturen auf einem oder beiden Servern manuell rekonstruieren und erst dann eine neue Replikationshruppe erstellen.
Danke erst einmal für deine Mithilfe,
habe ich alles so gemacht und konnte dann den Fehler wieder reproduzieren.
Die Lösung war dann ganz einfach.
Bei der Wiederherstellung des Server aus dem Windows Backup auf der VM wurde der ASR Schlüssel geändert.
Nun kam bei jedem Start des DSF-Dienstes das Event ID2107
Von der DFS-Replikation wurde festgestellt, dass der ASR-Instanzschlüssel auf Volume "C:" geändert wurde. Die Replikation wurde für alle replizierten Ordner auf diesem Volume beendet.
Danach Event ID 2108
Der DFS-Replikationsdienst wird nach der Änderung des ASR-Instanzschlüssels auf Volume "C:" wieder ausgeführt. Die Replikation wurde in replizierten Ordnern auf diesem Volume fortgesetzt.
dann Event ID 4102
Der DFS-Replikationsdienst hat den replizierten Ordner unter dem lokalen Pfad "C:\DSFR-TEST" 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.
Bis Event ID 4104
Der DFS-Replikationsdienst hat die erste Replikation für den replizierten Ordner unter dem lokalen Pfad "C:\DSFR-TEST" erfolgreich abgeschlossen.
Da der Ordner mit 130TB lange braucht um über VPN zu replizieren ist mir der Zusammenhang erst bei einem neuen kleinen Testordner aufgefallen.
Die Lösung habe ich dann in der Technet gefunden
https://social.technet.microsoft.com/Forums/windowsserver/en-US/47582917 ...
When the DFSR service is launched, it will detect the registry “HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CurrentVersion\ASR\RestoreSession\RestoredVolumes”, if this entry exists, DFSR knows a restore was once performed on the volume where the DFSR content resides, so DFSR will do an initial sync to confirm the local database is in a consistent state.
Problem is, this key is not getting removed, so when DFSR is disabled for backup, then enabled again, it believes it has just been recovered from backup and should sync again.
Remove the “RestoreSession” subkey under “HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CurrentVersion\ASR”.
Problem solved!
Wochenende gerettet.
Gruß
habe ich alles so gemacht und konnte dann den Fehler wieder reproduzieren.
Die Lösung war dann ganz einfach.
Bei der Wiederherstellung des Server aus dem Windows Backup auf der VM wurde der ASR Schlüssel geändert.
Nun kam bei jedem Start des DSF-Dienstes das Event ID2107
Von der DFS-Replikation wurde festgestellt, dass der ASR-Instanzschlüssel auf Volume "C:" geändert wurde. Die Replikation wurde für alle replizierten Ordner auf diesem Volume beendet.
Danach Event ID 2108
Der DFS-Replikationsdienst wird nach der Änderung des ASR-Instanzschlüssels auf Volume "C:" wieder ausgeführt. Die Replikation wurde in replizierten Ordnern auf diesem Volume fortgesetzt.
dann Event ID 4102
Der DFS-Replikationsdienst hat den replizierten Ordner unter dem lokalen Pfad "C:\DSFR-TEST" 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.
Bis Event ID 4104
Der DFS-Replikationsdienst hat die erste Replikation für den replizierten Ordner unter dem lokalen Pfad "C:\DSFR-TEST" erfolgreich abgeschlossen.
Da der Ordner mit 130TB lange braucht um über VPN zu replizieren ist mir der Zusammenhang erst bei einem neuen kleinen Testordner aufgefallen.
Die Lösung habe ich dann in der Technet gefunden
https://social.technet.microsoft.com/Forums/windowsserver/en-US/47582917 ...
When the DFSR service is launched, it will detect the registry “HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CurrentVersion\ASR\RestoreSession\RestoredVolumes”, if this entry exists, DFSR knows a restore was once performed on the volume where the DFSR content resides, so DFSR will do an initial sync to confirm the local database is in a consistent state.
Problem is, this key is not getting removed, so when DFSR is disabled for backup, then enabled again, it believes it has just been recovered from backup and should sync again.
Remove the “RestoreSession” subkey under “HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CurrentVersion\ASR”.
Problem solved!
Wochenende gerettet.
Gruß
