The issue revolves around bandwidth. For a RAID array to assemble, each drive needs (roughly) equal bandwidth. To achieve that, again in rough terms, SATA and SAS interfaces are capable of providing parallel data stream processing to each of the drives in an array.
USB, by it's very nature, is "serial". One drive is accessed at a time. While USB RAID can work, it's not reliable. As chente has said, there are examples on the forum.
If you're using an SBC (a Raspberry PI or other), there are alternatives to mdadm RAID that are very similar and arguably better.
Beiträge von crashtest
-
-
Man to have land like that.... My yard is about 14x14 meters.
By the meter, the property is about 264 X 167 meters. It's around 12 acres, with a clean stream running through. Roughly 6 acres is open fields. The rest is wooded with a nice selection of pines and hard woods. When I say we're out there, we are really "out there". We're just inside "the electrical grid". While we're at the hairy edge of DSL service (10mb down is about the best we can get), unbelievably, they brought a fiber optic cable us. (Frankly, that's shocking but it's a government sponsored program. We wouldn't have asked for it but we'll take it.)
_________________________________________________________________________
I lost the colony, in the previous post, to really cold weather early last fall. They didn't have a chance to spin up honey production before winter. In any case, I did what I could to give them a chance.
Moving on, I now have three colonies. Two are Carniolans and one, in photos below, is an Italian colony.
Following is how they "package bees". A package has a bit over 3 pounds of bees which is somewhere between 10,500 to 12,000 bees. They send them through the postal mail. When I went to be post office to pick them up, I noticed that the postal lady was nervous. She handed me the package in one of their (Government Only) plastic sorting boxes, "for safety".
I think it was so she wouldn't have to touch the package.
First, there's a piece of luan (really thin plywood) tacked over the feeder can hole. That's the first thing to remove.
_________________________________________________________________
Next is getting the feeder can loose so it can be pulled out. Bees can gum things up with waxy build up. (The feeder can is filled with sugar water. With 2 tiny perforations in the bottom of the can, the bees feed on sugar water and feed/tend to the Queen in route.)
Note the black strap. That's attached to the Queen cage.
The trick is to slide the can out while covering the opening with the luan plywood lid or bees will take to wing._________________________________________________________________
In the following:
The box is upright, the queen cage has been removed and the top opening is recovered.
Here's the queen cage. It has cork plugs in both ends. One end has a candy plug under the cork. The cork end, with the candy, is the one that's removed. With the cork removed, workers and the queen will eat through the candy to release her. If they don't (the candy is too hard) she's manually released by removing the cork at the other end.________________________________________________________________
I attached the queen cage to one of the hive frames with rubber bands. With that frame in the hive and some of the other frames removed to make room, this is how it's done: With a sharp rap to loosen the cluster and a lot of shaking and rolling the box around, bees are literally dumped into the hive. They immediately began to cover the closest frames.The removed frames are carefully reinstalled to avoid crushing bees and the hive is closed. There were some bees that wouldn't leave the box, so the box was placed on a bucket at hive entrance. With some time, the Queen's pheromones lured them in. (About an hour or two.)
________________________________________________________________________This colony is truly promising. With no resources other than a limited supply of sugar water, and with less than 3 full days in the mail, they created two pieces of comb about this size in the package box. Amazing. So far, of the the three hives, the Italians appear to be the most active. It will be interesting to see how they do.
-
Want to avoid usb sticks for booting, dont mind them for installing but just feel a sata ssd, is better,
I'll take two Thumbdrives (a working drive and a backup) over one high end SSD any day of the week. With the flashmemory plugin, thumbdrives last a good while. I've had a good quality thumbdrive last approximately 5 years, in an OMV server, through two versions of OMV. (I will qualify that and say that I don't have a lot of server add-on's, running from the boot drive, which reduces solid state media wear.)
Note that backup is only useful if it's easy to create AND easy to restore. When a server is down, that's not the best time to deal with a complicated restoration process. This is especially true when an upgrade takes out your server. Shutdown, pop in the backup, reboot and you're up again.
You might be surprised at how many boot from a thumbdrive.
Your call. -
Is there a step by step guide to
Backup the OMV drive (mines sata), like a usb to clone to another driveIts seems the addons should all work from 6-7?
Just want it so if anything doesnt work, its a case of revert back quicklyIf you're willing to boot from a thumbdrive, OS backup can be dirt simple. A thumbdrive is easy to clone and the clone is easy to test, before you'll need it. Restoration is a matter of minutes.
-> OS Backup
-
my last system was an asus intel board with an i5 and 32 gigs of ram with adata ssd 128. system drive.
my rant is this what hardware should i use to have it last more than 2 to 3 years? or is it expected to have something fail?
If you built the server yourself, from components, you've got to be careful about potential ESD damage. "Touching" the mobo's chip legs and solder points is a No-No. While some of the latest hardware has some ESD protection built into it, it's still possible to "zap" sensitive chips and you may not notice it. It doesn't take much.
During assembly, it's best to use a grounded static cuff. Without a cuff, at the minimum, first ground yourself on the case chassis and handle the motherboard and it's various plugin components (memory, etc.) at their edges when installing them.
-
Why are you working on the command line? OMV assumes that you're creating users, shared folders and SMB shares in the GUI. (I.E., there shouldn't be "sudo" anything, if you're working in the GUI.) If you don't work within the GUI, the server does not make the correct associations and log the changes into it's database.
For a test, follow this process -> Create a Network Share for creating a new shared folder and a new (SMB) network share, in the GUI. At the end of the process, the network share will be accessible to all users on the local network. This will be your starting point. After that, you could tighten up permissions on the shared folder, if you like, in accordance with the NAS permissions document.
Finally (assuming you're using a Windows Client), create a user in OMV's GUI that matches the username and password of your Windows client logon and you'll have transparent access, in accordance with the permissions set in the shared folder and SMB share layered on top of it.
If you're using a Linux client, that's another story altogether.. -
just so interesting to me when it goes up to 40-50% from 4-5% and get more or less stuck there regardless of what I do
Just about any copy operation, downloader operation, etc., will allocate unused ram to disk cache. It will stay allocated to disk cache until something else calls for it. Then ram is released to the app.
Note that Linux (and OMV) is very ram efficient. Both will run with as little at 512K. I personally have run Debian/OMV using 1GB ram, on an old model R-PI. Currently, I have a backup server with a ZFS pool (ZFS is known to grab memory) with as little as 4GB and an Atom CPU. I've had no problems. -
Give this a read -> NAS Permissions.
-
We (Helios64 owners) are currently experiencing significant problems when we try to use the script from...
https://github.com/OpenMediaVa…Script/raw/master/install
... to install the current OMV 7 on a Armbian Bookworm system.
You have to realize that you're using an unsupported "automated" Armbian build for Dev's only. Those builds are untested and unsupported, by Armbian and OMV. BTW: I'm in the same boat with an older SBC, the Rock64.
This is the CLI logon for the Rock64 and this is what you're seeing as well:
While I understand trying to get use some out of an older more specialized SBC, in the bottom line, it's not supported.
-
So, the script works fine, but not to do a fresh install. Still same problem with static IP
It should be noted, in the prescribed R-PI installation, that the first preinstall script must "execute" successfully. That means if a message like "could not resolve host" comes up, it has not executed successfully.
After the preinstall script executes successfully, a file named 10-persistent-eth0.link is created at the following location:
/etc/systemd/network
If the file is not there, the script failed and that's likely because be script's host couldn't be accessed. -
If the R-PI has been statically addressed AND it dropped out of the network, a rebuild is required.
-
This document might be of some help -> NAS permissions.
-
Install -> OMV-Extras. When OMV-Extras is installed you'll have access to a plugin called openmediavault-symlinks.
With the symlink plugin you can mount the new drive, as a folder, within your old 18TB. -
I am able to cd into the mergerfs with root, but normal users cant. What am I doing wrong?
How are you creating your shares? Are they created at the root of the mergerfs pool?
The reason for the question is:If you're nesting shares inside of a folder that's at the root of the pool, the permissions of the parent folder can affect the shares nested within.
Create a test share, at the root of the mergerfs pool, as shown in -> Creating a Network Share. Permissions will be wide open. -
If the scripts are that different, it should be possible for the plugin to config things for either script. We could have a checkbox to select which script you want.
And, possibly, one of those check boxes would enable @auanasgheps default script settings.
(A sort of, middle of the road, script for SnapRAID newbies.) -
Allright let's do this. I'll open a discussion/issue on GitHub so we can discuss it there.
Before this goes to github (where it will disappear for most forum users), what are you proposing? As noted earlier, the plugin already allows the customization of variables where, afterward (and saved), a Diff script is generated. With your version of a generated Diff, where the plugin is concerned, what would be different?
-
So, what am I to do to get this to work?
As noted above, the static IP address issue has been fixed.
If you've already built an R-PI and are using DHCP only, run the following script and reboot:
sudo wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash
**Note, after running the script, a reboot is required.**
After the reboot, static IP addressing in the GUI will work as designed.
_____________________________________________________________________________
Otherwise, when doing a new build, follow the standard ->build process. -
The static IP address issue has been resolved. As usual, the R-PI foundation pushed an unexpected change. In this case, it was the name of their repo.
-
Seems like the plugin (I assume that is what you mean by automation) could be enhanced if people provided suggestions.
I don't know. The plugin is pretty damned good as it is right now.
Setting drive recovery considerations aside:
Since a sync operation removes any chance of recovery of previously deleted or changed files, the real question is to when (or when not) to sync. That question, and where to set thresholds in the Diff section of the plugin, is a matter of the user's use case and personal preference.
- If a user wants to automate with Diff AND they're downloading everything under the sun, new files would have to be set high. (To allow a range that's typical for what they do.)
- If they're worried about losing files or, say, changed documents, that setting should be low.
What it really boils down to is, the user must familiarize themselves with how SnapRAID works, they must understand their own use case (their own wants and needs) and tweak Diff settings accordingly.
In this case, the plugin allows new users to focus on Diff settings versus worrying about the in's and out's of an actual Diff script. That's exactly what the plugin should do. -
In the interim:
After the OMV build, don't change anything in network settings. Use DHCP.
If a set IP address is required, use a "static DHCP lease" at your router's DHCP server. (If you don't know how to do this, check with the router OEM's web site on how to set a static DHCP lease.)
