JonathanM

Pretty sure you can preclear without starting the array, which means an expired trial should work just fine.

Previous content is irrelevant, clearing means writing zeroes to every bit on the disk, so many many hours is expected, especially since parity is calculated and written as well. Since you are replacing the parity drives, clearing the removed drives was not needed, and since you likely didn't complete the clear process anyway, keeping the original parity drives intact isn't helpful either. Just assign all the drives as desired and build parity.

Make sure you are in bridge mode.

Have you tried the USB manager plugin?

diagnostics?

Did you click on the blue icon link to the left of the serial number?

Could you please reformat one of those drives using rufus and see if it works after that?

Are you using the IPMI video chip? Many motherboards don't expose the iGPU unless you are using it.

Here is an example of a well constructed cable. https://www.amazon.com/dp/B009GULFJ0/ Here is an image of what to look for, generally. Notice the clear separations with distinct compartments for each cable. Avoid molded ends, the manufacturing process is so sloppy there have been many reports of fires caused by direct shorts inside the molded end, typically after the cable has been in use and experienced some normal heating cycles. The molex 4 pin end is not normally subject to this type of failure, as the wires have much greater separation. I do not think that word means what you think it means. Very few power supplies split their rails across connectors of the same type. Normally all the drive power connectors, SATA and 4 pin, will all be on the same rail, regardless of how many different strings of wires start at the PSU. But yes, if possible it's best to put each splitter on a separate wire set coming from the PSU. The goal is to limit the number of drives powered by any single set of wires. Each wire can only pass so much power before it starts to partially block the voltage, causing the drives to starve for power. SATA to SATA splitters are especially bad for this, as the tiny wires (comparatively) have much more resistance than the big fat wires and connectors in the 4 pin style.

If your Unraid is set up properly, the docker.img file is only a few minutes to recreate, and contains no user data, only common downloadable application run files. The only exception is any custom docker networks, they need to be redone before applying the previous apps download section. The appdata backup is all that is needed to recreate your docker ecosystem. That is taken care of already by this plugin as well, the libvirt.img is where the xml files live, so that's already done. VM's really need to be backed up with client software inside of the VM, I use Urbackup, it works well, and doesn't need the VM to be shut down to take a good backup. Any attempt to back up the virtual machine vdisk files while the VM is up will result in a snapshot of the running VM, which doesn't take into account any files the VM has open in RAM and hasn't committed to disk. This is a risky way of backup, sometimes it works, sometimes it doesn't. If you are ok with shutting down the VM before you take a backup of the vdisk, that's fine, it will work 100% I prefer backups done from inside the VM, that way it's also more portable. If I want to restore to a bare metal box I have an easy way to do that.

I moved your post to the correct subforum, hopefully someone here will have an answer. Virtualizing Unraid as a guest isn't supported, but this subforum is a place for people who get it working to collaborate. That said, I don't remember seeing anyone successfully running under Hyper-V.

Screenshot of "Main" tab?

Does the "Disk Log Information" icon directly to the left of the serial number on the main GUI page give you enough data?

It would be polite to put a note in the support thread for that plugin.

Yeah, that is NOT going to work well for spinner drives. It's questionable for SSD's, and not nearly enough power for HDD's. There is a very good chance whatever connector you have been feeding them from, as well as the source end of the adapter, have heat damage from overcurrent. You need the beefy 4 pin molex type connector feeding that many drives.

I moved this post to the correct subforum, hopefully someone here will be able to help.

Try stopping the array before rebooting. If it doesn't stop in a timely fashion, figure out why.

No harm in doing both at the same time.

Shutdown server, replace drive, boot server, select replacement drive in parity slot, start array to rebuild parity.

The screenshot you posted says "Additional Requirements: MySQL"

Mounting the drives normally will write some data. If you were to manually mount the drives read only it should still stay 100% valid.

If you do the upgrade in maintenance mode, so the data drives are not mounted, the old parity drive would stay valid.

No.

You must change the listening port in the application itself, not in the container config.