Solved? OMV and software raid 5

I read the thread and I'll add my 2 cents.
_____________________________

First, if you want to check out the details of what it takes to do something in OMV:

I'd highly recommend setting up Virtual Box, preferably on a client with more than 4GB of ram, and install OMV in a VM. You'll have the freedom to test plugin's, storage scenarios, etc., etc., without consequence.
(You'd even be able to snapshot a build, at a particular point, where restoring a broken install or back tracking would take just a few minutes.)
While VM tests would not be all inclusive, where specific hardware bits and pieces are concerned, there's nothing like first hand experience. It's far better than a HOW TO guide.
____________________________

On the subject of RAID (software or with adapters):
RAID, for the home user, is just not a good idea. Why? Here's a post I wrote awhile back on RAID, backup, data considerations, etc. Thoughts on RAID
In short form; RAID is a data center / server farm solution where experienced IT staff is available and real backup is the norm, not the exception.

ryecoarron is right on when he says the forum tends to avoid RAID questions, RAID How To's, troubleshooting, etc., because, well, RAID is a rabbit hole with outcomes that can be bad.
- One user wanted to know how to expand a RAID5 array. I provided the command line to do it and the array died at the beginning of the resilvering process. ((All he knows it, he asked a question and the answer trashed his array. There's ZERO upside to that.)) That kind of thing happens all the time. The user said he had backup up before he started, but we'll never know. I hope he did.

As arrays grow to stupendous sizes that are chock full, all the while their disks are growing older, the likely hood of the array being backed up regularly diminishes as the chances of failure begin to rise. Unfortunately, it's part of human nature. We get comfortable with something working, start taking short cuts, and then the failure comes along.
______________________________________________________________

If you're concerned about "disk efficiency", again, backup is less likely. Usually, that kind of thinking tends to lead to RAID5. It seems most users want to squeeze out every last GB of space when, as a matter of practice (if you want some elbow room), your storage media shouldn't be more than 50% filled. As a starting point, I aim for 25% or less.

In my scenario, I have a bit over 1TB of data (e-mail, files, music, photos, personal vid's) that I refuse to take chances with. I have a ZFS mirror with 2x4TB drives. That's roughly 8TB of disk storage for a bit over 1TB of data. Yes, I'd doing ZFS RAID1 for its bitrot protection and file scrubbing, not for data redundancy or the notion that RAID is backup. (It's not.) I view the RAID1 mirror as a single "4TB disk" because, functionally, that's what it is.
I also have a single unbacked 3TB disk (formatted ext4) for client images. The redundancy here are the clients themselves, versus the stored client images.

For data backup, I have 3 independent devices with full copies of what I have on my server, that go back in time. They are 1 day old, 1 week old, and 1 to 2 (or more) months old. While some might argue that's not true backup, I believe it is and it has served me well. (I've lost nothing since I started and, in years past, I've recovered from some serious events.)
I'm mentioning this because even with a separate internal drive for backup, PC's can fail in such a way to where all connected drives are toasted or their data is otherwise lost. Duplicating data to another independent host is a good idea and it doesn't have to expense. An old repurposed PC or laptop would be fine.

______________________________________________________________

With that said there are numerous drive pooling techniques that don't involved RAID.

Symlink's are a simple way to pool drives without actually pooling them. Just drop a Symlink folder in the root of your first data drive, that redirects to drive 2. Simple and elegant. On the other hand, if you're constantly adding data, you'll have to mind the fill rate. (In any server scenario, at least some admin is unavoidable.)

If you must have a common mount point, MergerFS is another way to do it. Along with Symlinks, MergerFS is among the best choices in my opinion. If there's a drive failure, only that drive is affected. It will merge different file systems (which remain separate and intact below) and, if you find you don't like MergerFS, it can be removed without data loss.

LVM2 is a pooling technique. It's been in use for awhile now but it has it down sides. It must be set up on a disk before the first file system is installed. In essence, it requires a bit of planning, where MergerFS and Symlinks don't. LVM2 is not unlike RAID in that it has specific CLI utilities and commands. In a similar manner, the loss of a drive can create unnecessary headaches with the remainder of the drives in the volume. (Also, LVM2 writes flags at the partition level that can be stubborn when attempting to repartition a drive, but it's nothing that Darik's Boot and Nuke can't remove.)
_______________________________________________________________

In the bottom line you can use any or even all of the above safely, to include RAID in any flavor, if you have solid BACKUP. However, as ryecarron has suggested, the KISS principle should be observed. "Simple" is always a good rule of thumb.

I'm going out of town for 4 or 5 days. If you want a ZFS mirror or some other form of RAID array, post what you have in mind. I'll put together a short "How To" with some screen shots when I get back. (If it's ZFS, I can provide a few command lines for a bit of necessary maintenance, along with automation and reports.)

Zitat von weebnuts

Don't worry about it... I will help you if I can.. Let us know how your tests go

Sent from my HTC 10 using Tapatalk

weebnuts;

If you have something to contribute, please feel free. (I'm not trying to barge in and take over.)

With that said, your willingness to help is sincerely appreciated. That's what the forum needs, practical, usable, advice offered in a friendly manner.

Thanks

ZFS:
The only reason why I'm doing a RAID mirror at all if for ZFS's check sums, self healing, and bitrot / data integrity. Otherwise it would be ext4. (I really like BTRFS but much of what I want to use is still in Beta. I see it as risky.) While I think CoW files systems are great, a giant step in the right direction, rescue utilities for data recovery are thin and still in the making. This is another reason why solid backup is a must.
_______________________________________________

Building OMV:
I'm not sure why you want to build Debian first and add OMV as a package. If you use the integrated OMV build, from Source Forge, Here you'll get tighter integration meaning that updates, security and other, should go more smoothly. (And, in that scenario, if there's an update or upgrade problem, OMV developers will be on it or, at least, have advice to offer.) If you want to use VMware, you can download the integrated OMV package and build it in a VM. Just a thought.
_______________________________________________

On 4GB of RAM:
Based on what I've heard / read, I expected ZFS to be a memory hog. From what I've learned in using it, ZFS doesn't actually use a ton of ram. As it seems, a lot of ram is only needed if deduplication is enabled. In my scenario, I'd never use dedup.

If you decide to go the ZFS route, there are a few features you'd need to activate if you want a permissions environment that is the same as ext4. It's an easy to do.
_______________________________________________

One last blurb on RAID:
RAID 5 is about "availability" (as in uninterrupted 24x7 operations) where customers complain (scream?) if they can't access their data when they want to. (Day or night, weekends, holidays, etc.) It's not for data redundancy. Some redundancy is achieved with a RAID1 mirror because, if a disk fails, its mirror disk remains and can stand alone. (In theory.) A viable RAID5 array is always co-dependent on multiple disks. Even with that distinction noted, as I mentioned before, I still see my ZFS mirror as a "single disk". For the purposes of provisioning backup, it's treated accordingly.

_______________________________________________

A "Clonezilla server":

I've seen the server feature but never pondered its use in a practical application. You must build a LOT of clients. In any case, if you build another server, consider using ECC. It doesn't have to be expensive. I got my server (in the signature) ready made, with 8GB ECC, no hard drive or OS for a bit over $200. (I added a used 4GB ECC stick, for about $20, from Ebay, for a total of 12GB.) There are a few good barebones deals out there, similar to that.

Given what it seems you're doing at work:
Could you use a client backup package, with a bare metal restoration utility, that runs from a single CD / USB drive? Take a look at UrBackup. The plugin integrates it into OMV. Restorations are fast and easy.

______________________________________________

I'm out the door. I'll post on return.

In the interests of full disclosure, note that I'm not a Linux "expert". Much of my background is in enterprise networking. I've had exposure to Solaris, on Sun workstations (DNS servers, networking utilities and consoles), which is very similar to Linux, much as Spanish is similar to Italian. Back then, in a server build, partitioning a drive correctly seemed to be the worst of it. In the rest, the form followed function.

I did a couple years as a site admin back in the day, as one of about 4 hats that I wore at the time (OS2 server and Win3.11 for Workgroups). As time rolled on, I've worked with various flavors of Windows Server (w/RAID 5), from WinNT 3.51 and up. I've taught LAN management and LAN installation (site setup) classes. Only toward the end did VMware for server provisioning, NetApp storage arrays, and Citrix Terminal servers cross my path. (I wasn't a fan of them, at the time, because such techniques are all about centralization.)

In the bottom line, I don't have a lot of direct experience with what you're attempting to do but I may be able to help with pointers for setting up and in avoiding many of the pitfalls that cause trouble.
______________________________________________________________

You certainly have an interesting "use case" - which seems to be a custom created and carefully tailored solution that resulted from incremental improvements, over time. You seem to be very conservative in your approach (we share that BTW), which keeps you in business (always good). Further, I imagine your customers appreciate being "recovered" from disasters that they create, but are not prepared for. What's important to note is, you don't have the typical use case of an OMV home user.
______________________________________________________________

The first thing that should probably be mentioned are some of the applicable attributes of ZFS. In my application and approach, I'm looking strictly at data preservation. For disk space purposes, I provision for 4X my actual requirement (The actual requirement is a bit over 1TB). And since my focus is preservation and integrity, I'm using a ZFS mirror. By extension, my disk requirement is 8X the actual data requirement. That equates to 2X4TB drives.
((Why? In a scrub, ZFS will compare the 2 file copies in the mirror and, if there's an error, it restores a corrupted file with the 2nd copy of the same file that passes its check sum. And I go further than that, and replicate data to 3 more devices with a minimum of 1.5TB of storage each. I mentioned this before.))

in your case, depending on the number of unique customer clones your have, 8X the actual data requirement may not be realistic. ((I do know that an unpopulated hard drive - or your version of "factory defaults" - is much smaller than the a typical user workstation drive becomes over time.))

In any case, ZFS in the equivalent of RAID5 (referred to as RAIDZ1), might be what you should consider for data storage. Here's a nice synopsis of the various types of "Z" array, what they give you space wise, etc.
ZFS The examples are using 8 drives and multiple VDEV's (drive groups). In practical application, the 8 drive examples are unrealistic. ((Even with a purpose built server, something that can be bought on Ebay, attaching a ton of drives to a single server is the equivalent of putting all your eggs in one basket.))

Outside of a purpose built server provisioned with several slots (Example), 4 drives is about the limit for any single array in a SOHO environment. (Based on reliability and other factors, this is my general opinion.) If you do RAIDZ1 (1 parity drive), I wouldn't go higher than 4 drives (3 data + 1 parity). You could stretch it to 5 total, with a purpose built server, but that's living somewhat "dangerously". (As the number of drives go up, so does the probability of failure.) At 6 disks, RaidZ2 is more realistic but the cost is 2 parity drives so you'd only have the space from 4 drives. Depending on the needed size of the array, I believe a 4 drive RAIDZ1 (+1 parity RAID5 equivalent) to be the best bang for the buck.

With RAIDZ1, you get check sums for data integrity and scrubbing, and a 1 disk fault tolerance in the event of failure. For the benefit, 1 disk is not excessively expensive. On the other hand, "TK" is correct; disks can fail in ways that take out the entire array. Accordingly, if I was you, I'd replicate my entire data store to at least one other, independent, device. That device, your backup, can be simple storage pooling using Symlinks or MergerFS.

Lastly, while some are quick to adopt new tech, I'm a bit on the skeptical side until it's proven. As I look at the hard drive market, which is pushing to ever greater storage levels, I keep a few things in mind.

- There's no such thing as perfect magnetic media.
- The bigger drives become, the greater the chance of failure (premature or otherwise).
- As drive sizes get larger, a premium for "large real-estate" seems to be assigned. (Where an 8TB drive can cost as much, or more, than 2x4TB.)

As I balance the above against the probabilities of failure, I prefer drives in the 2 to 4TB range, and I would prefer 2 each 4TB drives to a single 8TB. (I see the 8TB "shingled" archive drives, and other technologies, as experiments in progress.)

______________________________________________________________

On the first server - "A Debian Server for VMWare and cloning". I imagine this is a unique creation with at least two available sata ports for cloning drives. (Is the side of the server is open, with cables dangling? That's how I do it. ) Further, I'm guessing that you have a backup restoration method for the boot drive.

I would ask, from the post above, why do you need a RAID array (or the equivalent) for data storage on this particular server? Do you want to keep a certain number of drive images resident? If so, what's the space requirement? Also are copies available in another location, for the data on this server?
______________________________________________________________

Regarding: "OMV on 7 computers being used for storage": (Are these repurposed consumer PC's?)

This is the crux of the matter. I imagine that these boxes are the source/destination of all your client clone copies. Based on an earlier post, I'm guessing that the clone copies are organized alphabetically..??

Here are a few questions for you:

1. What is the total of your storage requirement, presently?
3. What is the data to be stored, primarily? (Factory default drive clones? Rough size of each?)
4. How many storage drives are in each OMV server?
5. What file system are you using?
6. Memory in the OMV boxes?
(While I don't know the parameters, or their reasons for suggesting it, ZFS pro's suggest 1GB RAM per TB of storage but that's in a file server / server farm application. (Which equates to a LOT of traffic with concurrent users.)
Without "file deduplication", the ZFS on Linux project recommends a minimum of 2GB. (See Hardware) In your scenario, with OMV, I think you'll be fine with 4GB ram. OMV will work with 1GB (on Raspberry PI's and other SMB's) In your scenario, that would leave the remaining 3GB for ZFS.

Finally, how critical do you see this data to be? Meaning, if you lost some or all of it, what would be the consequence? (I imagine there may be "classes" involved. ?TB is critical, where ?TB is important, but not critical.)
______________________________________________________________

Really, as it seems from the thread, your considerations may to be more about data organization than anything else. Of course getting the right storage structure would help, and go a long way toward preventing a potential disaster.
______________________________________________________________

Finally, the following two items, if you're not already using them, may make managing all of those server boxes a bit easier.

1. WinSCP This app will log into any of your Linux boxes using SSH, from a Windows client, as root. (If you have no Windows clients, WinSCP will run in Linux' WINE without issues.) You'll get a graphical representation of the file structure, you can directly edit config files, etc. Since you're in there as root, you can create, delete and edit permissions. Good stuff.

2. OMV's Remote Mount Plugin.
The remote mount plugin will allow you to mount a remote data share, in OMV, as if it's a local hard drive. If the user name / password combination has write access to the remote share (root?), you can manage the remote share locally. I use it to avoid the need for an Rsync server. (With remote mount, Rsync replication jobs are local. No server required.)