Help! Trying to recover data from a failed Seagate 2-bay NAS

[beaterrr]

I'm a veteran noob linux user, so here's what I know from hours of scanning forums. The filesystem is EXT4, 'LVM2_member'...following http://pissedoffadmins.com/os/mount-unk ... ember.html thread got me very close. All the way to the end where doing an

Code: Select all

# lvscan

returns the logical volume as ACTIVE. However, when trying to mount the volume I get this error...

"mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg8-lv8, missing codepage or helper program, or other error
In some cases useful info is found in syslog - try dmesg | tail or so"


mike@titan-ubuntu:~$ dmesg | tail
[ 3663.834090] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 3663.834104] 00 00 08 18
[ 3663.834111] sd 0:0:0:0: [sda]
[ 3663.834115] Add. Sense: Unrecovered read error - auto reallocate failed
[ 3663.834120] sd 0:0:0:0: [sda] CDB:
[ 3663.834122] Read(10): 28 00 00 00 08 18 00 00 08 00
[ 3663.834138] end_request: I/O error, dev sda, sector 2072
[ 3663.834162] ata1: EH complete
[ 3778.418844] EXT4-fs (dm-0): bad block size 65536
[ 5576.265194] EXT4-fs (dm-0): bad block size 65536
mike@titan-ubuntu:~$

mike@titan-ubuntu:~$ uname -a
Linux titan-ubuntu 3.13.0-32-generic #57~precise1-Ubuntu SMP Tue Jul 15 03:51:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[Mijzelf]

The disk has a hardware problem

[ 3663.834138] end_request: I/O error, dev sda, sector 2072

sector 2072 is unreadable, and apparently crucial for the filesystem.

This is not raid1, I guess? If it is, you can try to assemble the array with only sdb. Else your best bet is to create a low level copy from /dev/mapper/vg8-lv8 to a 3th disk, using dd_resque, and try to repair/mount that.

[beaterrr]

Thanks for your reply! I decided on option 2 (ddrescue) figuring that would be the best option just in case it doesn't work and I need to do the unthinkable, get a data recovery service involved..... $$$. After, some searching and reading, I was able to get the copy started. By the looks of the speed, it will be at least a day before it's complete...not complaining though! Especially if it works. Thanks again, I'll keep you posted.

Also...I read in the ddrescue info about option "-D" Use synchronous writes for output file. May be useful when forcing the drive to remap its bad sectors. ...I used it. Good or bad idea?

[Mijzelf]

Good or bad idea?

Don't know. This is about the destination disk, which is supposed to be good, so I think it will only slowdown the writing a bit. But when using ddrescue it's not the writing which consumes the time. It's the reading. An attempt to read a bad sector can take several dozens of seconds. So if you have hundreds of them...

Where did you find the manual? I'm aware of 2 different programs, ddrescue and dd_rescue. Two different programs with different syntax but with the same purpose. And coincidently for both -D means the same: use unbuffered writes to the destination disk. None of them talks about remapping bad sectors. Actually I don't think there is a difference between buffered and unbuffered writes, when it comes to remapping. From the point of view of the disk there is no difference between them.

[beaterrr]

Where did you find the manual?.

Code: Select all

mike@titan-ubuntu:~$ info ddrescue

Initial status (read from logfile)
rescued: 1996 GB, errsize: 1396 kB, errors: 39
Current status
rescued: 1996 GB, errsize: 1396 kB, current rate: 0 B/s
ipos: 0 B, errors: 39, average rate: 0 B/s
opos: 0 B, time from last successful read: 0 s
Finished


Soooo...I'm stuck. My ddrescue copy has finished and I don't see it and I'm confused on how to proceed. This is how I ran the command:
mike@titan-ubuntu:~$ sudo ddrescue -b 8192 -f -n -D /dev/mapper/vg8-lv8 /dev/sdb2 logfile



/dev/sdb2 being an external usb 3TB hardrive that I recently purchased specifically for this situation. After, i little more research, I found that it is best to define a name for the data being rescued like /dev/sdb2/data.img. So I was going run the process again, giving it a name but ddrescue see it as complete and won't let me re-run it. I assume the logfile (location?) is what's keeping me from starting over. The other confusing aspect is that when running df -h, the stats don't reflect that I have just copied around 2TB of data into it?

mike@titan-ubuntu:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 83G 2.9G 76G 4% /
udev 2.9G 4.0K 2.9G 1% /dev
tmpfs 597M 1.1M 596M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.0G 332K 3.0G 1% /run/shm
/dev/sda1 100M 28M 73M 28% /media/System Reserved
/dev/md5 9.6M 7.9M 993K 90% /media/2ea71d70-be22-4993-8877-77c0aae31e09
/dev/sda2 196G 194G 2.2G 99% /media/B2008CFA008CC6B7
/dev/sda3 311G 224G 88G 72% /media/8080DC1D80DC1B8A
/dev/sdb2 2.8T 152M 2.8T 1% /mnt/myRescue


