sdumas Posted December 8, 2011 Posted December 8, 2011 I am trying to recuperate data from what looked like a dead disk, but may be not (dead that is). The drive was giving me the DRDY error message and was kind of looping at boot. After a few tries, it finally came up. I setup a separate server to perform the recuperation. I used the ddrescue procedure enumerated in this forum. It seems to have recuperated 1TB of data minus 64kb. After a few hours this log file was created: # Rescue Logfile. Created by GNU ddrescue version 1.14 # Command line: ddrescue -f -n /dev/sdb /dev/sda logfile1 # current_pos current_status 0x00018E00 + # pos size status 0x00000000 0x00018000 + 0x00018000 0x00000E00 / 0x00018E00 0x00000200 - 0x00019000 0x01061000 + 0x0107A000 0x00000E00 / 0x0107AE00 0x00000200 - 0x0107B000 0xE8DFD3B000 + I had only 64k of errors at the beginning of the disk in two errors. I was getting kind of excited and I rebooted the box minus the failed disk. My new drive was showing unformatted... hum. Ran a reiserfsck and got this: "reiserfs_open: the reiserfs superblock cannot be found on /dev/sda. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb." Before doing this I decided to use the "unraid_partition_disk.sh -A -p /dev/sda" command. This is the result: ######################################################################## Device Model: ST2000DM001-9YN164 Serial Number: Z1E02X9S Firmware Version: CC96 User Capacity: 2,000,398,934,016 bytes Disk /dev/sda: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 64 3907029167 1953514552 83 Linux Partition 1 does not end on cylinder boundary. ######################################################################## ============================================================================ == == DISK /dev/sda IS partitioned for unRAID properly == expected start = 64, actual start = 64 == expected size = 3907029104, actual size = 3907029104 == ============================================================================ Reran reiserfsck --check and still could not find the superblock. Decided to run the rebuild-sb (don't have the output of this one) but I got a message that the rebuild-tree failed. Any ideas? Any other logs or procedures I could try? Thanks!
sdumas Posted December 8, 2011 Author Posted December 8, 2011 I do have the rebuild-sb log after all: root@Tower:/boot# reiserfsck --rebuild-sb /dev/sda reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check superblock and rebuild it if needed Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes reiserfs_open: the reiserfs superblock cannot be found on /dev/sda. what the version of ReiserFS do you use[1-4] (1) 3.6.x (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, ch oose this one) (3) < 3.5.9 converted to new format (don't choose if unsure) (4) < 3.5.9 (this is very old format, don't choose if unsure) (X) exit 1 Enter block size [4096]: No journal device was specified. (If journal is not available, re-run with --no- journal-available option specified). Is journal default? (y/n)[y]: Did you use resizer(y/n)[n]: rebuild-sb: no uuid found, a new uuid was generated (a1dbf596-df91-4182-afc7-0ba 0719ea20f) rebuild-sb: You either have a corrupted journal or have just changed the start of the partition with some partition table editor. If you are sure that the start of the partition is ok, rebuild the journal header. Do you want to rebuild the journal header? (y/n)[n]: y Reiserfs super block in block 16 on 0x800 of format 3.6 with standard journal Count of blocks on the device: 488378640 Number of bitmaps: 14905 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0 Root block: 0 Filesystem is NOT clean Tree height: 0 Hash function used to sort names: not set Objectid map size 0, max 972 Journal parameters: Device [0x0] Magic [0x0] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x1: some corruptions exist. sb_version: 2 inode generation number: 0 UUID: a1dbf596-df91-4182-afc7-0ba0719ea20f LABEL: Set flags in SB: Mount count: 1 Maximum mount count: 30 Last fsck run: Wed Dec 7 19:02:35 2011 Check interval in days: 180 Is this ok ? (y/n)[n]: y The fs may still be unconsistent. Run reiserfsck --check. and here is the reiserfsck log root@Tower:/boot# reiserfsck --check /dev/sda reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/sda Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Wed Dec 7 19:08:39 2011 ########### Replaying journal: No transactions found Zero bit found in on-disk bitmap after the last valid bit. Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete) Aborted By the way - all of this was done on the "rebuilt" disk done with DDrescue.
WeeboTech Posted December 8, 2011 Posted December 8, 2011 Hopefully you still have the original disk in case you need to recopy it. If I remember correctly. someone on the forum accidentally assigned parity to a data disk. I think they had to use a scan whole partition or something. I do not remember the thread, perhaps someone else will remember, or provide a good search pattern. But I do know that he recovered allot of his data. I've seen the --rebuild-sb and it failed. Did you run the --rebuild-tree ? Usage: reiserfsck [mode] [options] device Modes: --check consistency checking (default) --fix-fixable fix corruptions which can be fixed without --rebuild-tree --rebuild-sb super block checking and rebuilding if needed (may require --rebuild-tree afterwards) --rebuild-tree force fsck to rebuild filesystem from scratch (takes a long time) --clean-attributes clean garbage in reserved fields in StatDatas Options: -j | --journal device specify journal if relocated -B | --badblocks file file with list of all bad blocks on the fs -l | --logfile file make fsck to complain to specifed file -n | --nolog make fsck to not complain -z | --adjust-size fix file sizes to real size -q | --quiet no speed info -y | --yes no confirmations -f | --force force checking even if the file system is marked clean -V prints version and exits -a and -p some light-weight auto checks for bootup -r ignored Expert options: --no-journal-available do not open nor replay journal -S | --scan-whole-partition build tree of all blocks of the device
Joe L. Posted December 8, 2011 Posted December 8, 2011 I do have the rebuild-sb log after all: root@Tower:/boot# reiserfsck --rebuild-sb /dev/sda reiserfsck 3.6.21 (2009 www.namesys.com) That was a big mistake. The file system is NOT on /dev/sda, but on the first partition on the disk, /dev/sda1. reiserfsck was not incorrect in stating the superblock could not be found on /dev/sda... since it should not have been found there. I've no idea what you've now overwritten, but you might try reiserfsck --check /dev/sda1 followed by whatever advice it gives you. Joe L.
WeeboTech Posted December 8, 2011 Posted December 8, 2011 I might try a dd rescue again and start over with the /dev/sda1 Good catch Joe, I missed the obvious there with all the other information printed out.
bubbaQ Posted December 8, 2011 Posted December 8, 2011 After using ddrescue and reiserfsck, you may consider another tool -- HDDRegenerator. http://www.dposoft.net/hdd.html I have used it in many cases on drives with hard errors. If the drive spins up and is accessible, it will read/repair/rewrite bad sectors. I'm not sure how it works (although I have a couple of theories), but I can tell you from personal experience that it does work on many drives. In the situation of a particular bad spot preventing the system from booting, or preventing mounting, or just preventing access to some group of files, it can repair the bad spot, and the drive behaves as if nothing ever went wrong. The newest version also identifies "slow" sectors, which are those where the drive firmware error recovery kicks in and is successful. Slow sectors are a sign of a failing drive, but the OS is ignorant of them.
WeeboTech Posted December 8, 2011 Posted December 8, 2011 Cool tool, looks like an improvement over spinrite. Great to have in your pocket if needed.
sdumas Posted December 8, 2011 Author Posted December 8, 2011 Thanks guys!!!! - Good catch ... sda vs sda1... ouch. Weebotech - During the rebuild-sb, it tried to bebuild the tree and it failed. So I did not try running rebuild-tree separately. I am running it now - it looks like this can take a while... I'll let it run and then if this does not work - go back to square one since I do have the original "bad" disk. I will re-run another DDrescue on it and start from there.
WeeboTech Posted December 8, 2011 Posted December 8, 2011 Thanks guys!!!! - Good catch ... sda vs sda1... ouch. Weebotech - During the rebuild-sb, it tried to bebuild the tree and it failed. So I did not try running rebuild-tree separately. I am running it now - it looks like this can take a while... I'll let it run and then if this does not work - go back to square one since I do have the original "bad" disk. I will re-run another DDrescue on it and start from there. After you did a forward ddrescue, did you try a "retry" operation in REVERSE. I think -r # is retry (I used 3 or 5) then I think I use -R for read it in reverse. It actually saved over an extra gb of data that way.
sdumas Posted December 9, 2011 Author Posted December 9, 2011 The rebuild-tree failed - I did not have much hope anyway on this one. I am redoing the DDrescue "ddrescue -f -n /dev/sda /dev/sdb logfile2" (the drives are inverted on this pass) and when this part is finished, I will perform the reverse with 3 retry. I'll have then a "brand new disk" with the hopefully recoverable data on it. I'll wait for this to finish and then review the next steps before I proceed.
WeeboTech Posted December 9, 2011 Posted December 9, 2011 if it hangs or fails, on the second pass you take away the -n (no split) option. Then it continues from where it left off at. At the end you do a retry operation in reverse. -R -r3 So it's one full pass with -n and a log file until it fails or is interrupted. Then another or multiple passes without the -n option going forward. Then lastly is a -R (reverse) read (from end to start) using -r3 (3 retries per failed block). It was the last step that allowed me to dd the failed 1GB of data. I went looking for the tutorial website that showed how to do this yesterday but could not find it. There are some examples in the online manual. http://www.gnu.org/s/ddrescue/manual/ddrescue_manual.html#Examples
sdumas Posted December 9, 2011 Author Posted December 9, 2011 Thanks will do - that will take a while - It will be probably another 6 hours to complete the first pass. I'll start the reverse retry later on tonight! Thanks again!
sdumas Posted December 14, 2011 Author Posted December 14, 2011 Oh thy woes and howrors... :'( I had to not touch this for a couple of days as I was thinking (again) of ways to destroy the whole thing... Time to refrain myself of doing something bad. I redid the DDRescue - forward and backward - it recovered (or so it seems) all the data minus 57 kb. Pretty good, I think. I did the reiserfsck --check /dev/sda1 - Got the "superblock cannot be found" error again. Suggested a rebuild - did the rebuild - could not rebuild - suggested rebuild-tree, did the rebuild-tree. That took a while (8 hours) ... (don't have the beginning of this log) ######## Pass 1 ######## Looking for allocable blocks . . Finished Flushing .. finished 0 leaves read 0 inserted ######## Pass 2 ######## Flushing .. finished No reiserfs metadata found . If you are sure that you had the reiserfs on this partition, then the start of the partition might be changed or all data were wiped out. The start of the partition may get changed by a partitioner if you had used one. Then you probably rebuilt the superblock as there was no one. Zero the block of 64K offset from the start of the partition (a new super block you have just built) and try to move the start of the partition a few cylinders aside and check if debugreiserfsck /dev/xxx detects a reiserfs super block. If it does this is likely to be the right super block version Aborted ... Now what? - I am a little lost and discouraged. The data is not that important (it's more inconvenient than anything) but I would love to find a way to recuperate it. Because if this happened on another drive that was critical - I would be in big trouble. I still have the original "bad drive", I can DDrescue again if need be... Thanks for all the help so far!!!!!!
WeeboTech Posted December 14, 2011 Posted December 14, 2011 Did you use the scan-whole-partition option? I think that reads every block and makes a best attempt at recovery.
Joe L. Posted December 14, 2011 Posted December 14, 2011 Oh thy woes and howrors... :'( I had to not touch this for a couple of days as I was thinking (again) of ways to destroy the whole thing... Time to refrain myself of doing something bad. I redid the DDRescue - forward and backward - it recovered (or so it seems) all the data minus 57 kb. Pretty good, I think. I did the reiserfsck --check /dev/sda1 - Got the "superblock cannot be found" error again. Suggested a rebuild - did the rebuild - could not rebuild - suggested rebuild-tree, did the rebuild-tree. That took a while (8 hours) ... (don't have the beginning of this log) ######## Pass 1 ######## Looking for allocable blocks . . Finished Flushing .. finished 0 leaves read 0 inserted ######## Pass 2 ######## Flushing .. finished No reiserfs metadata found . If you are sure that you had the reiserfs on this partition, then the start of the partition might be changed or all data were wiped out. The start of the partition may get changed by a partitioner if you had used one. Then you probably rebuilt the superblock as there was no one. Zero the block of 64K offset from the start of the partition (a new super block you have just built) and try to move the start of the partition a few cylinders aside and check if debugreiserfsck /dev/xxx detects a reiserfs super block. If it does this is likely to be the right super block version Aborted ... Now what? - I am a little lost and discouraged. The data is not that important (it's more inconvenient than anything) but I would love to find a way to recuperate it. Because if this happened on another drive that was critical - I would be in big trouble. I still have the original "bad drive", I can DDrescue again if need be... Thanks for all the help so far!!!!!! Until you get the superblock rebuilt, everything else is probably useless. Joe L.
WeeboTech Posted December 14, 2011 Posted December 14, 2011 Before you continue further. Please read other peoples horror and recovery stories with reiserfsck. I did a quick search and saw allot where they used the -S or --scan-whole-partition with the rebuild-tree option. I remember people being able to recover allot of data even when practically formatting the part of the drives. Usage: reiserfsck [mode] [options] device Modes: --check consistency checking (default) --fix-fixable fix corruptions which can be fixed without --rebuild-tree --rebuild-sb super block checking and rebuilding if needed (may require --rebuild-tree afterwards) --rebuild-tree force fsck to rebuild filesystem from scratch (takes a long time) --clean-attributes clean garbage in reserved fields in StatDatas Options: -j | --journal device specify journal if relocated -B | --badblocks file file with list of all bad blocks on the fs -l | --logfile file make fsck to complain to specifed file -n | --nolog make fsck to not complain -z | --adjust-size fix file sizes to real size -q | --quiet no speed info -y | --yes no confirmations -f | --force force checking even if the file system is marked clean -V prints version and exits -a and -p some light-weight auto checks for bootup -r ignored Expert options: --no-journal-available do not open nor replay journal -S | --scan-whole-partition build tree of all blocks of the device
Recommended Posts
Archived
This topic is now archived and is closed to further replies.