Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Has anyone used Data Domain storage for SQL 2008 backups? Expand / Collapse
Author
Message
Posted Tuesday, February 19, 2013 11:57 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, August 22, 2014 7:25 PM
Points: 191, Visits: 895
Forgot to mention one detail. I copy from server to Data Domain, so the server's NIC is a GB NIC, and I'm slowed by the network link from those servers to the Data Domain location, which is 1/2 mile away at another building. That is definitely something to consider.

I think mine is a fibre link, so I'm probably not losing that much, it is actually pretty quick.

But, I would think I would have a tough time with a 1TB file!

I mitigate my large backups by backing up to the owning server, then copying to the Data Domain. You could go directly to the Data Domain if it was so big you don't have the room to go first to the server. Going directly would then definitely be restricted by the network link speed.

You could do Full backups once a week, with nightly incrementals, that would make it faster, unless a large percentage of the records are modified (directly, with page-splits, etc.).
Post #1421799
Posted Wednesday, May 8, 2013 9:21 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, May 8, 2013 2:23 PM
Points: 1, Visits: 12
We've implemented Data Domain backups for our SQL Servers when running in standalone mode. We are able to script it using xp_cmdshell in an agent job so that it mounts the disk, writes the backup, and then unmounts the disk.

The original poster asked about using this with a SQL Server cluster, which it doesn't appear anyone answered. We are looking to do the same, and if anyone has had any experience, please let me know.
Post #1450646
Posted Wednesday, May 8, 2013 1:42 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, August 22, 2014 9:39 AM
Points: 34, Visits: 307
We've implemented the data domain with a good amount of success. At first, the SAN admin wanted to remove tlog and full backup scheduling from SQL Agent and use the EMC Networker software to control this. After some questions regarding the viability of the backups in the event of Networker issues, we decided that adding another layer of complexity to the backups wasnt ideal for us. We implemented the data domain by hanging a windows file share off of the appliance so that the SQL server would see if just like any other file share. Since we were already using Ola Hallengren's maintenance scripts to backup our databases, all we had to do was change the directory the script was pointing to.
Post #1450771
Posted Thursday, May 9, 2013 4:39 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, August 5, 2014 2:51 PM
Points: 392, Visits: 803
cmarkowi (5/8/2013)
The original poster asked about using this with a SQL Server cluster, which it doesn't appear anyone answered. We are looking to do the same, and if anyone has had any experience, please let me know.


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.



Post #1451373
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse