Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I was recently hit by the AWS issues in Ireland, lost a volume, and need to attempt a recovery..

I've attached the problem volume to /dev/sdf -

I'm completely new to this, not entirely sure what's going on, but this doesn't look promising>>

> sudo fsck /dev/sdf
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdf

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 

When running fdisk -l /dev/sdf... I recieve>>

sudo fdisk -l /dev/sdf

Disk /dev/sdf: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

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

further information After running:

> sudo mke2fs -n /dev/sdf 
Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 

Can someone provide help, not much experience with running fsck.

Thanks in advance!

EDIT >> Found the answer:

> sudo mount -t xfs -o /dev/sdf /mnt/test-ebs
XFS: Filesystem sdk has duplicate UUID - can't mount
> sudo mount -t xfs -o nouuid /dev/sdf /mnt/test-ebs
mount: Structure needs cleaning
> sudo xfs_repair -L /dev/sdf
..
.
connected inode 9625284, moving to lost+found
disconnected inode 9625285, moving to lost+found
disconnected inode 9625286, moving to lost+found
disconnected inode 9625287, moving to lost+found
disconnected inode 17957583, moving to lost+found
disconnected dir inode 17977810, moving to lost+found
disconnected dir inode 17977835, moving to lost+found
Phase 7 - verify and correct link counts...
resetting inode 368465 nlinks from 2 to 4
resetting inode 17977810 nlinks from 0 to 2
..

Then I ran this again sudo mount -t xfs -o nouuid /dev/sdf /mnt/test-ebs

All Working now!

Cheers

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Before even running the fsck, make a image of the filesystem, and then work on it. So if something goes wrong, you'll have the original. Do not work on the file system itself.

Also, it's highly unlikely that sdf is the filesystem, sdf is the drive itself, and the filesystem is on some partition on it. Run fdisk -l /dev/sdf to see the partitions, the try fsck on /dev/sda1, etc.

To prepare an image of the device:

# dd if=/dev/sdfX of=sdfX.img

where X is the partition number, as listed with fdisk -l.

Then run fsck on the image: EDIT:(note, you can not use fsck directly, instead you need to tell fsck what type of file system is this)

# fsck.ext3 sdfX.img

After fsck fixes the partition, mount it like:

# mount -o loop sdfX.img /mnt/somedir

As per your comment, fdisk does not list any partition - this might mean that the partition table is lost as well.

Again, make an image of the whole device then:

# dd if=/dev/sdf of=sdf.img

Then try using testdisk on the image to try to recover the partition table.

Another option would be to use photorec on the image. It's very nice tool, which is able to detect and find files, even if the file system is damaged. It can recover tons of file formats. At least, you'll be able to get your data out.

share|improve this answer
    
Excellent, I think it's nearly there -rw-r--r-- 1 root root 7838928896 2011-08-10 13:11 sdf.img - big file, should be positive.. Is there a -command to go alongside fsck sdf.imgit returns the help options. Really appreciate this, completely new to me, cheers –  williamsowen Aug 10 '11 at 13:21
    
As I said, it's highly unlikely to have filesystem on the raw device itself. Filesystems live on partitions. So, first try testdisk to see if it can find partitions on the image. –  Sunny Aug 10 '11 at 13:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.