NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
ReadyNAS 716X data- Two volumes after Resync
System: Readynas 716X
F/W: 6.10.8
Old HDDs: 6TBx6 (WD Red)
New HDD: 8TBx1 (WD Red)
Raid 5 (X-Raid)
I have recently experienced some issues with my Readynas system. I found out that I had to replace the drive in slot4, which was working fine but about to fail. During the Resync process, apparently after it has completed successfully, slot0 drive failed and now I have two volumes data0 and data (image attached). I went through the KB and there are a couple of posts there about similar issues. I cannot enable SSH, therefore, still unable to explore any of what's been suggested.
New Volume
Please note that I've initially decided to replace this drive because the system started showing degraded Raid, specifically slot 4 in red from time to time. So I thought it would be better to replace this drive before it's too late. This problem (not able to access my nas) started when the resync was completed (per the system log) but with 1 drive (slot 0 this time) showing disk failure (the disk is surprisingly healthy now). I was still -then- able to explore the directories and they were all there and it seemed everything was normal, thus, -because the system was showing red Raid- I decided that if I reboot the nas system all the reds will disappear and it'll go back to normal then will be in peace and I'll be able to access the nas with no issues, alas that wasn't the case. It seems this is exactly similar to this kb post:
Now it's asking to 'remove inactive volumes to use the drives'.
In an effort to try to resolve this, -when I restarted the Nas system and found out of the problem-, I tried to remove/ isolate the drive that was reported as failure during the resync (now working with no issue) in slot 1, inserted the old drive that was replaced back in its old slot (slot 4), hoping everything will go back to where we started and should have worked normal, but nothing, it's exactly the same red Raid and two data volumes data (27.7TB) and data-0 (0TB). After going through the relevant KBs, Now I probably understand why that may be the case, since the BTRF journal could have got corrupted as a result of the sudden interruption in the sync, and therefore the system could not mount back to the original data volume.
From the KB threads I've also come across these threads, which I believe share similar symptoms/ issues:
Please note that I could not get the SSH service enabled, could be to do with the volume mounting issue.
I've tried my luck with Netgear support, but it looks like they no longer provide support to this system.
Would appreciate any support that could allow me to mount back/ access the data volume.
RN716x wrote:
Is it asking for an input here?
root@MaQBaLiNAS:~# cat /etc/mdadm/mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
This is the same as the file on my system, so nothing unusual here.
RN716x wrote:
root@MaQBaLiNAS:~# mdadm --assemble --scan --force
mdadm: NOT forcing event count in /dev/sdc3(3) from 11031 up to 19055
mdadm: You can use --really-force to do that (DANGEROUS)
mdadm: /dev/md/data-0 assembled from 4 drives - not enough to start the array.
mdadm: No arrays found in config file or automaticallyThis is telling you that /dev/sdc3 is missing a lot of writes - so it is seriously behind the other drives in the array.
- You could proceed with --really-force instead of force. You could end up with a lot of data loss/corruption if you do that.
- Another other option is go back to SDA. Power down, remove SDC, insert the SDA. Power up, and try the same mdadm command again, and see if the event count gap is smaller. If you go this route, you should definitely mount the volume as read-only - as we know that SDA is failing, and writes will likely only accelerate that. Also they would increase the event gap between sdc and the rest of the array (making going back to SDC even more risky).
This isn't an obvious decision. SDA likely will have a smaller event gap, but we already know it has unreadable sectors. Plus it might fail when you try to offload data. Still, I think it is likely the best path (with read-only mounting).
A variant of (2) is to clone SDA, and insert the clone. The cloning process will skip over any unreadable sectors on the original. The benefit of the variant is that there will be no bad sectors detected on the clone (which is a mixed blessing, as bad sectors do give you some information on file corruption). The risk is that the original will completely fail during the cloning process.
Either way (1, 2, or 2 variant), you'd copy off as much data as you can, do a factory default with the two new drives installed in place of SDA and SDC. You'd reconfigure the NAS at that point, and then restore the files from the backup.
18 Replies
Replies have been turned off for this discussion
Do you have any log zip files - either after the first resync, or after the reboot? Maybe also download one now if you can.
Your old drive is out of sync with the others, so adding it back will cause more problems, not fix them. But since it didn't mount, probably no additional damage was done.
Your "two volumes" are actually two broken halves of your old volume. The NAS cannot properly mount them as one, presumably because of the failed drive. Since drive 1 is the failed one, that may be the reason you cannot enable SSH. I suggest you try booting without drive one, in read-only mode (using the reset button menu to do so) and see if that doesn't fix the issue (one accessible volume, though it will be "degraded) or at least let you enable SSH. I may be wrong, but I believe read only mode still allows writing to the OS partition, which is needed to enable SH. Maybe StephenB can confirm.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
