JonathanM

Depending on the USB implementation, network may actually be faster. Give it a try, but if you have a healthy 1000Mb network, your overall time to transfer will probably be either the same or better there, and it's going to be less hassle.

Different versions wouldn't "matter", but could effect which files you wanted to copy from one USB to the other. Having the same version means just the config folder is all that needs to move. This, partially. Definitely wait to assign parity, since all your data is going to be a copy anyway. If a drive in the new server pukes during transfer, just replace it and move on, no data lost. Pools, on the other hand, I would create initially, as you will usually want your docker containers and system files to go there. I would NOT, however, set any of your shares to use the pools as the initial place for the transferred data, set those shares to cache:no, or set the array as the primary destination with no secondary if you are using 6.12.X when you get around to doing the transfer. Initial data loading from the old array drives should bypass any pools and go directly to the new array, then build parity after all the data is safely across.

Can't think of anything major. Just remember to delete the trial key from the new config when you put it on the old key. Are you planning on running the same version (6.11.5) of Unraid on both servers while you do the data transfer?

Is your monthly check correcting or non-correcting? If it's correcting, run a non-correcting check to be sure everything got back in sync. If it's non-correcting, run a correcting check followed by a non-correcting to make sure it's done. All this presupposes all your current drives are perfectly healthy. If you don't know how to be sure of what I'm saying, attach diagnostics to your next post in this thread.

Yes, I was saying you could avoid the license transfer by continuing to use the old USB stick. If you put the old license file on a new stick it will prompt you to transfer the license, blacklisting the old USB GUID. You can do that automated transfer once a year, if you do it sooner you have to contact support and tell them your situation. Why not continue to use the old stick? In my experience it's hard to find a good quality USB stick, I'd prefer to keep using a known good one than take a gamble on a new one until forced to by failure. If you keep a current backup it's a matter of minutes to do a transfer to a new stick. I'm not sure what happens if you try to move an existing license to a stick that has been issued a valid trial. Presumably you could do that, but the automated system might not work, forcing you to contact support to get it moved. @SpencerJ?

Yes, containers share many resources, so there is negligible waste by duplicating containers, and the benefit of keeping the changeable data separate is clear, especially for recovery like you are doing. If you eat sleep and breathe database building and maintenance, then maybe keeping multiple databases in a single container would be easier for you to manage, but for us mere mortals that often have to resort to copying from backups for disaster recovery, separate containers is the way to go.

Pinned (recommended) Should I unpin the 30 Nov 2022 now?

You can use a trial key to set up the new server, get it running, then when you are ready to decommission the old server move the config folder from the trial USB to your original licensed USB, just be sure to keep the old license key file. The rest of the config would be from the new server.

Yes, or you can continue to use the old flash drive and license. You can freely move the config folder minus the license file from stick to stick.

Does it act the same booting Unraid directly?

Squid's already done exactly what you are asking for, click on the apps tab, top left is installed and previous entries.

Not at all, Unraid is ideal for keeping a backup of your important files. Backup means a SECOND copy of something, if it's the only copy, it's by definition not a backup. If you keep the ONLY copy of a file on Unraid, then yes, you need to figure out a second place to keep a backup copy. Some people upload to a cloud storage provider, others have 2 arrays, some have USB attached drives that they update periodically and keep in a safe place while not being actively updated. You get to decide how important a file is, and what level of protection you want for it. Some of your files that are easily recreated from the originals, like Blu-Ray rips, there is no need to keep a second copy. Family photos however, they probably need need MULTIPLE backups, probably follow the 321 strategy, 3 distinct files on 2 different devices and 1 offsite, so a catastrophic event like a flood or fire is still recoverable.

No simple answers, other than fewer drives = less power = less heat. Unraid parity (or any RAID redundancy for that matter) is not backup, it's hardware redundancy. It doesn't protect against any of the common issues like accidental or malicious deletion or corruption. You need to plan for a versioned backup of any data that is important to you. I know you didn't ask about backups, but drive reliability and failures are only a small part of keeping data safe and available.

Depends. https://wiki.unraid.net/Manual/Shares#Allocation_method

rclone possibly. See if removing it changes the behaviour.

Some plugins use the docker subsystem to download and install on boot. Any containers created without a name get random names. Which plugins do you use?

XMP is overclocking. Don't overclock a server, it's not enough of a boost to notice, and the downsides can be catastrophic.

So change it to do what you want. That's the point of my post, here are the building blocks, assemble as needed.

You will have to rewrite this to do what you want, but I think the basic concept is there for you. This script pings an IP, waits until it responds, then runs a command. If you research the ping command you should be able to use the logic the way you want. #!/bin/bash printf "%s" "waiting for IP to respond ..." while ! ping -c 1 -n -w 1 192.168.1.1 &> /dev/null do printf "%c" "." done printf "\n%s\n" "IP is responding" docker start "Container"

I'm guessing then that you never told windows to disconnect it, which should result in "It's now safe to remove" message? https://www.howtogeek.com/685934/how-to-safely-remove-a-drive-on-windows-10/

Sometimes the USB enclosure alters the addressing, causing the partition not to start at the proper spot. Any way you can hook them up direct to SATA? Wouldn't hurt to collect diagnostics with them attached and attach the zip to your next post. In this case, either drive should be mountable, because as long as you used the parity1 slot, the two drives should essentially be a RAID1 mirror. It's possible only one drive will SHOW as mountable, because the XFS signature would be identical keeping the second drive from mounting. Since you only had 2 drives, you actually might be ok.

IF you have ALL the drives EXACTLY as they were when one drive went missing, Unraid will emulate as many drives as there were parity drives assigned at that point. Sounds like you may have hosed yourself by actively using some of the drives. You CAN start the array with a missing drive, but all the rest have to be there. Parity doesn't contain any data, just the answer to the equation formed by the rest of the data drives. When you know A+B+C+D=P, you can find the value of any single missing variable by using the rest. As soon as you remove 2 values, the answer isn't solvable for sure. Hopefully your repair works out for you.

Extended SMART test.

Do what they did to make it work.