Seeking new volunteers to continue this project

[highvoltage]

Hi everyone, a while back I gained rights to this project with the intent of helping with the PR backlog. While I made a bit of progress, I got increasingly busy in other areas and just don't have the time to do more maintenance on this. While there are newer (and probably better) tools that handles the functionality of zfs-auto-snapshot, many people still use it in long-term production environments so I think it might be good if someone continues to maintain it, even if just for bug fixes and managing PRs.

If someone is interested AND have the time to maintain this, let me know and I'll arrange the rights for you. If I don't hear from anyone in a month I'll make a note in the README that this project is no longer maintained and that users should rather seek to move to alternatives.

[behlendorf]

@highvoltage thank you for all the effort you've put in maintaining this project. It's been appreciated!

We could relocate the contents of this repository to the contrib/ directory of the https://github.com/openzfs/zfs/ repository. If members of the OpenZFS community still find the script useful they can then open PRs there which can be reviewed and merged. This would at least allow for basic maintenance activities. Though these days there are other good alternatives and I like the idea of encouraging that transition.

[TuncTaylan]

I'll be more than happy to maintain this project.

[nicman23]

is there an active fork for this ? if not i ll start one for sending through ssh to remote hosts.

[mailinglists35]

@behlendorf @TuncTaylan what is the state of maintainer?

I still find the script useful and I haven't been able to find a better solution despite lots of similar projects on github. I highly appreciate that it's a shell script with no external dependencies and I also appreciate that it can skip zero sized snapshots.

My local copy also has a small modification that also creates a bookmark for each snapshot which is extremely useful for remote replication in case the destination has lost all common snapshots. If this is maintained I would like to submit my bookmark creation modification as a PR but without knowing there is a mainainer I don't want to spend time on creating the git PR.

[behlendorf]

@mailinglists35 this repository currently isn't being maintained.

[mailinglists35]

@behlendorf but earlier @TuncTaylan showed willingness to maintain it.
what prevents this, in case @TuncTaylan are you still interested?

2023 and still nothing better than zfs-auto-snapshot

[TuncTaylan]

Hello everyone, sorry, but I offered to maintain this nearly three years ago, since then I got more busy. Unfortunately I wont be able to invest much time.

[dandudikof]

zfs-auto-mod would like to throw a hat in to the ring
https://github.com/dandudikof/zfs-auto-mod

bash based modular snap replicate prune script (pick which functionality you need)

just pushed a bunch of updates (working towards v1.01)

[mailinglists35]

@dandudikof does/can your script replicate the behaviour of zfs-auto-snapshot? including the same snapshot naming scheme, deletion policy and honoring com.sun:auto-snapshot dataset property value?

[dandudikof]

My script was written independently of any other software.
mainly based on my needs and to keep thing simple and clean.
(but i started thinking and adding options for other users)

Snapshot naming is described in
https://github.com/dandudikof/zfs-auto-mod#zfs_auto_snapsh-2-types-of-snapshots

com.sun:auto-snapshot is not used

mainly uses config file

and extra control is achieved with pfix:inc and pfix:excl
(pfix being one chosen in the config file)

sort-type1 is auto inclusive for all s_sets or s_pool (need to use pfix:excl to exlude)
sort-type2 is manual for (need to set pfix:incl for every set)
(pfix being one chosen in the config file)

all of this is described in the README.md on main page

[mailinglists35]

then why bother mention it while this discussion is strictly about keeping zfs-auto-snapshot alive?

[oskarfessel]

So, even though some people try to make contributions, we still don't have someone who maintains this?
I have seen someone working on FreeBSD compatibility, I have changes for NetBSD locally and systemd
changes were also made but not committed. Among other things.
Any ideas on how to move forward?

[mailinglists35]

@oskarfessel I believe the best way for keeping this project alive is by forking and commiting to maintaining it.

no interest from OpenZFS has been manifested for keeping this alive - on the contrary see brian's comment from 2022 #117 (comment)