ConnerVT

I use both DuckDNS and Cloudflare with my server and network.  I have two domains with Cloudflare (look at the non-.com domains, many are very reasonably priced).  DuckDNS has had some issues the past month.  Fortunately, I only have noncritical things associated with them.  But still annoying.
 
Cloudflare has been rock solid.  I use both tunnels and DNS with them, and have never had an issue.  They also have a few security related benefits, such as 2FA and Geoblocking, that are available for free users.

https://docs.unraid.net/legacy/FAQ/console/#to-cleanly-stop-the-array-from-the-command-line

You need go to Settings and set Enable Docker and Enable Vms to "No".  Then run Mover.

Run less Docker containers?  All this should fit easily in the default 20GB dockerimg file.  If it isn't, you likely have something mapped incorrectly, where it is writing in the dockerimg vs to an outside drive/pool/array.
 
This fits well in a 30GB dockerimg:
Name Container Writable Log immich 4.16 GB 2.04 GB 1.93 MB binhex-krusader 2.58 GB 0 B 52.4 MB PhotoPrism 1.82 GB 0 B 52.4 MB binhex-delugevpn 1.62 GB 949 kB 942 kB binhex-sabnzbdvpn 1.25 GB 100 MB 13.6 kB homebridge 998 MB 85.6 MB 11.4 MB DiskSpeed 869 MB 1.74 MB 21.8 kB Thunderbird 807 MB 7.35 kB 7.89 kB ApacheGuacamole 795 MB 57.8 MB 89.6 kB overseerr 702 MB 2.22 MB 16.0 MB PostgreSQL_Immich 687 MB 63 B 5.41 MB homarr 663 MB 0 B 52.4 MB plex 615 MB 275 MB 213 kB dupeGuru 569 MB 0 B 52.4 MB nzbhydra2 530 MB 0 B 52.4 MB nextcloud 448 MB 597 kB 1.36 MB bazarr 428 MB 23.2 kB 3.27 MB bazarr4K 391 MB 73.3 kB 41.9 kB speedtest-tracker-1 343 MB 27.1 MB 679 kB sonarr 335 MB 138 MB 18.8 MB mariadb-next 333 MB 25.2 kB 8.33 kB QDirStat 314 MB 19.7 kB 33.7 kB gaps 300 MB 32.8 kB 88.9 kB lidarr 270 MB 23.6 kB 1.10 MB nzbget 208 MB 27.9 MB 7.31 kB radarr 198 MB 23.6 kB 3.41 MB radarr4K 198 MB 23.6 kB 1.19 MB tautulli 197 MB 23.2 kB 483 kB SpeedTest-By-OpenSpeedTest 181 MB 4.73 kB 40.7 kB NginxProxyManager 178 MB 48.4 kB 6.72 MB jackett 171 MB 0 B 52.4 MB Redis 138 MB 0 B 997 kB glances 73.8 MB 0 B 52.4 MB Rickroll 72.3 MB 5.06 kB 1.17 MB cloudflared 51.3 MB 0 B 2.70 MB Docker-WebUI 17.5 MB 0 B 44.0 MB Dozzle 15.5 MB 0 B 776 B Total size 23.5 GB 2.76 GB 489 MB  

Let's be sure we are all agreeing on our word definitions before getting too deep into this thread.
 
