RAID with Raspberry Pi

  • Hi,


    I have a problem with last build OMV_3_0_99_RaspberryPi_2_3_4.9.80.img
    I have a Raspberry 3 B+ and Raspberry 3 B with the same problem for both of them


    I did a fresh install into a USB Card and installed it.
    After, I have 3.0.79 version of OMV and kernel 4.9.80-v7. In the RAID menu, I found my two disks (/dev/sda and /dev/sdb).


    Then I waited for the update and reboot.
    After, I have 3.0.99 version of OMV and kernel 4.14.30-v7. And in the RAID menu, I don't find my two disks. It's empty !
    I can't create a RAID 1 with my two disks.


    Do you have a solution to resolve my problem?


    Thanks


    • Offizieller Beitrag

    Do you have a solution to resolve my problem?

    I recommend not using raid with usb and highly recommend not using raid on a RPi.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

  • The first question you should ask yourself is why you want to play RAID. Most probably the answer has something to do with data protection and then you're already wrong (RAID is not backup).


    RAID-1 only protects from a hard drive fail (happens not that often) and doesn't provide any more benefits. It's all about increased availability and reliability.


    If you are concerned about availability and reliability why do you choose then the most crappy platform possible? Every Raspberry Pis from a NAS point of view is just horribly unreliable and way too slow anyway.

    • Those things suffer from underpowering problems
    • The CPU has only one single USB2 connection to the outside
    • If you want to access USB storage you want to use UAS (USB Attached SCSI). Cheap SBC like an Orange Pi Zero for $7 can do UAS but Raspberries not (they're only capable of the old and slow BOT mode)
    • Every disks connected to a Pi is behind the same internal USB hub
    • Even the Ethernet interface is behind the internal USB hub
    • On RPi 3 B+ it's not just one internal USB hub but two cascaded ones (they managed to make things even worse)
    • All devices behind these internal USB hubs have not only to share bandwidth but add to USB bus contention problems
    • The internal USB hub is a so called SPoF (single point of failure -- RAID is all and only about eliminating those!!!)

    Adding to this: to access USB disks flawlessly you need a perfectly working USB-to-SATA bridge inside the drive enclosure (99% of USB disks connected to a Pi do not apply). RAID rebuild times are horrible since bottlenecked by the single USB2 connection and shared bus. The time a rebuild takes your array has no redundancy any more. Such a RAID rebuild is disk and bus stress. What if now the most prominent SPoF on these thingies fails? When the internal USB hub decides to fail with heavy RAID accesses your whole array is gone instantly.


    RAID with USB disks is already insane given the many problems that prevent reliable operation. USB RAID with all disks behind one USB2 hub is close to stupid. Do yourself a favour and don't try this. It's a useless waste of at least one disk and the setup will fail when needed anyway (RAID rebuild after a disk failure, maybe even before. Just search the forum or see here directly).

  • Thanks you very much for your explain. You have open my eyes for RAID via RPi. For me, RPI is not expensive. And the RAID it's just perfect for me for data protection (in addition to a backup).


    OMV it's just perfect for a home NAS. I use this :)

  • And the RAID it's just perfect for me for data protection

    Again: RAID does NOT provide any means of data protection. It's only about increased availability (one disk fails but operation can continue without manual intervention -- that's the idea, often it doesn't work that way since hardware is too crappy, users do not test appropriately and are then surprised that their whole array has gone with the first failing disk).


    Availability (business continuity) is all what RAID is about (leaving aside the performance aspects when running larger RAID arrays on server grade hardware and not on toys).


    If you do RAID for data protection then you do it wrong. If you want to play RAID on a Raspberry toy you're doing wrong too. The hardware is way too unreliable to be able to increase reliability or to provide higher availability.


    If you're fine with abysmal NAS performance and some reliability issues then a Raspberry Pi is fine as single disk NAS. But that's it. And for the low performance these things are way too expensive.

  • >Again: RAID does NOT provide any means of data protection.


    Mirroring and RAID-5 protect your data against hardware failure. If you had a single hard disk (with no backup) and this disk failed, then your data has gone. With mirroring, one drive can fail and you don't lose your data. Is that not data protection? Sure, it's not a backup but to say it doesn't give any form of data protection is IMO a bit misleading. RAID is about data protection, maintaining up time and improved performance.


    >If you're fine with abysmal NAS performance


    I appreciate that using a Raspberry Pi NAS in a business situation is probably out but what about in small business or home media server? I've ended up here because a friend was asking about cost effective NAS solutions and OpenMediaVault seems perfect. I've just done a test install in a virtual machine to play with the functionality. I happen to have two spare 1TB 2.5" disk drives and a 32GB memory card which we can re-use.


    A client of mine has a QNAP TS-869 Pro which comes with 1GB RAM and a dual core Intel Atom D2701. The Raspberry Pi 4B compares pretty well with this.


    >some reliability issues then a Raspberry Pi


    What reliability issues exist? This is all new to me so just learning about what's possible.

    • Offizieller Beitrag

    While this is a terrible idea with usb drives not just the RPi, if you really want to use raid on an RPi with OMV, all you have to do is create the array from the command line. You can do everything else from the web interface. Just don't complain here when you have issues with the array assembling. This is a much greater and likely risk potentially causing you to lose all data than a drive failing.


    RAID is about data protection, maintaining up time and improved performance.

    Doubtful you would see improved performance on usb drives sharing a usb hub. And raid is about availability not data protection. Backups are for data protection. If you are just going to mirror the drives, rsync'ing (or rsnapshot) them together is a much better option in my opinion. If you accidentally delete file(s), mirroring will instantly delete both copies where a scheduled rsync will give you time. Rsnapshot would give you multiple copies. Most home users don't need realtime mirroring.

    What reliability issues exist?

    There is no redundancy on the board. It is powered by a usb port. It costs $35 (yes, I know the 4GB rpi is $55). You shouldn't expect server grade reliability out of it.

    A client of mine has a QNAP TS-869 Pro which comes with 1GB RAM and a dual core Intel Atom D2701. The Raspberry Pi 4B compares pretty well with this.

    The QNAP is designed to be a NAS and has extensive development to make it works as NAS. An RPi is design to be a small desktop system with I/O to do fun things.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

  • The MAIN aspect of offering a RAID system is for redundancy. It's the FIRST letter in the name. Different RAID modes have been able to improve the performance (just because of the number of read heads available). They've also been able to provide higher data availability because of the redundancy of the system, but the initial goal was to provide redundancy. People at home DO also need this. I have a NAS on my home network that acts as a centralized file store. I've had it this way for MANY years. All of my photos, music and videos are stored there. My NAS has 2 drives in it setup in RAID 1. That saved my butt. A few years ago, one of the drives in the RAID died. If I had not had that second REDUNDANT drive, all of that data would have been lost. My brother just went through this exact same problem, but his wasn't a RAID setup. Guess what? All that data is gone now. Music and videos (non-personal ones anyways) are easy enough to replace, but all the photos and personal videos are gone.

    And you're half right when you say that RAID is not backup. But I backup to my NAS, and if it's not a RAID NAS, then if that drive goes, so to do my backups.


    Now, you can say that USB doesn't perform as well as a SATA connection right on the MB, or that the connection reliability is not as good. These may be true....depending on your use and expectations. But, ANY mechanism that helps protect data (I don't care if it's connected via a parallel connection or a 2400baud modem) is not a bad thing. If that is the only thing available, why would you block it's use? As long as the expectations of speed and reliability are spelled out, how could making USB drives available for RAID hurt?

  • recommend not using raid with usb and highly recommend not using raid on a RPi.

    This applies to software supported RAID and multiple drives connected via USB2 to an RPi3.


    One USB connection (especially using the 5Gbit/s USB3.1 or higher) to an enclosure providing hardware supported RAID is fine with an RPi4

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    • Offizieller Beitrag

    The MAIN aspect of offering a RAID system is for redundancy. It's the FIRST letter in the name. Different RAID modes have been able to improve the performance (just because of the number of read heads available). They've also been able to provide higher data availability because of the redundancy of the system, but the initial goal was to provide redundancy. People at home DO also need this. I have a NAS on my home network that acts as a centralized file store. I've had it this way for MANY years. All of my photos, music and videos are stored there. My NAS has 2 drives in it setup in RAID 1. That saved my butt. A few years ago, one of the drives in the RAID died. If I had not had that second REDUNDANT drive, all of that data would have been lost. My brother just went through this exact same problem, but his wasn't a RAID setup. Guess what? All that data is gone now. Music and videos (non-personal ones anyways) are easy enough to replace, but all the photos and personal videos are gone.

    And you're half right when you say that RAID is not backup. But I backup to my NAS, and if it's not a RAID NAS, then if that drive goes, so to do my backups.

    Raid does stand for redundancy. But the reason a business runs raid is to prevent down time. Very few home users will explode if their system is down while the restore from backups. And backups save your butt against data loss better than raid. What if a crypto virus hits your server? Both drives instantly have encrypted files. Worthless. If you using rsnapshot or borgbackup to periodically backup (most users would be more than good with every hour), then you would have multiple backups on the second drive to recover from a crypto virus OR a drive failure. If the backup drive failed, you still have your primary drive.


    So, none of your arguments actually justify needing raid. The do justify backups. And unless you have hardware with redundancy through the system, why have it just for your drives? I have actually seen more people lose their data because their array becomes corrupt. I haven't heard anyone unless with a periodic sync of the two drives.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

    • Offizieller Beitrag

    One USB connection (especially using the 5Gbit/s USB3.1 or higher) to an enclosure providing hardware supported RAID is fine with an RPi4

    I disagree and will keep recommending against it (plenty of experience owning a few and providing support for them to many people). I still think it is ridiculous to run raid (no matter what method) with an RPi. These enclosures are just as bad as the faux "hardware" raid on some motherboards.


    Just wait until the cheap power supply in that enclosure fails and/or the cheap sata connectors in the enclosure stop seating on the sata connector of the drive. I have had both happen and have helped people recover from both problems. Then you go to buy a new enclosure and can't find the same chipset because it isn't made anymore. You just lost your data.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

  • RAID is not a substitute for backup, RAID only buys time for fixing a disc failure.

    Why would there be a difference for usefulness of RAID using a PC versus a RPi4?

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    • Offizieller Beitrag

    RAID only buys time for fixing a disc failure.

    And most users can handle the downtime while they are fixing (as I said above) avoiding the complexities and problems that most RPi users won't understand.

    Why would there be a difference for usefulness of RAID using a PC versus a RPi4?

    If you are referring to a desktop-grade "PC", I would recommend against raid for that as well. More users accidentally delete things or get hit by viruses where raid doesn't help. And if all of your drives are tied up in an array, most users won't backup anything.


    Hell, I have server grade hardware and don't run (I did for years and years) raid myself. I would rather see people buy two RPis and connect one drive to each. With a periodic sync from one to the other, they have a great setup that is much easier to understand and recover from problems.


    I work all day long with enterprise-grade, redundant hardware. Very, very few OMV users (especially RPi users) need redundant anything. I guarantee they will benefit from backups much, much more.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

  • Just wait until the cheap power supply in that enclosure fails and/or the cheap sata connectors in the enclosure stop seating on the sata connector of the drive. I have had both happen and have helped people recover from both problems.

    this is a generalization using Fear, Uncertainty and Doubt (FUD). FUD was sales approach used by IBM in the 1970 to dominate the computer market. but by now they lost it. Can we please get back to a conversation based on facts?

    I don't buy into FUD reasoning without having verifiable examples.


    I.e. IcyBox has an external power supply, you can get a replacement literally "just around the corner".

    go to buy a new enclosure and can't find the same chipset because it isn't made anymore. You just lost your data.

    Good input I've verified it and at least for Icy Box IB-RD3662-C31 using hardware supported RAID1 the above prediction didn't come true, because plenty devices with same ASMedia chipset are available.


    Verification procedure used was:

    • shutdown RPi4
    • remove a drive from IcyBox IB-RD3662-C31 / hardware supported RAID1, disconnected USB cable from RPi4
      • Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
    • put the drive in an Inateck FD2005, USB-B 3.0 external HDD dock, connected USB cable to RPi4
      • Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
    • booted RPi4
    • connected SMB share from a laptop
    • it worked, all data was there, no change to OMV config required!

    By coincidence both HDD enclosures use the same ASMedia chipset: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge.

    I had bought them at very different times and wasn't aware of the chipsets until today.


    I'd call this the simplest recovery from a hardware failure, I've ever done!

    Would love to hear results from other OMV users trying the same approach but different chipsets.


    most users can handle the downtime while they are fixing

    this decision is what users have to take for themselves, hence not a technical reason.

    Note: many of these "home users" run a small business and use OMV as the backup server


    Very, very few OMV users (especially RPi users) need redundant anything.

    As above, again not a technical reason.

    they will benefit from backups much, much more.

    "backup" is a different topic and we agree "RAID is not backup"



    Given the positive technical proof for the error scenarios given above, does this change above statements?

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    9 Mal editiert, zuletzt von mi-hol ()

    • Offizieller Beitrag

    this is a generalization using Fear, Uncertainty and Doubt (FUD). FUD was sales approach used by IBM in the 1970 to dominate the computer market. but by now they lost it. Can we please get back to a conversation based on facts?

    I don't buy into FUD reasoning without having verifiable examples.

    FUD, huh? So, my experience personally owning at least five of these enclosures is FUD? I have few opinions on that but I will keep them to myself.

    Would love to hear results from other OMV users trying the same approach but different chipsets.

    Do you honestly think I am just making shit up? I have owned these things and had to rebuild arrays because of failures. Just because icybox happens to work doesn't mean every damn external raid enclosure works this way.

    As above, again not a technical reason.

    I honestly don't care if it is a technical reason. Since I have support users of OMV much longer than you, I have better feeling what works well for them. Once again, I see I can't say anything right and you are trying to change years and years of practices we recommend on this forum. Not sure what you goal is but I really getting tired of it....

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

  • Well currently my perceptions on OMV installations on SBCs (specifically RPi4) is that they are treated like "seconds class citizens" in OMV forum. "Years of practices and past recommendation" have, from my view, been invalidated by technical improvements delivered via the RPi4 and similar SBCs. RPi4 stands out of the competing SBCs, because of the global availability, coverage in tutorials and volume sold.


    It's time for a change in attitude towards this group of users and revised recommendations.

    An example to illustrate the topic, is to change recommendations from "no (software) RAID" to "only use hardware RAID using verified HDD enclosures".

    To support this technically the software RAID configuration application (mdadm) should be de-installed during OMV installation and the reasoning be explained in the "new user guide".


    Prediction is that "80% of use cases covered by OMV are well served by an SBC with external HDD enclosure connected via USB3"


    Does this start to make sense?

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    • Offizieller Beitrag

    Well currently my perceptions on OMV installations on SBCs (specifically RPi4) is that they are treated like "seconds class citizens" in OMV forum.

    Pre-RPi4 that is true. Rpi4 is a good board. I have three. And why would a second class citizen have very specific code in the install script?

    "Years of practices and past recommendation" have, from my view, been invalidated by technical improvements delivered via the RPi4 and similar SBCs

    Bullshit. I own and test most of the popular SBC boards. So, this is just nonsense. You may be referring to old threads but I am quite sure my current advice when people ask is as current as possible.


    It's time for a change in attitude towards this group of users and revised recommendations.

    Says who? You? I almost never see RPi users asking for recommended hardware. They buy what they can afford. It is almost always higher spec amd64 systems.

    An example to illustrate the topic, is to change recommendations from "no (software) RAID" to "only use hardware RAID using verified HDD enclosures".

    Why? Once again, you don't see to understand the budgets of a large number of sbc users. Your icy box enclosures may be nice (i have a few of their multi 2.5" to 5.25" enclosures) but most do not want to spend that much. And if they are using raid and can only afford two drives, where is their backup??? If they use borgbackup, not only do they have multiple backups with bitrot detection but they still have redundancy (you can mount borgbackup archives directly in the plugin). Your raid suggestion gives no bitrot detection or protection against crypto viruses or accidental deletion. Good thing their empty or encrypted drive is still working when one fails.

    To support this technically the software RAID configuration application (mdadm) should be de-installed during OMV installation and the reasoning be explained in the "new user guide".

    You will have a lot of fun supporting the destruction you cause by telling people to do that. mdadm is a dependency of OMV and you will uninstall OMV if you uninstall mdadm. mdadm is not a plugin.

    Prediction is that "80% of use cases covered by OMV are well served by an SBC with external HDD enclosure connected via USB3"

    Thank you captain obvious. Over 80% of SBCs don't have sata ports and have to use hdd enclosures. I said don't use usb raid NOT usb hard drives.

    Does this start to make sense?

    Only in your head. Unlike you, my recommendations are formed by interacting with users to see what they need NOT what you think they need. Since you preach continuous improvement, you should know that one important factor is customer satisfaction. Can you show me someone unhappy with my recommendations? Or even someone who would have avoided a serious issue if they were using your recommendations?

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

  • Such pedantic toxic tone here people. Let’s analyse.


    Premise:


    - RAID 1 to protect from disk failure and RAID 0 for performance (oversimplified, sorry.)


    - Other than HDD, many components along the pipeline of storage can fail. So, RAID 1 is solving only against disk failure. You should check everything in system should be replaceable to a reasonable degree.


    - Backup to another complete separate system is literally the best since it has all the ingredients of RAID + easy duplication of hardware too (also eliminating need to find exact duplicate hardware.)


    - the only reason why RPI4 should not be considered is because it’s not “purpose built” for storage and has more things between your data and you that can go wrong. Having said that many commercial NASes are SBCs with onboard SATA and specially tuned OS as the only difference between Pi 4)


    - everything can go corrupt or fail in various degrees of MTBF. Hence the only way to have peace of mind is reduce the number of things that can fail and use only high MTBF stuff


    Practical:


    - it may not be feasible to have two systems (for whatever reason)


    - the joy of diy creating NAS is priceless


    - if creating worthwhile NAS needs a PhD, that defeats whole purpose of OMV and this community.


    - at times, there’s just another spare disk than a spare SBC and hence many want to use it than waste it.


    - setting up differential backup has been historically tricky unless you’re using TimeMachine or some other proprietary software and as such has a bad rap among many. (Cue for OSS developers here to make their work more accessible for the masses.)


    - the backup method is also not that “cohesive”. If your backup fails / or main NAS fails, re-setting up backup is not like swapping drives but repeat of same multi step setup of the syncing software.


    All things said, I have a NAS that I use for actual backup and that has RAID. I went commercial WD NAS so that I can avail their service. This is where I store very very priceless data. On the other hand I have one RPI4 with one USB HDD and OMV that also syncs (backup) to my WD NAS.


    Best of both worlds.

  • @ryecoaaron:

    I research a few hours and found NO deliverable arm based board with more than one native SATA connector (ignoring add-on PCIx cards, which would add complexity).

    Therefore, based on your statement, you can currently only build an arm based OMV-NAS without RAID. That is disappointing.


    I hope, that as some point you remove the additional code, that blocks using USB(3) disks as RAID.

Jetzt mitmachen!

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