If the remote and the local servers are of different endianness (Sparc vs. Opteron, for example) -- what endianness will go into the dump? That of the compressing, or that of the original server?
Also, when you say "You need to be running v12.5.2+", is that the requirement for the main, or for the compressing server? We have a FreeBSD machine, for example, on which we can install the old Sybase-11 -- will it be able to compress dumps received from the 12.5.3 servers?
It's my understanding that the format of the dump will be from the source server.
Both servers have to be v12.5.2+ for remote compressed dumps, as Sybase changed the way that compression works in that release. From v12.5.2 onwards the compression was moved into the sybmultibuf processes for the first time. Compression on v11x servers isn't supported by Sybase, although it will (probably) work if you copy the libcompress.so library into the library path from a later server.
You can also consider using a fifo special file with rsh to the remote server
Note: cat command submitted in background. The gzip –dc to uncompress will not do much as the file was compressed with 0 compression, then it is recompressed to max compression.
Interesing... Last time I tried this, Sybase complained, that the fifo was "unsupported file type". Maybe, this has changed with newer Sybase versions... Or, maybe, the "compress::" prefix makes it less picky...
There is also another trick to it -- the dump device is supposed to be rewindable, because the way, Sybase geniuses wrote things, is Sybase rewinds to the beginning of the file afterwards and modifies a few bytes...
I guess, dumping with compress (even at level 0) avoids that. Thanks for the idea, I'll try it.
BTW, why would I need the cat? Why make the source machine go through one extra cycle of memory copying (from cat to rsh)? rsh can do the reading with simple input redirection, can't it?
Ok, I figured out Sybase's (unpublished) API for backup plugins. I can now do the following:
dump database WHATEVER to 'pipe::ssh me@example gzip -9 \> /meow/tmp/WHATEVER.cmp';
As you can guess, it could be ANY command (interpreted by sh), the data will simply be pumped into its standard input. Instead (or in addition to) compressing, for example, one can encrypt the dump before it ever hits the disk. Whatever...
Obviously, the dump in the above example can be loaded back using the traditional 'compress' plugin (so you can send it to others), or with
load database WHATEVER from 'pipe::ssh me@example gzcat /meow/tmp/WHATEVER.cmp';
If you chose other processing methods (like bzip2), you will, of course, have to use my plugin with the UNprocessing command line to load the database...
I'm very proud of myself, and plan to make loads of money with this library :-) But I need beta-testers, who will all get to keep (but not redistribute, please) the final version of the plugin.
Anyone interested in the beta of libpipe.so for Linux or Solaris?