Media Vault (MV1) Disk Layout
This page refers ONLY to the MV Generation 1 products. The MV2 products are completely different. The disk format used inside the HP Media Vault (MV1) is based on a reference design from Broadcom. Broadcom uses the term 'pool' where HP uses the term 'volume'. This pool technology resembles a Logical Volume Manager, but it is unique and thus until recently was not recognized existing disk recovery tools. In October, 2010, we were informed by several MV owners Yahoo Group that they had luck with a general purpose Windows data recovery program available from CNW Recovery. CNW has recently added a feature to recover MV1 drives. This program is free to download in 'demo' mode and if you are able to see your files, the odds are pretty good you can recover them. The demo version of the program won't allow you to write the files to another drive. For that you need a licensed copy. A 30-day licence costs $19.99 and a permanent license costs $34.99 for individual users.
Listed below are links to a document and source code that will help to shed some light on this format. This information has been provided with written permission from Broadcom.
All files listed above in zip format.
With this information it would be possible to write a utility for a Linux system or PC that could be used to recover data from a Media Vault disk should it be necessary.
Steve Pritchard has a blog entry on how to use basic Linux tools to mount the reiserfs file system from a Media Vault drive on a standard Linux system to recover its data.
I've included the content of the blog posting below. I wanted to make a few comments here for those who may not be that familiar with Linux. Some of the commands may require superuser privileges. You can do that by typing 'sudo su' to put yourself in superuser mode, although some Linux people frown on that method and instead recommend using the 'sudo' command in front of any command that requires superuser privileges. You will need to know the superuser password. If you get an error or an unexpected response when typing any of the commands as shown in the blog posting, you can try preceding the command with 'sudo', for example, instead of typing 'fdisk', you'd type 'sudo fdisk'. It will ask you for the superuser password once and then not again for the rest of that session. Also, in the section that discusses the hexedit program, the command 'tab', which toggles between hex and ASCII can be substitued with "<Ctrl> t" and the '/' command which means 'search', you can use <Ctrl> s. I found it necessary to do this when I was using hexedit because the <tab> and '/' did not always work.
I also found it necessary to install the hexedit program on my Ubuntu Linux system since it wasn't on there as part of the regular install. You can do that with 'apt-get':
sudo apt-get update
sudo apt-get install hexedit
The Media Vault drive is a SATA drive and I've found it helpful to use a SATA-to-USB interface, because it allows you to hot swap the drive on a standard Linux system without the need to reboot. When you connect the drive via USB, there may be some indication at the end of /var/log messages to help you locate it. You can look at the last few lines added to that file with this command:
tail /var/log/messages
Whereas Steve's system had the drive appear at /dev/hdi, I've generally found the drive to appear at /dev/sdb on systems where I've tried it.
Here is Steve's blog posting:
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/.
The default locations for an MV1 are generally located here:
Internal MV1 SYSTEM disk - first data partition offset: 646225920
Internal MV1 Disk1 disk - first data partition offset: 512006144
External MV1 (USB) disk - first data partition offset: 5120
If you are feeling lucky, you can just substitute one of those numbers in place of the "$[ num - 65536]" string depending on whether you're trying to mount the system drive, the mobile rack drive (Disk1) or a USB drive formatted with a native Reiserfs format. If you've been adding Volumes to the drives, then it would be best to skip down to the section below that describes a C program Gerard wrote that dumps the starting locations of all the volumes on a drive.
I received a message from Pete Nevill who was having trouble getting the drive to mount, so he wrote a script that automatically tried to find the beginning of the block with a script. Here is his email with the script attached:
Not being smart enough to know where the begining of the block was on the drive I decided to use the brute force approach. I found the byte potion of the letter R using the above method, for me that was hex "1E859834" using the following site http://www.easycalculation.com/hex-converter.php converted to "512071732". I then wrote a short shell script that used that as a starting point tried to mount the drive if it failed increment by -1 until success, code below. Worked for me I hope others find it useful.
#!/bin/bash
i="0"
while [ $i -lt 80 ]
do
losetup -o $[ 512071732 - 65536 - $i] /dev/loop0 /dev/sdb
mount -r -t reiserfs /dev/loop0 /tmp/tmp
if (( $? )); then
{
echo "could not mount";
losetup -d /dev/loop0
}
else
{
echo "mounted using byte position: $[ 512071732 - 65536 - $i] ";
exit;
}
fi;
i=$[$i+1]
done
Gerarad Robinson wrote a c program that finds the locations of all the partitions by looking in the boot block of the drive. This boot block is described by the 'pool structure' document linked to the beginning of this page. He has the program as well as the README file and instructions on how to use it here. This may be easier for people with Linux background who know how to compile and use a C program. It also may allow you to see beyond the first partition, since the hex editor approach is generally only good for finding the first partition. This program also depends on the boot block not being corrupted.
Return to the HP Media Vault FAQ
This web page has had 9473 visits since Sept 25, 2009.
Return to Lee Devlin's Home Page