JonathanM

I also have obsolete devices in my menagerie, and am on 7.2.95. At this point I believe you would be best to hold at your current version, specifying that tag if you are on latest, if it's working for you. Don't mess with a working system, until you see what effects an update could have on you. I fully agree, but I also wouldn't allow any more upgrades to the controller if you aren't willing to give up and replace old equipment. Every upgrade is a risk point, which is why we stress to never use the latest tag. My obsolete AP's are still chugging along, and if it becomes necessary I could always log in to them and set the inform host to a different controller running an older version.

I don't recommend posts unless "I" can recommend the post. If you know what I mean. If it looks like I'm missing something, DM or ping me so I am aware. If you want to make a clearly worded warning post stating the situation after the dust settles, ping me and I'll recommend it instead of the current one. Do you all think enough time has passed to remove the 5.14 recommended post? I moved to 7.2.95 some time ago. The "don't run latest" recommend will probably stay there forever.

Not really, had you pressed enter yet in that screenshot? I was thinking the blinking cursor would be at the beginning of the first blank line after you press enter. If you haven't hit enter yet, you could add status=progress to the command, separated by a space of course. dd if=/dev/sdi of=/dev/sdf bs=1M conv=noerror,sync status=progress

Be VERY careful with that philosophy. Your 'nym very much applies here, as each data drive is equally important when it comes time to rebuild a failed drive. The last thing you want is for a rebuild of a different drive to fail because one of your rarely used array drives buckles under the strain of being read completely. The ability to rebuild any single failed drive relies on the rest of the array drives performing flawlessly for the duration of the rebuild. Never leave a "failing" drive in the array. A "good" drive unexpectedly dying means all your questionable drives are suddenly very important, regardless of what data was on them. Periodic parity checks help verify that all drives are still worthy of array participation. Setting up notifications and acting on any warnings promptly will help you keep the array healthy.

Because Unraid doesn't always keep static /dev/sdX designations between boot cycles, it is vitally important to identify the source and destination /dev/sdX immediately before starting the dd command, don't reboot and trust the letters are the same.

Short summary, positively identify the source and destination /dev/sd? devices, then issue a terminal command dd if=/dev/sd(source) of=/dev/sd(destination) bs=1M conv=noerror,sync Be VERY sure of the destination disk you put in the of (output file) section of the command, you really don't want to overwrite the wrong drive.

root and user passwords are omitted, probably some other privacy stuff I can't remember.

Change proxy_pass https://192.168.XXX.XXX:XXXX; to the address that works to access the container from a desktop on the LAN.

Did you reboot after installing?

That is NOT the Main page. Where it says, "Dashboard Main Shares Users Settings Plugins Docker VMS Apps Tools" click on the word "MAIN"

Post a screenshot of the entire Main GUI page.

@Duh., what are you expecting to happen from this interaction? He offered to refund your money after you return the card in the same condition as sent.

https://morsecode.world/international/translator.html

Create a replacement USB stick with the USB creator or manually, restore your backup, boot up, transfer the license key, done. I personally just went through this exact scenario a couple days ago, took less than 15 minutes. It's not designed to. The license is tied to the stick, don't remove it while the array is running. Much better to mount the stick inside the case, if your motherboard doesn't have a full size USB port on the board itself you can get a cheap adapter that converts from the 10 pin IDC header to a USB. Having the stick inside the case makes it much more difficult to accidentally damage or remove.

Hardware specific tweaks will need to be undone or redone or added. VM's with passed through hardware can cause serious headaches, because the identification of the hardware can change, for instance if you had a video card passed, and the new hardware has the USB controller at that address, Unraid will lose access to the USB boot stick as soon as the VM is started. That said, it's definitely doable, you must be aware of the differences. Setting all the array and all services to not autostart before the final shutdown on the old hardware will allow you to take stock of everything on the new build before you hit start.

Exactly. Install a second instance with a different name, assign and forward a different port.

How valuable is this deleted data, cost wise? The proper way to do this sort of recovery is clone the drive bit for bit to another disk, same exact size or larger, then run the recovery tools on the clone, one at a time to see which one gets the best result. That way you keep the original drive intact until it's obvious you can't do any better. I haven't been following this thread very closely, but if you have another good 3TB that has no valuable data on it you could use it for the recovery process. Professional recovery tools generally don't write to the disk being recovered, so you need another destination disk or free space besides the clone to write the recovered files. The reiserfs rebuild tree generally gets very good if not perfect results, but it DOES write to the target drive, so if the data is very important, you need to run it on a cloned copy, not the original. This sort of thing is very time intensive to get right, so you need to decide now whether the data is worth it.

Yes, parity is updated realtime. That's why you need a versioned backup to recover from data corruption or deletion. Parity only rebuilds a drive exactly as it was when the drive was dropped. If there was data corruption, it will be rebuilt with the corruption. If parity was NOT in sync when the drive was dropped, the rebuilt drive will have corruption where it was out of sync. That's why periodic parity checks are important.

Not a common problem, my instance is up to date and working fine. Have you powered down and restarted the server? Maybe there is a previous instance that didn't exit properly.

That card has a port multiplier chip, it's likely the issue. Probably can't handle the load.

Are you using Host mode?

This is a protection mechanism, it keeps you from setting the VPN to yes and thinking you are protected when the VPN is not working.

Do you have a diagnostics zip file from that time period? It should show what the connection speeds were.

Pretty sure if you delete your docker.img and recreate it, the custom networks will be gone. Adding all your containers back is easy, just go to the apps tab, previous apps on the left, select everything you want reinstalled, and hit install selected applications.

Since the containers will share common base resources, there is no space penalty for running multiple instances of the same container, and it allows you to do maintenance and other tasks individually. No real reason I can think of to NOT use unique database containers per app.