JonathanM

Better get familiar with database backup and restore using PGadmin. If one of your containers that shares your database gets messed up, you will need to dig in to database repair instead of taking the easy way out and blowing away the database and starting over. Not that it's extremely difficult, just more work to keep multiple databases in a single container maintained vs. the ability to work on one at a time where there is no chance of interaction between the database you are having problems with and the ones that are running fine. As I said before, there is almost no benefit to running a single container with multiple databases vs. using multiple identical containers each with their own database, and plenty of downsides.

Since Unraid runs from RAM and the boot device is only used to save settings, I see no reason to use a hard drive. How exactly did you set that up? It's not meant to be done that way.

That's because Unraid runs from RAM, the flash drive is there to store some persistent configuration changes, the license, and the OS archives that are extracted into RAM every boot. The flash is FAT32, so no permissions, so no good running executables from there, it's mounted at /boot. You can copy to another location and change permissions then run the executable with a script. With those limitations in mind, sounds like you have a valid plan. The biggest issue for things running at startup is timing, array and pool locations are only available after the array is started.

Check if your router has a feature that tries to hack into devices on the network to expose weaknesses.

Since you formatted it, the table of contents for the drive is erased, so there is nothing to rebuild. You may be able to get some data back using recovery software like https://www.ufsexplorer.com/ on the drive in another machine.

Why not just replace the two disks one at a time and let them rebuild from parity?

Before you start digging in I recommend you collect diagnostics and attach them to your next post in this thread. It's entirely possible that the situation is actually different than what you are assuming right now. That implies the system is still running currently, try to collect diagnostics BEFORE you restart.

Yeah, well. I looked at the last post and saw a quote from 2020, so the thread had to be at least 4+. I wasn't really doing comprehensive research at that point.

Wow, something REALLY weird happened when you did that. All the posts in that thread are dated two hours ago, I got notifications and stuff about it, and my posts said I had posted two hours ago. Since I wasn't logged on two hours ago, and just woke up, I freaked out a little bit thinking my account got hacked. I quickly realized ALL the posts were from 2 hours ago, but there weren't any actual new posts. All the quotes embedded in the posts are from around 5 years ago, and have the original account names. No harm, no foul, but if any more threads get the same treatment it would be nice to figure out what happened and attempt to keep the original dates, as outdated advice with current dates could cause issues.

If you like the forum design, it's from https://invisioncommunity.com/ It probably could be hosted on an Unraid server, but the forum software is definitely not free.

your sonarr has /data mapped to /mnt/user/data/, but bazarr has /media mapped to /mnt/user/data both sides of the mapping must match, not just the host side. you may have to delete the current mappings and remake them, as well as point bazarr to /data instead of /media inside the application. I'm not familiar with bazarr so I can't tell you specifically what to do.

They are stored inside the docker.img file. You can delete and recreate it empty, and all layers will be downloaded fresh. If you have any custom networks, make sure you recreate those before you pull any containers that reference them.

If that was a response to me, that is exactly what I did, I had binhex-mineos that produced the archive, I put it in the import folder and created a server based on that archive. The issue is that binhex's container ran mineos with Unraid type generic permissions, but this official container sets up a mc user that owns all the files. When trying to read the world file for mapping with another container, permission is denied. This mineos sets permissions that make the files difficult to work with outside of the container.

Then it definitely did NOT write zeroes to the entire capacity of the drive while updating parity to keep it in sync. That would typically take at least as long or longer than a full parity check, probably a day or so under ideal conditions. If the array was still in use while it was writing, I wouldn't be surprised if it took several days. Empty != clear. Empty means the table of contents has no pointers to files or folders. Deleted files still exist as ones and zeroes across the drive, you can only remove the drive without rebuilding parity if the entire drive has had zeroes written to it. It definitely did not, based on the length of time it took, as well as... The time it takes to do a correcting parity check is way longer than the time it takes to do a build from scratch, so if it's less than a quarter completed by now, you should probably stop the check, unassign the parity drive, start the array, stop the array, assign the parity drive, and let it rebuild, followed by a correcting check that should have zero errors. If it's almost done with the correcting check I'd let it finish, then follow it up with another correcting check to make sure you have zero parity errors remaining. That script works for some, fails miserably for others. This is the second time in the last week or so I've seen the same thing reported. There is a reason it's only in the legacy documentation and hasn't been moved to the current docs. When first authored it worked well, but something in newer configs seems to be causing issues. Keep in mind that valid parity can recover a failed drive as long as all the rest of the data drives are able to be read perfectly, but it doesn't protect your data from user error or corruption. You must still keep a second copy of data that you feel is irreplaceable somewhere other than the server. You probably don't have to back up the entire content of your server, but if it can't be replaced from another source, either your backups or the internet in general, it's not protected. Unraid or any RAID only covers a subset of things that can eat your data.

Can you reproduce this on a different machine or a fresh install of windows?

This isn't a USB issue, you must disable secure boot.

How big was the drive? How many days did the script take to complete?

Update it, but yes. Technically Unraid reinstalls itself every boot, it installs into RAM and runs from there. The USB stick holds the OS archives that get extracted into RAM, as well as any configuration changes to the OS itself. To update Unraid, you overwrite the bz* and other files in the root of the stick.

Use this to upgrade then register. https://docs.unraid.net/unraid-os/getting-started/manual-install-method/

Just use your already licensed USB stick. Make a full backup, then set it up as new, and copy the license key file from the backup and keep the rest of the files from the fresh install. All the customization of Unraid is in the config folder, so just keep that securely backed up so you can recreate your config if you want later.

If you duplicate an existing container, they share the data layers in the docker image. There is practically no redundancy and waste when doing this, the only "extra" would be the repeated stuff in the appdata folders.

No, I'd replace it with a stock file extracted from the download I listed above. You can edit it and change the server name to what you had before instead of "Tower" if you want.

ident.cfg is just a text file, like most of the config files. You can extract just that file from the latest download from https://docs.unraid.net/unraid-os/download_list/ and edit it, if you don't remember customizing the entry in the file just leave it as default, you can change things after you boot. Did you look through the other files in your config folder to see if any others were messed up? I think only the super.dat and the key file aren't plain text.

Split level overrides high water, so if the copying method creates empty folders and then fills them, the allocation method won't be applied.

Maybe this from the first page of this thread? https://forums.unraid.net/topic/123985-timemachine-application-support-thread/?do=findComment&comment=1131485