JonathanM

Unraid assumes any multi-drive pool is redundant, since that's the default setting. It's a known issue.

Not recommended, be sure you keep good backups.
See the RAID section of this article, and many others.
https://itsfoss.com/btrfs/

Try setting the share to cache:yes, then run the mover. If you enable mover logging before you run it, you can see any error messages in the logs. If you can't figure it out from there, attach diagnostics to your next post and someone can take a look.

Looks perfect to me.
 
I'd add another step, after everything is complete do a non-correcting parity check, and be sure to keep an eye on the SMART status for all the drives through the whole procedure.

ddrescue appears to do the same thing as safecopy, and it's already available for Unraid in nerdtools.

Expedite replacement, don't bother with extensive testing of the new incoming drive, the rebuild process followed by a non-correcting parity check and long smart test will be a trial by fire for the new drive.
Might be a good idea to order another replacement to have on hand, I personally keep a tested drive same size as parity in a box as an on deck option.
Good reason to consider keeping a tested cold spare to limit time at risk.

Are you sure your phone didn't get connected to a guest network?

Try setting the primary vdisk bus to SATA instead of virtio.

The empty filesystem still has ones and zeroes accounted for in parity, so to remove the disk you will need to rebuild parity after doing the new config without the disk. Do NOT check the "parity is already valid" box, because it isn't. Parity doesn't "do" files, it does the entire drive, which includes the filesystem. Think of the filesystem as the filing cabinet with drawers and blank labels for holding files, it's part of the parity emulation even if there are no files recorded there. That 7GB is the organizational structure needed to keep track of potential files.

Check "parity is already valid" near the array start button, and nothing should be overwritten. New config never overwrites data drive slots, only parity, and if you check the parity valid box, it won't even overwrite parity.

Try reducing the cores and RAM assigned to the VM. Remember, all the resources assigned to the VM are off limits to the host that is emulating the motherboard and I/O. Slow motherboard with lots of RAM and CPU = poor performance.

Dashboard includes cpu time spent waiting for i/o, and since preclear is waiting for the disk i/o 100% of the time it's running...

Slave, note the IP address in the device field, set it to match the fixed IP of your master Unraid.

Master, nothing special, as long as the apcupsd is up and running it defaults to broadcasting as master on port 3551

 
Be sure the network path between the two boxes is powered during an outage, otherwise the slave box will never shut down. I recommend starting shutdown on the slave box almost immediately, so you can be sure it's down cleanly before the master box even starts to shut down. If you have VM's on the two boxes, install the apcupsd program on them as well, use the same slave settings, and start the shutdown first on them. Depending on load, capacity, and desired stress on batteries I recommend starting shutdown on VM's at the 60 second mark, the slave unraid box at 180 seconds, and the master at maximum 300 seconds. That way everything has time for a clean orderly shutdown without distressing the batteries by discharging below 50% or so. Once the heavy draws are shut down, you can leave the UPS running for a little while to keep the network alive.
 
Your situation may differ slightly, but the basic outline will probably be the same.

Extensively discussed in the support thread. Quick fix is delete nginx.conf ssl.conf and replace them with the corresponding .sample files.

Try reformatting the drive with RUFUS
 

Try reformatting the new USB sticks with RUFUS, then follow the normal install instructions.

Have you tried SeaBIOS instead of OVMF?

Too many different goals have different requirements. No way to generalize except to set an upper limit that is rational for some situations, keeping a minimum free space of at least the size of the largest single file that is currently on the disk or a few multiples of that.
 
You need free space if you need to run file system checks, if you get corruption too little free space can keep the repair from completing.

If you stop VM and Docker services, so the menu items no longer appear in the GUI, you should be able to use Dynamix File Manager to move all the appdata folders onto a single disk. Then set the split level to manual, and it should stay on whichever disk you put it, and you can re-enable the Docker and VM services.

Semantics. The backup put the key file that belongs to the old USB stick onto the new stick, so you must obtain a new key file that matches the new stick. That's done with the replace key procedure.
 
I realize I'm saying the exact same thing that you said, just wording it differently, if I'm not clear reply back and I'll try to explain better.

nomachine

This guy has many videos encompassing pretty much all Unraid can do, have a poke around and see what you see.

What result do you get when you ping your duckdns name?

Can you log in with SSH if you set "Use SSH" to Yes on the Management Access page?

Assuming you have the file manager plugin, click on the "view" icon at the far right of disk1, select all, move, and select disk 2 as the destination.