JonathanM

Yes. Installing a data drive larger than the current parity is more complicated, but the end result is exactly what you describe. In the case of replacing a failed drive with a larger than parity model, the parity swap procedure has you covered. If you are adding a drive slot, then you would first swap the parity drive for the larger one, rebuild parity to it while keeping the old parity aside for the moment, then once that is done you would add the old parity drive to the data slot. NOTE!!! Any backups of the boot USB Unraid stick that were taken before this kind of procedure become dangerous to your data, as drive slot assignments are recorded by drive serial number. The last thing you want to do is forget and restore a backup taken when a current data drive was previously assigned to a parity slot. You would likely lose any data on that drive. Any time you change drive slot assignments you need a new USB stick backup. Each parity drive in combination with the rest of the good drives can emulate and rebuild a single drive. So, yes, if both parity slots are valid and in sync, you can have 2 data drives fail and the contents will be emulated. Parity emulates the entire drive, filesystem, blank space, erased files, etc. That means if you delete or corrupt a file, or format the drive, those changes are synced in parity and the emulated drive will match. PARITY is NOT backup.

Parity doesn't hold any sensible data, so "amount" of parity is meaningless. The limiting factor is that no data drive can be larger than either of the two parity drives. You can lose 1 drive for each valid parity drive, currently Unraid allows 2 parity drives.

Set up a new barebones linux vm, then temporarily add the problem vdisk file as a second hard drive and operate on it from there.

Shares tab, compute button will give you an idea. If you can't figure it out from that, tools, diagnostics, download the zip file and attach it to your next post in this thread, along with the screenshot of the shares tab showing which disks hold how much of each share if you want.

reboot

Because data != downloads You only made the host side match, container side must be the same as well.

remove that. If you have your container paths matched between the download client and sonarr, you don't need remote paths set up in sonarr.

both halves of the mapping?

That's wrong, it's asking for this, EXACTLY.

What, exactly, did you type at the console?

Since you are already in the container console you don't need the first half. Just type sync-icloud.sh --Initialise

Are you wanting to securely wipe the drives so there is no way to forensically recover the data, or do you just want blank formatted drives?

Normally when a manufacturer refurbs a drive they reset the SMART stats. It's more likely a return fraudulently sold as new.

Agreed, out of band management is a must, but that doesn't remove the need to use a physical USB stick for Unraid. Most server grade boards include some form of IPMI so adding an external solution like PiKVM is only needed when using consumer desktop grade parts. If you are choosing parts to buy and not using an existing build, it makes sense to pick a board with IPMI built in rather than fussing with adding it later.

Not precisely. If any TWO of the main drives fail they can be emulated and rebuilt. Parity encompasses all the drives, it requires the remaining drives to emulate the missing drives.

Stock Unraid does not support sleep. Did you add a plugin to enable it?

Depends on the quality of the PSU. Wattage doesn't tell nearly the whole story. If you are talking normal consumer grade power supplies, I would be very worried about even a 500W rated unit with 8 3.5 drives and 4 2.5 drives.

Strange. I tested 2 different Unraid servers, one on my same local subnet, one across the WAN, both responded instantly.

How did you come to this conclusion? I just tested it by putting the name of my Unraid server in the ntp server box for one of my windows laptops, and it synchronized just fine. With the appropriate firewall rule in place, it works over WAN as well.

See title of this thread.

Using it as a drive in a typical non - RAID windows system it would possibly be ok. The issue is in Unraid, every bit of every drive is valuable, as it will be used to rebuild a failed drive. All drives in the Unraid parity array must work perfectly, you can't afford to trust a drive with even seemingly minor issues. I wouldn't RMA it, I would straight up return it for a refund and get another.

sdX designations are subject to change on reboot, so don't rely on them. Any changes will need to be scripted, and run either from the go file or using the User Scripts plugin scheduled on array start.

I recommend looking up Spaceinvader One's videos on youtube, he has several on VM's as well as pretty much any other Unraid topic.

It's been too long since I spun up a box stock version, but I think the monthly schedule is there by default, in any case it's easy to do. There is a plugin to handle more complex scheduling, like pausing the check and resuming at specific times to minimize impact, or other triggers.

Most people schedule parity checks once a month, a parity check reads every bit of every drive in the parity array and confirms the parity calculation.