Any reason NOT to use SQL's inbuilt Backup Compression?
Seems to me it saves disk space and may reduce performance of the backup, but I suspect that in practical terms the performance issue is non existent?
From what I have read (nothing easily found that was recent) the concensus was to turn it on and forget about it, with possible exception of databases storing Image/PDF/etc data or using Transparent Data Encryption.
For me the gains would be saved disk space (not a current issue ...) and tape space (much more of a benefit) plus the dramatically (I presume) reduced time if we ever had to retrieve from tape and then restore. I gather that restore-from-compressed-backup-file-on-disk is faster (less I/O) which is definitely an advantage, not that we restore often - but when we do its normally DEVs on TEST servers and they'll only sit twiddling their thumbs during the Restore so its actual money-saved. Reduced backup time (i.e. I/O reduction) is not of particular interest to me (or so I think??) as backup [well ... "big backups"] happen out-of-hours and on dedicated backup-only devices.
Only other PRO that occurs to me is that our backups are synchronous - one database after the other - so when the backups are big their is a delay before the last databases in the list gets serviced.
Makes me wonder why Compressed is not now the default setting in SQL install ...