Datavolume doesn't exist ! message

[Nathan_H]

Use our Windows Data Lifeguard Diagnostic tool to write zeros to the drives.  You'll have to do the Full Erase and it will take some time.  In any case, once the drives are entirely zeroed out, you can put them back into the ShareSpace and turn it on.  It will take a few hours for the ShareSpace to rebuild itself but once the green light stops flashing you'll find yourself with a working unit.

Don't format the drives after you write zeros--just put them back into the ShareSpace and it will handle everything.

Last of all, congratulations on getting your data back!  That's never a sure bet (as you've found out) and I'm really happy you were able to find a company that performed successful recovery.  Please make sure to store your critical data in more than one physical storage device.  I would hate for you to have to go through this again.

Data Lifeguard Diagnostic for Windows

http://support.wdc.com/product/download.asp?groupid=608&sid=3&lang=en

[krisix]

Just a few word to thanks everyone in this thread cause i was able to access my DataVolume after many hours (days) of sweat...

and the worst of it is that i had power outage during the first try of recovering my data !

I just tried a second time but this time i use lvmr1 instead of lvmr and it works !! Many thanks to you all specially fibreiv.

Here's what i've done :

$ mdadm -D /dev/md2

$  mdadm --assemble /dev/md2 /dev/sda4 /dev/sdb4 /dev/sdc4 /dev/sdd4

$  pvcreate /dev/md2

$ vgcreate lvmr1 /dev/md2

$  lvcreate -l 714329 lvmr1 -n lvm0 (didn't work with 714329 just enter the value in the error message)

$  fsck.ext3 /dev/lvmr1/lvmr0

Here i-ve got more then 15000++ answers (!!!) to fix Inodes, directories...etc) just press enter key till the end like previous posters said.

$ mount -t ext3 /dev/lvmr1/lvm0 /DataVolume -o rw,noatime

and access your shares by UNC \\10.0.0.25 and copy your data.

good luck

[Mike_69]

I have the same issue only my drives are all showing as failed in disk manager (Storage > Disk Manager)

HDD 4 Unassigned 1.36 TB WDC WD15EARS-00Z5B1 Failed    
HDD 3 Unassigned 1.36 TB WDC WD15EARS-00Z5B1 Failed    
HDD 2 Unassigned 1.36 TB WDC WD15EARS-00Z5B1 Failed    
HDD 1 Unassigned 1.36 TB WDC WD15EARS-00Z5B1 Failed

I have even tried moving the drives to another sharespace with the same issue

Any ideas on what I can do to get the drives back online and get the data off

Tried SSH and got the following issue

 $ mdadm --assemble /dev/md2 /dev/sda4 /dev/sdb4 /dev/sdc4 /dev/sdd4
mdadm: /dev/md2 assembled from 2 drives and 1 spare - not enough to start the array.

[Mike_69]

WOW, WD phone support really has no idea. They say the only solution is data recovery by a third party. I really wouldnt buy another one of these drives, this is the second time I lost all my data on this crap device

[rofo2010]

Well, thanks Nathan_H for the instructions on how to completely clean the drives so that I can rebuild a new array. This worked and its now back up and running fine (for now).

I will NOT make the mistake again of confusing a RAID 5 for a backup. I now have my data stored on 2 completely separate items of hardware, and am still hurting from the cost of data recovery. If only WD could create something more than Diagnostics, like a proper recovery system or even a NAS that didnt cause so many headaches.... then I might recommend it to others. Overall, its a Thumbs Down to WD from me.

[Cohiba88]

Everyone,

I've suffered too much from the WD Sharespace running RAID5,  it failed on my almost once every 2 months and required a rebuild or a very time consuming recovery.  I now use Disk Striping and have not had an issue for almost a year now.  My issue was that a power cut would immediately break the raid5 and then an automatic rebuild of the drive would occur, taking almost a day.  In the case of disk striping, I assume that there is no inconsistency when the data is written and the power interrupted, so it just continues from there.

The proabability of a power cycle is much higher than the probability of a drive failure for me at least.

I still backup to another media just in case.

[Footleg]

Well, isn't this an interesting thread!

Can't say I'd had many problems with our 8TB device with RAID5, except for every month or two, it'd tell me one of the drives was missing, but SMART always showed it as good. Clean it, pop it back in and it'd rebuild no problem.

