In the entire discussion in response to my editorial I saw two reoccurring concerns:

1. Key backup location/complexity

Yes, indeed, you must store the key backups in a different location than the database backups. If they were stored on the same media or on a different media but kept in the same physical location (thrown in the desk drawer with the wind-up chattering teeth) they can be stolen together resulting in the keys and database being restored elsewhere and the sensitive data would be gleaned.

The backups of the keys are not something that must occur on a daily basis, unless you are changing your keys on a daily basis (which is a bit over the top). Does it increase the complexity of your backup strategy? It does; but not to an overbearing degree. You are implementing a new feature to your database. In doing so it does add to considerations and actions when it comes to recovery.

2. Key life cycle Management

Maintaining the strength of a key requires maintenance. Given an indefinite period of time a hacker can crack any key. Limit the time and it makes that potential much less of a possibility. Also, changing the key periodically will reduce the data that is protected by a given key which reduces the volume of data that could be compromised if the key is hacked. Key life cycle management can be challenging. There is no native functionality within SQL Server (nor should there be within the database) to provide key life cycle management other than offering Extensible Key Management (in SS2008). EKM allows you to use third party providers or devices for keys and key management.

Also, there was a lot of discussion regarding the password that protects the key and concern over "backing up" the password. Consider taking advantage of the full key hierarchy and take a look at the service master key as a means to protect your database master keys instead of a password.