Restore partial data from single file of SQL Server Full Strip Backup

Question

I don't know if I ask for something possible, but here is my problem:

We had a disaster (virus) in our SQL Server Database and we lost all the information and backups.

The only backup remaining is a single file of a Full Backup in strip mode (the one that splits a single backup in multiple files).

Logically, when I try to restore the database using that file I get the error:

The media set has 2 media families but only 1 are provided. All members must be provided

Is there any way to recover some partial information from that piece of the backup? either using SQL or third party software.

Even if I just manage to get some information of a single table it would be more than none.

• Henrik Staun Poulsen: could you provide the results of a RESTORE HEADERONLY, as per msdn.microsoft.com/en-us/library/ms178536.aspx ?
• Albert: @Henrik, I have uploaded a file containing them here: restore headeronly txt file
• Henrik Staun Poulsen: I think this tread explains it all: stackoverflow.com/questions/12224745/…
• Albert: Thanks @HenrikStaunPoulsen, I was aware of the problem and in a way it is the same situation that I am going through. Sorry I couldn't find the thread you pointed. I was hoping to recover some information but I guess there's nothing I can do. Thanks anyway!

Answer 1

There is no way to recover a transactionally-consistent database from only half of the backup media set.

The problem is that, while a full backup contains the data file, there is also a portion of the transaction log, at the end of the backup file, to ensure the restored database is transactionally consistent.

Even if you did manage to recreate portions of the MDF file from this backup, you would still be missing the transaction log that rolls back in-flight transactions and rolls forward completed transactions that took place after the backup started.

Making matters worse, if the striped backup is written out as interleaved files (which I believe it is), you'd have one out of every two 8KB data pages, and a corrupted log at the end. There's no functional way of establishing any consistency with this kind of recovery.