Unexpected RAID Rebuild?

  • For those of you that recently noticed your RAID array rebuilding for no reason, no need to worry. On the first Sunday of every month at 1:06am, an array check is scheduled to run with Debian based systems. This is mainly a read-only operation, just let it finish its job and don't freak out.




  • Never knew that. Good to know :)


    /proc/mdstat uses the term check. Maybe the term recovering could be changed to checking??

    omv 5.5.12 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Sorry to bring up this old topic, but as I have brother systems with the same setup, having a "clean recovery" running at the very same time is not convenient (in case something happen, or even just no to have 100% CPU running at the same time).
    How can we customise this? It should be set to random day if you ask me...

  • Mine appears to want to run at 3:57AM on the first Sunday. Note though I do not have a raid setup. Noticed the entry in the log files.


    WARNING: You are on your own on this. Because it may be possible to lose your data if the wrong changes are made.


    You might want to look at the cron jobs in /etc/cron.d and look at the file mdadm


    Make a back up of the mdadm file - in case something goes wrong


    You could then change the time and day it runs.


    Also a version update to OMV may overwrite any changes made.


    It would be nice if the GUI of OMV had an options page where we could change when internal OMV cron jobs are run. OS (Debian) cron jobs though OMV should not list as they could be changed with OS updates. The OS ones then fall on to us to control.

  • Since when has this been an auto job? this is the first time it has ran for me since I have set up my raid5 more than 6 months ago. It does not show up on any job schedule on the GUI I have this running on an RPI3 and checking this uses about 72 hours of cpu load resources once a month now? I would at most want to run this quarterly or even bi annually at most. anyone please advise on how to change this.

  • This is what my /etc/cron.d/mdadm had in it.
    I changed this to run twice a year. Monthly was way too much for me.
    Does anyone see issues with this?


    Thank you in advance.


    D


    # cron.d/mdadm -- schedules periodic redundancy checks of MD devices
    #
    # Copyright © martin f. krafft <madduck@madduck.net>
    # distributed under the terms of the Artistic Licence 2.0
    #


    # By default, run at 00:57 on every Sunday, but do nothing unless the day of
    # the month is less than or equal to 7. Thus, only run on the first Sunday of
    # each month. crontab(5) sucks, unfortunately, in this regard; therefore this
    # hack (see #380425).
    #57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi


    #changed to do this 2x year
    * * * 1,7 * root /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

  • I have set up my raid5 more than 6 months ago ... I have this running on an RPI3 and checking this uses about 72 hours of cpu load resources once a month

    @votdev: is it possible to prevent mdadm being installed on certain platforms? Or a UI tweak requiring people who want to play RAID to accept a dialog reading 'RAID on toys does not work. I understand that I will lose my data later'?


    IMO on every platform accepting a dialog 'I understand that RAID is not backup' is also needed.

  • is it possible to prevent mdadm being installed on certain platforms?

    No, it's not possible, or more precise too much work and ugly workarounds.



    Or a UI tweak requiring people who want to play RAID to accept a dialog reading 'RAID on toys does not work. I understand that I will lose my data later'?

    Hmm, maybe, but i really do not like this idea. If i want to use a feature as user, i should get some information before if it matches my requirements. We can not prevent users from doing bad things. Sometimes you just have to learn from pain.

  • NameDriveStatusLevelCapacityDrives
    Servername/dev/md-xyclean, checkingRAID 5xyTB/dev/sda
    /dev/sdb
    /dev/sdc
    /dev/sdd
    ...




    I got this message at 1 o'clock in the morning with a drop in transfer-speed. Needs a lot of CPU power and will check for another ~ 9 hours.
    The message is "clean,checking" or "active, checking" in Detail-Report.


    Good to know it's nothing to worry about.



    pappl

  • I was wondering if my shutdown script was not working well and also came across "clean, checking" after I recognised that the shutdown was prevented by high load average.

    Secondly, I wonder if the system started up on its own to do the check. I think it should have been shut down at 1:06 a.m.


    EDIT: 12 hours later I had to reboot the system due to another issue (I had to remove a remote file system and the GUI did not show it anymore. I did not realize loggin out and in would have solve the issue.). At the time of rebooting the system was still in "clean, checking" mode but it did not resume this mode after rebooting. Now I wonder if the check was done correctly...

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!