Thanks for your reply.

—8<—
I think there must be some typo near "127M down from 1.3GB using bzip2 or pbzip2" . If pbzip2 does what it says it should >produce exactly the same output as bzip2, and certainly the same output as itself.
—>8—

There is no typo in this statement; "using bzip2 or bzip2" was just expressing that either program resulted in the same size. 1.3GB is the original size of the file.

—8<—
Besides that, there is a key downside to this technique: While the wall time to do the compression gets smaller, the risk of taking away CPU from production processes (such as the database engine on this server) increases. Depending on server specifics, this may be mitigated by careful use of the "nice" command to run the parallel compression job at a lower priority.
—>8—

Yes, one can use the nice command as with any CPU-intensive process. Please take note that this is just an example; as I'm sure you would agree, this is a very general statement and must be applied to anything that's CPU intensive like compressing. I tested this on a production database server that does about 2K queries/sec, and I saw almost no performance decrease when compressing those files with the parallel implementations. Your results may very and you should always exercise caution in production environments.

—8<—
RAM consumption may or may not be an issue, as a parallel bzip2 will probably increase its memory consumption by about 9.4MB per CPU used (400K + 8 x 900K + 2x900K buffers to hold input and output as external input and output happens serially).
—>8—

Interesting information and dully noted. Unfortunately, I can't cover every single difference on the system that will be felt by using the parallel versions of these compression tools.

—8<—
A related issue for virtual servers is if the surrounding framework (such as the GoGrid API) allows the CPU and RAM allocation to a server to be temporarily boosted for the few minutes that particular server is running a scheduled backup job. So far in the industry, I have only seen APIs that allow such adjustments while the virtual server is shut down, which typically isn't a good thing to do in a nightly backup job. And yes, I have seen this limitation in the underlying virtualization engines too, so it is hardly GoGrid's fault.
—>8—

This seems more like a generality in cloud computing, and not really related to the topic at hand.

Thanks again for your response, and hopefully I cleared up some of your concerns.

Besides that, there is a key downside to this technique: While the wall time to do the compression gets smaller, the risk of taking away CPU from production processes (such as the database engine on this server) increases. Depending on server specifics, this may be mitigated by careful use of the "nice" command to run the parallel compression job at a lower priority.

RAM consumption may or may not be an issue, as a parallel bzip2 will probably increase its memory consumption by about 9.4MB per CPU used (400K + 8 x 900K + 2x900K buffers to hold input and output as external input and output happens serially).

A related issue for virtual servers is if the surrounding framework (such as the GoGrid API) allows the CPU and RAM allocation to a server to be temporarily boosted for the few minutes that particular server is running a scheduled backup job. So far in the industry, I have only seen APIs that allow such adjustments while the virtual server is shut down, which typically isn't a good thing to do in a nightly backup job. And yes, I have seen this limitation in the underlying virtualization engines too, so it is hardly GoGrid's fault.