JonathanM

Out Of Memory

Another consideration is cooling the LSI controller. They are generally designed for rack mount servers, which have a lot of forced airflow over the I/O slots. Regular consumer cases rely on the cards themselves to do the cooling, so you may need to add a fan to force air over the card's heatsink.

You can change USB keys, just not back to an old one. Once a license is validated on a new USB stick, the old USB stick can't be used for Unraid. What I outlined keeps both servers running, exactly as you outlined, the only difference being which physical key is used in which machine during the process. As long as you keep the license file with the physical key it was issued to, there is no need to reactivate the pro key or mess with licensing. You just need to activate the basic license to the trial key when you are done the trial and ready to use that key on the old server with a basic license. The rest of the config folder can migrate with the drives to the physical stick that you want to use, just keep the physical stick and its license file together.

https://docs.unraid.net/unraid-os/troubleshooting/data-recovery/#lost-array-configuration

The rename is pretty much instant, the encryption to finish the "ransomware" bit happens in the background, limited by the performance of the infected pc.

Parity is realtime, not a backup. What's there now is what will be rebuilt if a drive is replaced. Sounds like you have some flavor of ransomware working its way through your system.

If I were in your shoes I'd set up the new hardware in Unraid with 2 pools, one being the "media" pool, a large spinning rust drive, XFS, either as a single member pool or disk1 in the traditional Unraid array, and the 2nd pool being 1 or 2TB of SSD, ZFS, for system files like docker container image layers and application data. Leave all your current disks untouched until you have a good long play with Unraid on those scratch pools, then blow everything away and set up in earnest after you have the knowledge needed to migrate without regret. Unraid is enough different than a typical linux install that it can be a learning curve, main thing is the OS portion runs completely in RAM, with the boot USB used for the OS archives and OS configuration stuff. It should definitely do everything you want, but it's going to be just a little different, and I'd hate for you to get half way through the migration and realize you should have set things up just a bit differently. Unraid has been steadily evolving, so older tutorials may not cover things exactly as they should be currently, but check out Spaceinvader One's youtube videos, he's got loads of good stuff about the Unraid ecosystem.

First order of business is to remove all outside access until you can figure out which port forward rule allowed you to be hacked.

All you need is the files in the config folder. Don't bother with the tool, you can just copy / paste the files. Yes, for parity array drives, maybe for pool drives, depends on whether all the drives that made up a multi volume pool are available. If all the drives are plugged in to a single system it should be fine, but if you are trying to check one drive at a time you may run in to some issues, depending. Not if you mount the data drives read only. The parity drive wouldn't mount anyway, but it's no good without all the rest of the data drives, ALL unmodified. Do you have the entire server or just the drives? This quoted statement makes me think you have the whole thing, but this statement makes me think you just brought the drives. What Unraid installed services are you wanting to provide remotely to the family? Do you have access to his email accounts? Did he have an Unraid Connect account?

Keys are tied to a specific USB GUID, and can't be moved. So... Won't work unless you use a physically different USB stick. The active pro key issued to Server A's stick will be unusable if you migrate it to the trial key stick. However... The key is tied to the USB stick NOT the rest of the config. So... wherever you physically move the stick the key file should stay with it, the rest of the config can be moved at will. First step looks good. Second step should be modified to... Backup files on Pro Key, backup files on trial key, delete existing config folder content except for the pro.key file from the pro key and copy config folder except for the trial.key file from trial key onto the pro key, physically move pro key to new server. Unraid won't need to move key or activate anything, it should just work. Third step would be pretty much the inverse of second step, difference being you would put the basic key in the config folder instead of the trial key. Unraid will then migrate the basic key to the trial key USB stick. Clear as mud? Stated differently for clarity. The config folder minus the *.key file should stay with the data drives, the key file itself needs to stay with the USB stick.

I'd recommend setting up a fresh instance of each container, that way you can see how the path interactions and variables are set up, along with where the data expects to live on Unraid. Once you have a handle on that, it should be relatively easy to migrate your application data and media to Unraid. Try to use the layout that has become "standard" for Unraid if you can, it will make any troubleshooting a little easier. The cool thing about containers is that you can map internal container paths to match your current settings so they should migrate pretty easily, it's just figuring out where to map those onto the server in a way that makes sense. Based on your first post it may be difficult to do this, but I really recommend figuring out a way to run both systems for a period of time to make the migration easier. Unraid is pretty forgiving to move across systems, maybe put an older rig into temporary use as the Unraid machine while you learn?

Why do you have "Enhanced macOS interoperability" enabled?

Do you have any port forwarding rules in your router, or DMZ set?

Was the array started in maintenance mode when you ran the check command?

You need the key file that was issued for the new flashdrive. Did you happen to make a backup? If you can't find it, you will need to contact support and ask them to send you the file. Did you possibly get an email with a download link for the new file? You need the key issued when you did it the first time.

Diagnostics might reveal something.

Click on the link diagnostics and read there what is needed.

Should be fine, did you use the same format type?

The flash should be readily readable in windows, it should be FAT32, labeled UNRAID, with all the filenames visible, contents of the config folder pretty much readable text files. Have you made any disk changes since the backup was made?

Where did you run the command?

Yes. The main Unraid array will want to rebuild parity, and assuming the drives haven't been mounted elsewhere you can check the box saying parity is already valid. Unraid should not alter drives (except for the parity slots) without you explicitly clicking the format button after affirming that yes, you want to do this. You will need to name the pools the way they were previously, pool names aren't derived from the disks like shares are.

If you want to start over with your apps, reorganize and copy only what's needed, then your approach would be better. If you upgrade one at a time, then yes, the first drive to be upgraded would be the parity drive. Moving VM's and containers is a little trickier, but I suppose it's a good exercise to figure out if your backup routine is robust enough.

In theory, yes. You just don't have the ability to go back and undo like a real backup. In practice it seems when a device fails the RAID duplication doesn't always take over seamlessly, so a backup is the better use of a second drive in my opinion. YMMV, my opinion only, others disagree, etc, etc.

Remember, RAID is not a backup, it replicates all changes in realtime, which means corruption, deletion, etc are all faithfully replicated. Backup allows you to step back in time to the moment the backup was taken if something bad happens. Redundant RAID levels allow for device failure without downtime.

Why not put all the current drives in the new machine, then upgrade them one at a time? That way the old disks will still have all your data as a backup, and you can continue to use the machine while it's in process, albeit at the cost of slowing the rebuilds down.