FILE MDF repair

[sempre]

Hi to all!

I have this file to repair and it I have in a good result of the repair, open in file with winhex and perceived that from page 2.374.735 it has in it date ties end 82098334, this file was copied by the customer before hd burning heads….

This file cannot be recovered…?

Attachments

[beto]

Hello sempre
Like u can see the file doesnt has code "sectors" u need to find why, maybe that zone its damaged and the system jump that sectors (head)

Regards

[wiseleo]

My question is what happened to the companion LDF?

If this is a SQL MDF and you have a companion LDF, you can do some magic. If it was ever backed up and you have an intact LDF for the period from last backup, you can recover it to the point of failure using that ancient backup.

[sempre]

My question is what happened to the companion LDF?

If this is a SQL MDF and you have a companion LDF, you can do some magic. If it was ever backed up and you have an intact LDF for the period from last backup, you can recover it to the point of failure using that ancient backup.

Yes file SQL, yes file LDF, no backups!!

[sempre]

Hello sempre
Like u can see the file doesnt has code "sectors" u need to find why, maybe that zone its damaged and the system jump that sectors (head)

Regards

Thanks your reply! (Beto)

[wiseleo]

My question is what happened to the companion LDF?

If this is a SQL MDF and you have a companion LDF, you can do some magic. If it was ever backed up and you have an intact LDF for the period from last backup, you can recover it to the point of failure using that ancient backup.

Yes file SQL, yes file LDF, no backups!!

OK, if the LDF is intact and the MDF file was never backed up, that would explain why MDF does not have much data in it. SQL database files have pre-allocated empty space at the end. Do some research into SQL data recovery and you'll see why this makes sense. In this case, the lack of a backup is a good thing.

One thing you can try is to attempt to attach both the MDF and the LDF to a SQL server instance. Obviously you as a recovery professional would be working with copies, but for anyone else who finds this message in the future: ONLY WORK WITH COPIES OF THESE FILES. The LDF file changes when you attach it to an instance.

[sempre]

My question is what happened to the companion LDF?

If this is a SQL MDF and you have a companion LDF, you can do some magic. If it was ever backed up and you have an intact LDF for the period from last backup, you can recover it to the point of failure using that ancient backup.

Yes file SQL, yes file LDF, no backups!!

OK, if the LDF is intact and the MDF file was never backed up, that would explain why MDF does not have much data in it. SQL database files have pre-allocated empty space at the end. Do some research into SQL data recovery and you'll see why this makes sense. In this case, the lack of a backup is a good thing.

One thing you can try is to attempt to attach both the MDF and the LDF to a SQL server instance. Obviously you as a recovery professional would be working with copies, but for anyone else who finds this message in the future: ONLY WORK WITH COPIES OF THESE FILES. The LDF file changes when you attach it to an instance.

Ok, already I used these tools to repair of file: Repair for Kernel, officerecovery2008, and outhers....

not recovered one of tables most important of database...

all help and well coming...

[wiseleo]

What happens if you try to attach to a SQL Server instance?

There shouldn't be a need to run recovery tools on this file.