Backup Performance best practices I'm in the process of re-writing our maintenance plans and at the moment the focus is backups. Whilst preparing this plan, I'd like to try and ensure that procedures are in place to ensure that backup performance is optimal. I am aware of implementing the below, however I'd like to get an idea of how I can improve beyond that scope.

Current Considerations:


Backup Compression
Multiple data files for larger databases - perhaps over 100GB?
Writing backups to another I/O subsystem
Defining values for parameters including BLOCKSIZE, MAXTRANSFERSIZE &amp; BUFFERCOUNT
Purging old files
Deleting backup history


Beyond the above, is there anything that would be benificial to implement. Also whilst setting the values for BLOCKSIZE, MAXTRANSFERSIZE &amp; BUFFERCOUNT, are there any considerations I should take/how do I go about defining the correct values? I appreciate it will be a bit of trial and error with testing but it would be useful to get an idea of best practices.

To give an idea of my routine, I'm to run hourly transaction log backups, daily differentials and weekly full backups.

Thanks
Firstly, I'd encourage you to stop using maintenance plans for your backups.  Ola Hallengren's maintenance scripts are used by a LOT of people.  Simply schedule them using the SQL Agent.

I agree that taking steps to ensure your backup process is optimal, but I'd also encourage you to think about your restore strategy as well. 

By taking transaction log backups every hour, you are saying it's ok to lose up to 1 hour of updates should you need to restore. IMO, implementing more granular backups is really no more difficult and brings some additional piece of mind.  See Back Up Transaction Logs Every Minute. Yes, Really.

When researching and developing a restore strategy, the main two things you'll tend to see over and over are: RTO (Recovery Time Objective) and RPO (Recovery Point Objective).

RTO basically is the maximum time allowed to get things back to 'normal' or at least functioning. You would need to take into consideration small problems (server went down) to big problems (the building just exploded).

RPO basically is, how much data could we 'possibly' lose should a bad problem happen? 5 minutes, 1 hour, 1 day, NONE?

Take some time to read The 9 Letters That Get DBAs Fired
(Basically RPO, RTO and CYA).

Also, The Accidental DBA (Day 8 of 30): Backups: Planning a Recovery Strategy, discusses Designing a Restore Strategy.

One last thing - develop a plan to routinely test your backups.  

The only way to verify a backup is good/usable is to restore it.

REPEAT – you don’t know you have a good backup until you have restored it! 

I provided an example in my answer to How to conduct integrity test on SQL Server database backup file?