January 28, 2020 at 4:13 pm
Any one have any experience with using Cohesity as the backup/restore platform instead of doing native SQL backups? With TSM, we always did a SQL backup, and then swept that up to tape. In our new backup system based on Cohesity, my backup admins want to backup up the database and log files directly from their system, but I still remember that doing so used to be a resume generating practice. Our installation engineer is telling me that what is happening under the covers is a regular SQL backup, just the destination is the Cohesity storage which is then moved to tape.
Any thoughts?
January 29, 2020 at 12:25 pm
I never argue on these things. I just ask them to demonstrate a point in time restore that meets both our business defined Recovery Point Objective and Recovery Time Objective. If they can do it. Great. We're done. If they can't, we're not using that tool because I have to meet the RPO & RTO. It's not a fight. It's simple logic. Get them to show you how they can meet the RPO & RTO (and check the database integrity when they're done). If they can't, smile, say thanks playing, and go about your day.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 30, 2020 at 12:10 am
Along with what Grant has stated and since they said it did "regular" SQL Backups, have them do a test restore using native tools only to prove it's a regular backup.
Also ask to see the plan for doing test restores of different databases on a regular basis as well as the DR Test Plan where they pretend the build the prod box is in was wiped off the face of the Earth, all replication had failed, and you need to stand up the DR Test site only from backups.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2020 at 8:44 am
Along with what Grant has stated and since they said it did "regular" SQL Backups, have them do a test restore using native tools only to prove it's a regular backup.
Also ask to see the plan for doing test restores of different databases on a regular basis as well as the DR Test Plan where they pretend the build the prod box is in was wiped off the face of the Earth, all replication had failed, and you need to stand up the DR Test site only from backups.
Yes to all this.
There should never be a fight as to what backup tool to use. It's all about meeting the restore and recovery requirements. Period. If they can. Great. If they can't. No, we're not using that.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 30, 2020 at 10:38 pm
This was removed by the editor as SPAM
January 30, 2020 at 11:39 pm
to be a resume generating practice. Our installation engineer is telling me that what is happening under the covers is a regular SQL backup, just the destination is the Cohesity storage which is then moved to tape.
Another spammer. This one and another one just go back and update their posts and embed links in the updates. Go fix that Grant 🙂
Sue
February 1, 2020 at 6:06 pm
We just got Cohesity. I was working with a server engineer on what this means to SQL Server.
I had a TEST SQL Server 2014 that we did some tests on. Cohesity was able to, behind the scenes, do a byte by byte backup of the actual server and then we shut it completely down and brought it up in its entirety in the Cohesity VM Host environment. SQL Server started and appeared OK and the application databases were accessible. However, I then restored all of the databases with our other SQL Server backup toolset. Integrity checks ran just fine. I wish I would have thought to run integrity checks before I restored the databases though. Our next test was to utilize the Cohesity supplied SQL Server backup/restore process. Something wasn't working correctly though because it would run the backups and I saw them complete in the SQL Server logs but the tool did not see the backups so we could not restore them. We were going to call Cohesity support but got working on other things and just never got back to it.
February 2, 2020 at 6:49 am
I'd bet back around to it. Knowing, through valid and successful tests, that you can restore your individual databases per the business RTO & RPO is the only way to know for sure that you can recovery in a disaster.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 2, 2021 at 10:20 pm
Please be aware the Cohesity does not support backing up SQL databases that include FILESTREAM filegroups. Wen you use Memory Optimized Tables, like we do, you do have FILESTREAM filegroups and there is no way of getting rid of them, short of dropping and recreating the database, which is far from ideal for a production db.
November 8, 2021 at 6:38 pm
No. Just no. It never ceases to amaze me how little dbas actually know about what these third party solutions actually do. They don't go into the database and do traditional backups. If you have TDE enabled they can't compress/encrypt your files and the client just burns your precious CPU doing nothing while the companies tout massive compression/de-dupe savings. B.S. All these "solutions" that want to manage SQL Server Backups simply use VSS. If you have a 10TB file with 1MB used, guess what is sent across the network? These solutions don't have any insight into SQL itself and can't backup just the data being used. Instead they transfer the entire mdf/ndf/ldf files. If you have a 10TB file with 1MB in use and do a native backup (we all should use compression but leaving it out for this argument) you will wind up with a 1MB whatever.bak file that would then be file swept by traditional means. So that problem aside, what does VSS do? Anyone out there have a really transactionally heavy database? There is a momentary stun these apps do for a crash consistency guarantee. This causes the disk to hang and if sql happens to be writing/reading you will see a hang while accessing disk. If you are lucky things will queue. Unlucky and you can see errors in the error log about IOs taking longer than expected. Either way, your client will see a temporary blip. It's like VMWare who always says "oh no a vmotion doesn't cause an outage." Then you do a continuous ping or any kind of continuous check and you see packets dropped while the stun happens. Sure, some environments can handle it, but for the size/compression/tde/encryption/vss/stun/wasted cpu cycles etc... it just is not good practice to use these third party softwares to do anything more than a file sweep.
November 8, 2021 at 6:41 pm
Jeff Moden wrote:Along with what Grant has stated and since they said it did "regular" SQL Backups, have them do a test restore using native tools only to prove it's a regular backup.
Also ask to see the plan for doing test restores of different databases on a regular basis as well as the DR Test Plan where they pretend the build the prod box is in was wiped off the face of the Earth, all replication had failed, and you need to stand up the DR Test site only from backups.
Yes to all this.
There should never be a fight as to what backup tool to use. It's all about meeting the restore and recovery requirements. Period. If they can. Great. If they can't. No, we're not using that.
Absolutely positively wrong. Another statement made by someone who probably has never run anything highly transactional with more than a 2 9s uptime requirement. Choosing the wrong backup solution can have performance impacts as my previous post just mentioned. There are about 50 other reasons why your statement is completely wrong as well all from performance perspectives of VLDBs.
November 9, 2021 at 10:37 pm
Grant Fritchey wrote:Jeff Moden wrote:Along with what Grant has stated and since they said it did "regular" SQL Backups, have them do a test restore using native tools only to prove it's a regular backup.
Also ask to see the plan for doing test restores of different databases on a regular basis as well as the DR Test Plan where they pretend the build the prod box is in was wiped off the face of the Earth, all replication had failed, and you need to stand up the DR Test site only from backups.
Yes to all this.
There should never be a fight as to what backup tool to use. It's all about meeting the restore and recovery requirements. Period. If they can. Great. If they can't. No, we're not using that.
Absolutely positively wrong. Another statement made by someone who probably has never run anything highly transactional with more than a 2 9s uptime requirement. Choosing the wrong backup solution can have performance impacts as my previous post just mentioned. There are about 50 other reasons why your statement is completely wrong as well all from performance perspectives of VLDBs.
I saw your rant - and while there can be issues with some of these, there are some that can work very well. The concern you have about backing up 'empty' space is not true for all solutions.
Using VSS allows for the freezing/thawing of SQL Server - which is supported by SQL Server and built into VSS. In fact, utilities that do not utilize a freeze/thaw method also utilize the VSS to perform 'native' backups under the covers. Redgates SQL Backup is one of those - as well as Quest Litespeed.
IBM has a product called SPP (Spectrum Protect Plus) - that uses VSS to freeze the database, snap, unfreeze - then performs a delta on that snapshot with the previous snapshot and creates a differential. That data is then deduped (if possible) and replicated to offsite storage with no impact on your production system. The only data included is allocated and used data in the data file(s) - empty space is removed.
As has been stated - work with the server/storage team to test and validate the proposed solution. If that solution can meet the businesses RPO/RTO requirements - and can prove it with a restore, then it is a valid solution and should be considered. If the solution cannot meet your RPO/RTO requirements then it doesn't matter how it works - it is not a valid solution for your environment.
And yes - I have managed several VLDB OLTP systems (10TB+) and have used native backups, Litespeed, Netapp SAN backups, IBM SPP and others quite successfully.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
November 10, 2021 at 3:08 pm
Grant Fritchey wrote:Jeff Moden wrote:Along with what Grant has stated and since they said it did "regular" SQL Backups, have them do a test restore using native tools only to prove it's a regular backup.
Also ask to see the plan for doing test restores of different databases on a regular basis as well as the DR Test Plan where they pretend the build the prod box is in was wiped off the face of the Earth, all replication had failed, and you need to stand up the DR Test site only from backups.
Yes to all this.
There should never be a fight as to what backup tool to use. It's all about meeting the restore and recovery requirements. Period. If they can. Great. If they can't. No, we're not using that.
Absolutely positively wrong. Another statement made by someone who probably has never run anything highly transactional with more than a 2 9s uptime requirement. Choosing the wrong backup solution can have performance impacts as my previous post just mentioned. There are about 50 other reasons why your statement is completely wrong as well all from performance perspectives of VLDBs.
Well OK then.
BTW, I have successfully run systems with more than 2 9's of uptime, but, you are absolutely entitled to your opinion.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
November 11, 2021 at 3:33 am
Grant Fritchey wrote:Jeff Moden wrote:Along with what Grant has stated and since they said it did "regular" SQL Backups, have them do a test restore using native tools only to prove it's a regular backup.
Also ask to see the plan for doing test restores of different databases on a regular basis as well as the DR Test Plan where they pretend the build the prod box is in was wiped off the face of the Earth, all replication had failed, and you need to stand up the DR Test site only from backups.
Yes to all this.
There should never be a fight as to what backup tool to use. It's all about meeting the restore and recovery requirements. Period. If they can. Great. If they can't. No, we're not using that.
Absolutely positively wrong. Another statement made by someone who probably has never run anything highly transactional with more than a 2 9s uptime requirement. Choosing the wrong backup solution can have performance impacts as my previous post just mentioned. There are about 50 other reasons why your statement is completely wrong as well all from performance perspectives of VLDBs.
Either that, or they simply haven't seen what you're talking about. I'm a big fan of native backups/restores and I seriously dislike and strongly (on the job) argue against 3rd party backup software for some of the reasons you mention and other reasons as well but you don't have to make passive agresssive ad hominem attacks. And, yeah... I DO get the reason why you're trying to drive the point home. You'll find that people listen better when you're not throwing hatchets at their heads. 😉
For the uninitiated, do you have a link or two you'd like to share?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2022 at 2:15 pm
I know this is an old topic but we are using Cohesity 6.6. It now has SQL log backup and Point in time restores. So far I'm liking it really well.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply