Forum Discussion

Aspirant

Apr 19, 2019

Second NAS RN104 backup Maintenance Schedule

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

StephenB

Guru

Apr 19, 2019

BJB wrote:

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.

StephenB

Guru

Jan 08, 2021

StephenB wrote:

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.

Sandshark
Sensei
Jan 08, 2021
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.
- StephenB
  Guru
  Jan 09, 2021
  Sandshark wrote:
  
  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.
  
  Sandshark wrote:
  
  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.