This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
After losing access (no web, ssh, mounts, anything) from my ReadyNAS Pro 6 running 6.7.4 firmware, I decided to hard-reboot it by holding down the power button until it powered off. after booting back up, I was confronted by no data and two volumes (zero bytes each).
I bought a QNAP and am trying to get data restored manually for now. Luckily I have online backups of the critical stuff (10+ years of photography shoots and proofs).
Regardless of the outcome, I think I'll roll-back the firmware to the "officially" supported version 4.x. Ever since upgrading to the unsupported 6.x, I've noticed it locks up fairly often - I even setup a cron job to reboot it nightly to try and reduce the impact.
I know any OS dis-likes hard-reset... and it's been restarted this way a few times in the past couple months.
My wife thinks it's because she gave it the middle finger before powering it off...
If it was my NAS, I would replace it immediately. It doesn't show any error, but has 25,000 hours and a terrible reputation.
Based on the logs:
You have daily snapshots on 8 shares (applications, backup, Documents, istat, Music, Pictures, Transmission, Videos).
No balance nor defrag were run since the creation of the volume, 2017/01/04.
I cannot see the metadata allocation because the data volume isn't mounted.
The logs don't give any details about the configuration of the shares in regards to Bit Rot Protection (implies Copy-on-Write) and Compression, can you tell us?
My guess is that the metadata allocation is high and the data fragmented which may lead to crashes. But the issue can be completely unrelated. It's not something I can explain from these logs. Unfortunately, after a reboot, the dmesg logs are flushed. It's possible to setup something like netconsole to push the kernel logs with a similar process to syslog in order to capture them on another machine, so you have the ones just before the crash.
Not sure why, but you have a cron job to capture the last status of processes and load every 5 minutes. Maybe in an attempt to debug the lock-ups?
The LAN interface seems to be connected to a FastEthernet network (100Mbps), that's weird.
It would be interesting to know to read the loadavg.log file, but I don't know how. (@mdgm maybe?)
The NAS was power-cycled twice recently:
- It seems that the NAS was power-cycled on Jun 18 15:01 (the logs start there so can't tell when it hung).
- It seems that the NAS crashed shortly after Jun 18 18:25 and was power-cycled on Jun 19 20:28. There didn't seem to be much going on before the crash, in terms of process anyway.
Power-cycles clearly don't help, but I understand you may not have had a choice.
The NAS remained then shutdown for nearly a month. When it booted last, the volume was unmountable.
Thanks for the write-up. I'll post details from the NAS once I'm home and have tried your suggestions.
Good point on the logs, I've disabled sharing.
Agreed on the Seagate... it was my first 3GB purchase.
I think copy-on-write and compression are enabled...? not 100% sure if those are defaults with 6.x
You are correct, the cron 5 minute was an attempt to narrow down the crashing cause. Good news is a have Splunk-Universal-Forwarder installed and configured. Everything from /var/log/ _should_ be captured on my Windows desktop Splunk server (shameless plug: Splunk is 100% free if your data volume is less than 500gb/day - super awesome for troubleshooting faults like this as you can correlate timesamped event across multiple files)
100mbit LAN is correct - I moved the NAS from the basement to my office upstairs and the switch there is only 100.
Once I realized the data volume was gone (about a month ago) I did some simple troubleshooting, then decided to power it down (using the web interface) until I could spend more time with it. After discussions with the spouse, we decided the age of it, and the ongoing unstability warrented a full NAs replacement. It remained off until the new one (a QNAP 671) arrived and I could mount drives in it.
I'll post again tonight once I try the fstab settings, and output from brtfs command. Any other logs you'd like to see? I'll check if they're indexed in Splunk.
Tried mounting from the command-line (at this point I'm a bit like a bull in a china shop... barely understanding the commands I'm Googling)...
sudo mount -r --source LABEL=33ea999f:data /data
mount: wrong fs type, bad option, bad superblock on /dev/md127,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
