Please see the below snapshot, showing the timestamps of all the data files as well as transaction log files for one of the SQL Server instances under my management. This is a production instance.

enter image description here

Today is Dec 27th, 2019. However, as you can see, all the timestamps are showing much older times.

The truth is, I took this snapshot a few days ago on 24th Dec. However, as I checked today, the situation is still unchanged.

The snapshot above was taken from the user databases. I checked the system databases as well, which are residing on a separate drive, and took the snapshot of the files' timestamps, which were as shown below:

enter image description here

These databases are certainly not super active. But, I am certain that there are transactions running all the time. Additionally, I looked at the "Schema Changes History" report for a few of them, and could confirm that our maintenance jobs have been working and rebuilding indexes in as recently as yesterday 26th Dec.

The databases are all in FULL recovery model (although that may not be relevant - just a fact to mention). The OS is Windows NT 6.0 (= Windows Server 2007) and SQL Server version is 2008 SP3. Both the OS and SQL Serve are due for upgrade next year Q1. Also as is evident from the above snaps, with data files and log files both residing in the same disk drive and folder, the configuration of this server which I have "inherited" is certainly not the best. So, hopefully all will be fixed during the planned upgrade/migration activity which is going to happen in a few months.

Now the question for me is why the timestamps of these files are not getting updated, despite the databases being active anyway? (even manually running of Checkpoint didn't change anything). and then, if the transaction log files are not getting updated, will the backups be good and reliable? Do they really contain the records that they are supposed to?

  • the modified date only changed when the mdf / ldf files are closed. Not when transactions are inserted / updated.
    – Squirrel
    Commented Dec 27, 2019 at 9:01
  • @Squirrel Is that a feature of Windows or is it something specific to Sql Server? I always thought whenever a file gets changed, its attributes are changed, too, without needing to close the file handle (similar to how a word processor application works)
    – RGO
    Commented Dec 27, 2019 at 9:07
  • 2
    SQL Server keeps the database files open whenever it’s running, for better performance and protection against other processes changing them. So the attributes don’t get changed on every file write. Commented Dec 27, 2019 at 15:12

1 Answer 1


In answer to your main question ("what is being backed up"), everything that is supposed to be 😀 More seriously, you can't use those time stamps as a sign of changes happening in the database files. SQL Server doesn't make any guarantees about how the modified date of database files will be changed or updated.

There is an interesting blog post here that attempts to find patterns with when and how the date modified stamp is updated on MDF files:

SQL Server Database File - Date Modified

Their observations line up with your situation I think: normal writes to the data file don't update the date modified stamp. It looks like growth events (manual or automatic) would update that value, as would restarting the service (or anything else that might "open" or "close" a database - using the autoclose feature, explicitly taking the DB offline, etc).

I expect 19/12/2019 9:52 PM corresponds with a Windows or SQL Server restart, which is how several of the date / times got sync'd up.

However, again, this behavior is undocumented. Any patterns we notice could change at any time, or have unexpected edge cases.

For SQL Server data files residing on an NTFS file system, this applies:

The only guarantee about a file time stamp is that the file time is correctly reflected when the handle that makes the change is closed.

Though, to be clear, that's a guarantee provided by Windows. We can't necessarily know a ton about how SQL Server creates and destroys file handles in every scenario.

David Browne (a Top Microsoft Man) mentioned this in a comment, which is useful to know:

SQL Server keeps the database files open whenever it’s running, for better performance and protection against other processes changing them. So the attributes don’t get changed on every file write.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.