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, if you have no backups you want or can fall back on I would take a slightly different approach.
1) Before everthing else make images of each of your current drives, even the third, and make copies of each of those images (backups). The reason is that recreating the raid array puts a heavy load on the two remaining disks. If you have no backup, slotting in a new disk actually increases the chances that one of the two, or both remaining disks fail too. In that case you'll have lost everything. A good imaging software reads the disk sequentially, and thus creates minimal stress on a harddrive. Once you have those images you can do with the hardware as you wish:
2) Try to slot in a new drive as you suggest and hope that the array rebuilds.
3) If succesful make backups of your data, no need for further images after that.
3) If not succesfull use software to mount the images created in step 1 and rebuild the array and/or recover the data.
4) Determine a backup strategy
5) Replace all old disks: If they were bought together the chance that the other two will fail is high now the first one has given up already. If they were bought together they are probably from the same batch, thus of the exact same quality. Or you could continue and rely on backups in case they fail.
6) Copy data back to Readynas NV, keep backups and images for a while untill you are certain you have everything you need.
7) Make initial backup and put backup strategy in place.
Once you have recovered your data you could consider to continue with the old disks untill they go, a good (implemented) backup strategy will safeguard your data, but mind you, once your HD goes again you might only have your backup to rely on. And if that fails too... some people here by default make backups of their backups. It is not a bad idea, albeit more complicated and expensive.
Cheers, Hombibi
Hombibi wrote:
1) Before everthing else make images of each of your current drives, even the third, and make copies of each of those images (backups). The reason is that recreating the raid array puts a heavy load on the two remaining disks. If you have no backup, slotting in a new disk actually increases the chances that one of the two, or both remaining disks fail too. In that case you'll have lost everything. A good imaging software reads the disk sequentially, and thus creates minimal stress on a harddrive. Once you have those images you can do with the hardware as you wish:
First of all, when you are cloning a RAID array you need to ensure that you are doing a sector-by-sector copy. So you need imaging software that does that (and it will work sequentially). I'm not convinced that reduces the disk stress, since I generally don't see much evidence of disk trashing when the RAID array is resyncing (with no other disk access). But it does give you more options in recovery.
But I wouldn't start by inserting those clones into the NAS. Right now bad sectors are detected (since they can't be read). The NAS can try reconstruct the missing data from the other drives, and even if that is not possible, at least it knows that the data is bad.
On the clones, all the sectors are good/readable, but not all of those sectors will have correct data (since the damaged bits on original weren't copied). That will result in some amount of filesystem corruption when you use the clones. So don't actually insert the clones unless you have to.
Hi Stephen, not sure if you are arguing against me but please note that I never suggested or even discussed restoring an HD image to a new harddisk and putting that one back. I have no idea if that works and I frankly don't see the need once I have images that I can mount when and where I want.
Than on your point that resyncing does not stress a harddisk more because you have not seen much failure at that time. With all due respect, I hope you agree that that is not really an argument. What's more, why take the risk?
My advice to start with making images does not come out of thin air but is based on this explanation from those who write hd recovery software for a living: http://www.r-studio.com/Clone_Disks_Before_File_Recovery.shtml I think it makes sense.
Hombibi wrote:
Hi Stephen, not sure if you are arguing against me but please note that I never suggested or even discussed restoring an HD image to a new harddisk and putting that one back. I have no idea if that works
LongTimer listed it as his first option earlier in the thread, and I was just trying to take that off the table. I wasn't disagreeing with you, just amplifying the intended use of the clone - which I think we agree is on.
On disk stress - These posts often get read much later on, so I do sometimes make clarifying statements for future readers. The idea that cloning is somehow easier on the failing disk than a RAID resync is just your opinion (and your link speaks to data recovery, not to RAID resync - which is quite different).
But we agree that making a clone to maximize success with data recovery is a good idea. As your link says, attempts at data recovery will often increase the failed sectors on the disk, and the clone does minimize that (because data recovery can make multiple passes over the disk, and the cloning process doesn't).
Okay, I'm glad you guys brought that up. I had thought that I would be inserting the clone(s) into the NAS. Per Hombibi, the idea is to keep clones out and use them only on another machine to do external data recovery if things go south on rebuilding the drives in the NAS. I would think that once the NAS starts to rebuild a faulty drive and fails, that a clones cannot be mixed with the drives from the NAS as a clone would then be "stale"?
Since drive 2 seems good and has alot fewer hours, I only bought 2 of 2.0 TB drives but from what I am reading, a totally safe plan would require at least five drives. (3 clones plus a new drive 3 and new drive 1). Is it possible to clone 2 or 3 drives onto one large drive (2-3x bigger) on separate partitions and then mount them somehow for external data recovery? or would a person be better off to create images on the large drive and then extract the images back to physical drives for data recovery if required?
At this point, I have cloned Drive 1 using gnu_ddrescue with 0 errors showing and I am running Western Digital Diagnostics on Drive 1. If this shows no issues, I had planned to reinsert the old Drive 1 and swap a new drive into slot 3. Then power on. I think with the diagnostics check, the risk is low.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
