JonathanM

I think adding a warning requiring typing YES to acknowledge before the wipe command is executed would be sufficient. Maybe it would be a good idea to add a new section to the "New Config" area to manage the resetting of pools. Limit the current new config reset to parity array only, and add individual line items for each currently defined pool.

Arguably the parity drives are the LEAST valuable, as when they fail you have no data lost, and the chances of losing data then rests on the data drives. Here is how to best visualize this. 2 parity drives allows for 2 simultaneous drive failures, the 3rd failure will cause the total data loss of all failed drives. So, no data loss until the 3rd failure. If the 2 parity drives fail, and then a data drive dies, you ONLY lose that single data drive's content. If 1 parity and 2 data drives die, you lose both data drives worth. If, and here is the takeaway, both your parity drives are fine, but you lose 3 data drives, ALL the data on ALL three drives is gone, and the 2 parity drives can do nothing to recover any of that data. So, best case scenario, in a 3 drive failure, is for BOTH of the parity drives to die. If you have less faith in a particular drive because it's not "new", then the best place for it is in a parity slot where it can do the least harm if it fails. Now, the parity drives do get writes for every bit of data sent to any drive in the parity array, so I'm not saying use junk drives for parity, just statistically speaking you want the parity drive(s) to fail, not the data drives.

Safe mode

Not necessarily that specific adapter, but yes, a wireless game adapter, or some other piece of equipment that translates WIFI into wired ethernet. Some routers can be reprogrammed to serve that function, and they typically work better than the game adapters.

I realize this isn't what you are asking, but just saying, "nothing beats the bandwidth of a station wagon full of tape backups". Have you considered getting the system initially synced locally, then just doing differential syncs over WAN?

Why?

So did the domains share move to the vm_machines pool?

Move the vdisk from the array to the pool using dynamix file manager or mc at the console or whatever your favorite file manager is, then change the VM XML to point to the new location. Or, to make it even simpler, assign the pool as the primary location for the domains share, assuming the vdisk is in the domains share, and the array as the secondary location with the mover set to move from the array to the pool. This assumes your pool is big enough for all the content of the domains share.

You can encrypt just a single drive in the array if you wish, and any shares on that drive will be encrypted. You would need to copy all data off of that drive before changing it to encrypted.

Because the boot drive for Unraid has to match the license file.

If you leave it attached I think it will still be detected as a pool member, whether it's in the logical slot or not. Wait for @JorgeB to confirm, but I think you should probably be able to substitute wiping the mbr / partition table instead of physically removing it, but I'm pretty sure you can't allow it to be found as a former pool member.

It would be nice to have in the GUI, but it's fairly easy to do with scripting if you wish.

Flipping the switch on the PSU kills power to the motherboard, then you need to press the normal power switch to drain the residual power in the capacitors in the PSU and on the motherboard. No need to leave it off for long, just so the motherboard has no more power to maintain the failed state, and has to reinitialize from a known state.

??

Not a universal issue, works here.

Have you shut down, removed power and discharged the PSU by hitting the power button while the power is off, then started back up?

Ideally you would remove all the spinning rust drives and put them in a drive carrier meant for shipping, each drive gets its own impact absorbing compartment. Another issue is the CPU heatsink, they are typically rather heavy, and not always securely fastened to the board. If it comes loose it has sharp corners that can ruin the motherboard and any PCIe cards it hits inside the case.

2 parity disks allow the failure of any 2 disks simultaneously without losing data. If you could arrange it the way you propose, then if both 16TB drives died, you would lose the information on the 16TB data drive, with no recovery possible.

Best policy is to stop the container when it's not needed. Start it when you want to use it, and stop it as soon as you are done.

The reason there isn't a guide is largely because intel tends to just work with default settings, unlike amd which can be a project just to get running smoothly. Sure, intel can use some tweaks for certain situations, but it's much less hassle to get running.

Building a second server is always better IMHO, that way when you experiment just a little too much it doesn't effect your daily routine.

Reformat will erase the drive, including what is emulated by parity. Parity doesn't hold files, it has the entire drive, filesystem and all. If you reformat it updates parity and the rebuilt drive will match.

See here. https://forums.unraid.net/topic/48383-support-linuxserverio-nextcloud/

Try using

Try using a different ethernet emulation.