Jason,

As the links I posted earlier shows, it can be done via the service API, because fbsvcmgr can do it too. At a high level, the main thing that is wrong with IBO right now is that it assumes the returned data to be text— which it is when you pass an ordinary filename for the backup to be saved to on the server—whereas when you pass 'stdout' as the filename, the returned data is the binary backup.

In case of restoring, as benm_rms mentioned, the returned data is still text.

The only thing I'm not sure of and worry about a bit, is how one is supposed to know the backup succeeded successfully when the log becomes inaccessible due to the returned data being the backup itself. I don't care for the text, I just want confidence. If the connection suddenly dies, there should still be an exception thrown. If the database suddenly becomes unavailable in another way, still I would expect some kind of connection error. I'm not familiar enough with the service API to know how that works - if it would always signal an error even if it can't show the log. Perhaps someone else can comfort me that I can be sure never to silently get corrupt (incomplete) data.