• We eventually got our SQL Server database backups working with the Data Domain. (Outside of the scope of the original post, we also eventualy got our Oracle database backups working with the Data Domain as well.) Although the product literature (and Data Domain Tech Support) led us to believe that using Active Directory would be "easy," it was not. Tech Support was clueless! Our Disk Admins finally figured it out after *months* of conference phone calls, patches, and Data Domain upgrades. Unfortunately, I have no idea what they ultimately changed to integrate Data Domain security with Active Directory security.

    Once the CIFS share was configured properly to work with our Active Directory, we were able to route our SQL Server backups to it. We run our backups from PowerShell, using sqlcmd.exe, scheduled under Task Scheduler. All of our databases are encrypted (which causes our backups to be encrypted as well); so, compression does not really save us anything. While we were trying to get the Data Domain to work, we routed our backups to a Windows file share, and the Windows file share consistently performed faster than the Data Domain CIFS share. De-dupe does not seem to save us much space because of the encrypted database backups.

    We have been using Data Domain for roughly two years. We have had to revert back to the Windows file share a *number* of times because of failed patches, upgrades, etc. When it works, Data Domain works reasonably well. When it doesn't work, it usually doesn't work for a week or two at a time. If it were left up to me, I'd just use a Windows file share because it's easier to debug when something breaks.