OMV 5 + Full Disk Encryption (SSD) + automatically unlocked ecrypted RAID 5 (data drives)

  • Hey,


    I followed thegandalf's guide [HowTo] OMV 4.x LUKS Full Disk Encryption, unlock via SSH and successfully installed a fully encrypted OMV 5 that unlocks the data drives upon successful unlocking of the system drive via SSH (details see the HowTo). It is really great that the methodology worked perfectly in OMV 5 aswell! :)


    However, what I would want to achieve: Having the same setup BUT with RAID 5 instead of having individual volumes that are managed using mergerfs + snapraid. One article I found for doing that can be found here: http://thelinuxchronicles.blog…are-raid-5-on-debian.html


    My questions:
    1. Data drives: In this particular scenario: Is it recommended to have an encrypted RAID 5 in general (performance, possible problems if one disk is lost, possibility to add more disks)?
    2. System drive: Given that another SSD ist added: How would I install a RAID 1 for the system drive (SSD) in order to have a backup of the system drive? What other best-practices are there to backup the system drive?


    My use case of OMV:
    - Hosting of docker services (portainer)
    - Files: media + important files (goal is the get away from dropbox)


    My server:
    - Older Intel dual socket (2x Xeon X5672 ) + 48GB ECC Ram
    - 128GB SSD
    - 3x 4TB HDDs (Seagate IronWolf)


    It would be great if you were to give me general recommendations on that topic! :)

    • Offizieller Beitrag

    Clone the system drive.


    Make sure only use the system partition for the basic root filesystem. Don't install a lot of apps there and don't use it for storage of metadata databases and other app data. Then the system partition is rarely modified. Typically only during major updates or reconfiguration. And you really only need to make a new clone then. And if you keep app data away from the root filesystem it will only take up a few GB. Very fast to clone and restore. Store app data on some shared folder.


    Another benefit from having the root filesystem cloned is that you can very quickly recover from fatal mistakes. Just restore the clone image and carry on.


    If you don't have very good reasons otherwise (contractual obligation to maintain >99.99% uptime, for instance) skip RAID.


    Automatically unlocked encryption is silly...

  • Hi Adoby,


    thank you for your suggestions!


    So where exactly would you put the dockers themselves then (i.e. the docker storage which defaults to /var/lib/docker in OMV)? E.g. a nextcloud docker: The docker would reside on the system drive and the application files would be mounted to the data drives. According to the guide a set my system up with ([HowTo] OMV 4.x LUKS Full Disk Encryption, unlock via SSH), it is recommended to put the dockers and their config on the system drive; data drives pure data only.

    Automatically unlocked encryption is silly...

    Yep, my opinion aswell. But in my system, encryption is not automatically unlocked. When the NAS boots, the user is asked to unlock the system drive with a password; this password is provided via connecting to dropbear (SSH service running in initramfs) and unlocking the datadrive by providing the password. Afterwards - when having the unlocked system - the NAS boots and automatically unlocks the data drives by using key files that are ONLY stored on the (encrypted) system drive (in order to be safe, each data drive has a password for unlocking aswell)

    • Offizieller Beitrag

    Keep apart drive and partition. A drive can have several partitions. However, you might have to use other tools than the OMV GUI to make it so.


    The root filesystem partition I like to keep small and fast and easy to clone or restore.


    To achieve this you could create a separate extra partition on the system drive for /var/lib/docker or /var/lib or even /var. Especially if the system drive is a SSD. Perhaps 8 GB for the root filesystem and the rest of the SSD for /var/lib.


    Various app data folders, download folder, caches, metadata databases could either be located on the partition with /var/lib (if the SSD is big enough) or in a shared folder on a separated SSD or in a shared folder on a storage HDD. The advantage of using a shared folder for app data is that you then can use the OMV GUI tools to manage it. Backups and so on. And the advantages of using a SSD for docker images and app data are obvious. Say: Fast!


    If the system drive is a SD card or a USB thumb drive then, as long as you just have a few small rarely updated dockers you either could keep the docker images on the root fs partition or create an extra /var/lib partition on the flash memory as well. But I prefer to put the docker images as well as the app data in a storage drive shared folder. This help both performance and the longevity of the flash memory.


    Even if you have a SSD that you intend to use as system drive and some HDDs you intend to use for data storage, you still might consider putting the root filesystem on a USB thumb drive. And dedicate the SSD drive for docker images and docker appdata. Having the root filesystem on removable storage makes it extra easy to clone, copy and swap.


    If you use a SD card or a USB thumb drive as system drive, then you should also use the flash memory plugin, otherwise the flash memory will wear out quickly.

  • Thx again for the suggestions. Especially the use case for the USB drive ist interesting. I think I'll stick to having the following setup for now:
    - System drive (SSD) + dockers + docker configs / caches / metadata et cetera; encrypted and unlocked on boot via ssh
    - 3 Data drives (HDDs), 4GB each, each encrypted and automatically unlocked once the system drive is unlocked and booted; shall hold data for the docker services (e.g. nextcloud data); I'll also investigate the advantage of configs in shared folders

Jetzt mitmachen!

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