JonathanM

Your symptoms remind me of what happens when there are two devices on the network with the same IP. How are you managing IP assignment in general on your network?

Unraid doesn't generally play well with RAID controllers, it needs direct access to the drives.

Are you running your RAM to the motherboard and CPU spec? The speed the memory is rated to run is rarely supported by the CPU in modern AMD systems. Have you run at least 24 hours of memtest with zero errors?

The issue is if you need to move a drive to a different controller Unraid will not know it's the same drive if the ID is changed. Do you have any SATA ports NOT on the controller that you could connect a drive?

Your Pro license will easily transfer to a new system, and you can leave the current system intact while you copy data. All you need is a copy of your pro.key file.

Any data you care about on disk4 and disk15 needs to be copied to another location.

You still didn't answer the question about your hardware, but based on the screenshot you just posted, especially with the read errors next to disk4, I think you are in a precarious state. My gut reaction is to tell you to make sure everything currently on the array that is of value is backed up elsewhere, before you start mucking around and possibly making the situation worse. I see from your browser tabs you are looking at new drives, I think that's for the best. Ideally you should probably build another box and copy the data without disturbing the current server. I'm betting your current setup isn't going to be happy running V6.

Where in the manual? I did a quick glance, didn't see those specs mentioned anywhere. Typical 12V SLA voltages go from around 13 to around 11. http://www.solarnavigator.net/battery_charging.htm What voltage does NUT report currently?

Just to confirm, the drive id's are passed through to Unraid unchanged and the SMART data is automatically populated when doing this? If either condition isn't met, there are issues that can come up.

I can't help with the actual question because I don't use full disk encryption on Unraid, but before you get deep into it, I feel obligated to ask a couple questions. 1. Why are you interested in encrypting your data? 2. Do you have current backups of all the data you wish to keep encrypted? Encryption greatly increases the risk of data loss. Do you have a plan to keep backup copies of all new encrypted data as it is generated?

Describe your hardware. Motherboard, CPU, RAM, HBA, drives.

You forgot to attach the diagnostics zip file.

Have you tried https://<IP Address>? Note the https and use the IP that is working for putty.

It's not the parity drive that's the biggest concern, it doesn't have a valid filesystem anyway so there aren't any files or file changes to trim. It's the data drives, and even then there are very few drives that have been shown to have issues. Mainly it's the big what if's that haven't been proven or disproven that cause the warnings. Imagine if Limetech made a blanket statement that SSD's are now ok to use in the parity array, and some less used models happens to break parity and cause data loss. The loss of performance is also a conditional thing, and as SSD firmware and controller circuits get more mature it will probably be less and less of an issue. It's already a non-issue on high end drives, they are intelligent enough to do the needed housekeeping without interfering with performance. Since the primary purpose of Unraid has always been a rock solid NAS appliance with easy storage expansion, implementations without mass storage and expandability in mind are always going to be viewed as suspect. @JorgeB has done some serious work with SSD arrays, addressing both performance and reliability. The discussions are posted here on the forum somewhere.

In a nutshell, the container is the UrBackup host, it provides an endpoint for any UrBackup clients that you add. After you have it set up, you log in to your UrBackup site, add a client to the backup list on the status page, download the executable it generates and run it on your machine that you want to back up.

Which is the primary reason why Unraid can't quickly "fix" this. They didn't author the docker system.

If you are specifying a user share (/mnt/user/blah) then you will need to set cache : yes, run the mover and wait for it to complete, then set cache : no before any further writes are made to the share. If you don't want to pause your activities until the mover can catch up, there is no harm in setting cache : no for now, and leaving the current files in place on the cache until you reach a point that you want to temporarily stop adding material and do what I said in the first sentence.

Any root folder on any array disk or cache pool is automatically a user share. Look through your containers and any user scripts for a path with "backup".

This build is not typical of Unraid usage, especially using SSD's in the parity array. There are downsides to this, discussed multiple times in the past, and adding storage without SATA or SAS is extremely problematic. I'm not saying this isn't a good usage of Unraid, it clearly is, I'm just saying that recommending a NUC based build is wrong for the majority of Unraid use cases.

VPN would be more appropriate for what you need to accomplish.

You can't swap the license without physically changing the flash drive. You could set up a new flash drive for each server and copy the appropriate plus and basic files to the new sticks, and they would be activated and blacklist the old sticks. That would require physically changing the usb stick, but you wouldn't have to send the specific stick, just get a new one at the remote location. You can't. The best option without physically touching the remote machine in any way is just to upgrade the basic license to a plus. If you figure out a way to physically swap the sticks, you can simply move the config folder minus the license key file and be done.

TDP is only useful for determining how large a heatsink and how much airflow is required. It has NOTHING to do with overall system efficiency. In your specific instance, the i7-7700T and i7-7700K appear to be sibling processors, with the only difference being the T version has a hard limit imposed on maximum frequency. They will use exactly the same amount of power under light loads, but as soon as you start a heavy computation task, the T will stay throttled back and the K will go to max power. That means your task will take much more time to complete on the T version, keeping all your other items like RAM and drives at full power waiting for the T to be done, while the K is finished and can allow the whole system to go back to idle much quicker. As a general rule, each new redesign of a chip family brings more efficiency. So to get the best performance per watt as a broad rule you want the newest chipset and die type, and the most powerful CPU in that die type excluding gamer type tweaks. Overclocking tends to reduce performance per watt, so stay within the normal desktop range.

3TB is RAID0, where each chunk of data is striped across all devices for speed. I forgot that tidbit when I initially replied. The odd number of drives thing makes BTRFS RAID levels rather unpredictable with usual logic, which is probably why free space calculation is hard in that config.

Pools default to RAID1, which would mean you have 2TB usable space with full redundancy using the drives you have listed. You would need to change the desired RAID level and rebalance if that is not what you want. I suspect when you added the 2TB it did not get properly balanced into the pool. Each share has a setting to determine where files will initially be placed and whether the mover will change their location. Your screenshot shows mover to already be running, so shares set to cache : yes will be moving from the cache pool to the array.