Borg support

Added 1 commit:

caef4408 - [borg] added copyright notices

added 1 commit

6e92d3f6 - borg is called borgbackup in Debian and on github so we should recommend that (u…

I've started testing using this handler script, and while it doesn't yet support encryption, it does seem to be working. https://gist.github.com/maethor/01b1466f3b11f25b9c12a675d0c682ea

I'm planning on taking a look to see if I can make it support encryption.

Oh, I see now yours are based upon those, great! What steps are needed to test this to move it forward?

I'm familiar enough with git to be able to poke around the repo, but not good enough to know how to make my own request for update to your code.

I have gotten encryption working using this handler as the basis.

Here is the code for a borg handler file that works with encryption if you add a "passphrase = " line in your /etc/backup.d/*.borg job.

borg

I also made a handler that enables me to do borg backups to usb drives that I mount and unmount, combining code created by @JonG for rdiff local backup jobs years ago, with your handler.borglocal

added Handler: new label

added 24 commits

6e92d3f6...f8e1664e - 16 commits from branch riseuplabs:master
c067f871 - Add example.borg to Makefile
c591c38f - Merge pull request #2 from module0x90/borg_support
1d13acd9 - Merge branch 'master' of 0xacab.org:riseuplabs/backupninja into borg_support
4d2df913 - [borg] added encryption support (credit to @mxroo and @leoberry)
fcdf6ca5 - rebase me
e95c2fec - fix automake failing since there's no README file anymore
c3c321a0 - pgsql shouldn't be different from master here
00061235 - Merge github.com:Benzhaomin/backupninja into borg_support

Compare with previous version

@JonG @mxroo encryption support was added with a mix of code from @mxroo and @leoberry from Github

@mxroo support for temporary external drives could be merged if you make it cleanly optional as right now we'd always run mount and umount commands. I think dedicating a section of the conf file to automounting and adding a toggle to enable it should do the trick. Thanks for your help

resolved all discussions

Next step: find people interested in reviewing this.

For the sake of clarify: do those who participated in developing this new feature commit to maintaining it on the long-term? (backupninja has essentially been in maintenance mode for years, and the past/current maintainers cannot commit to maintain ay additonal code themselves.)

Thanks!

Hello, I have tested this handler and the connection test fail if we use a ssh forced command as mentioned in the borg documentation. I add a complement to the connection test to take this possibility into account (see patch attached).

test-connect.patch

@LeLutin: you might want to review & test this :)

added 16 commits

00061235...8f29e112 - 15 commits from branch riseuplabs:master
ef02cd7d - Merge branch 'master' into borg_support

Compare with previous version

added 1 commit

977ae26b - [borg] fixed connection testing (thanks @orel)

Compare with previous version

i haven't reviewed all the details here but it seems to me there's an overlap between this and the handler here:

https://github.com/mxroo/borg_backupninja

has anyone reviewed the changes between the two? is there an overlap or is this the same effort?

In my use case, a connection failure is not necessarily fatal (Using a laptop and a borg server on a local network). This is why I added an option to allow to have only a warning in this case (to avoid being spammed by backupninja).

This option does not change the default behavior. It has not been added to the helper. See patch attached.

fatal-connect.patch

@orel I don't think this patch the correct method to solve your problem. Instead, you should either configure your backup to run manually and implement an extra cron job which tests for the presence of the server before launching the backup job using backupninja, or have NetworkManager launch it when connected to your specific network using a dispatcher.d script.

@intrigeri I plan to use this handler on a fleet of servers, so I can offer my help in maintaining this new handler (and backupninja in general).

added 6 commits

977ae26b...f3aa50f3 - 3 commits from branch riseuplabs:master
04ea3d30 - Merge branch 'master' into borg_support
a604b75d - reverted unwanted change from .gitignore
b662b728 - [borg] fixed include order in example file

Compare with previous version

@lavamind Yes, I may not have taken the problem at the right end...

Concerning other points:

The handler does not allow the use of the "keephourly" option. If you are OK to integrate it, you will find a patch keephourly.patch
I think there is a problem with the helper. Currently, even if you choose "none" as the encryption method, you must provide a password. That's why I changed it to set the encryption method separately from the destination encryption.patch

@intrigeri I plan to use this handler on a fleet of servers, so I can offer my help in maintaining this new handler (and backupninja in general).

Excellent :)

resolved all discussions

@orel I don't think this patch the correct method to solve your problem. Instead, you should either configure your backup to run manually and implement an extra cron job which tests for the presence of the server before launching the backup job using backupninja, or have NetworkManager launch it when connected to your specific network using a dispatcher.d script.

Agreed. Let's try to keep consistent semantics accross backupninja handlers, i.e. a backup that was attempted but could not be successfully cmpleted (for whatever reason) is a failure.

It's not 100% clear to me what's the next step here. Anyone who feels like they own the next action, please assign this to yourself :)

@intrigeri @lavamind i think there are still issues with the current MR as it stands. in particular, i think it would be important to support encryption-less configurations, ie. add the patch @orel suggested above (which I haven't reviewed).

i also wonder if there should be a way to not purge backups at all... but maybe that can be bolted on top later. this has been sitting here for a year, we could just merge it and improve it later, if there are no glaring (e.g. security) holes.

@intrigeri also: what's the policy on merges here? should we cleanup the history? there's a bunch of merge commits in the MR history - should we rebase this properly? how about unrelated whitespace changes in the makefile and README? do we care?

@intrigeri also: what's the policy on merges here? should we cleanup the history? there's a bunch of merge commits in the MR history - should we rebase this properly?

I'm not part of the "Git history MUST be linear" church. I don't mind merge commits.

how about unrelated whitespace changes in the makefile and README? do we care?

I care about atomic commits whose diff match what the commit message says. I often use the "what would the Debian release team say if I cherry-picked this commit in my packaging for a stable p-u request?" heuristics as a way to define whether the unrelated changes are a problem or not.

okay, so it might still be worthwhile to rebase this to properly cleanup the patchset at least...

mentioned in merge request !10 (merged)

Superseded by !10 (merged)

closed

Borg support

Merge request reports

Activity