DFSR Jet DB crash after ransomware sim (500k files) clearing dirty shutdown without reseeding

Question

I just ran a ransomware simulation tool that modified file extensions on 500,000 files in our replicated DFSR share. It caused the DFSR database (Jet/ESE) to crash from transaction log space exhaustion, and the share is now stuck in a dirty shutdown state.

I need to bring replication back online, but I really want to avoid a full content re-seeding.

is there a safe procedure to recover the database without triggering a complete sync?

Answer 1

Welcome to Microsoft Q&A!

Thank you for providing the detailed information.

Yes, if the DFSR Jet (ESE) database entered a dirty shutdown due to transaction log exhaustion, you should first attempt database recovery rather than rebuilding the replicated folder. A dirty shutdown by itself does not automatically require reseeding. The objective is to recover the DFSR database while preserving the existing replication state.  

I would like to provide you a recommended recovery approach is:

1. Verify that the underlying issue has been resolved (for example, confirm adequate free disk space is available and that the ransomware simulation activity has stopped).
2. Review the DFS Replication event logs for database-related events, such as Event ID 2213, ESENT errors, or database recovery failures.
3. If DFSR reports a dirty shutdown, allow DFSR's built-in recovery process to run. On supported Windows Server versions, DFSR can often recover the database without rebuilding replication state.
4. If automatic recovery does not occur, follow the documented Event ID 2213 recovery process to resume replication after consistency checks, rather than deleting the database.
5. Consider deleting the DFSR database and performing a non-authoritative synchronization only as a last resort, as this can trigger reinitialization and generate a large replication backlog.

Important: Avoid performing unsupported ESE repair operations, such as running esentutl /p, unless specifically directed by Microsoft Support. Hard repairs can result in DFSR metadata loss and may ultimately require database reconstruction or additional recovery work.

For a scenario involving approximately 500,000 file renames or modifications generated by a ransomware simulation, the safest approach is to:

• Recover the DFSR database in place.
• Resume replication using the appropriate DFSR recovery procedure.
• Allow DFSR to process the resulting backlog.

As long as the database remains recoverable and the replicated data is intact, a full content reseed is generally not required. Reseeding is typically necessary only when the DFSR database cannot be recovered or when replication metadata has been corrupted beyond recovery.

For the next steps, please check whether the DFS Replication log contains Event IDs 2213, 2104, 2004, or any specific ESENT errors. The exact events will help determine whether a simple database recovery and resume operation is sufficient, or whether more extensive recovery steps are required.

If the information provided is helpful, please click Accept Answer.

Thank you for choosing Microsoft Q&A!