It is difficult to say what may have happened with your vague description, and which may not be accurate. You say that the transactions were committed, but how do you know that they were? Furthermore, I am not familiar with Macruim.
But I can think of two possibilities:
- The transactions were in fact not committed, but Macruim clinged to an open transaction, and therefore everything was rolled back when the server was restarted.
- Someone restored a backup and applied logs and for some reason stopped at 17:26.
On the other hand, Macruim did not "lock the MSSQL file" - that can't be done.
I make some other observations in the file which calls for attention (beside the ones you have already pointed out):
- They are on SQL 2017 RTM. They should apply CU22 which is the latetest cumulative update.
- Look at the message 11:16:45. That is bad for performance and everything else. Maybe SQL Server should have Lock Pages in Memory. Or you should set max server error, if there are other applications on the machine.
- And 14:21:06 there is another warning sign - I/O should not take 15 seconds, not even on a spinning disk.