trurl

All of your disks are mounting. Doesn't look like you have much data, but all disks seem to have shares on them. And no shares are empty. Which share do you think you are missing? You don't have a system share but it doesn't look like you were using one. Your disks are all XFS except for btrfs cache, not reiserFS, so reiserfsck would not have been appropriate. Do you have any output from that attempted reiserfsck? Are you sure you didn't reformat any of them?

OK, that is all as it should be, appdata and system shares are all on cache where they belong. Mouse-over warning triangles to get a popup explanation. Since you currently have no redundancy for cache that is the way those will be. It is not necessarily a bad thing as I explained. And you have plenty of room on cache. I like to set appdata and system to cache-only so I know they will never overflow to the array. And, I prefer to just use the default high-water allocation for all of my shares. It is a good compromise, spreading your files out without constantly switching disks just because one temporarily has more free than another. I don't bother with split level since high-water will usually keep things together anyway, and the only consequence of splitting things is a possible delay while another disk spins up. The most important share setting that controls which disk Unraid will choose is Minimum Free. If a disk has less than minimum, Unraid will choose another disk. It has no way to know how large a file will become, so you should set Minimum Free for each share to larger than the largest file you expect to write to the share. If you allow Unraid to choose a disk that doesn't have space for the file, the write will fail. Cache also has a Minimum Free setting in Global Share Settings. It works in a similar manner. If cache has less than minimum, Unraid will choose an array disk instead, but that only takes effect for cache-yes or cache-prefer shares. I'll let you decide which other shares you want to cache. I recommend none until you have things working well again. So, review each of your share settings, paying particular attention to Minimum Free. Then we can move on to getting your dockers going again.

Post new diagnostics

OK, then back to this: Post a diagnostic from after the upgrade.

So do you mean it is working correctly now with the new version?

Try this. Since you were having problems with the filesystem on flash when you made the backup then maybe you no longer have a good install. And, in fact, that syslog shows you still have corruption of flash. After you prepare a new install and copy config, be sure to use a USB2 port to boot from. Also, see this sticky pinned near the top of this same subforum for instructions on how to get diagnostics from the command line: https://forums.unraid.net/forum/index.php?topic=39257.0

This means it isn't getting DHCP. Check your ethernet connection.

You should NOT have a growing docker image, and making it larger won't fix your problem. Start a new thread in General Support and post your diagnostics.

I may split your post and any replies to its own thread since we are still trying to support OP in this one. Can you get diagnostics?

Possibly just doing checkdisk on your PC would have fixed this. Did you prepare a new install then copy just the config folder from that backup, or did you attempt to use the complete backup zip? Config folder is all you need to add to a new install to get your configuration back. Have you cleared browser cache and whitelisted your server in your adblocker?

See here for an explanation of the tradeoffs: https://forums.unraid.net/topic/50397-turbo-write/

You really shouldn't base shutdown on battery level anyway. You don't want your server running on batteries until they are almost dead. You want it to shutdown after only a short period of time without power.

Is this the same UPS model you mentioned in the OP?

Set your appdata and system shares to cache-prefer, run Mover, wait for it to finish, then post a new diagnostic.

Shouldn't take long.

If cache is the only one that shows Unmountable then go ahead.

The main thing you want to avoid is formatting any other disk. After you start the array it should show you that all of your array disks are mounted and only the cache disk is available for formatting. I don't expect any problem here since your other disks have been fine so far but just being cautious Go ahead and Start then post another screenshot that also shows your Array Devices if you can.

Try manually editing the file config/domain.cfg on flash to disable VM service.

yes

Post your docker run command as explained in the very first link in the Docker FAQ: https://forums.unraid.net/topic/57181-docker-faq Probably worthwhile for you to read the Getting Started section also. Here is another link in the Docker FAQ that might be useful to get your dockers to work together: https://forums.unraid.net/topic/57181-docker-faq/page/2/#comment-566086

I haven't needed to format anything in a while and I am not going to try it now just to refresh my memory. I may not describe it in exacting detail, but it is fairly simple. Before it will allow you to format anything, you must stop the array first. Go to Main - Array Operation and Stop. Then, go to Main - Cache Devices and click on the disk to get to its Settings page. Change the File system type to btrfs. Then go to Main - Array Operation and post a screenshot just to refresh my memory. Ask questions if this is unclear or there is something missing in my description.

You MUST format it while it is in the server and assigned as cache. Instructions to follow.

There is nothing in diagnostics specifically to track spin up/down. You might be able to get some information by carefully analyzing the syslog but I am not sure everything related to that is logged. The default schedule for Mover is daily in the middle of the night. That schedule is at Settings - Scheduler. Mover is intended for idle time. Some people try to cache too much and then expect Mover to keep up. It can't regardless of the schedule or even running it manually. There is no way to move from fast SSD cache to slower HDD parity array as fast as you can fill cache, and trying to write and move at the same time just causes competition for the disks. Better to not cache if you have a lot of data to write.

OK. The whole point of course was to get everything moved off cache so it could be reformatted, so we are ready for that now. You have 2 choices, XFS or btrfs. If you think you might want to eventually add another cache disk then btrfs is the only choice. That is the only way to get redundancy for cache. Whether or not redundancy is important for cache is another question. Cache is where your system share and appdata will live. appdata share will contain all the "working" files for your dockers, such as your plex database. system share will contain docker image, which is easily recreated so no need to backup. If you ever have VMs system share will also contain libvirt image. There is a plugin that will automatically backup appdata and libvirt to the array. So, redundancy in cache for these is less important. If you decide to also cache some of your user shares, then those cached writes will have no redundancy unless you have another cache disk. But those cached writes will be moved to the array anyway. If you think you might eventually want to add another cache disk you have to choose btrfs for the current cache disk, or else you would have to repeat this whole thing later so you could reformat cache. Personally, I have 2x275GB SSDs as btrfs raid1 cache pool, but to some extent I just did this as a learning exercise. I could probably do just fine with a single cache disk and the backup plugin. And I don't cache user share writes since most of my writes are scheduled backups and queued downloads, so I am not waiting on those writes to complete anyway. By writing directly to the array they are already protected. Some people keep other things on cache just for performance or to avoid spinning up array disks. I have a copy of some of my music and photos in cache-only shares so they can be frequently accessed by other devices on my network. But since those are only a copy redundancy isn't needed. In addition to those and my appdata and system shares, I also use SSD cache as temporary storage for DVR since there is some benefit to the performance gain when trying to record and playback at the same time. Plex has DVR capability but it requires some hardware to get the signal to record. So, your choice, XFS or btrfs. btrfs is arguably the more flexible choice, and the default choice for cache on new installs.

You were trying to do a parity check and load all of that data at the same time? Parity check or sync uses all of the disks in the array so that would also be in competition with moving or writing to the array. Some people even wait until after the initial data load to install parity so that big write won't be slowed down by parity. Good advice from @je82