Nuuki

Great - thanks Jorge! So the big question is, what's the right/best way to clone the data across? And just to confirm, as this is the risky bit, are these the correct steps: Format SSD Create a new cache pool using just the SSD Copy data from old to new cache Delete original cache pool Rename new cache pool to match old (is this needed? Some docker volume mappings use "/mnt/cache") Add name to new pool to create RAID1 No - the new drive is larger, so I'll run with just that until I upgrade my chassis to something with twin M.2s. Are you saying that I could add the new drive to the pool, remove the old drive and then expand the cache pool to use the full capacity of the new drive? I didn't think that was possible and that a new cache pool was required to change size.

I'm looking for some advice before I make things worse... I run Unraid on a Dell 7060 Micro, which has a single SATA and a single M.2. I don't have a local array - my storage is on a separate Synology with this server just handling containers and VMs, via a cache pool. Currently I have a single nvme drive providing the cache. I used to have a RAID1 mirror but the second drive was SATA and was getting old so I took it out with the intention of upgrading. Then pricing exploded... Inevitably, the nvme is now starting to fail, and I need to replace it. My intention is to pickup a larger and better quality nvme more suited for server operations, so I'm just looking at options to handle a migration. The new drive looks like taking a week to arrive, so getting some redundancy back in the meantime would be no bad thing too. Firstly I tried to recreate the RAID1 mirror, but as the SATA drive is only 480Gb and the nvme as 512Gb it clearly won't let me do that. If I had an array I could backup to that, but I don't. I think the next best option is probably to clone the nvme to the SATA drive, make that the primary in the pool and then re-add the nvme - as it will be larger than the pool I assume that would be fine? Then, when the new drive arrives, I assume I'd need to break the pool again to just the SATA, drop in the new nvme, create a second pool at the larger disk's full size (1Tb) and then copy over the data from 1 pool to the other. Whether any of this is workable or best practice I don't know, so I'm looking for some advice. I have plenty of capacity on the Synology, but I assume that using that isn't sensible, given likely issues with permissions etc when copying between systems? Any advice gratefully received - I'm a bit anxious that I don't do this right I'm going to take the server down. I do have data backed up, but I still don't really want to be rebuilding it. Thanks in advance for any advice or suggestions!

Probably me being dense, but how are you handling authentication? Hyperbackup requires it but your image doesn't reference setting a password.

Its now been running for about 17 hours without issues - plugged in at the wall rather than to a smart plug and UPS. I'll probably try moving it back to the UPS to see if the issue comes back, as if so I think that's then conclusive. Either way this doesn't seem to be Unraid related, so I'll close this out. Thanks for the support, as ever!

OK - so I powered the server back on after the above outage, but I then started seeing Emergency logs from nginx, indicating "Address already in use". I issued a reboot over SSH and its now come back up without those same issues - I've attached the logs from when it came up following the loss of power. Maybe its a result of the sudden power failure, and not part of the root cause? Anyway the server is up again, this time running from a standard output (rather than the UPS). I'll see if it stays up for longer than 15 minutes... new logs.txt

OK, so I had the server running for about an hour with no issues. I removed the out of date mover plug-in, checked nothing unexpected in the logs and fired up Docker. I'd moved it so I could connect a monitor and keyboard, so once I was happy that everything seemed fine, I moved it back to my equipment cupboard. After about 15 minutes it powered off again. No beep to indicate it was going to shut down, and when I check the remote syslog I see it was in the middle of bringing up containers, with nothing indicating any shut doen had been initiated. I just looked over and realised the power light was off. I'm now noticing that my UPS is clicking about once per minute. However its not beeping to indicate its on battery, and none of the other equipment is having any issues. Its on Low sensitivity for input voltage. So overall I'd be a bit surprised if that was causing the server to completely power off, but its clearly possible that its related. I guess my next step will be to leave it where it is, but run a separate power cable to it, bypassing the UPS. Anything else I should be doing in Unraid?

Yeah sorry for not being fully clear. I'm just running a check on 1 of the 2 drives in the cache pool. Once that's done I'll power up in safe mode and see what it does.

Thanks. I don't actually run an array - I'm just using Unraid for Docker. I'll remove that plug-in though, once I get things back up and stable.

The server initially powered down shortly after 1am. I turned it back on manually, but then initiated a standard reboot. So that reboot was likely from me.

Last night my server unexpectedly shut down shortly after 1am - no issues with the UPS and everythng else was running fine. I powered it up but after a short while it shut off again. I did grab a diag dump before that happened, though I asume it will be missing any relevant info from the over night crash. It now seems to be powering off every time - the UI is useable but after a few minutes or so it powers off. I do also ship SNMP events to a remote server though, so I've also attached logs from just before the point where it originally shut down. Any help is much appreciated. server-diagnostics-20250306-0751.zip syslog.csv

Thanks! I've added a memory limit for now, but I guess I'll need to do more digging if it starts running out of control again. As noted above its a shared postgres container, so maybe its time to run 1 per application...

It looks like the postgres container was to blame. I use that for about a dozen application - the one exception being Immich, which I have moved to its own postgres instance. I've bounced back and forth on whether to have a dbms per app stack or one shared one - up to now I've gone the shared route as I'm not using compose and it seemed more elegant, but maybe its time to split postgres out, to make troubleshooting and resource management easier. Good to know. I've rebooted since then so I can't check which container that was I don't think, but I'll keep an eye on the logs to see if it crops up again.

Been running my Unraid server for a few years without issue. In the last couple of weeks I've had a few occurances of it grinding to a halt - some apps still run, but the Unraid UI is inaccessible, and even SSH is inconsistent. Apps are typically not accessible. A reboot clears it for a while but then I can't grab the diags. Today it happened again, but I was able to use the GUI. Fix Common Problems indicated "Out Of Memory errors detected on your server". I was also able to grab a diag download. I assume one of my containers if probably to blaim, but the system is so unresponsive that I'm struggling to troubleshoot it at the time. server-diagnostics-20241130-1548.zip

In the end I switched to a Docker image - its clearly not necessarily anything to do with the root cause, but its resolved things for me for now.

I noticed that a couple of containers were Stopped. When I try to start then I get the following: docker: Error response from daemon: Conflict. The container name "/Rallly" is already in use by container "fc8e9affcd6dc1be9853b7aec51893d1af5a5fd8f6dcdd8fd4f557d71c5e2144". You have to remove (or rename) that container to be able to reuse that name. Tried deleting and recreating the image but no luck. A quick search on them forums indicated a possible corrupted image. However in my case I'm using a docker directory (zfs). Is there a way I should be removing just this image? server-diagnostics-20231031-1400.zip