Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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 ...
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.
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).
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
Last edited by Dataguyz; 05-05-2013 at 11:42 AM.
Reason: typo
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.
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:
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
Quote:
Originally Posted by Dataguyz
mkfs -t ext3
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
Code:
sfdisk -l /dev/sdb 2>&1 | tee -a /tmp/output.txt
, run
Code:
man fsdisk
, run
Code:
fdisk -b 4096 /dev/sdb
, 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
Code:
mke2fs -n -S /dev/sdb1 2>&1 | tee -a /tmp/output.txt
and attach "/tmp/output.txt" plus the relevant parts of running
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.