EMC Clones or SQL Backups for 100 + GB databases

  • My network operations group really wants to start going to EMC Clones for all databases that are SAN attached. The argument is that the EMC Clones are faster than SQL Backups and they can copy them to tape for long term storage faster than they can pull the SQL Backup off to tape. I dont' like putting responsibility for backups into someone elses hands. Additionally they would only do a clone once nightly. Our transactional systmes have very time sensitive data and I do very frequent transaction log backups. In a conference call with the EMC vendor the EMC rep told me that they could restore a database from a clone and leave it in a recovering state so transaction log backups could be rolled forward just like with a SQL Full backup however we have not done this for testing purposes to date. The network operations group wants to have a meeting to settle the issue once and for all and I want to get as much info as I can about what others are doing and any best practices that may be in place regarding backing up databases that are SAN attached...especially databases that are 100 + GB.

    Thank you.

  • I'd definately have the EMC folks help you test the performance of bringing the db back into a restoring mode so that you could apply tlogs to check on performance.

    Also, have you looked into other tools like LiteSpeed or Redgate's products to cut your backup and restore times? How do they perform compared with the native SQL backups?

    I think those would be important metrics to have before attempting to walk into a meeting that will "resolve" the issue once and for all...

    -Luke.

    To help us help you read this[/url]For better help with performance problems please read this[/url]

  • oh yeah, and why can't they copy the SQL backups to tape for long term storage? Once they're written they're just a file like any other...

    To help us help you read this[/url]For better help with performance problems please read this[/url]

  • I havent had any experience with this setup , but make sure that whatever they implement gets fully tested before going anywhere near your production system.

    For our backups we use Redgate backup and It handles databases over 100gb quickly and with ease.

  • The issue really hasn't been the creation of the bak files to local disk. I can do differentials during the week to reduce backup time and bak file size and have also tried third party tools for backup compression. The issue seems to be copying the large bak files to tape across the network. I am unclear on why the EMC clones don't present the same problem.

  • More than likely the clones do some sort of compression on the large backup files, which is why something like Redgate's backup product or Litespeed or whatnot may offer some help. The compression will be there and will reduce the load on the network copyign the files.

    Even with a simple .zip archive I've seen up to 4 times compression on smaller db files, which helps when transferring them across slower network links.

    -Luke.

    To help us help you read this[/url]For better help with performance problems please read this[/url]

  • At my last job, I used Idera's SQLSafe backup tool on our 275 Gig database, and our backup time went from 90 minutes to 30 minutes, and disk space for the backup went from 275 G to 45 Gig. At my current job, we used Redgate which I think is pretty equivalent. We don't get the same compression on our 650 Gig database but that's because we have a lot of image data that doesn't compress well.

  • the EMC clones will almost definitely be homed on replicated LUNs, the SAN fabric will move data around a hell of a lot quicker than any disk to tape I\O. Depending on your SAN set up the typical throughput would be around 300MB second (sustainable) or even higher

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply