Has your SAN admin or CIO been telling you not to compress your SQL Server backups because they’re doing it for you with a dedupe tool like EMC’s Data Domain? I’ve been hearing from a lot of DBAs who’ve been getting this bad advice, and it’s time to set some records straight.
The Basics of Storage Deduplication
Dedupe appliances basically sit between a server and storage, and compress the storage. Sometimes they do it by identifying duplicate files, and sometimes they do it by identifying duplicate blocks inside files. It isn’t like traditional compression because the process is totally transparent to anything that stores files on a deduped file share – you can save an Excel file to one of these things without knowing anything about dedupe or installing any special drivers. In theory, this makes dedupe great because it works with everything.
The key thing to know about dedupe, though, is that the magic doesn’t happen until the files are written to disk. If you want to store a 100 megabyte file on a dedupe appliance, you have to store 100 megabytes – and then after you’re done, the dedupe tool will shrink it. But by that point, you’ve already pushed 100 megabytes over the network, and that’s where the problem comes in for SQL Server.
Dedupe Slows Down SQL Server Backups
In almost every scenario I’ve ever seen, the SQL Server backup bottleneck is the network interface or the drives we’re writing to. We DBAs purposely set up our SQL Servers so that they can read an awful lot of data very fast, but our backup drives have trouble keeping up.
That’s why Quest LiteSpeed (and SQL 2008′s upcoming backup compression) uses CPU cycles to compress the data before it leaves the server, and that’s why in the vast majority of scenarios, compressed backups are faster than uncompressed backups. People who haven’t used LiteSpeed before think, “Oh, it must be slower because it has to compress the data first,” but that’s almost never the case. Backups run faster because the CPUs were sitting around idle anyway, waiting for the backup drive to be ready to accept the next write. (This will really ring true for folks who sat through Dr. DeWitt’s excellent keynote at PASS about CPU performance versus storage performance.)
With dedupe, you have to write the full-size, uncompressed backup over the network. This takes longer – plain and simple.
Dedupe Slows Down Restores Too
The same problem happens again when we need to restore a database. At the worst possible time, just when you’re under pressure to do a restore as fast as possible, you have to wait for that full-size file to be streamed across the network. It’s not unusual for LiteSpeed customers to see 80-90% compression rates, meaning they can pull restores 5-10 faster across the network when they’re compressed – or in comparison, deduped restores will take 5-10 times longer to copy across the network. Ouch.
It gets worse if you verify your backups after you finish. You’re incurring the speed penalty both ways every time you do a backup!
And heaven help you if you’re doing log shipping. That’s the worst dedupe candidate of all: log shipping does restores across one or more SQL servers, all of which are hammering the network to copy these full size backups back and forth.
So Why Do SAN Admins Keep Pushing Dedupe?
Dedupe makes great sense for applications that don’t compress their own data, like file servers. Dedupe can save a ton of backup space by compressing those files, saving expensive SAN space.
SAN admins see these incoming SQL Server backups and get frustrated because they don’t compress. Everybody else’s backups shrink by a lot, but not our databases. As a result, they complain to us and say, “Whatever you’re doing with your backups, you’re doing it wrong, and you need to do it the other way so my dedupe works.” When we turn off our backup compression, suddenly they see 80-90% compression rates on the dedupe reports, and they think everything’s great.
They’re wrong, and you can prove it.
They don’t notice the fact that we’re storing 5-10x more data than we stored before, and our backups are taking 5-10x longer. Do an uncompressed backup to deduped storage, then do a compressed backup to regular storage, and record the time differences. Show the results to your SAN administrator – and perhaps their manager – you’ll be able to explain why your SQL Server backups shouldn’t go to dedupe storage.
In a nutshell, DBAs should use SQL Server backup compression because it makes for 80-90% faster backups and restores. When faced with backing up to a dedupe appliance, back up to a plain file share instead. Save the deduped storage space for servers that really need it – especially since dedupe storage is so expensive.
