Risks when expanding RAID5?

  • Hello,


    maybe you contribute to this thread by describing experiences you've made (or want to avoid) when expanding a RAID5.


    Thinking about risks expanding a RAID5, the following dangers come to my mind:


    RAID5 is your data's lifesaver when one hdd becomes defective.
    => When adding more than one hdd to an existing RAID5 at a time there is a higher risk while reshaping (adding the new hdd's to the RAID5). This can be avoided just adding one hdd at a time.
    Disadvantage of this process is the time needed for reshaping. This time is nearly equal to adding x hdds at a time. For example adding one 4TB hdd to my RAID5 (4x4TB) takes approx. 24 hours, adding two 4TB hdds at a time takes 24 hours too.



    Please correct me if I'm wrong and any addition is welcome.


    Kind regards tsch

  • RAID5 is your data's lifesaver when one hdd becomes defective.

    Backup is your data's lifesaver when $anything bad happens. Just to repeat the obvious since I'm pretty surprised/impressed by the amount of people running a RAID (especially anachronistic RAID modes like RAID5) and totally forgetting about backup. RAID is availability only and not related to data safety :)

  • Thanks for your reply.


    I can understand your point of view but for me the "anachronistic" RAID5 is far better/safer than using JBOD's and fits my needs concerning safety. The failure of one hdd is much probable than two ore more hdd's failing at the same time.


    An yes, you're absolutely right, RAID is no Backup. But I personally don't need to backup everything saved on my NAS.


    It was not my goal to start a discussion "RAID vs Backup" in this thread. :D

    • Offizieller Beitrag

    I would never add two disks to a software raid 5 array at the same time.


    It was not my goal to start a discussion "RAID vs Backup" in this thread

    We bring that up so that other people reading this thread don't think RAID is backup or really a safe option (I've seen too many unrecoverable arrays)...

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • I can understand your point of view but for me the "anachronistic" RAID5 is far better/safer than using JBOD's and fits my needs concerning safety.

    Hmm... I still fail to understand the 'safety' aspect but anyway. I was talking more about replacing anachronistic concepts with something more suitable. Eg. raidz instead of mdraid-5 :)


    But I've to admit that I have not the slightest idea how a recent ZoL (ZFS on Linux) interacts with OMV 3. Starting to test right now since ZoL 0.7 release note reads very very very promising :)

  • Starting to test right now since ZoL 0.7 release note reads very very very promising

    Well, first steps don't look that promising but maybe starting to test on ARM is wrong anyway ;)


    https://forum.armbian.com/inde…ab=comments#comment-39344 (write performance is horribly low and I still have not the slightest idea how to get ZFS datasets being shared by OMV :) )

  • I would never add two disks to a software raid 5 array at the same time.


    We bring that up so that other people reading this thread don't think RAID is backup or really a safe option (I've seen too many unrecoverable arrays)...


    Thanks for your confirmation regarding 1 hdd vs 2 hdds at the same time.


    You and tkaiser are right to mention that RAID5 is not a backup. I had a lot of discussions in my organisation why to spent a lot of money for a professional backup-solution since we have a SAN in two datacenters with syncronous mirroring (and internal RAID).

    • Offizieller Beitrag

    I had a lot of discussions in my organisation why to spent a lot of money for a professional backup-solution since we have a SAN in two datacenters with syncronous mirroring (and internal RAID).

    Kinda sad that you had to "convince" people to spend money on backup for a mirrored SAN. We have a whole team just for backup of our SANs. We have plenty of media servers for local backups and lots of LTO tape drives for offsite backup/storage.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!