When I posted the original message, I didn't know much about Data Domain. Since that time, we have implemented Data Domain for all of our cluster and standalone backups. Initially, we had lots of vendor problems in getting security implemented using Active Directory. However, once we finally got past that (which took literally months), we've had to revert back to file share backups from time to time when Data Domain patches had issues. (It's a site standard to patch everything often and quickly.) However, Data Domain has been reliable for the last 6 months or so.

Instead of using xp_cmdshell (which has security issues), we chose to use a PowerShell script (launched by Task Scheduler) which calls the TSQL "backup database" command using sqlcmd.exe. (By the way, we had issues with the PowerShell 2.0 invoke-command verb because we could not trap backup errors reliably using it. "$?" seems to trap errors from sqlcmd.exe reliably.)

We have the same script scheduled on all nodes in the cluster, and the script checks to see if a given instance is running on that particular node before it backs it up. That way, we avoid backing up the same instance multiple times from Task Scheduler.

We have over 20 instances writing their backups to Data Domain. Most instances execute a full backup once a week and hourly incremental backups throughout the week. We also have a script that tests the backups (via PowerShell, sqlcmd.exe, and TSQL "restore database") from each instance once a week. A backup set often has 80+ transaction logs, and we have not had any significant issues with restores. When we have an backup or restore issue, it is usually caused by a network glitch.

In our experience, Windows file share performance is faster than Data Domain performance, which makes sense because file shares are not performing de-duplication, but Data Domain makes sense for our configuration.

By the way, we use UNC (\\data_domain_server_name\share_name) in our SQL Server backups, rather than mapped drive letters. We had all sorts of headache trying to use mapped drive letters, but UNC fixed that fairly reliably.