Mr.Grumpy

Disclaimer, I don't know much about this as I've yet to do it but since you are stressed, I'll give a suggestion. Libvirt is probably missing. Seems it's in the "System" share and if that was on your cache drive, that could be why your docker containers won't start. /mnt/usr/system/libvirt/libvirt.img /mnt/usr/system/docker/docker.img

I second this and the parity check tuning doesn't offer this. It only manages increments/pause/resume I believe as per the author. I asked the same question in that thread. Basically an option to run a parity check every x days and/or on a schedule, whichever interval happens first. Thanks!

Looks like it's been asked.

Ahh I see. Messing with the built-in functionality is a bad idea for sure. I'll look into a change request but like I said, not needed, just could be a nice to have type thing. Thanks!

@itimpi That is correct, only run if it hasn't run in x days no matter how it previously ran (from a crash or schedule). I currently have mine to run 4 times a year but recent server crashes made me think of this idea. It might be as simple (probably not!) as a new variable of number of days between parity checks and doing a date compare with the last parity check. Then it would just be math, date greater than or less than and process form there or if days between is set to 0, ignore. How that would all fit into the existing script, I have no idea! It's a challenge and certainly not needed, just an idea. Thanks again.

Thanks for the plugin! This is a possible feature request, or it might already be possible. I looked for a search option for just this thread but couldn't find anything, apologies if this has been asked and answered. I'm wondering if it's possible to schedule a parity check every x days instead of a set date. Say every 90 days instead of Jan/March/June/Sept. The reason, server crashes which starts a parity check. And if you are unlucky and a crash happens just before your next parity check, you get two checks close together which equals more power, heat and drive wear. Just a thought. Thanks and keep up the great work.

For regular ryncd, not using ssh I've figured this out... for my use case this should be fine as I'm running Tailscale between a DS218j and my UNRAID instance but smarter people than me can weigh in on that. Limited to a single user best I can tell. Keeping the secrets file and the rsync.conf outside of the Docker container would be nice but I don't know enough about Docker on how this would be accomplished. Anyone? Doing that could mean multiple users I think as you could just edit the files and they'd survive a container upgrade as they'd be in appdata. On the DiskStation side the "share" shows up as "volume". This is configurable as per the Docker docs but I'm not sure to what advantage at least for my use case. Hopefully this helps someone else. Also, side note, I followed the video below (I can't speak/understand Spanish!) but I was able to setup Diskstation as a VM on UNRAID for testing this following the video. I haven't done a backup yet of a "Real" Diskstation but I'm able to connect now and proceed through the HyperBackup wizard so I can't see it not working the same as my virtual Diskstation. Docker container: https://github.com/axiom-data-science/rsync-server Windows Explorer of the rsync folder contents Console of the rsync docker with contents of the rsyncd.conf and rsyncd.secrets file for reference.