Forum Discussion

Junwoo_Jo's avatar
Junwoo_Jo
Copper Contributor
Aug 24, 2025

SQL Server 2019 – Repeated Recovery Mode and Backup Failure After Server Shutdown

Hello, We are currently using SQL Server 2019 Standard Edition in our company.

Recently, our server experienced a complete shutdown due to a lightning strike. After the incident, one of our databases entered Recovery Mode, and it took approximately one hour before it returned to normal operation.

The issue is that this behavior repeats every time we restart SQL Server. In other words: Server restart → Database enters Recovery Mode → Returns to normal after about one hour.

Additionally, we are unable to perform backups on this database. Based on the SQL Server error logs and Windows Event Viewer, it appears that the backup attempts fail because the database has not completed recovery at the time of execution.

We would like to ask for guidance on the following points:

  • Could this issue be related to physical damage or disk corruption?
  • Is there a way to prevent the database from entering Recovery Mode, or at least speed up the recovery process?
  • Besides running DBCC CHECKDB, are there any other diagnostics or recovery strategies we should consider?

Additional Information:

  • SQL Server 2019 Standard Edition (on-premises)
  • The affected database is running on a single instance
  • We attempted to copy only the MDF file to another server and recover the database, but this also failed

Thank you in advance for your support.

3 Replies

  • ajinaniyan's avatar
    ajinaniyan
    Copper Contributor
    Sep 10, 2025

    It sounds like SQL Server is running crash recovery on every restart, which is why the database stays in “In Recovery” for about an hour and backups fail until it finishes. This can often be caused by corruption or disk-level issues after the shutdown. You can check the database state first:

    SELECT name, state_desc, recovery_model_desc 
FROM sys.databases WHERE name='YourDB';

    Then run an integrity check:

    DBCC CHECKDB('YourDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;

    If corruption is found and you cannot restore from a good backup, you can attempt repair (last resort):

    ALTER DATABASE YourDB SET EMERGENCY;
DBCC CHECKDB('YourDB','REPAIR_ALLOW_DATA_LOSS');
ALTER DATABASE YourDB SET ONLINE;

    Always back up the MDF/LDF files before running repair. If CHECKDB cannot resolve safely, you may need a dedicated recovery tool like Stellar Repair for MS SQL. Also, review your storage hardware because repeated recovery often indicates underlying I/O issues.

  • Javier_Villegas's avatar
    Javier_Villegas
    MVP
    Sep 01, 2025

    I believe you must do a DBCC CHECKDB to evaluate if there is a problem with the database

    if it comes back with no error, probably the DB is going to recovery because there are long running DML sessions running when server get restarted so it requires long time to recover. you can consider to enable Accelerated Database Recovery (ADR) on that specific database https://learn.microsoft.com/en-us/sql/relational-databases/accelerated-database-recovery-concepts?view=sql-server-ver17 

  • SivertSolem's avatar
    SivertSolem
    Iron Contributor
    Aug 26, 2025

    When attempting to move the database by copying the MDF (data) file, did you remember to also copy the ldf (log) file?

    In my experience, all files used by the database are required in order to attach it to a different server.

     

    This T-SQL Query will print out the location of files related to each of the databases on your instance.

    SELECT d.name DatabaseName, f.name LogicalName,
f.physical_name AS PhysicalName,
f.type_desc FileType
FROM sys.master_files f
INNER JOIN sys.databases d ON d.database_id = f.database_id
GO

     

Resources