Please advise

[Mijzelf]

First, likely the logifle is in the directory where you executed the command. That will probably be /home/mike.

About the 2TB data, you didn't copy data, you copied a defective filesystem. I can think of at least 2 scenario's how you have an almost empty disk now.

• The disk contained a mounted, empty, filesystem before you began, and you didn't unmount/remount it after you finished. In that case you are looking at the cached old filesystem. The filesystem is exchanged behind the OS' back.
  If that is the case unplug the disk without unmounting it. Every attempt to write to the old filesystem is a hazard for the new one.
• The disk is mounted now, which means the ext4 driver repaired that defective sector. (A copy of an unreadable sector contains bogus. In case of ddrescue zero's, I think. Possibly that sector pointed to the rootdirectory, or something like that, in which case all files are there, you only can't reach them. Have a look in /var/log/messages (or dmesg) to find the kernel log about that mounting/repairing. (If your box runs systemd, you can try journalctl)

When you are facing an damaged filesystem you can try TestDisk to recover it. (On the copy, created with ddrescue, of course)

[beaterrr]

Hi, it's me again. I had to take a break to try and regain my sanity. Now I'm back for more punishment...kiddding...I want this win. Now, After scouring the net for proper usage of Testdisk, I haven't been able to figure it out. I apologize for my noobiness but I'm going to show you what I have done thus far in hopes that you can give me a more comprehensize plan of action. Running Testdisk with:
-No log
-[EFI GPT] EFI GPT partition map (Mac i386, some x86_64...)

Gets me to this point below, but I don't really understand what to make of this or how to proceed.

Code: Select all

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - 3000 GB / 2794 GiB - CHS 364801 255 63

     Partition                  Start        End    Size in sectors

 1 P MS Data                   264192 5860532223 5860268032













 [  Quit  ] >[Deeper Search]  [ Write  ]
                          Try to find more partitionsmike@titan-ubuntu:~$ 

Also, found info on mounting the fiesystem direct, from the *.img using the method below:

Code: Select all

mike@titan-ubuntu:~$ sudo parted /media/508299B3520D7A95/vaultRescue.img
[sudo] password for mike: 
GNU Parted 2.3
Using /media/508299B3520D7A95/vaultRescue.img
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit
Unit?  [compact]? b                                                       
(parted) print                                                            
Model:  (file)
Disk /media/508299B3520D7A95/vaultRescue.img: 1996039913472B
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End             Size            File system  Flags
 1      0B     1996039913471B  1996039913472B  ext4

(parted) quit                                                             
mike@titan-ubuntu:~$ sudo mount -o loop,offset0B /dev/sdb2/vaultRescue.img /mnt/myRescue
/dev/sdb2/vaultRescue.img: Not a directory

Another bit of information is after speaking with a buddy, he's convinced that my NAS was RAID5 and not RAID1 as I had beed thinking this whole time.

[Mijzelf]

proper usage of Testdisk (...) but I don't really understand what to make of this or how to proceed.

It should be something like this.

mounting the fiesystem direct, from the *.img

The command in this case should be

Code: Select all

mount -o loop /media/508299B3520D7A95/vaultRescue.img  /mnt/myRescue

That 'offset' part can be added, but doesn't do anything as 0 is the default.

You can also check/repair the filesystem in the files

Code: Select all

e2fsck /media/508299B3520D7A95/vaultRescue.img

or

Code: Select all

testdisk /media/508299B3520D7A95/vaultRescue.img

Side effect of the 'everythink is a file, even if it isn't a file' philosophy. If a partition is actually a file, then a file can be treated like a partition.

Here you can read about other recovery techniques

Another bit of information is after speaking with a buddy, he's convinced that my NAS was RAID5 and not RAID1 as I had beed thinking this whole time.

Nope. If it's a 2 disk NAS it cannot be RAID5. RAID5 needs at least 3 disks.

[beaterrr]

Thanks for all your help, I'm just about ready to throw in the towel. This part of the game is just well beyond my level of understanding and expertise. To make a long story short, in the process of running Testdisk and other tools, I have downgraded my filesytem to an "EXT3", then again to an "EXT2". I was finally able to mount the filesystem but ZERO files show up. It's looks like a brand new partition. I'm leaning towards re-imaging the original disk once again and starting over, but not before I have better understanding and grasp of what to do with it next.