Good article.

edit: bits struck through below because now I've done some tests instead of believing what I read and what I was told, which turned out to be incorrect when i tested it.

On the compressed backup of a compressed table question: no, the compression algorithms/formats are different, so backing up a compressed table/index involves decompressing and then recompressing; so the CPU impact is higher than you might expect. But yes, you do save disc activity on both the source and the destination, and since the backup is usually disc bound this should bring the elapsed time down and also mitigate the CPU hit because there is less IO to handle.

I haven't done any testing myself, so can't be completely certain, and of course the outcome will depend on configuration, but people have told me that compressed backups of compressed data and indices gives even more elapsed time saving than compressed backups of non-compressed tables/indices for not much more CPU cost. But it all depends on your individual system - for example if you are using SSDs for both the DB and the backups the elapsed time saving from compression will be far smaller that if you are using slow and clunky cheap discs; but then the cost reduction from needing less space might be more important, as SSDs are still not as cheap as HDDs.)