question

In my experience it impacts more on the CPU side of things. See [MSDN][1] for other things to consider. Other 3rd party tools like Idera backup allows you to change the compression ratio to best suit the environment, therefore potentially reducing the impact but benefiting from some about of compression. [1]: http://msdn.microsoft.com/en-us/library/bb964719(v=sql.100).aspx

for normal SQL Server Database backup – majority of waiting time spend is on I/O. that's why backups are called I/O intensive operations For Compressed backup – I/O wait is still there. However, the amount of data being backed up (overall size) is less. what this means is the total time spend on waiting for I/O is also less.Though this increase load on CPU i.e. CPU goes higher reducing the backup elapsed time. If you are running with compressed backup you may study the wait-types pattern in your SQL Server environment and you will find out that the BACKUPIO is relatively less than the environment running with Normal sql server backup. You may like to watch this [Video][1] for more knowledge on backup internals [1]: http://technet.microsoft.com/en-in/sqlserver/gg429796.aspx Hope this helps you!

It really comes down to the slowest part of the process being what gets written to disk. So yes, a standard backup uses less CPU and less memory, but it writes more to disk. Most systems are suffering from I/O issues and starved for memory. While compression adds to the memory load, it alleviates I/O. This applies to index compression as well as backup compression. And, index compression actually helps with memory issues since the page read from the disk isn't decompressed, but is read in the compressed state.