Maintenance needed

[bebehei]

Obviously, rsnapshot is not maintained anymore. I have not made any contributions in recent time. Also it won't happen anymore: I migrated from rsnapshot to another backup solution.

There are plenty of unmerged pull requests, which I won't merge.

So, If someone is interested in taking over the maintainership, I'd appreciate it.

[philhq]

I'm curious, what backup solution did you migrate to?

[shodanshok]

Please consider merging #179

It is a one-char change, but a big improvement in reporting serious errors.

[bebehei]

Please consider merging #179

@shodanshok After reading through, it seems quite reasonable and also @sam-at-github has already approved the changes. Actually I don't want to merge such "big improvements" anymore bc I can't test them anymore fully.

The primary goal of this thread should be finding a new maintainer and not me merging some stuff.

[shodanshok]

@bebehei I fully understand. Thank you for merging the change.

[Zerophase]

@bebehei Which backup solution are you using?

[vimeitor]

Can't talk for him, but I've heard very good things about https://github.com/borgbackup/borg, so that might be what he is using.

[bebehei]

Can't talk for him, but I've heard very good things about https://github.com/borgbackup/borg, so that might be what he is using.

@vimeitor Your second name is by accident Holmes?

Yes, I migrated to borgbackup. For the questioners: Didn't captain obvious call you?

I think I have to be more open about it:

Why did I change: My backup configuration failed. I can't afford a RAID1 to back it up and my backupdrive started to fail. Long story short: I had no backup anymore. My colleague already used borgbackup and he loved it. So I said: Ok, let's start from 0 again and compare both at first.

And yes: borgbackup outperformed rsnapshot on my dataset.

I have to warn you: Just because the maintainer changed to the other side, doesn't suffice to switch your backup solutions. There are plenty of differences in borgbackup and rsnapshot and also some big differences in design. Rsnapshot has its advantages here, too!

I hope in future, someone with good Perl skills and enough time will get found to fix the outstanding bugs and develop it further. I'm pretty sure there is someone around, but he might haven't looked into the bugtracker yet.

[mrjcleaver]

Fair enough, everyone on their own path.
I do hope you are willing to pass over the reigns of the rsnapshot account to someone willing to take over. If you were me you'd be looking at who had the most commits waiting, and offer it to them.

[bebehei]

I accept suggestions and volunteers. Until now, two persons reached out to me but their interest declined quickly.

I do hope you are willing to pass over the reigns of the rsnapshot account

That's why the issue got opened 😉

If you were me you'd be looking at who had the most commits waiting, and offer it to them.

@mrjcleaver Do you have any reasonable suggestion?

[mrjcleaver]

Sadly not. I was looking for a tool, something rsync based, when I came across this.
I found some gui tool[1] that looked great, but they depend on you, and you are going away.

[1] name escapes me!

[bebehei]

Well, rsnapshot is packaged in almost every distro. It's stable and all usual issues are well documented (and mostly have a workaround). If I would need something rsync based, I'd choose rsnapshot again. No matter if it's maintained or not.

[1] name escapes me!

You probably found elkarbackup.

[mrjcleaver]

You probably found elkarbackup.
That was it ;)

I don't doubt it'll work this year, and next. And while I don't expect anything to work beyond 5 years... not having someone at the helm concerns me for anything I invest attention to.

[AndiDittrich]

if there will be a new maintainer soon, you might suggest to merge our rsnapshot-ng fork - it inlcudes some enhancements like js based testcases and systemd examples but also some breaking changes. and it requires some additional work to update the old docs.

unfortunately i'm not very familiar with perl...therefore i'm not able to maintain the whole project alone :(

best regards, Andi

[bebehei]

I've finally got a promising e-mail conversation with an interested future maintainer. I have requested him to also make contact here in this thread. If some of you guys want to help him out, he'd definitely appreciate it.

I hope this project will finally get some pace again!

[djk20]

I am not the person referred to on 2018-01-05.
I am interested in helping with maintenance of rsnapshot, and I have a bit of spare time.
But I am new to using github.com and the updated development process in the last few years, and haven't really been paying attention to rsnapshot 1.4.x.
So I don't think I can do this maintenance alone, but I think I can be part of the solution.

[bebehei]

@djk20 Well, most of you will know your real name, as you had been a previous maintainer of rsnapshot.

The person mentioned in #191 (comment) was @StefanMoch. I already invited him to the @rsnapshot organsiation. Maybe you guys could get together here and get things on.

[AndiDittrich]

any updates ?

[bauen1]

I'm also interested in maintaining (until somebody else has been found perhaps) rsnapshot, because i'm using it as my backup solution and because this issue hasn't been resolved for 1.5 years.
I know how to use git/github but don't know how to program perl (I can read the code and understand It, I just haven't taken the time to learn it yet)

