DFS Replication probleem na corrupte DFSR database

[Urk]

Ik heb 2 Windows Server 2012 R2 servers waarop DFS-Namespace en DFS-Replication actief zijn.
Ik noem ze maar even server01 en server03.

Door een RAID5 crash is server01 (=VM) teruggezet van een backup. Tijdens deze stroring zijn netjes alle fileshares gekoppeld aan DFS op server03. Nadat server01 weer draaide liep eigenlijk alles weer prima, behalve DFS-R. De DFS-R database is corrupt geraakt en dit werd duidelijk gemeld door de volgende events:

code:

The DFS Replication service failed to recover from an internal database error on volume F:. Replication has been stopped for all replicated folders on this volume. 
 
Additional Information: 
Error: 9214 (Internal database error (-1605)) 
Volume: CE1655D2-C716-4863-A983-AE9180D6C888 
Database: F:\System Volume Information\DFSR

Het lukte de server niet meer om deze database zelf te herstellen. Dus heb ik volgens dit artikel:
https://thetechl33t.com/2...-restore-dfsr-error-2104/
De DFS-R database op server01 verwijderd en opnieuw laten aanmaken.
Hierna waren de foutmeldingen in de DFSR Event log weg en leek alles weer goed te gaan.

Echter... het lijkt erop dat veel bestanden nu de verkeerde kant op worden gesynced.
Voorbeeld:
Op server01 staat het bestand Dollar rates.xlsx met last modified date 20 juni 2018 - 15:32
Op server03 staat het bestand Dollar rates.xlsx met last modified date 23 maart 2018 - 17:18

Hier gaat het mis want je zou verwachten dat DFS-R het bestand van server01 verplaatst en overschrijft over het bestand op server03. Maar het gebeurd precies andersom. Dus hierna hebben ze beiden een last modified date van 23 maart 2018 - 17:18.

De DFSR event log logt over dit bestand het volgende:

code:

The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder. 
 
Additional Information: 
Original File Path: F:\Data\Operations\Website\Dollar rates.xlsx 
New Name in Conflict Folder: Dollar conversion ra-{062650A5-0C46-44F9-837C-D6D369D8C1D0}-v331361.xlsx 
Replicated Folder Root: F:\Data 
File ID: {9D5BD091-612F-48D3-AF93-56D166107604}-v1309214 
Replicated Folder Name: Data 
Replicated Folder ID: 07BA00EF-2D7C-4A77-AEFD-D45FC5F01C1E 
Replication Group Name: Repl 
Replication Group ID: 4727D9D3-8E71-4098-B77D-B576103F9473 
Member ID: 157CA694-D812-4E7C-8764-9AAEE66E41B4 
Partner Member ID: 0EEAEE40-F4A4-444B-837A-F77260AF12A9

Zoals genoemd heb ik alleen de DFS-R database op server01 verwijderd en opnieuw laten opbouwen, het artikel is hier onduidelijk in maar is het wellicht nodig om ook de DFS-R database op server03 te verwijderen en opnieuw te laten opbouwen?
Of wat gaat hier anders mis? Bovenstaande gebeurd trouwens bij meer bestanden, het is dus geen incident. Via Previous Versions en ConflictAndDeleted kan ik mooi zien dat de vorige versie een nieuwere last modified date heeft.
Alvast

[ Voor 4% gewijzigd door Urk op 07-08-2018 23:17 ]

[belrpr]

Niet eenvoudiger van server 1 uit de dfs te zetten.
De bestanden te verwijderen en de opnieuw te configureren zodat server 1 al de data uit server 3 haalt zonder conflicten.

[Killah_Priest]

Wijze les bij replica's : altijd een goede recovery strategie klaar hebben om dit soort zaken te voorkomen.
Een domain controller restore je immers ook niet vanaf een backup (tenzij het de laatst overgebleven DC is) ivm replicatie problemen.

Ik weet dat je hier nu weinig aan hebt.

In het verleden deed ik het als volgt met deze "restores" : nieuwe fileserver uitrollen (15 min werk met een WDS server), server opnemen in de DFS en de replica laten lopen.
Eventuele files welke nieuwer waren op de "overleden" server controleerde ik dmv een simpel script en die werden dan gekopieerd.
Omslachtig : ja, maar op die manier wist ik wel zeker dat er geen files de verkeerde kant op gesynched werden.

[Urk]

belrpr schreef op woensdag 8 augustus 2018 @ 08:59:
Niet eenvoudiger van server 1 uit de dfs te zetten.
De bestanden te verwijderen en de opnieuw te configureren zodat server 1 al de data uit server 3 haalt zonder conflicten.

Ja, ik vrees het ook dat het beter is DFS gewoon opnieuw op te zetten. Nu is alles verkeerd gegaan, veel bestanden zijn van server03 (oude files dus!) overschreven op server01 (welke nieuwere bestanden had), nu alles terug zetten van shadow copies en backup van gisteravond. Drama