[Borgbackup] [IDEA] Add support for external commands

[Melkor Lord]

On Sun, Oct 2, 2016 at 4:17 AM, Sitaram Chamarty <sitaramc at gmail.com> wrote:

Speaking as a borg user (i.e., not a borg developer), it seems to me
> that the output of the command, which could be arbitrarily large, needs
> to be preserved somewhere, somehow, until the exit happens, and then --
> if the exit is good -- create the archive.
>

No. This is not the intended use. Please (re)read my first post. The goal
is to apply the equivalent of "someapp | borg create ..." to a networked
version via "borg serve".

I'm not a borg dev, and I can't speak for them, but it seems to me that
> is not something borg should be doing.  The output could be arbitrarily
> large before this happens.
>

This is not a problem, this is the intended usage! Again from my first post
(either you didn't read or did not understand, no offense) :

(mockup)
borg create --remote-cmd user at host: -- mysqldump [options] db.sql

"borg serve" running on "host" would simply execute "mysqldump [options]
db.sql" and yes, the output could be arbitrary large but we don't care
since it is piped into Borg on *PURPOSE* !

"borg serve" running on "host" would just have to capture stdout to feed
"borg create" on the backup server _AND_ capture stderror as well as the
returncode of the executed process (here: "mysqldump" for instance).

"borg serve" running on "host" would then notify "borg create" if the
returncode is non-zero (or another returncode if supported via the adequate
option) to NOT create the backup and optionally return the contents of
stderr of the failed process to display or mail to the admin.

I hope it's clearer now.


> If I needed something like this, I'd make a wrapper that calls the
> command needed and uses a TMPDIR to buffer it's output, *then* call borg
> depending on the exit.
>

This approach is impossible in the case of "borg serve".


> Another way is to write a wrapper that creates the archive anyway, but
> if the pipe fails, deletes it.


That would be necessary in some cases yes. I have some in mind like making
backups of MSSQL servers. There's no way to create the SQL dump and output
to stdout so, a script would first create the SQL backup to a file and if
everything is fine, "cat" the file to stdout for "borg create" to capture.


> (As for the bash rant; to each his own.  I would suggest that any
> environment that *requires* such complex features should be able to
> install the right tools, but that's just my opinion.  In any case, it
> sounds weird that you can install borg but not bash).
>

Where did you see any rant? I use and love Bash everyday on interactive
shells but ALL scripts I write are in pure POSIX shell and I have yet to
find a case where Bash is required over a pure POSIX shell. Believe me, I
wrote highly complex apps in pure Shell script for the past 2 decades.

As of the weirdness you imply in your last sentence, please don't draw
conclusions when you don't have all the details. There are numerous
situations where you can't install software on servers. They can be
"certified" servers where no installation is allowed. They can be
proprietary or limited systems/appliances where you have minimal shell
support via SSH. Ever tried to install Bash on a VMware ESXi host?

In all those cases, we could not install Borg either (well, using some
cxfreeze magic could make it possible though) but these are special cases.

-- 
Unix _IS_ user friendly, it's just selective about who its friends are.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/borgbackup/attachments/20161002/d88f8895/attachment-0001.html>