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»»

abandon Redgate for Compellent? Expand / Collapse
Author
Message
Posted Thursday, April 21, 2011 9:01 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 21, 2013 10:46 AM
Points: 2, Visits: 128
Our network folks are using Compellent Storage Center for their file backups and DR. They are pushing to have us abandon Redgate for SQL backups and go with a Compellent option. As a SQL DBA I'm uncomfortable with this change. Has anyone moved all SQL backups to this product that would be willing to comment on the process and outcome?
Post #1097056
Posted Friday, April 22, 2011 5:20 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 6:38 AM
Points: 13,755, Visits: 28,147
I'm not familiar with Compellent, but I went to their web site. It looks to me like it's a SAN management and backup software. Is that right?

If so, those things work really well. If you have giant databases on stand-alone systems, it's really one of the best ways to do backups and restores. However, if you have lots of small or mid-sized databases (< 1tb), getting snapshots of the drives, even if it is transaction aware snapshots (and that's the one thing you should validate) won't help you for restoring individual databases since multiple databases live on a drive. Personally, I'd see if you can't just do both.


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1097399
Posted Wednesday, April 27, 2011 9:46 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 21, 2013 10:46 AM
Points: 2, Visits: 128
Thank you for the reply, Grant. Compellent is SAN management and backup software. It is not transaction aware. I've been told by one of their customers that they set every database to simple recovery.

As we have many small databases (<= 2GB), on a single drive, you are correct that this technology doesn't help much with single database restores. An entire drive would be restored and I would have to detach and then attach the database that I need restored.

I'm voting to keep Redgate.
Post #1099597
Posted Wednesday, April 27, 2011 9:55 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 6:38 AM
Points: 13,755, Visits: 28,147
David Egnoski (4/27/2011)
Thank you for the reply, Grant. Compellent is SAN management and backup software. It is not transaction aware. I've been told by one of their customers that they set every database to simple recovery.

As we have many small databases (<= 2GB), on a single drive, you are correct that this technology doesn't help much with single database restores. An entire drive would be restored and I would have to detach and then attach the database that I need restored.

I'm voting to keep Redgate.


