JonathanM

Short answer, the "cache" nomenclature is a holdover from very early in Unraid's history, but it was never a full "cache" in the classic sense.
 
The preferred term nowadays is pools, since there can be multiple types and purposes for these groupings of single or multiple disks.
 
The mover tuning plugin may provide some of the functionality you are looking for.

That file only exists in RAM while the server is running, and is extracted from the archives on the USB every reboot. Any changes you make need to be redone after each boot. Best way is "CA User Scripts" plugin, write a short script to accomplish the edit, and set it to run "At startup of array"

If it were me, I'd not do any reconfiguration until the data was backed up.
Since that is the case, easiest way forward may be to copy from the emulated failed disk directly to the new empty disk.
 
rsync -arv /mnt/disk5/ /mnt/disk6 rsync -narcv /mnt/disk5/ /mnt/disk6 First command does the copy, second command verifies the copy was bit perfect, it only outputs files with differences.
 
After that is complete, you could do a new config and re-order the drives where you want them and rebuild parity.
Short of obtaining another new disk to rebuild the failed one, my method gets you protected the fastest while recovering the data.
 
 

Since you know for sure which drive is parity, and your pool config, you can simply reassign all the drives as they were, check the box "Parity is valid" (it's not totally valid, but pretty close) and the array should come back with all your data. Your shares are simply the root folders on all the drives, so they will come back up, with default settings. You will need to edit each one to export it via SMB and / or NFS and set users.
 
The parity check that runs will find a few errors, hopefully not that many.

Another option, probably quicker than going to the array and back, is to create another single device pool with the new drive, and copy directly from drive to drive. After the copy is verified, rename both pools, giving the new pool the correct name after renaming the old pool.

Maybe this?
 
I use nextcloud, but that's probably not what you are after.

Teamviewer must be configured differently on Windows Server. Have you followed the instructions specific to server editions?

That means any data written is suspect, as it all flows through RAM. Likely all the recovery attempts while the bad RAM was installed caused more issues and corruption. When the machine can pass a long memtest, preferably more than 24 hours, then you can start recovery efforts.

https://docs.unraid.net/unraid-os/manual/storage-management/#upgrading-parity-disks
https://docs.unraid.net/unraid-os/manual/storage-management/#replacing-disks

Only thing I see is before you run the mover, all services that access files on the pool need to be shut down. Typically that means disabling both the docker and VM services, not just stopping the containers or guest OS's.

The support link for the container seems to point here
https://github.com/cross-seed/cross-seed/issues?q=is%3Aissue
I suggest asking there, that is the designated place to get support for that container.

Why not boot from your Unraid key, and format the drive there using Unassigned Devices? As long as you don't mess with array assignments or accidentally format your Linux boot disk it should work fine.
 
I'd make a backup of the config folder on the key before doing this, just in case, plus it never hurts to have a current backup of your config.

That would probably do it. I thought there is logic in place to eventually force the shutdown, but maybe that only applies to UPS power failure shutdowns.

Probably easier to use
 

If you are using the 7 series beta, you simply define another pool with the 2 disks and select RAID1 either BTRFS or ZFS.
If you are still on the 6.x release, the array is still necessary, but you can assign any old drive, even a USB, to disk1 and then define all the different pools with whatever RAID levels you want.

They are part of the Unassigned Devices plugin.

I'm not well versed in ZFS, but I think you have to destroy the dataset.

Depending on how much risk you want to expose yourself, you could do one parity at a time, that way you will always have valid parity if a data disk fails. Preclear is totally optional, it won't speed things up, but it will test the new drives for infant mortality.
 
When you get to the point of adding old parity drives to data slots, be sure to make new backups and delete all your old flash drive backups, or mark them in some way so you never try to use them. If you accidentally use a backup that has your old layout, the first thing Unraid will do is overwrite your data drives that were parity.

If you are ok with invalidating parity and rebuilding it, you can set a new config with all the drives and rebuild parity.
 
You will be unprotected from drive failure for the duration of the parity build.
 
Probably quicker just to let the clear finish.

The biggest issue tends to be when it comes time to migrate to different hardware, Unraid identifies the drives with hardware identification, which RAID controllers don't pass intact. One of the biggest benefits of Unraid is the ability to move the drives to almost any plain vanilla platform, as long as the disk controller is a plain HBA the drives will be detected and used without any changes needed at all.
 
Sometimes RAID controllers alter the drive's geometry, which can put the partition at a location that isn't compatible when the drive is moved to different hardware, causing unmountable drives.
 
USB instead of SATA or SAS is very hit or miss, typically miss. The USB bus resets can and do cause writes to fail, and Unraid will drop the drive when a write fails.
 
Another issue for many people (not for you, you seem to have this taken care of) is that Unraid's ability to monitor and report on disk health is disabled by many RAID controllers. If a drive is failing, you want to investigate, and possibly replace the drive sooner rather than later. Unraid (like most RAID) requires the entire capacity of all the data drives and the parity drive to rebuild a failed drive. The reason it's super important with Unraid compared to other RAID setups, is that in the Unraid parity array disks are allowed to spin down when not accessed, which means a drive can possibly go months without being touched, but when another drive fails the spun down drives are all required to be read perfectly.
 
As long as you keep good backups you will be fine. The issue is simply that you are bypassing or hamstringing many of the features and safeguards built into Unraid to help protect your data. People tend to get upset when they lose data, so we try to mitigate as many causes as possible.

Take a look here.
tldr: create a text file named stop in the config folder.

Then there is no way to do instant moves, because the data must copy from one disk to another.

You should be able to add the drive to the pool, it will automatically balance to RAID1, which will still only have 1TB space, but it will be redundant. You can then rebalance to a single profile, which will add both drives space together. However, keep in mind that your data will be interleaved across both drives, which means if either drive has an issue you will lose the whole pool.

Yes, until the source drive is formatted as XFS to become the next destination. That's why I mentioned staying aware of writes to the involved shares. You can temporarily exclude the source drive from the user share system, then the files would appear to be gone from the share until they were copied. How you use your array will determine what method is best for you.
 
If you temporarily stop any processes that can add files to the array, and just allow reading only on the drives you are messing with, then duplicates are not an issue, as only one copy of the duplicated file will show in the user shares at any given time.

When you get on site, try to stop the array, and then power down safely from the GUI.
 
Put the USB in another machine, copy the entire config folder and do a checkdisk on the USB. Corrections or not, make another copy of the config folder just to be safe.  Examine the ident.cfg file in the config folder, it should be plain text and obvious if there is something wrong. Possibly it was corrupted and regenerated with defaults, which would explain the reversion to "TOWER". You can browse around the files in the config folder looking for corruption, the vast majority of the files are plain text, notable exceptions would be the .key file and super.dat.
 
Follow the online directions for resetting the password, and you should be good to boot back up, if you have a flash backup you can use the config folder from the backup as reference files to fix any corruptions found.
 
I've personally dealt with something very similar on one of my machines a few years ago, when it happened to me the only corrupted file was the ident.cfg, but you probably should poke around and check other files just to be safe.
 
If you know how to do a binary compare, you can check the current copy against the config folder from your backup, and examine the differences found. I wouldn't mess with differences in non-text files, but all the plain text stuff is pretty easy to parse and see if it makes logical sense.
 
I think you will probably be fine based on your description of events.