Michael_P

What time is Plex's scheduled maintenance set to kick off?

Just format them with an encrypted file system

He does in the videos before he bought his house - it's a thunderbolt dock and fiberoptic cables

No, I don't know how docker determines when to enforce it or not - you can force docker to do it instead of the kernel with the --oom-kill-disable flag, but use it cautiously as it's highly likely to bring down the entire system if docker doesn't do it right. https://docs.docker.com/engine/containers/resource_constraints/ Your best bet is to figure out why crashplan is running away and change its config to prevent it.

Crashplan was using ~11GB when it was killed

Crashplan is running the host OOM, check its config and/or limit its RAM usage. Restart the server to clear the log or FCP will continue to warn you about the past events.

Looks like Jellyfin ran it OOM back on July 30, restart the server to clear the logs or FCP will continue to warn you as it wlll keep finding it in the syslog. If it happens again, check the containers config to make sure large files go to disk and/or set a maximum RAM limit for the container.

I use this rsync script to backup important stuff on my main unraid server to another unraid server For my PC clients I use UrBackup - I've read you can use it on unraid without issues, but I haven't tried it myself as the rsync script works fine for my needs

Post new diagnostics Your old diagnostics shows 3 containers using python3 - SABnzbd, nzbhydra, and something related to dirsyncpro

You could try it from the docker's console - the binary in Binhex's container is at /usr/lib/plexmediaserver/'Plex Media Server' You'd just need to dig up your db's location.

You'll need to reboot to clear the log, too - or FCP will continue to alert on the OOM message that happened on the first.

In syslog, look for what the OOM reaper killed - it's usually what was using the most memory at the time it was invoked and is a good starting point for things to look at Aug 24 04:58:31 Thor kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/docker/3eadda6d1b73333324db9fbaa031c372ef50c91c2649e30af0c159dd285d8b20,task=bztransmit64.ex,pid=13979,uid=1000 Aug 24 04:58:31 Thor kernel: Out of memory: Killed process 13979 (bztransmit64.ex) total-vm:7675808kB, anon-rss:7409296kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:14836kB oom_score_adj:0

Looks like Backblaze ran amok yesterday - you'll need to reboot to clear the log or FCP will continue to report it. If it happens again, you'll need to work on whatever Backblaze is doing to make it stop

Is anything else using your GPU? Have you tried asking in the container support thread/forum? Have you mirrored your syslog to flash so it's saved before it locks?

Equal in that they're not protecting your data at all, yes. Z1 and single parity are essentially the same. Back up your important data.

Interface priority should work here too https://support.apple.com/guide/mac-help/change-order-network-services-mac-mchlp2711/mac Similar is available in Windows if anyone's looking for that

OK, but your log and the fact your system ran OOM says otherwise- but you do you.

Looks like frigate is running a python3 process that's chewing up a bunch of RAM

Probably best to start fresh there, and recover any apps/docker containers you had installed.

There's nothing on the parity drives, no actual data is stored on them

You deleted all your files dude lol - Getting them back was never going to be easy. For btrfs try the equivalent script.

Big oof - but if your FS is xfs you can give this a shot if you haven't written to the drives https://github.com/ianka/xfs_undelete

If you're happy enough with the file transfers, any tweaking would need to be done in whatever streaming software you're using (ie: using buffers/caching).

SMB doesn't like latency, at all. 90Mbps isn't bad considering

Not just overhead, latency is a transfer speed killer