Maximize performance of a Sybase Dump

Looks like you've already covered the main points. I can add a bit here and there.

Adding memory to Backup Server - a careful reading of the manuals will show that you have to do this in proportion to the number of stripes. Holding memory steady but doubling the number of stripes effectively halves Backup Server memory. If there's ample memory to play with then with 8 stripes I'd go with 8 x default Backup Server memory, for 8 x 48Mb = 384Mb. Heck, if you had plenty, I'd try 512Mb jus to see if it made any difference. Backup Server will only use it if it thinks it will help.

Compression: As Bill says, compression shifts some of the burden from I/O to CPU. In your scenario it sounds like you should have plenty of CPU to go around so I would expect it to make a significant difference. That said, the gain in performance in moving from compression 1 to compression 5 or higher is usually small, and I've seldom found compression 9 improves matters any.

That said, which compression syntax are you using? "compress::[...]" or "with compression = [...]"? The latter is marginally faster and consumes slightly fewer resources, because it is native to Backup Server rather than being passed to an external file to handle the compression...

Stripes: the limiting factor is not the number of ASE engines, because the ASE engines are not performing the backup! The limit is the number of CPUs on the box. I'd suggest you would almost certainly see 12 stripes being a bit faster than 8, and I'd be curious to test 16 as well. You may need to increase the number of Backup Server threads, and/or the number of large i/os within ASE (ok, it *does* do a small amount of the work, but not so much that the number of engines is a bottleneck).

But surely the biggest factor here has to be dumping to tape rather than to disk. How come? If you can get enough space to dump to disk directly, and the disk is reasonably fast and properly setup, it's not unusual to see disk be twice as fast as tape...

That said, if you must go directly to tape, backup your databases in strictly increasing order of size. Dumping to tape has to rewind after each backup (true!! Needed for capacity calculations), so by dumping your smallest databases first you are minimising that rewind and fast forward time.

Finally, if you can't use 100% of the hardware resources despite pushing compression and the number of stripes up - dump two different databases at the same time (each using compression and stripes). This might not be twice as fast as doing them serially, but if there really are resources still left to go around, this *will* be faster than doing them one at a time. Obviously this isn't something you can do to tape very easily...