Thursday, December 27, 2007

Recovering data from a HP Media Vault

I had a customer bring in a drive from a HP Media Vault that had failed (or flaked out or something, we're really not sure yet). It was kind of interesting trying to find data on the drive, so I thought I'd share...

First, the drive obviously didn't have a standard PC partition table.
# fdisk -l /dev/hdi

Disk /dev/hdi: 300.0 GB, 300069052416 bytes
255 heads, 63 sectors/track, 36481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/hdi doesn't contain a valid partition table

I should note that I tried testdisk at this point too, but it didn't find anything. Next, I checked for anything recognizable at the beginning of the disk.
# dd if=/dev/hdi count=8 | strings
Broadcom NAS Version 1.1 MBR Tag
SYSTEM
8+0 records in
8+0 records out
4096 bytes (4.1 kB) copied, 0.00013262 s, 30.9 MB/s

After a little Googling for "broadcom nas", "hp media vault", and a few other things, I figured out there was a reiserfs filesystem on the thing somewhere. (Note: As pointed out in the first comment to this post, there is some great technical documentation on this thing online. Rather than follow it, I chose to cheat and do this the (relatively) easy way.) Google found me this nice document describing the on-disk structure of reiserfs. That's how I figured out that I was looking for a magic string "ReIsEr2Fs" (or "ReIsErFs" for version 1, or "ReIsEr3Fs" for version 3, according to some other search results). I used hexedit to find the offset of the magic string by doing hexedit /dev/hdi, hitting tab, hitting /, then typing in ReIsEr.
2685A020   84 03 00 00  1E 00 00 00  00 00 00 00  00 10 CC 03  06 00 01 00  52 65 49 73  ....................ReIs
2685A038 45 72 32 46 73 00 00 00 03 00 00 00 05 00 B7 08 02 00 00 00 CC A3 00 00 Er2Fs...................

In this case, the magic string was at hex location 2685A034, which means the beginning of the superblock was at 2685A000, or (decimal) 646291456 bytes. The beginning of the superblock is 64k bytes before that, so I set up a loop device there:
# losetup -o $[ 646291456 - 65536 ] /dev/loop0 /dev/hdi
# mkdir /mnt/tmp
# mount -r -t reiserfs /dev/loop0 /mnt/tmp

The files my customer needed were in /mnt/tmp/FileShare/.

7 comments:

Lee Devlin said...

Hi Steve,

Nice work! I was the Systems Architect for that product and this topic comes up periodically. I also maintain a FAQ and Yahoo Group for the Media Vault. The superblock is unique but the file system is plain Reiserfs. I have the complete documentation for the disk layout here:

http://www.k0lee.com/hpmediavault/diskformat/index.html

Good job on recovering the data with a standard Linux system.

Joe McVety said...

Steve, wonder if you feel like being a hero? I recently had the same thing happen to my MV2010 media vault. I am desperately trying to duplicate what you did using knoppix. I found the ReIsEr string and tried to mount it, the drive reads for along time, then it says "cant read superblock". I searched for the next instance, calculated the new offset, same message. Any ideas?

PoliticAl2008 said...

Excellent Job.

Here is how I used your instructions with my MV drive in a USB housing connected to a laptop booted from Ubuntu CD:


1. Get an Ubuntu boot CD (I'm using 8.04 beta)
2. Boot from CD into Ubuntu, making sure the MV drive is in a USB housing and already connected to the system
3. System -> Administration -> Software Sources
* Check Community-Maintained Open Source software (universe)
* Click Close
* Click Reload
4. Applications -> Accessories -> Terminal
* Type: sudo apt-get update && sudo apt-get install hexedit
5. Get into hexedit for /dev/sdb
* Type: hexedit /dev/sdb
6. In HexEdit, search for ReIsEr
* Hit the Tab key (Toggles to the ASCII column)
* Hit Ctrl-S (puts you in search mode)
* Type: ReIsEr
* Hit ENTER
7. When you find the line (ex. 1E859830), change the last two digits of the line number to 00 (ex. 1E859800).
8. Convert Hex to Decimal (ex. 512071680)
9. Mount it up (loop0 was already taken on my system, so I moved to loop1)
* Type: sudo losetup -o $[ 512071680 - 65536 ] /dev/loop1 /dev/sdb
* Type: sudo mkdir /mnt/tmp1
* Type: sudo mount -r -t reiserfs /dev/loop1 /mnt/tmp1


You should now be able to see contents on /mnt/tmp1

Apex said...

The step with the loop device can be skipped:
mount -t reiserfs -o ro,loop,offset=512006144 /dev/sdb /mnt/tmp1

With that trick one could even put it in the /etc/fstab

James said...

I tried following the examples given, but keep getting a "permission denied" message.

Any ideas?

Tre said...

I just lost all my data from my HP MV2040. I just decided to send it to a data recovery specialist and they are also having a little difficulty retrieving the data while keeping the file directory structure intact.

Brief history: mv2040 setup in raid 1 config with two 500gb sata drives. I purchased a new 1tb internal drive for my desktop to have an additional backup to the backup.

I first tried to copy the data from the media vault to the 1tb drive on my pc, but kept receiving errors. This is when the nightmare began...........

I took it upon myself to take the mirrored drive out of the vault and connect it to my xp pro desktop to perform a ghost. Windows recognized the drive and tried to initialize it. I cancelled it and return the drive back into the vault. I guess the vault tried to rebuild the mirror or something. In any case I am now not able to access my data. I reset the vault and also reloaded the source drive with the vaults OS (nasloader)

The vault can now boot and all is well except I cannot find my 270GB's of data.

Just imagine losing your entire company's data :(

This is the boat we are in.

The data recovery team reported to me today and said they can see the data but the directory structure seems to be lost or overwritten. It is just a ton of files without their original filenames and directories. I will spend at least a year opening up all the files we had just to rename them and place them in a new directory.

Any ideas for me to tell the data recovery team?

Tre
2404321252
tparks@comptroub.com
www.ctbowie.com

OfurMatt said...

Thank you sooo much... you saved my life. I managed to get my entire company's data back plus all my music.