UnionFileSystem and Shared Folders -- single point of failure?

  • Hi friends. I'm trying to tease out some details of a home project and running into a pretty glaring question that I'd like clarification on. For context, I run an Ubuntu 18.04 server at home which has 4x3TB in a RAID6 via MDADM. This is my main server which houses all data, backups, etc. I have a 4TB external drive which I store at work and bring home once every 2 weeks or so to punch through an rsync script, thereby retaining a copy of my most important data offsite. I want a middle man, something at home that runs every day/every other day, etc. Given I had a bunch of 1TB drives on the shelf, I figured I could build a pool stitching all the drives together and leverage that.


    As it stands, I have a box with OMV installed and 5x1TB HDDs. I could use RAID 0, but we all know one drive would pop the whole array, so I nix'd that. Currently I'm tinkering with UnionFS provided by the plugin from the extras repo. I set everything up and decided to experiment with a drive failure by me removing a hard drive from the pool. In a perfect world, removing one drive from the five drive UnionFS pool would result in a 20% max loss (1TB HDD of 5TB HDDs in my case) of data, but the remaining drives should still be there and accessible via the UnionFS mount point. To test, I did the following:


    1) Created UnionFS file system
    2) Created shared folder by targeting the UnionFS volume
    3) Copied 2GB of data to the UnionFS volume
    4) Checked individual disk usage in OMV
    5) Took note /dev/sdc is where the 2GB file went
    6) Removed /dev/sdc from the volume
    7) Noticed my entire shared folder volume was gone via SSH despite the shared folder still being set in the OMV UI


    If I replace step 6 with any other drive in the volume besides /dev/sdc, the volume remains intact. To test this theory further, I blew it all away and rebuilt the UnionFS setup. I created a shared folder entitled "data". Via SSH I ran tree and here's what I found:



    In this case, the "data" shared folder was placed in ac5e3 (the UnionFS mount point) and also /dev/sde. Clearly this is what I ran into in steps 5 and 6 above. Given that the shared folder gets explicitly placed on an individual drive, it stands to reason if I happen to lose that exact drive that my entire volume could be in the crossfire, whereas if I lost any drive except the one that retains the data shared folder, I'd be in much better shape.


    With that said, I ask, is there a more appropriate way to set this up, or something I can do differently to mitigate this from happening? As I said earlier, best case scenario in my mind is that I can lose any drive and I'd only lose the data pertaining to that particular drive. But if I can lose my shared folder in the process (effectively the parent folder containing all data on this volume), it appears as if I can lose my link to everything in the event I lose that specific drive where the shared folder resides.


    Note: This is not a mission critical box and I understand all of the downsides surrounding spanning drives across a single volume. That's not really the point, as the point here is to employ an available tower and available drives small enough I'd never use as my main server but in a meaningful way as it's hard to sneeze at adding another box in your LAN which acts as another backup resource.


    Thanks for any insight!

Jetzt mitmachen!

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