Backups, if you are only using them for disaster recovery, have been made fairly easy to manage in SQL Server. The problem, as I see it, is that I don't use them for disaster recovery as much as for development. We have a couple dev boxes that are restored at will by anyone in the department. If we need to check data from a certain time in the past or if we want to test something on recent data we run a restore to a dev box using backups from the production environment.

Here's the problem. The simple GUI interface to perform these restores is based on tables - tables that are only current in the production environment. They aren't available to the dev boxes. That means I need my backup files to be named reliably so I can write a script that knows what files to restore based on whatever criteria I require.

Yes. I could set up log shipping if I were so inclined. I'm not. I've instead taken to writing backup and restore scripts that manage things. I'm using extended properties on my databases to specify which ones get differential and T-Log backups. The scripts I have written are fairly easy to use for the structure I have in place. It would be a different story if I wanted to use partitioned tables (which I'm beginning to consider).

I don't see this as something that can be easily managed by simple GUI tools. There's so many different ways you can store data, backup data, and restore data that it starts to look like something that a DBA should be intimately involved in. It's not needlessly complicated - unlike many MS products (BizTalk /shudder). It is complicated to the point it actually needs to be to provide us with the level of security we want or need.

Take a day or two, or maybe a week, and design your backup/restore strategy to meet the needs of your organization. You'll look like a genius (and rightly so) when things go bad and you have things back up and running quickly by running a single script.