Hey again! I’ve progressed in my NAS project and I’ve chosen to go for a DIY NAS. I can’t wait for the parts to arrive!

Now I’m a bit struggling to choose an OS. I am starting with 2x10To HDD + 1To NVMe SSD. I plan to use 1 HDD for parity and to add more disks later.

I plan to use this server purely as a NAS because I will be getting a second more powerful server some time next year. But in the meantime, this NAS is a big upgrade over my rpi 4, so I will run some containers or VMs.

I don’t want to go with TrueNAS as I don’t want to use ZFS (my RAM is limited and I’m not sure I can add drives with different sizes). I’ve read btrfs is the second best for NAS, so I may use this.

Unraid seemed like the perfect fit. But the more I read about it, the more I wonder if I shouldn’t switch to Proxmox.

What I like about Unraid is the ability to add a disk without worrying about the size. I don’t care much about the applications Unraid provides and since docker-compose is not fully supported, I’m afraid I won’t be able to do things I could have done easily with a docker-compose.yml I also like that’s it’s easy to share a folder. What I don’t like about Unraid is the cache system and the mover. I understand why the system works this way but I’m not a fan.

I’ve asked myself if I needed instant parity for all my data and if I should put everything in the array.

The thing is that for some of my data I don’t care about parity. For instance, I’m good with only backing up my application data and to have parity for the backup. For my tv shows I don’t care about parity nor backup while I want both for my photos.

After some more research, I found mergerfs and snapraid. I feel that they are more flexible and fix the cache/mover issue from Unraid. Although I’m not sure if snapraid can run with only 2 disks.

If I go with Proxmox I think I would use OpenMediaVault to setup shares.

Is anyone using something like this? What are your recommendations?