However, after it last happened and a discussion with WDC support, we decided to RMA the drive. The new 2TB disk duely arrived, popped it in and it started to rebuild.  THEN, shock horror, after the 60% complete message, it all went to poop and now I find myself with the "doesn't exist" issue - albeit slightly different circumstance to what others are seeing here.

After reading this and other threads carefully, I started down this path:

~ $ mdadm --assemble -f /dev/md2 /dev/sd[abcd]4
mdadm: forcing event count in /dev/sdd4(3) from 4283834 upto 4283840
mdadm: clearing FAULTY flag for device 3 in /dev/md2 for /dev/sdd4
mdadm: /dev/md2 has been started with 3 drives (out of 4) and 1 spare.
~ $ pvcreate /dev/md2
  No physical volume label read from /dev/md2
  Physical volume "/dev/md2" successfully created
~ $ vgcreate lvmr /dev/md2
  Incorrect metadata area header checksum
  Incorrect metadata area header checksum
  Incorrect metadata area header checksum
  Volume group "lvmr" successfully created
~ $ lvcreate -l 714329 lvmr -n lvm0
  Incorrect metadata area header checksum
  Logical volume "lvm0" created
~ $ fsck.ext3 /dev/lvmr/lvmr0
e2fsck 1.38 (30-Jun-2005)
fsck.ext3: while trying to open /dev/lvmr/lvmr0

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

fsck.ext3:

Despite it not looking good, it seems to be "recovering" something according to the mdadm detail output:

~ $ mdadm -D /dev/md2
/dev/md2:
        Version : 00.90.01
  Creation Time : Fri Apr  3 13:54:17 2009
     Raid Level : raid5
     Array Size : 5854981248 (5583.75 GiB 5995.50 GB)
    Device Size : 1951660416 (1861.25 GiB 1998.50 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 2
    Persistence : Superblock is persistent

    Update Time : Wed Apr 27 11:41:01 2011
          State : clean, degraded, recovering
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

 Rebuild Status : 13% complete

           UUID : b2c561ae:9acfcff0:2594d787:fb4eb047
         Events : 0.4283848

    Number   Major   Minor   RaidDevice State
       0       8        4        0      active sync   /dev/sda4
       4       8       20        1      spare rebuilding   /dev/sdb4
       2       8       36        2      active sync   /dev/sdc4
       3       8       52        3      active sync   /dev/sdd4

I guess I'll wait and see what happens, but not very optimistic right now.

If anyone has anything to contribute to my situation, please feel free to do so!

Thanks in advance.

[rofo2010]

I'm no expert at all (I ended up forking out for a professional recovery), but your situation looks OK to me....

Perhaps you made a typo at :

$ fsck.ext3 /dev/lvmr/lvmr0

perhaps should it have been :

$ fsck.ext3 /dev/lvmr/lvm0

Good luck!

[Pascald]

You are giving me hope, guys (lost 8T of data, Raid5).

I have created the partitions according to your useful feedback.

I am starting the file check but it seems to be getting forever (and only in Pass1). Is this normal?

After:

fsck.ext3 /dev/lvmr/lvm0

e2fsck 1.38 (30-Jun-2005)

Couldn't find ext2 superblocks, trying backup blocks...

ext3 recovery flag is clear but journal has data.

Recovery flag not set in backup superblock, so running journal anyway.

NASRAID: recovering journal

Pass 1: Checking inodes, blocks and sizes

... and it seems not to be moving anymore (30' already). Is this normal?

Regards,

[Footleg]

Well, it's not looking good.

Twice now it's failed during the rebuild process, leaving me with:

~ $ mdadm -D /dev/md2
/dev/md2:
        Version : 00.90.01
  Creation Time : Fri Apr  3 13:54:17 2009
     Raid Level : raid5
     Array Size : 5854981248 (5583.75 GiB 5995.50 GB)
    Device Size : 1951660416 (1861.25 GiB 1998.50 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 2
    Persistence : Superblock is persistent

    Update Time : Fri Apr 29 14:17:52 2011
          State : clean, degraded
 Active Devices : 2
Working Devices : 3
 Failed Devices : 1
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : b2c561ae:9acfcff0:2594d787:fb4eb047
         Events : 0.4283852

    Number   Major   Minor   RaidDevice State
       0       8        4        0      active sync   /dev/sda4
       1       0        0        1      removed
       2       8       36        2      active sync   /dev/sdc4
       3       0        0        3      removed

       4       8       20        -      spare   /dev/sdb4
       5       8       52        -      faulty spare   /dev/sdd4

Any suggestions (and thanks for the typo pickup earlier...)