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.
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!