Yeah, if it's not transaction aware then there's no way in the world I would support using it as a means of backing up my database systems. That has nothing to do with keeping Red Gate or not. You need to know that when you restore the drive that the databases on it won't be corrupt, that committed transactions are written to disk and uncommitted transactions are rolled back. That's also completely independent of whether or not your database is in simple recovery mode (you might want to to talk to them and their customers, they're operating in a dangerous manner).


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1099605
Posted Wednesday, April 27, 2011 10:20 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, September 19, 2014 12:47 PM
Points: 2,049, Visits: 3,584
I'm not familiar with Compellent but others that do similar work allow you to take transaction log backups along with their backups and allow for restores through the same.

That all being said though there are reasons to keep the Red-Gate backups as well (or any type of SQL backups) some of which include the ability to restore without having to go to your probably already overworked SAN admin to do basic recoveries or to copy data to another environment, etc. Before throwing all other backups out I would sincerely look at all processes where backups might be used and then make sure that the SAN admins are going to be willing to support those activities.

One other thought too, but if you are doing any replication I would make sure that they support the KEEP_REPLICATION option as part of their restores.


David

@SQLTentmaker
SQL Tentmaker
“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Post #1099619
Posted Friday, April 29, 2011 5:05 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 10:47 AM
Points: 258, Visits: 1,093
David Egnoski (4/21/2011)
Our network folks are using Compellent Storage Center for their file backups and DR. They are pushing to have us abandon Redgate for SQL backups and go with a Compellent option. As a SQL DBA I'm uncomfortable with this change. Has anyone moved all SQL backups to this product that would be willing to comment on the process and outcome?


I am a certified Compellent SAN administrator as well as my company's DBA.

We were faced with a similar choice when we migrated from direct attached storage to our SAN. After considerable research, debate, and experimentation, we decided to:
1. Implement Compellent replays (their name for snapshots). Think of replays as a type of database backup but not like a SQL Server or RedGate backup. We also implemented them to facilitate efficient data migration between storage tiers, another subject.
2. Use Compellent's Replay Manager software package (which is fully transaction aware) for all database snapshots.
3. Continue to execute our regularly scheduled database backups using SQL Server in the simple recovery mode (our preference) as "insurance" and to retain the ability to store off SAN backups, which we regularly migrate to a file server.
4. Use Compellent's simple replays for efficient data migration of SQL Server produced database backups stored on the SAN.

At first we didn't trust the whole SAN replay/snapshot concept because we'd had no experience with it. But, we've had ample opportunities to use it for database restorations and it has never failed. It is also very fast, much faster than normal database restorations, especially if you have large databases.

Ask me any question. I'll be glad to respond.

LC
Post #1101098
Posted Friday, April 29, 2011 5:18 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 1:15 PM
Points: 5,383, Visits: 7,454
You mention you use simple backups. If you have full backups and need point in time restoration capability, can compellent's snapshots deal with this? I'm assuming it can't but as long as we've got an expert in the house...

Also, are compellent's snapshots splittable, in particular does it file or drive snapshot? I don't want to be recovering 30-40 databases when I only need one off a logical array.



- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Post #1101102
Posted Friday, April 29, 2011 6:37 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 10:47 AM
Points: 258, Visits: 1,093
Craig Farrell (4/29/2011)
You mention you use simple backups. If you have full backups and need point in time restoration capability, can compellent's snapshots deal with this? I'm assuming it can't but as long as we've got an expert in the house...

Also, are compellent's snapshots splittable, in particular does it file or drive snapshot? I don't want to be recovering 30-40 databases when I only need one off a logical array.


Great questions, Craig.

We only use Compellent's simple replays (snapshots/backups) for the database backup files produced by SQL Server's regular backup operations.

We use the Compellent Replay Manager generated replays for all of our databases. The difference is that the simple replays are not "transaction aware". The Replay Manager generated ones are and they ensure a consistent snapshot of a database's data and log files. Replay Manager uses Microsoft's VSS technology to accomplish this.

Either of the 2 types of Compellent replays can be used for point in time restoration to the degree of frequency the SAN administrator has set them up.

Compellent simple replays are file oriented. That is, they consist of a replay for a specific file.

Compellent Replay Manager replays are database oriented and are "splittable". We have several of these replays with more than one database included in them. I can restore a single database (both the data and log files) out of an aggregated replay.

The Compellent SAN is not drive/spindle oriented to an administrator. There is no way for an administrator to know exactly on which spindles his databases and/or other files are located. Not only is the information not available but the data is frequently in transit between defined "tiers", from 15K FC drives to SATA drives, or from RAID 10 to RAID 55, for instance.

The Compellent SAN is the closest thing to a black box I've ever seen. If I need to allocate disk space, I instruct it to allocate a certain amount on certain storage tier(s) that I've defined and the SAN just makes it happen.

LC
Post #1101121
Posted Sunday, May 1, 2011 2:11 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 1:15 PM
Points: 5,383, Visits: 7,454
crainlee2 (4/29/2011)

Great questions, Craig.

We only use Compellent's simple replays (snapshots/backups) for the database backup files produced by SQL Server's regular backup operations.


Interesting. So you're not using the SAN to avoid standard backup procedure. You're snapshotting the .bak files.


We use the Compellent Replay Manager generated replays for all of our databases. The difference is that the simple replays are not "transaction aware". The Replay Manager generated ones are and they ensure a consistent snapshot of a database's data and log files. Replay Manager uses Microsoft's VSS technology to accomplish this.

Either of the 2 types of Compellent replays can be used for point in time restoration to the degree of frequency the SAN administrator has set them up.


So if they snapshot every 15 minutes, that's your point in time you can return to. However, if it's snapshotting the log AND DB constantly, that's got to be a space hog if you want 15 minute point in time ability. Also, you mention consistent snapshot of data and log file. I assume somehow you pair them in compellent as mdf/ldf combinations, but still, if you poke around there's any number of articles out there about how an unclosed/detached/offlined database that you do this with would end up performing and the data errors. What's the workaround here?

SAN snapshot backups of mdfs, particularly because of point in time requirements, have always worried me.



- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Post #1101375
Posted Sunday, May 1, 2011 7:56 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 10:47 AM
Points: 258, Visits: 1,093
Craig,

No, we don't use the SAN to avoid standard database backups using SQL Server. We do both SAN replays and SQL Server backups for the purpose of intentional redundancy, in case one fails. Plus, sometimes it's easier and quicker to restore the backup of a small database using SQL Server, so there's the issue of convenience, as well.

We take simple replays (snapshots, what Compellent calls Instant Replays) of the database backup files, the .bak files. The reason is that Compellent says Replays improve the performance of the automated data migration from Tier 1 storage (15K FC) to Tier 3 storage (SATA).

Currently, and this is soon to change:
1. We are taking a Replay Manager snapshot every 24 hours. We are soon going to experiment with increasing the frequency of these to see how much additional space they require. We will probably start out conservatively, say every 4 or 6 hours, and shrink that window until it reaches a point of diminishing returns by consuming too much disk space.
2. We take SQL Server generated full backups once every 24 hours.
3. We take SQL Server generated differential backups every 30 minutes, except when the full backups are in progress.

We decided not to implement point-in-time recovery. Business requirements dictated that being up and online was more important than some data loss, so we use the Simple Recovery model in SQL Server.

I was as skeptical as you about the synchronization of the .mdf and .ldf files during a SAN replay (snapshot). Compellent assures their customers that as long as they use the Replay Manager software (which utilizes the Microsoft VSS technology) to coalesce the 2 files, there will never be any data errors. We've experimented with it to the point that we believe Compellent and are comfortable with it.

LC
Post #1101413
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse