After putting my RN424 in live service as my live current backup NAS, my old RN104 is not on most of the time and is really just a backup to THAT NAS for certain shares as a failsafe.
I had the same maintenance schedules setup for each of them based on recommendations on various posts here....annual, quarterly, etc. as appropriate which made sense when it was my primary NAS.
My question is what maintenance processes and at what frequency should I run on the RN104 based on its infrequent use? It only rarely has data written to it and is not left on. However with the old schedule still active, I found when I did turn it on, it would fire up some process.
Just don't want to overtax these drives for no reason. Although of course I do want to know if a drive is failing.
As a side questions, my live NAS the RN424 turns on once a week for backups and otherwise is also off. I do want all maintenance run on that one. If it misses a scheduled maintenance, will it fire it off when it turns on if it missed it?
I had the same maintenance schedules setup for each of them based on recommendations on various posts here....annual, quarterly, etc. as appropriate which made sense when it was my primary NAS.
My question is what maintenance processes and at what frequency should I run on the RN104 based on its infrequent use?
Certainly this is an area where people can disagree. Personally I use the same maintenance schedule on my backup NAS.
One aspect here is that at least some of the tests won't finish if you have a power schedule enabled. I noticed this week that the disk test on my RN524x started, but never finished (because the NAS powered down on schedule). There's no good workaround, other than power up the NAS, temporarily disable the power schedule, and run the test(s) manually.
One aspect here is that at least some of the tests won't finish if you have a power schedule enabled. I noticed this week that the disk test on my RN524x started, but never finished (because the NAS powered down on schedule). There's no good workaround, other than power up the NAS, temporarily disable the power schedule, and run the test(s) manually.
I've looked into this more deeply, and if you are skilled with linux this is something you can fix. Of course this is at your own risk.
The NAS uses a script to detect if the scheduled powerdown needs to be delayed. That script is /frontview/bin/autopoweroff. I added some checks to look for a running maintenance task - the mod I am using is
# Check for running maintenance task (mod).
# the four tests below are structured to stop looking for uncompleted tests at the most recent boot of the ReadyNAS.
# That prevents a previously aborted test (due to a crash, manual shutdown, etc) from postponing the auto poweroff
#
# These tests do not handle the case where a test is running on multiple volumes in parallel.
# That could be fixed by cloning the tests, and including a grep for the individual volume names.
#
scrubtest=`tac /var/log/frontview/status.log | egrep -m1 'LOGMSG_SCRUB|LOGMSG_START_READYNASD'| egrep -v LOGMSG_START_READYNASD | egrep started`
disktest=`tac /var/log/frontview/status.log | egrep -m1 'LOGMSG_DISKTEST|LOGMSG_START_READYNASD'| egrep -v LOGMSG_START_READYNASD | egrep started`
balancetest=`tac /var/log/frontview/status.log | egrep -m1 'LOGMSG_BALANCE|LOGMSG_START_READYNASD'| egrep -v LOGMSG_START_READYNASD | egrep started`
defragtest=`tac /var/log/frontview/status.log | egrep -m1 'LOGMSG_DEFRAGEND|LOGMSG_START_READYNASD'| egrep -v LOGMSG_START_READYNASD | egrep started`
if [ "$scrubtest" != "" ]; then
OK_TO_HALT=0
CAUSE="Scrub"
elif [ "$disktest" != "" ]; then
OK_TO_HALT=0
CAUSE="Disk Test"
elif [ "$balancetest" != "" ]; then
OK_TO_HALT=0
CAUSE="Balance"
elif [ "$defragtest" != "" ]; then
OK_TO_HALT=0
CAUSE="Defragmentation"
fi
The basic idea is to search for the most recent occurence of the each maintenance taks, and see if it says "started". That search stops at the most recent boot of the NAS, since anything before that clearly isn't running now. If the returned string is "" then there either is no test found or the most recent occurence doesn't say the test was started.
This script isn't autogenerated, but of course could be overinstalled (or updated by Netgear) in future firmware updates. So you should keep a copy of the original and the mod handy, since it is possible you'd need to apply something like this again.
I took a look at the original script because I know my backup NAS already holds the power-off for a scrub. It does so because it initiates an MDADM re-sync concurrently with the scrub and a re-sync is already checked for. I've not noticed if there is any significant time from when the re-sync normally ends to the end of the scrub, so it still might interrupt the very end of the scrub.
But I am a bit surprised that Netgear didn't take into consideration those other tasks to delay a shut-down and that there isn't a system flag already present to say one is in progress that would eliminate the problem with multiple parallel tasks. For me, the scrub is taken care of as I described, the balance is short enough to complete in the allocated on time, and I don't do the others. But not everyone takes those into account when scheduling a power-down.
I took a look at the original script because I know my backup NAS already holds the power-off for a scrub. It does so because it initiates an MDADM re-sync concurrently with the scrub and a re-sync is already checked for.
There is another scenario - and that is if you do a scrub on a volume that doesn't have RAID redundancy. For instance, if you do a scrub on a JBOD volume, the NAS will only do the btrfs scrub.
My motivation was to defer shutdown when the disk test was running. But the approach I used is easily adapted for each maintenance test (since I am just looking in the status log, and not attempting to figure out what is going on by looking at smartctl, mdadm, and btrfs directly). So I just did them all.
But I am a bit surprised that Netgear didn't take into consideration those other tasks to delay a shut-down and that there isn't a system flag already present to say one is in progress that would eliminate the problem with multiple parallel tasks.
Agreed. @kohdee did engage in a related thread in the idea exchange - for some reason he seemed to think that most users would prefer to abort the maintenance in order to maintain the schedule. That made no sense to me.
BTW, when testing this script I discovered a problem with a jbod volume on my RN202. The disk test failed (though the smart stats and hdsentinel both say it is "perfect"). So I am glad I spent the time to do the mod.
