NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Original Infrant ReadyNAS NV powers up but not responding
After a recent power outage, our original Infrant NV seems to turn on but will not respond. It was populated with 3 WD 3 TB drives and has been that way for 6 or 7 years working perfectly. So prefe...
Well I've been rooting around the rabbit hole for a while now and I'm finally up for air. I was trying to use System Rescue CD but that was a dead end as it was too hard for me to add the necessary software without apt-get. I switched and set up a live persistent USB with Mint 18 and was able to access the files. As we speak they are being transfered to another drive. The USB was very easy to setup using Windows software here: https://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/
As many here know, the key was to use "fuseext2". Not "fuse-ext2" and not "mount". For those who are reading this without seeing alot of other info the SPARC versions of the ReadyNAS NV with version 4.x firmware use a non-standard 16k block size so fuseext2 is the only one that will play nice-ish. I still could not access the mounting with any GUI applications on Mint and it would lock up the LV if I tried. With my level of knowledge the only way out at that point was a reboot.The following instructions posted elsewhere will work. Just use the right mounter fuseext2 and do not add a dash. That was a huge time waster for me.
(1) sudo su (2) apt-get install fuseext2 (3) apt-get install lvm2 (4) modprobe fuse (5) vgscan (6) vgchange -ay c (7) fuseext2 -o ro /dev/c/c /mnt (7) fuseext2 -o ro -o sync_read /dev/c/c /mnt That’s it!!! You can now see the mounted files in the /mnt directory
While the clues were there, it took a long time for me to put them together. On an unsuccessful mount, Mint gives some advice to check the dmesg using
Code: dmesg | tail where I found this:
Code: EXT3-fs (dm-3): error: bad blocksize 16384
Googling the message found someone with the same issue and that fuseext2 must be used to accommodate the nonstandard block size. With that change, it was off to the races and plodding through authoring the proper rsync and find commands to get what I wanted.
I still like the tool set on the SytemRescueCD and while it can be done, I don't think I am at the level to add the software required to this live CD. It is a shame that it is not easier as there are always new (or old) tools that come along a person might need or want when troubleshooting.
Thank you very much for the time you spent considering my challenge. Just knowing there are knowledgeable people like you willing to help lowered the anxiety greatly.
Hi Longtimer, sorry to hear about your situation. I have experienced something similar a while ago, and managed to recover everything without too much costs.
In short, I had a dynamic X-RAID array in which disks corrupted one after the other rendering the whole array inaccessible. Your situation is somewhat different but I would take the same approach I ended up recovering my data with:
My first step was securing the data off the disks: figuring the disks were old any could break up any moment now I bought a USB cradle that I connected to another computure, so that I could make exact data images of each disk. I used software that read the disks as a record (sequentially?) so that the platters/heads etc were least stressed. (Repiecing back data structures puts a lot of stress on disks.)
This allowed me to put the "old,fragile,unreliable" disks aside and only use the images to recover the data.
Once I had the images I used a piece of software that could detect dynamic arrays: select all images, and start. After the software recognised the dynamic array I was presented with the original filesystem which easily allowed me to recover/copy all data quickly.
In the end I recovered all my data, setup an automatic backup and simplified my NAS disk configuration.
Here is the sequence of events of my recovery, hopefully it will help you recover your data.
WD-WCAZA2099151 shows a pending sector count of 1452, which is definitely a sign of a failing disk.
Hombibi's link is worth reading through. One correction - XRAID's on-disk format is not proprietary (despite what the recovery folks said). It uses standard linux software raid and the btrfs file system. RTT's tool doesn't support btrfs, but ReclaiMe does.
Thanks for all the great advice and the link to your experience . I must agree with the comments on drive 3. The current pending sector count on hdc went from 1 to 2 back at the beginning of Feb. This being the case, is it still recommend to make an image of one or more disks or just pull drive 3 and plonk a new one in?
I have several WD20EFRX drives coming. These `Red`drives are not stellar and I would rather have used the Hitachi (HGST HUA722020ALA330) but I can`t seem to find them from a reputable vendor. Apparently alot of the HGSTs available now are OEM drives and have minimal warranty.
Attached is a summary of the stats if anyone cares. I put them into an excel table so that it was easier to see any trends.
Date 14-Jan-18 21-Jan 28-Jan 04-Feb 11-Feb 18-Feb 25-Feb 04-Mar 11-Mar 18-Mar 23-Mar hdc 1 Raw_Read_Error_Rate 10 10 12 12 12 12 12 12 12 12 12 3 Spin_Up_Time 6683 6708 6708 6708 6708 6708 6708 6708 6708 6708 6666 4 Start_Stop_Count 91 92 92 92 92 92 92 92 92 92 96 5 Reallocated_Sector_Ct 0 0 0 0 0 0 0 0 0 0 0 7 Seek_Error_Rate 0 0 0 0 0 0 0 0 0 0 0 9 Power_On_Hours 61458 61624 61779 61946 62114 62282 62450 62617 62784 62952 63005 10 Spin_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 11 Calibration_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 12 Power_Cycle_Count 57 58 58 58 58 58 58 58 58 58 62 192 Power-Off_Retract_Count 46 47 47 47 47 47 47 47 47 47 51 193 Load_Cycle_Count 282924 282932 282933 282942 282949 282954 282970 282975 282984 282993 282999 194 Temperature_Celsius 29 18 36 36 35 33 36 35 34 35 32 196 Reallocated_Event_Count 0 0 0 0 0 0 0 0 0 0 0 197 Current_Pending_Sector 1 1 1 2 2 2 2 2 2 2 2 198 Offline_Uncorrectable 0 1 0 0 0 0 0 0 0 0 0 199 UDMA_CRC_Error_Count 0 0 0 0 0 0 0 0 0 0 0 200 Multi_Zone_Error_Rate 3 4 3 2 2 2 3 6 3 1 3 hde 1 Raw_Read_Error_Rate 0 0 0 0 0 0 0 0 0 0 0 3 Spin_Up_Time 1258 1258 1258 1258 1258 1258 1258 1258 1258 1258 1125 4 Start_Stop_Count 17 18 18 18 18 18 18 18 18 18 22 5 Reallocated_Sector_Ct 1 1 1 1 1 1 1 1 1 1 1 7 Seek_Error_Rate 0 0 0 0 0 0 0 0 0 0 0 9 Power_On_Hours 30972 31137 31292 31460 31628 31795 31963 32131 32298 32465 32519 10 Spin_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 11 Calibration_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 12 Power_Cycle_Count 15 16 16 16 16 16 16 16 16 16 20 192 Power-Off_Retract_Count 13 14 14 14 14 14 14 14 14 14 18 193 Load_Cycle_Count 2245 2246 2250 2257 2265 2272 2286 2291 2304 2313 2319 194 Temperature_Celsius 33 19 40 40 40 38 40 38 38 38 37 196 Reallocated_Event_Count 1 1 1 1 1 1 1 1 1 1 1 197 Current_Pending_Sector 0 0 0 0 0 0 0 0 0 0 0 198 Offline_Uncorrectable 0 0 0 0 0 0 0 0 0 0 0 199 UDMA_CRC_Error_Count 0 0 0 0 0 0 0 0 0 0 0 200 Multi_Zone_Error_Rate 0 0 0 0 0 0 0 0 0 0 0 hdg 1 Raw_Read_Error_Rate 1 1 1 1 1 1 1 1 1 1 1 3 Spin_Up_Time 1200 1225 1225 1225 1225 1225 1225 1225 1225 1225 1166 4 Start_Stop_Count 34 35 35 35 35 35 35 35 35 35 39 5 Reallocated_Sector_Ct 7 7 7 7 7 7 7 8 9 9 10 7 Seek_Error_Rate 0 0 0 0 0 0 0 0 0 0 0 9 Power_On_Hours 61260 61425 61580 61747 61915 62083 62251 62418 62585 62753 62832 10 Spin_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 11 Calibration_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 12 Power_Cycle_Count 32 33 33 33 33 33 33 33 33 33 37 192 Power-Off_Retract_Count 31 32 32 32 32 32 32 32 32 32 36 193 Load_Cycle_Count 297189 297198 297202 297211 297222 297230 297244 297249 297263 297266 297271 194 Temperature_Celsius 31 19 37 37 37 36 38 36 35 36 33 196 Reallocated_Event_Count 7 7 7 7 7 7 7 8 9 9 10 197 Current_Pending_Sector 1453 1453 1453 1453 1453 1453 1453 1453 1453 1452 1452 198 Offline_Uncorrectable 0 0 0 0 0 0 0 0 5 15 0 199 UDMA_CRC_Error_Count 0 0 0 0 0 0 0 0 0 0 0 200 Multi_Zone_Error_Rate 0 1 1 2 66 0 13 6 2376 16041 194
So then the question is, do I do anything more than pulling drive 3 and replacing it or is it important to clone drive 3 and use the clone? Obviously drive 1 must go as soon as possible after.
I feel like I'm making a mountian of a mole hill but when the NAS went unresponsive, I was pretty worried.
Here is a summary of the smart stats:
Stat 14-Jan-18 21-Jan 28-Jan 04-Feb 11-Feb 18-Feb 25-Feb 04-Mar 11-Mar 18-Mar 23-Mar hdc 1 Raw_Read_Error_Rate 10 10 12 12 12 12 12 12 12 12 12 3 Spin_Up_Time 6683 6708 6708 6708 6708 6708 6708 6708 6708 6708 6666 4 Start_Stop_Count 91 92 92 92 92 92 92 92 92 92 96 5 Reallocated_Sector_Ct 0 0 0 0 0 0 0 0 0 0 0 7 Seek_Error_Rate 0 0 0 0 0 0 0 0 0 0 0 9 Power_On_Hours 61458 61624 61779 61946 62114 62282 62450 62617 62784 62952 63005 10 Spin_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 11 Calibration_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 12 Power_Cycle_Count 57 58 58 58 58 58 58 58 58 58 62 192 Power-Off_Retract_Count 46 47 47 47 47 47 47 47 47 47 51 193 Load_Cycle_Count 282924 282932 282933 282942 282949 282954 282970 282975 282984 282993 282999 194 Temperature_Celsius 29 18 36 36 35 33 36 35 34 35 32 196 Reallocated_Event_Count 0 0 0 0 0 0 0 0 0 0 0 197 Current_Pending_Sector 1 1 1 2 2 2 2 2 2 2 2 198 Offline_Uncorrectable 0 1 0 0 0 0 0 0 0 0 0 199 UDMA_CRC_Error_Count 0 0 0 0 0 0 0 0 0 0 0 200 Multi_Zone_Error_Rate 3 4 3 2 2 2 3 6 3 1 3 hde 1 Raw_Read_Error_Rate 0 0 0 0 0 0 0 0 0 0 0 3 Spin_Up_Time 1258 1258 1258 1258 1258 1258 1258 1258 1258 1258 1125 4 Start_Stop_Count 17 18 18 18 18 18 18 18 18 18 22 5 Reallocated_Sector_Ct 1 1 1 1 1 1 1 1 1 1 1 7 Seek_Error_Rate 0 0 0 0 0 0 0 0 0 0 0 9 Power_On_Hours 30972 31137 31292 31460 31628 31795 31963 32131 32298 32465 32519 10 Spin_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 11 Calibration_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 12 Power_Cycle_Count 15 16 16 16 16 16 16 16 16 16 20 192 Power-Off_Retract_Count 13 14 14 14 14 14 14 14 14 14 18 193 Load_Cycle_Count 2245 2246 2250 2257 2265 2272 2286 2291 2304 2313 2319 194 Temperature_Celsius 33 19 40 40 40 38 40 38 38 38 37 196 Reallocated_Event_Count 1 1 1 1 1 1 1 1 1 1 1 197 Current_Pending_Sector 0 0 0 0 0 0 0 0 0 0 0 198 Offline_Uncorrectable 0 0 0 0 0 0 0 0 0 0 0 199 UDMA_CRC_Error_Count 0 0 0 0 0 0 0 0 0 0 0 200 Multi_Zone_Error_Rate 0 0 0 0 0 0 0 0 0 0 0 hdg 1 Raw_Read_Error_Rate 1 1 1 1 1 1 1 1 1 1 1 3 Spin_Up_Time 1200 1225 1225 1225 1225 1225 1225 1225 1225 1225 1166 4 Start_Stop_Count 34 35 35 35 35 35 35 35 35 35 39 5 Reallocated_Sector_Ct 7 7 7 7 7 7 7 8 9 9 10 7 Seek_Error_Rate 0 0 0 0 0 0 0 0 0 0 0 9 Power_On_Hours 61260 61425 61580 61747 61915 62083 62251 62418 62585 62753 62832 10 Spin_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 11 Calibration_Retry_Count 0 0 0 0 0 0 0 0 0 0 0 12 Power_Cycle_Count 32 33 33 33 33 33 33 33 33 33 37 192 Power-Off_Retract_Count 31 32 32 32 32 32 32 32 32 32 36 193 Load_Cycle_Count 297189 297198 297202 297211 297222 297230 297244 297249 297263 297266 297271 194 Temperature_Celsius 31 19 37 37 37 36 38 36 35 36 33 196 Reallocated_Event_Count 7 7 7 7 7 7 7 8 9 9 10 197 Current_Pending_Sector 1453 1453 1453 1453 1453 1453 1453 1453 1453 1452 1452 198 Offline_Uncorrectable 0 0 0 0 0 0 0 0 5 15 0 199 UDMA_CRC_Error_Count 0 0 0 0 0 0 0 0 0 0 0 200 Multi_Zone_Error_Rate 0 1 1 2 66 0 13 6 2376 16041 194
Am I doing something wrong? Twice I posted a reply (message 10) and they were both deleted.
When the NAS went unresposive I was quite worried and I may have made a mountain out of a molehill. But as you guys have pointed out the logs show that drive 3 is the bad actor. Should I just swap a new drive into slot 3 and see what happens? or is there something else I should do first? Are the stats on drive 1 concerning?
The way I see it, here are my options:
1. Swap out drive 3. Then swap 1 once 3 is up.
2. Clone 1 and 3 and install clones
3. Clone 1 and install then swap 3
4. Something else?
I'm thinking about this too much.... I think.
PS. The current pending sector count went from 1 to 2 back in January 2018.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
