Commented by: @AlexPeshkoff

Extending services API currently is problematic due to extremely bad design of API (i.e. adding new parameter to svc_start parameters block break compatibility with older servers).

But in the future, when we have new format for that blocks, I do not see big problems with what you suggested.

Commented by: @dyemanov

What's the problem with redirecting the gbak output to e.g. gzip?

Commented by: @AlexPeshkoff

There are no problems when you use gbak as utility, but if you want to run it service - there are problems. Certainly, it's possibke to hack it - create named pipe, start any compressing utility from one size and use that pipe as service output. But this requires access to server to start *zip, and one looses main services feature - ability to run tasks witout access to server.

Commented by: PizzaProgram Ltd. (szakilaci)

I have used GBAK + 7zip for this:
CORE762?focusedCommentId=26272&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#⁠action_26272
but it turned out:

it is absolutely NOT SECURE !

Every separate windows process is visible including parameters. So it shows DB location + username + passwords during backup & restore.
(Even with a simple "task manager" or "process explorer" everything is visible. So it is a huge security risk.)

So YES, it would be really essential to be able to access the backup/restore filestream from API securely.

Commented by: @AlexPeshkoff

5808 includes zip compression - it's absolutely required for encrypted backups that are uncompressable. Therefore changed to sub-task.

Commented by: @AlexPeshkoff

Sorry, not 7zip - but plain zip support is added in 5808.
If there is real need to achieve better compression ratios we should think about adding compression _plugins_ - other people may need low CPU consumption (like in lz4), etc....