Help! I Formatted my /Backup Drive in Error
 

I did an OS reload on my CentOS Server and mistakenly ran mkfs -t ext3 on my backup drive prior to mounting it. All the data has been wipe off and I have no remote backup.

Is it still possible to recover my data? Any help would be appreciated.

Thanks

We are to assume you have not written anything (else) to the filesystem ?.

Back it up with something like "dd". Before you do anything else.
I have had success with "mkfs -S ..." - that's a capital S; see the manpage for details and warnings. This may recover everything if you're lucky - it has in my testing on ext3.
Else you'll need to look at file scraping - photorec or one of the forensic tools.

Now about them backups in the desk drawer that you can't accidentally write over ...

Many Thanks for your response. Are you into Data Recovery? Can you recommend any? The Hard Drive is on my Server and I hope it can be fixed remotely.

I installed testdisk but it could not find any file or directory but i did not make any changes.

Hello,

I have done an image backup of the drive. So how do I proceed?

Thanks

Read these two:
http://www.cgsecurity.org/wiki/Data_Recovery_Examples
http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
And when you run the commands you need to execute Testdisk like
and recover the partition table first. Then attach testdisk.log as plain text file.

I did almost the same thing. I had to use a 'Cough!!" WinXXXX machine and this http://www.easeus.com/landing/partit...FSU6QgodyVUAPA and it worked on my dd copy.

Thanks a lot uspawn. Here is what I found in the logs:

Partition table type (auto): None
Disk /dev/sdb - 500 GB / 465 GiB - ST3500410AS
Partition table type: None

Analyse Disk /dev/sdb - 500 GB / 465 GiB - CHS 60801 255 63

recover_EXT2: s_block_group_nr=0/3726, s_mnt_count=3/37, s_blocks_per_group=32768, s_inodes_per_group=16384
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 122096646
recover_EXT2: part_size 976773168
Current partition structure:
P ext3 0 0 1 60801 80 63 976773168


How do I proceed?

Looks like a disk with one partition on it. Since you have a backup I'd suggest letting it recover the partition boundaries and write a partition table. Note writing the partition table won't automagically "fix" things but it won't harm the data inside the partition either. After that if 'blockdev --rereadpt /dev/device' doesn't reread the partition table you may have to reboot or dis / reconnect the device. If you can now read the partition table have testdisk enter the partition and see if you can browse the file system (don't post but attach log). If that doesn't work run, like syg00 said, 'mke2fs -n -S /dev/device_partitionname' and note the super block positions. Then run e2fsck on the partition with one of the spare super blocks BUT USE THE "-v -n" switches no NO OTHER ones: 'e2fsck -n -v -b superblockpostition /dev/device_partitionname 2>&1 | tee /tmp/e2fsck.log' and show us the logs. (Again don't post but attach log files).

How do I write the partition table? Testdisk does not pop up the write option after all the Searches. It just shows the mistakenly created P ext3 0 0 1 60801 80 63 976773168.

Thanks

Can you confirm is this a disk which originally had just one partition that spanned the whole drive and if not, what was the layout? Perform a quick search then select the "Deeper search" to see if it can find those partitions. Once its finished you should have a "Write" option to write the partition table. You should have an idea what partitions the disk previously held though.

Yes, it was a single partition disk used for backup. When running deepsearch this appears:

Linux 0 0 1 60801 80 63 976773168

But the moment the search is done it disappears.

Thanks

I have now been able to rebuild the table but testdisk now says:

No ext2, JFS, Reiser, cramfs or XFS marker

Here is the log of e2fsck.

Data recovery is always a difficult and hazardous operation to guide. Difficult because we aren't there to look over your shoulder to see what actual commands you type and hazardous because the wrong command can lead to disastrous results. That's why I, from reply one, asked you to attach log files to be able to follow things closely. Your fsck log file shows the current file system only uses 11 inodes, meaning it's looking at the reformatted super block. We don't know how you formatted your backup device in the first place but if you actually ran
on your backup drive when reformatting it (not a partition like /dev/sdb1 but the whole /dev/sdb block device and using no other flags) then it could be mke2fs selected the default block size (512 bytes) instead of the 4K this drive seems to need. Since you have a backup of the drive you should be able to use '(s)fdisk' on /dev/sdb, check the partition table , run , run , delete any partitions if listed, create a partition spanning the whole disk, mark it as ext2 and save the partition table. Now list the partition table again and run and attach "/tmp/output.txt" plus the relevant parts of running to your reply.

Here is what the output log says. Can I PM you? You appear to be a pro. I am willing to pay for your service.

Thanks