JonathanM

How / where did you back up the data? Commands used?

As a general rule, yes. i5, i7, and i9 do not support ECC.

Yes, or a xeon if you want the extra safety of ECC at the expense of higher idle power consumption.

What is the end goal?

If you set all the statics in pfsense, you could download the xml backup, do a text search and replace, then restore the backup. If ALL the electronics are powered down, they should all just get their new addresses and work when powered back up. Probably you will just need to slog through all your devices one at a time making sure each one is working correctly. I'd also make a backup of your Unraid stick and do a text search for 192.168.1 and 192.168.001 and see if you get any hits. Some of your containers could also have IP's defined, so you will need to walk through and check them as well.

Processor design family. As of this writing, "Rocket Lake" is the newest desktop intel processor. The Xeon on your list is "Comet Lake", which is the previous generation. The atom on the list is "Tremont", which is a totally different family, not directly comparable. What I'm trying to get across is that idle power is going to be very similar if not identical between processors with the same layout. If you put together a system with the i5-11400T, measure the idle power, swap in an i9-11900k and measure again, the idle power will be virtually the same, but the i9 will draw much higher peak power under load while getting the work done that much quicker. Since the processor is only a part of the total electrical draw of the system, it's important to finish the work as quickly as possible to allow the rest of the system to go back to idle as well. Consider this scenario, processing a video file. Assume it takes a specific number of calculations to solve, the slower CPU takes an hour to finish, the faster one is done in 15 minutes. The CPU's take roughly the same amount of power overall to get that work done, assuming like I said they are from the same design family. The hard drives have to stay spinning the entire time, so the slower CPU uses 3 times more hard drive watts while the faster CPU is done and lets the hard drives go to sleep. Also consider the total lifetime of the system. The faster the CPU, the more likely it will be useable in the future. A slower CPU will need to be replaced sooner, at a significant cost, since replacing the CPU generally means replacing board and memory as well. It's not usually wise to buy the very fastest CPU, but somewhere at the upper end of the speed range is better than the slowest model.

It's like playing russian roulette. If the connected equipment is totally isolated or has another good path to ground, you generally are fine. If the only path to ground is through a monitor cable, or a network cable, it's possible you could have a bad day. Some UPS's handle it better than others, so it's very much YMMV.

If you disconnected the cord from the wall, that's normal for most UPS, they aren't designed to operate without a constant ground reference, especially if there is a path to ground through other parts of the equipment like network or other cables. Be glad the UPS shut down instead of dumping full power through your stuff and letting the magic smoke out, like mine did many years ago when I found this out the hard way.

In general, the newer the die type, the more efficient the rig is going to be, with the faster the specific model within the die type being more efficient overall. The quicker the chip can complete the tasks, the more time can be spent at idle with the disks spun down, which is the most efficient way to run. So, for overall lowest consumption you generally want the newest die available with the highest speed you can afford. Efficiency is determined by how much work the rig will do with a given amount of power.

Make sure amule is running as the same user that has permissions to write smb. Be aware root has no access to smb shares on Unraid.

Sounds like you have a pretty good handle on the issue, so my recommendation is follow your gut. Others may have opinions for you, but only you can make the final decision over how much the hassle of manually monitoring the health of free stuff vs. spending money to go the easy route is worth.

Another option (better supported) would be to assign the 12TB to a cache pool.

Just use samba in Fedora to connect to the Unraid share normally, just like you would any other computer on the network.

That network config is VERY not standard as Frank pointed out. I would delete the network.cfg file, plug ethernet cords from your network into both of the jacks and reboot, then download and post new diagnostics.

Enable mover logging and check the syslog after step 3 and see what it says.

I've seen PSU's, motherboards, or PCIe cards cause it. Try temporarily removing all cards and see if it changes. Before you start altering things be sure to set your array not to autostart, that way you can boot up, shut down, test, repeat, without having to deal with stopping the array.

Just create a bookmark.

Correct. It will show an error.

No data drive can be larger than either parity drive. Ever.

Probably need to do a file system check / fix.

https://wiki.unraid.net/The_parity_swap_procedure

You can't change the file format and keep the data. Hopefully you haven't messed it up enough to preclude reading the drive when you switch it back to ReiserFS, but you may need to fix the ReiserFS filesystem if it's damaged. https://wiki.unraid.net/index.php/File_System_Conversion

Skim through the support thread for unbalance. It's been addressed there multiple times.

No, mover only operates back and forth between the parity array and the specified cache pool. Unbalance is your best option, like Gragorg said.

Depends on the mapping, but in general, yes. Which leads me to my main point. Why bother moving things? Just let the new data go to the fresh 8TB. Since the actual location is hidden behind the /mnt/user structure, why does it matter which disk number is used?