Thanks!

  • TCB13@lemmy.world
    link
    fedilink
    English
    arrow-up
    19
    arrow-down
    11
    ·
    edit-2
    9 months ago

    Use Debian, no need for those over bloated systems. BTRFS as filesystem. Then setup LXD/Incus to run containers and VMs and you’ll get a very Proxmox like experience without the bloat or the nagging to buy licenses.

    Some people also like Cockpit which comes with a nice UI, has basic virtual machine management features and has a Samba plugin to manage users and shares.

    • VelociCatTurd@lemmy.world
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      4
      ·
      9 months ago

      I’m going to disagree with this. I’ve setup everything in one Debian server before and it became unwieldy to keep in check when you’re trying new things, because you can end up with all kinds of dependencies and leftover files from shit that you didn’t like.

      I’m sure this can be avoided with forethought and more so if you’re experienced with Debian, but I’m going to assume that OP is not some guru and is also interested in trying new things, and that’s why he’s asked this question.

      Proxmox is perfectly fine. For many years I had an OMV VM for my file server and another server for my containers. If you don’t like what you’ve done it is much easier to just remove one VM doing one thing and switch to some other solution.

      • 9488fcea02a9@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        2
        ·
        9 months ago

        end up with all kinds of dependencies and leftover files from shit that you didn’t like.

        I’ve been using debian for 10 years and never had this problem. Apt keeps everything very neat and tidy

        Are you downloading random .deb packages off the internet and installing them manually?

      • TCB13@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        6
        ·
        9 months ago

        I’m going to disagree with this. I’ve setup everything in one Debian server before and it became unwieldy to keep in check when you’re trying new things, because you can end up with all kinds of dependencies and leftover files from shit that you didn’t like.

        Run your new things inside Docker OR LXD/Incus and destroy the containers/VMs when not required anymore. I don’t get your comment.

        Proxmox is perfectly fine. For many years I had an OMV VM for my file server and another server for my containers. If you don’t like what you’ve done it is much easier to just remove one VM doing one thing and switch to some other solution.

        And you can use LXD/Incus for that as described. LXD replaces Proxmox the difference is that it isn’t an entire OS with quirks but a simple thing you install on Debian. It will allow you to create, move, remove VMs and containers, and also has a WebUI for those interested. The irony here is that in your Proxmox setup, if you’re using containers, you’re already using LXC containers, a technology effectively created by the same people who made LXD.

        But as I said, even if you don’t want LXD/Incus you can also use Cockpit, it also provides a WebUI you can use to create and manage your VMs.

        • VelociCatTurd@lemmy.world
          link
          fedilink
          English
          arrow-up
          6
          arrow-down
          2
          ·
          edit-2
          9 months ago

          Look, I never said you were wrong man. Clearly you probably have a lot more experience than i do. Which is why I said what I said. Because I personally believe Proxmox is way easier for someone who is a casual like me. That’s all.

          Edit: Also, though it doesn’t really matter, I don’t use LXC.

            • TCB13@lemmy.world
              link
              fedilink
              English
              arrow-up
              2
              arrow-down
              1
              ·
              9 months ago

              Think about it, if I was payed at least I was pushing for something that is actually useful and decent. :P

          • TCB13@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            arrow-down
            8
            ·
            9 months ago

            I personally believe Proxmox is way easier for someone who is a casual like me. That’s all.

            Maybe… maybe not. Proxmox has a ready to go ISO that will setup everything up and whatnot, that’s true, but there are also the hidden small costs here and there.

            I believe if you managed to install Proxmox, I’m sure you can install and use Cockpit without trouble. LXD/Incus might be another more complex weekend project but it still has an automated installer that asks you a few questions (and defaults work) to get things running.

    • jkrtn@lemmy.ml
      link
      fedilink
      English
      arrow-up
      3
      ·
      9 months ago

      I read a 2021 Ars Technica article on BTRFS and it was extensively critical, to put it mildly. Have things changed since then? I’m down with LXD or Incus but I don’t know if that’s the file system for me.

      • TCB13@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        edit-2
        9 months ago

        People like to complain a lot about things that aren’t particularly true. The default file system in Fedora and SUSE is BTRFS and I think that speaks volumes, besides others (including me) having been using BTRFS in production for serious stuff for years now. Even Synology is all up for BTRFS: https://www.synology.com/en-global/dsm/Btrfs

        There are also advantages of using LXD/Incus with BTRFS, most likely taking advantage of the sub volume features and snapshots so VMs and containers run faster (each machine gets a sub volume that works like a classic partition and is better / faster than a simple folder with files). Snapshots are also a good feature as you can use them to backup and rollback your base system or the containers/VMs as well.

    • Kwa@derpzilla.netOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      9 months ago

      Don’t I need mergerfs and snapraid with BTRFS?

      Also it’s not clear what LXD/Incus replaces? Is it Promox or Promox + OMV?

      • TCB13@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        10
        ·
        9 months ago

        Don’t I need mergerfs and snapraid with BTRFS?

        No. It’s just a FS like any other… actually it’s a proper filesystem unlike Ext4. Why would you need those tools? https://wiki.tnonline.net/w/Btrfs/Profiles

        Also it’s not clear what LXD/Incus replaces? Is it Promox or Promox + OMV?

        It replaces Proxmox and can run both containers and VMs, but it isn’t an entire OS, it’s just something you can install on a clean Debian system (from the Debian repository) and enjoy it.

        Some people also like Cockpit which comes with a nice UI, has basic virtual machine management features and has a Samba plugin to manage users and shares.

        • Kwa@derpzilla.netOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          9 months ago

          Thanks, I’ve seen Incus have an online demo, this is nice, I’ll give it a try.

          For BTRFS, if I understand correctly, I can have a similar result as mergerfs if I use SINGLE. But as RAID5/6 is unstable it seems I would still need snapraid, or am I missing something?

          • acockworkorange@mander.xyz
            link
            fedilink
            English
            arrow-up
            3
            ·
            edit-2
            9 months ago

            Btrfs is great, but you’re right that their own documentation advises against RAID in a production environment. People tend to use mdraid to achieve redundancy and Btrfs on top of it for the other features.

            BTW, you mentioned not using ZFS because of differently sized disks. That’s exactly one of the use cases for ZFS. Its RAID z1/z2/z3 modes provide for dynamic stripes that allow you to lose 1, 2, or 3 disks in a vdev, regardless of disk size. Oh and the ram thing is that it will use any idle ram for caching, to speed your disks. But it promptly releases it back to the system if another process needs it. Basically, the more ram you have, the more it will accelerate your disk operations.

          • TCB13@lemmy.world
            link
            fedilink
            English
            arrow-up
            3
            arrow-down
            5
            ·
            edit-2
            9 months ago

            “Need” is a strong word. But yes BRTFS RAID 5/6 is unstable but unless you’re only after space efficiency RAID 5/6 shouldn’t be used at all, those shames will put you on the worst position possible if something fails (and also low throughput). When you try to rebuild a RAID 5 with large drives it will probably go into days and you’ll be risking the failure of a second drive and lose everything right there.

            Btw, give a try to Cockpit as well. If you don’t require much of the advances features that Proxmox / Incus offer and just a bunch of VMs then it should be enough.

            • atzanteol@sh.itjust.works
              link
              fedilink
              English
              arrow-up
              3
              ·
              9 months ago

              “Need” is a strong word. But yes BRTFS RAID 5/6 is unstable but unless you’re only after space efficiency RAID 5/6 shouldn’t be used at all, those shames will put you on the worst position possible if something fails (and also low throughput). When you try to rebuild a RAID 5 with large drives it will probably go into days and you’ll be risking the failure of a second drive and lose everything right there.

              I’ve had a RAID5 for 10+ years, had drives fail and I’ve replaced them. Rebuilds are fine and rare. It’s very unlikely to have two drives fail within a week of each other and I don’t want to only get 1/2 my disk space. RAID6 makes that small chance even smaller. If you’re worried about loss you have backups - RAID is for uptime not recovery.

              You seem to think the way you’ve done things is the one and true right way to do it and that’s not the case.

              • TCB13@lemmy.world
                link
                fedilink
                English
                arrow-up
                1
                arrow-down
                1
                ·
                9 months ago

                You seem to think the way you’ve done things is the one and true right way to do it and that’s not the case.

                Not at all and I totally agree with what you’ve said. To clarify things, I’m not the only one saying people should stay away from RAID 5/6, even large vendors say that nowadays, and the issue is when a drive fails, if you’ve to run for hours to get a new one rebuild a second hard drive is highly likely to fail on that time - specially if they’ve the same runtime, model etc.

                Obviously that having a real backup will solve the issue, as long as you can retrieve the data from the backup quickly and cheaply enough and that’s not always the case.

                • atzanteol@sh.itjust.works
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  edit-2
                  9 months ago

                  if you’ve to run for hours to get a new one rebuild a second hard drive is highly likely to fail on that time - specially if they’ve the same runtime, model etc.

                  If you’re running a 2-disk RAID-1 you have the same problem.

                  And I restate - that risk is small. You’re not running a data center where you have thousands of disks to see the effect.

                  • TCB13@lemmy.world
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    9 months ago

                    And I restate - that risk is small. You’re not running a data center where you have thousands of disks to see the effect.

                    Fair enough, even though I’ve seen that effect in smaller setups than that.