3

We have an instance where some how a 1tb volume has become corrupted. There are Event ID 55 errors in the system event viewer. When running chkdsk, it gets to 47% verifying indexes and returns to the command prompt.

If we are unable to rescue the data on the drive then we have a full backup of the databases from some time ago. The logfiles of which are on a different volume which is intact.

Would it be viable to restore the databases and somehow replay the log files? I have seen articles about replaying logfiles from a logfile backup (.trn), however we have the actual logfiles (.ldf) Any help would be appreciated.

p.campbell
  • 4,407
  • 6
  • 41
  • 51
  • By all means keep this on SF but given this isn't really a server problem, more just a corrupt disk issue, you might be better asking this on superuser instead/as-well ok. – Chopper3 Mar 05 '10 at 11:24

3 Answers3

1

To restore you need:

  • A full DB backup
  • All log backups since then

Log files only do not contain any data as such. You may be able to reply if you have FULL recovery model and the log has never been truncated (etc) since the last FULL backup.

However, the chances are you have lost data because you have no backups to recover from. No amount of 3rd party trickery will help.

gbn
  • 6,079
  • 1
  • 18
  • 21
0

In my experiences trying to test kind of thing out, no. When trying to do something similar to this I would receive an error message saying that the .ldf is incorrectly formed. No matter what I did I couldn't find a method to do this that comes standard with SQL Server.

I believe there are third party tools out there that can read through the log files to help recover your data for you. I've never used one so I don't want to offer a recommendation but this may be your best option to get the data back.

Shane
  • 1,869
  • 4
  • 20
  • 34
0

It depends on how badly damaged the drive is. We have used Stellar Phoenix & R-Studio for recovery, R-Studio seems to be more effective. Both apps manually read the drive and try to recreate files from what they find. The recovery process may not recover the file names and directory structure so it can be very time consuming to review the recovered files and find what you need.

If the app is not able to physically read part of the drive then whatever is located there will be not be recovered. At that point the next option is sending the drive to a data recovery service. We have used DriveSavers but there are many others out there.

With SQL, unless the recovered files are from a db backup it is likely that they are in an inconsistent state which may require other manipulation to get the data out. I can't comment on that process, beyond my expertise.

Ed Fries
  • 1,619
  • 2
  • 12
  • 14