I remember a conversation I had at the Redmond campus with the program manager (at that time it was Paul Randall... now I think he goes by Paul Tripp, but all the same he's not a MS anymore.). Anyway though, he was asking me about my favorite Katmai features and I listed 2 or 3, and he was astounded that my favorite feature wasn't backup compression. They were particularly proud of that one. It turns out the SQL team at MS had never even conceived that someone wouldn't just jump out of their skin for the chance to have backup compression in the product.
My reasoning is sound. And it's not that the feature itself isn't cool, or even long overdue. It's that the implementation itself isn't practical to real DBAs. Let's look at what we have today and how the native Katmai backup compression will stack up.
Today, if you want backup compression you go with one of the big vendors... Quest LiteSpeed, Red-Gate SQL Backup, Hyperbac, etc. And these products bring you features like object-level restore, resource management, and central reporting. And those are just the top 3, there are more features that come with products like these that make them attractive. One of the most important to any DBA is centralized reporting because it's far easier than writing routines to cycle through all your servers to pull all the backup stats into a single report. Those routines will usually consist of an SSIS package that does the cursoring or putting a job on each box to ship the job info up to a central server repo. Either way it's manual work with moving parts and queries that can be difficult to work out properly.
Sign up to receive InfoWorld Resource Alerts
2 Recommendations