Cache drive being the physical drive, which the Mover moves data (in this case, your photos) from the Cache to your data array. Appdata is the share where the docker containers keep their internal data (configurations, databases, cached information, etc).  It usually resides on the Cache drive for fast/improved docker performance.  Typically the Appdata share is configured as "cache only" and is never moved to the array. I will assume that your photos are stored on your array.  My best guess what is happening is that the Photoprism appdata folder is just getting huge, which is one of the reasons I abandoned actively using it (Tried it - Didn't like it).  My appdata folder grew to be 31GB in size, nearly all of it being thumbnails.
 
 
 

I use the Uptime Robot website.  It's free, and it can email you and/or send other notifications (I use Telegram).
 
I run two instances,  One pings my firewall device, the other checks one of my https services that run on my server, through my domain and Cloudflare Tunnel.  This way I can tell if my ISP is down or just my server.

https://unraid-dl.sfo2.cdn.digitaloceanspaces.com/stable/unRAIDServer-6.9.2-x86_64.zip

For Sonarr/Radarr it does not matter, you can point it anywhere as you wont be downloading anything without a Download Client specified in the settings.

Check your Docker template (Advance View).  Anything in there (extra parameters?) that is for Intel hw transcoding?

Both will likely give you the same performance transcoding.

Try this:
 
watch -n1 "grep \"^[c]pu MHz\" /proc/cpuinfo"  

Early Ryzen processors (Zen/Zen+) were more problematic than the newer models.  For the 5700G, don't overclock your processor and set your memory speeds to match your DRAM (3200 or less, and not XMP), and if your BIOS has this setting, set Power Supply Idle Control = Typical Current Idle.
 
Things on the Internet are forever.  Then people repeat what they've seen/read/heard from long ago.  Modern Ryzen processors are not as problematic as you may read.  After all, the same Zen processor chips (and I/O dies) are the same in Ryzen and EPYC, and EPYC is a mainstay of datacenters, all running Linux.

No.  Upgrades are one license.

20TB isn't an extreme amount to move.  Not the fastest to move across a 1GB LAN, but not totally unbearable either.  I'll suggest two different options:
 
1. Treat the new server as a hardware upgrade -
Think of it as replacing the CPU/MB/Power Supply/Case.  Put the drives from your current server in the new system (including any cache/pool drives).  Before shutting down your old server for the last time, be sure to update any plugins and turn off the Start Array Automatically as well as VM and Docker services.  Boot from your current licensed flash drive, and sanity check that all runs correctly as expected.  Move on to starting the array, Unraid should remember your drive configuration and start normally.  You can then start up Docker, and this should also start normally, as your appdata is still in the same place as it was in the old server.
 
Once the system has proven itself functional and stable, you can start swapping out the disks.  Start first with the Parity Drive, and let parity rebuild.  Then a data drive, and let that rebuild.  After this, you can move data from old drives to the new one (assuming there will be less drives in the new system than the old) or just swap in another new drive.  (Unraid Docs for details)  Lather, rinse, repeat.
 
Some benefits of going this route:  Limited amount of down time (as array will be accessible through emulated disk during rebuild); stays true to your current configuration (less chance to name/config something wrong and messing things up); data always 100% in sync between old and new servers during migration transfer; old server drives are in hand as an effective backup in case you have any issues.
 
2. Create Trial USB for new server -
You can build the new server hardware with all the drives as you want in the final server.  Create a Trial USB for the new server.  Then you need to configure it all.  Afterwards you transfer all of the data from the old server to the new server.  You can do this via you LAN, or using Unassigned Devices and pulling a drive from your old server, put it in a USB enclosure (or attach internally in the new server if there are available connections, IMHO a PITA) and copy the data.  Continue until all is transferred.  (Note:  You will want to either enable Turbo Write or just not enable your parity drive until all is transferred).  After all is done, you can copy the contents of your new trail flash drive over that in the license one (SAVE your *.key file from the old USB config folder first!), then copy the license back to the original flash drive.
 
The benefit of doing it this way (at least, copying by LAN) is zero down time of the server.  But it doesn't guarantee the data will be 100% in sync, as a file/folder you copied at the beginning of the process may have been updated/added/changed before all is done copying.  But personally think that this is way more prone to error.

It is usually a crap shoot trying to diagnose why without a diagnostic file or much info to go on.  Assuming there are no other issues (except for the errors mentioned on the drive being replaced, which shouldn't have any affect), my first guess is that there was some read/write activity happening in the array during the rebuild.  That's assuming the ~30MB/s was happening during the rebuild stage.
 
Speeds during parity check/repair and drive rebuild can be funny when there are different sized drives in an array.  I'll use my array as an example, which has both 8TB and 16TB HGST drives.  Drives access faster on the first tracks, slower on the last tracks.  My read access is basically 250MB/s to start, 150MB/s at the end.  Obviously when you write, it is slower (and slower still when calculating and writing (parity or data).
 
It takes a few moments for the reads of multiple disks to sync up, then will start off at the fastest speed (250MB/s).  As I have 8TB and 16TB, the speed will track that of the smallest drive (8TB), so for the first 50% of the process, speeds will track down to 150MB/s.  After it is done needing to access the 8TB drives, the speed will jump back up to 200MB/S, ramping back down to 150MB/s at the end.  (Remember this is parity check speeds, read only.  Obviously much slower for read/write parity or data rebuild).
 
If there is any sort of array activity happening other than the rebuild operation, the synchronization of the reads gets messed up, so the drives thrash around a bit, really slowing down the drive rebuild.
 
 

Going the Magic Mirror (or similar) route would end being so much easier to implement (and likely more customizable) that running something natively from your sever.

There is no need to preclear a drive before using it for Parity.  The preclear application writes zeros to the entire drive to prepare it for use as a data drive in the Unraid array.  As installing a new Parity drive requires the parity to be rebuilt which will write to every location on the drive anyway.
 
Here is the relevant section from the Unraid manual for replacing a Parity drive:
https://docs.unraid.net/unraid-os/manual/storage-management#upgrading-parity-disks
 

Yes.  File system overhead.  7.5GB is 0.7% of the 1TB drive.

I hade similar issues when trying to get my Ryzen iGPU to display the local GUI.  Try this:
 
 

Unraid cannot run on your Mac - It does not run on ARM processors, only x86 Intel/AMD processors.
 
Unraid is basically a NAS (Network Attached Storage) server with native resources to run both Docker containers and KVM virtual machines.

Following up to close this thread.  I jumped over to another support thread, where ich777, our master of all things display related, helped me out.
 
 
I had tried this earlier, but it didn't seem to work.  Turned out it *does* work perfectly, from a power off start.  There is some other issue going on, where a Reboot does display on the AMD iGPU but in a strange 640x960 resolution (output is long and squished).  So at least a partial solution, and one which I can work around, now that I know what I know now.