[bebehei]

@bauen1 TBH: I don't think it's a good sign to stand up for maintainership just because the project isn't maintained for >1.5yrs whilst you haven't got any Perl skills.

But if you really want to go on: Pick a bug. All of them are actually unassigned. Take your time to develop a solution, write tests and fire a PR and get it reviewed. If the review is positive, I'll invite you to the organization and you can click the merge button for your own PR 😉

[bauen1]

That sounds good, I'm just don't want this project to end up abandoned, since it's by far the best backup utility for my use case

[bebehei]

Well, I've already outlined the rules. I appreciate a PR from you 😉

[admirabilis]

Can't talk for him, but I've heard very good things about https://github.com/borgbackup/borg, so that might be what he is using.

I use rsnapshot for local backups and Borg for remote. It seems to work good, although I haven't tested restoring files with it much. I used Duplicity years ago, which is similar to Borg and more established (I think it's the default in some distros with the Déjà Dup GUI), but restoring is hell and it made me lose a couple of files.

I still think rsnapshot has its place in, for example, backing up the whole root directory to a different drive. For my daily backups of select files to a separate partition, I still use rsnapshot too.

I'm grateful to everyone who contributed to rsnapshot over the years, it saved my skin so many times. I'm probably gonna use it until it doesn't work anymore.

But for anyone in search of backup solutions, here are some links:

• https://wiki.archlinux.org/index.php/Synchronization_and_backup_programs
• https://duplicacy.com/
• https://www.ezix.org/project/wiki/Pukcab
• https://vermaden.wordpress.com/2018/05/01/bareos-backup-server-on-freebsd/

[DrHyde]

although I haven't tested restoring files with it much

For the love of god test that! If you've not tested your backups you don't have backups, you have hope!

[admirabilis]

For the love of god test that! If you've not tested your backups you don't have backups, you have hope!

I generally recover files from my local rsnaphot backup instead of the remote Borg's. But it turns out I'm not that stupid. I had these lines that actually test the restoration process in my borg script all along:

borg extract ::"{hostname}-$date" home/teresaejunior/Notes.ctb
file home/teresaejunior/Notes.ctb | grep -q SQLite

It never failed. Now in contrast, I've made duplicity backups to two different servers, and lost files in both. I think the reason is you should logout to run the backup, which kind of defeats the purpose of having a daily backup for me.

[MTecknology]

@bebehei @djk20 Regarding the comment in #242- does that mean this issue can now be considered resolved?

[bebehei]

Ok, as @djk20 nominated @sgpinkus to be the new owner, I guess this is resolved. He has got already 'ower' privileges. (For all freshones, djk20 is an original author of rsnapshot).

@MTecknology I guess, you should ask @sgpinkus for maintainer privileges. He has got full rights now.

I'll leave the orga now. Best wishes for this project to gain some momentum again.

[MTecknology]

@bebehei I'm glad you stuck around until a replacement was found. 👍

[sgpinkus]

Hmmm ... never agreed to be maintainer. I'm owner now allows me to maintain better when it's needed I guess. Anyway ... @bebehei thank you for your service.

Note, my opinion is and always has been rsnapshot is in maintenance mode. I'm not really willing to work on big new features and never have been. My whole involvement with this project started with just wanting to get a bug fixed in upstream. Pretty sure it was the same for @bebehei .

The code base is pretty long in the tooth by now and has been worked on for many years, by different authors, so naturally has become somewhat brittle. Making big changes to the code to incorporate new features can be quite challenging and lead to unexpected bugs, especially when tests are not provided.

[djk20]

This is probably the wrong place to put this, but I'm not sure where else would be better. (Happy to hear suggestions.)

The nice people at Port Morgan who run DNS servers for rsnapshot.org have said they would like to move DNS servers to cloud.
Unless anyone expresses concerns about that, I will go ahead with that change.

You can reach me (and hopefully soon other rsnapshot maintainers) at maintainers@rsnapshot.org.

David Keegel.

[ghost]

Hi

I sent you an email. Has it landed in the spam folder?

[Yannik]

As per #279

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986709

The rsnapshot package is being removed in the next debian release.

That really hurts, as I use rsnapshot heavily.