bstone108

no problem! while it's not pretty, it's functional! let me give you a bit of advice though. Set your run frequency and retention policy to something sane. If you keep too many snapshots you'll notice mount time on your zfs pools gets very slow. If you notice this, just dial back the retention policy and give plugin a bit to do cleanup on it's next run. Please note, on a massive cleanup that takes longer than your next scheduled run, it'll skip that snapshot since plugin is still busy. So don't panic if a big policy change causes a few skipped snapshots.

In the process of cleaning up the code a bit in both release and testing. Tracking down a few minor security concerns and removing some macos leftovers. I'll publish an update shortly. there are a few security concerns but they require direct access to be exploitable. if anyone spots more issues like that please let me know. that being said I'm releasing an update right now to both branches that fixes what I've found so far. main branch doesn't have all the fixes because I don't want to break plugin for those using it, testing will have all fixes applied but it's a testing version, no idea if it works yet. Also I've gotten a couple complaints from people that this was ai written. I want to tell you the following.. You're not entirely wrong. My original script this plugin was based on was entirely written by me. And as I'm not familiar with writing plugins and never remember to write changelog comments, i'm using ai to help guide me with the plugin writing, and dealing with those pesky comments I always forget to write. Sometimes the code is ai, sometimes it's me. I review it all and test but as I'm not a skilled programmer I do miss stuff. I learn daily, skills improve. I didn't write this plugin because I had skills or wanted something to brag about. I wrote it because there's no easy to use plugins in unraid that does the same, what we do have are over complicated for just a simple automatic snapshot tool and I needed something simple for a friend. Contributors with more skill than me [of which that would be most] are greatly welcome aboard if they want to help improve this project. it's a work in progress.

I need a little more information from you to figure out what’s going on. What shortcut? If you’re trying to get into settings, I don’t have a shortcut set up to link straight to it from the plug-ins page yet. Once the plug-in is installed, go to your settings page and scroll down to the bottom to get into the plug-in. You will see the ZFS auto snapshot plug-in.

This plugin is a very simple to use automatic snapshot management plugin for unraid. It should work on any version since 6.12.0 instructions for use, install and go to settings and find the zfs auto snapshot plugin near bottom of the page. From there pick the datasets you'd like to automatically manage snapshots for and set a minimum amount of free space. It defaults to 100G. if the free space drops below this amount, the next time the plugin runs it'll prune old snapshots to try and get it back above this limit, so try to pick an amount and a schedule that makes it unlikely you'll run out of space before the next scheduled time to take snapshots. Next is prefix name. The plugin will always create snapshots with this prefix, and will only ever delete snapshots with the same prefix. This prevents the plugin from deleting any manual snapshots you may have. Beware that due to how snapshots work, manual snapshots can still consume all free space and trick plugin into removing all your existing snapshots it's created. In a future version I'll try to implement some logic so that it won't delete a snapshot to free space if it'll have no effect, not counting snapshots with zero changes. Next set a retention policy, the defaults are already prefilled and generally work good for my use case, but you can adjust them to your liking. Please note, it's highly possible you never reach your retention settings if your free space doesn't stay above your set threshold so don't be alarmed if it never reaches your retention policy. The point behind the policy is just to keep excessive numbers of snapshots from accumulating. At this point I'd suggest enabling dry run and running a single manual run by clicking run now button. review logs for any problems. Finally, choose your schedule! it'll convert your choice to an appropriate cron expression and update cron for you when you save it. Note, I'm in the process of designing a snapshot manager for the next release. For now, I suggest using zfs master to manage snapshots. I'll update this message when that feature is ready. https://github.com/bstone108/zfsautosnapshot-unraid if you have any issues or suggestions please open an issue at https://github.com/bstone108/zfsautosnapshot-unraid/issues install links Stable (main): https://raw.githubusercontent.com/bstone108/zfsautosnapshot-unraid/main/dist/zfs.autosnapshot.plg Testing (testing): https://raw.githubusercontent.com/bstone108/zfsautosnapshot-unraid/testing/dist/zfs.autosnapshot.plg New features/changes, testing build. Please help me test these and report bugs found; insured testing version always works, might be buggy, but should work. improved snapshot handling logic. it should prune from datasets on a smarter behavior. only pruning an old snapshot if doing so would free space for the dataset with low space. Added some logic to auto prune all snapshots with 0 changes as they serve no purpose whatsoever other than to clutter up the metadata on the drive. So if you see gaps in snapshots, that's because the gap had no changes so snapshot was pruned to keep metadata from growing and slowing down mount speed, and for readability sake when browsing snapshots.

you should check your processor fan and heatsync. apply better thermal compound. Make sure there's good ventilation around the server and it's not in a hot room. if you keep having overheating issues you might want to consider underclocking your processor. If it's hard drives causing the overheating then make sure the plugin is configured to pause parity checking when drives are over a reasonable temperature, it'll resume automatically when they cool enough.

oh and for the curious, my build isn't anything super fancy. 8 10tb drives in a diy nas enclosure. just a basic mini atx server board who's only redeeming qualities is 8 independent channel sata ports and 2 nvme slots on the board. an 8x psi express slot and a 16x slot. 128 gigs ecc memory. 3.6ghz xeon processor. 1 tb nvme cache. planning to add a good video card for hardware transcoding but haven't decided on what to use yet. Don't need anything super powerful as even a cheapo can handle hardware transcoding at reasonably good speeds. it does take average of 1.5 to 2 days, sometimes a little more, for a parity rebuild. if I shut off all other services I can get it down to about a day.

lets do some math shall we? parity check on 10tb drives, 8 of them, 2 parity 6 data. takes around 1 to 1.5 days. lets add in a little interference like say syncthing and plex competing for some drive time and it's closer to 2 days, sometimes more. so for simplicity we'll just say 1.5 days. that's 36 hours. 36 hours divided into 30 minute segments, that's 36*2. that's 72 30 minute segments. so best case it would take 72 days to do a parity check doing 30 minute segments a night. please revisit your thinking on your 1-2 month claim. yes I'm sure some have faster rigs that can finish this quicker than mine, but mine ain't too bad so I don't see anyone getting too much improvement on speed here. As stated by others in the group, unless your rig is using much smaller hard drives, or you're using ssd's or some other setup that's faster than 8 spinning rust drives each hooked on dedicated lanes, then your system will be scheduling another parity check before first finishes and restarting. a common mistake in the plugin is at the top of the page, setting your parity check to daily. don't do that. this setting has nothing to do with the automatic pausing and resuming each day. Please set it to monthly or more. I suggest you leave the plugin at its default of what was it? 3 hours of checking a night? much more reasonable and still shouldn't bother you since it's happening while you sleep anyway. it stops around 3:30 by default because the mover is scheduled by default to start at 3:45am so it's trying to make sure mover doesn't have to compete with parity checking for hard drive access. If you need more time, then set it to start before midnight and leave ending where it's at already. This should work I believe, unless it was badly coded and fails the date calculation to determine your intent is to start before midnight and end after. my times might be off a little, if so feel free to correct me anybody. Sleep deprivation will do that to you. I'm running on 2 weeks with about 20 hours of sleep total the entire 2 weeks.