April 6, 2009 at 11:18 am
With the advent of third-party enterprise-level backup solutions, such as Symantec or CommVault, how justifiable is it to maintain that DBAs should still be the owners of the database-backup/restore process?
Some of these (enterprise) backup tools include the entire O/S system in the backup plan, in addition to database files. In a company using a tool like this, one might argue that the responsibility of database backups and restores should now belong to the system administrators or operations staff or a specially designated backups team. The DBA team might then be shut out of one of the most important roles of the DBA, which is data security and data access management.
What do people think about this? How important is it for DBAs to stay in control of database backups/restores, even if the tools used are third-party tools that do system-level backups?
I'm a DBA BTW... 😉
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
April 6, 2009 at 12:00 pm
Marios Philippopoulos (4/6/2009)
With the advent of third-party enterprise-level backup solutions, such as Symantec or CommVault, how justifiable is it to maintain that DBAs should still be the owners of the database-backup/restore process?
I think it comes down to responsibility. If a database needs to be recovered, or a disaster happens, who's doing the restore? IT dept or the DBA? In your scenario, it's more of a blend, so daily restores to fix mistakes or whatever ares probably for the DBA, but full blown disaster falls in the lap of the IT group.
Some of these (enterprise) backup tools include the entire O/S system in the backup plan, in addition to database files. In a company using a tool like this, one might argue that the responsibility of database backups and restores should now belong to the system administrators or operations staff or a specially designated backups team. The DBA team might then be shut out of one of the most important roles of the DBA, which is data security and data access management.
I know sans and system level backups are supposed to work great, but I'd still make regular backups via a SQL job. finding out that the sys backup doesn't work as expected AFTER a panic session is really the worst way to find out about the backup plan.. part of the DBA job is to test backup and restoration on an ongoing basisanyway, so you'd have to test doing that whether it was a sys backup or regular anyway. If the third party software is preventing that because only IT uses it, that's an important thing that has to change.
What do people think about this? How important is it for DBAs to stay in control of database backups/restores, even if the tools used are third-party tools that do system-level backups?
I'm a DBA BTW... 😉
doesn't matter the tools, I'd say, if the databases are your responsibility, so is backups...but you can share with IT i guess.
Lowell
April 6, 2009 at 2:22 pm
Hi,
I have nothing to add about this except that I am 100% agreed 😎 with Lowell.
Thanks.
April 6, 2009 at 3:31 pm
controversial marios, people at work saying they don't need dbas to do backup\restore now they have an expensive tool and need to justify the cost? 🙂
I think there are three points here:
Its not the backing up, its being able to restore the backups.
Whoever is doing the backups might need to restore individual databases so is going to need to know things like database recovery modes, point in time recovery, restoring the master database, oh yeah, things DBAs know about.
There is a difference between backup\restore and disaster recovery at the server or data centre level. these tools are useful in a DR scenario and other areas such as wintel admins or storage guys may well do that. I'll bet they still will want a DBA to health check it afterwards though.
I don't care what fancy enterprise level tool they've got (we use SRDF) I'm still going to take native backups of everything small enough to fit on disk, and especially of system databases.
Just thought, these tools might be good for backups of the resource database!
---------------------------------------------------------------------
April 6, 2009 at 3:42 pm
Thanks all for your input.
If I may add one more point here to what George just mentioned: data encryption and protection of encrypted data.
Who else but the DBAs is better qualified to design and maintain a system for protecting sensitive database information and managing data access?
That, along with performance monitoring and tuning, is the essence of DBA work.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
April 6, 2009 at 4:05 pm
I completely overlooked point in time restores, tuning, development, etc., some of the many things we do outside of backups.
george is spot on; getting a point in time restore without a native backup would be impossible.
excellent points you guys brought up. tuning, indexes, db health...oh yeah there's more.
Lowell
April 12, 2009 at 8:28 am
Hey guys,
Once or twice a year, someone from some SAN vendor or other pops in to claim that SQL Server backups can now be done automatically by their SAN solution, including restores to an arbitrary point in time. So far (and there is a guy in now, so watch this space), we have always managed to find a fatal flaw in the process. However, as time goes on, it is getting closer.
I am looking forward to the day when the whole backup/restore thing becomes Someone Else's Problem, with the important caveat that the new way of doing things has to be better in some respects than previous practice, and no worse in any respect.
Just my 2 cents 😉
Paul
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
September 14, 2009 at 4:48 am
As long as it's not you getting canned when it goes wrong... Let the sysadmins carry it. That way when they get binned, you can negotiate a nice little raise to take on the additional responsibility. If the company is still a going concern at that point!
September 14, 2009 at 6:08 am
Marios Philippopoulos (4/6/2009)How important is it for DBAs to stay in control of database backups/restores, even if the tools used are third-party tools that do system-level backups?
Rule #33 says DBA is responsible for recoverability therefore DBA are still responsible for backup quality and backup/recovery strategy no matter how/who executes the task.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.September 14, 2009 at 7:49 am
Rule #33 ?
I am curious what the list of rule you have is ?
Would you mind sharing ?
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
September 16, 2009 at 9:26 am
Here's my take. All of the agent based tools have had issues at times. I've sen too many of them fail on restores, which is what is critical. I don't need backups, except that at some point I'll have to restore.
The SQL native backup, and the 3rd parties that use it (SQL Backup, Litespeed), have proven to be 100% reliable. If the file is written out, it can be restored.
I'm happy for the backup guy to own backups, but he owns the backup of my backup files. not the process. The SQL restore is too important to be trusted to someone that doesn't know how it works inside and out. and it's not that hard to manage and run. I'll happily be on call for my backups.
Run to a file, let the backup people own the backup after that.
September 24, 2009 at 7:50 am
Steve Jones - Editor (9/16/2009)
Here's my take. All of the agent based tools have had issues at times. I've sen too many of them fail on restores, which is what is critical. I don't need backups, except that at some point I'll have to restore.The SQL native backup, and the 3rd parties that use it (SQL Backup, Litespeed), have proven to be 100% reliable. If the file is written out, it can be restored.
I'm happy for the backup guy to own backups, but he owns the backup of my backup files. not the process. The SQL restore is too important to be trusted to someone that doesn't know how it works inside and out. and it's not that hard to manage and run. I'll happily be on call for my backups.
Run to a file, let the backup people own the backup after that.
Amen...!!!
-Roy
September 25, 2009 at 6:39 am
It is important to move away from a turf war about who should do what, and focus on the business objectives.
Most businesses will have recovery objectives and SLAs. These may be to recover to the last available backup or to a point in time. If you have a backup tool that can deliver the recoveries you need, does it matter to the business who has ownership of the tool of the process?
What should be measured is the ability of the toolset to deliver what the business needs.
We know that SQL native backup (also backup using vendor tools such as Litespeed, SQL Safe, SQL Backup, etc) can meet any recovery objective. The only trick is to make sure the backups are scheduled in the appropriate way and checks aer made to ensure they have run successfully. Many DBAs will keep 2 routes to recovery, often by keeping backups on disk until at least 2 tapes have been sent offsite. Also, many DBAs will regularly run restores to a trial system to prove that what is stored offsite contains the data that is backed up.
If your management are keen to move to an alternative approach, the people who will have ownership of that approach should prove they can meet the recovery objectives. This means they should show they keep 2 ruotes to recovery, and also regularly recover individual databases to the required point in time to show their system really works.
At the end of the day, if both systems work equally well but one needs less staff time than the other, then we must expect management will choose the cheapest system. On the other hand, if one can do the recovery 100% of the time and the other can only recover 95% of the time but at lower cost, management will have to justify the business and audit risk that cutting cost is likely at some point to leave the business with an unrecoverable hole in its data.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
September 25, 2009 at 7:21 am
EdVassie (9/25/2009)
...if one can do the recovery 100% of the time and the other can only recover 95% of the time...
:blink: do elaborate, please.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.September 25, 2009 at 8:03 am
If testing restores in multiple scenarios shows
if one can do the recovery 100% of the time and the other can only recover 95% of the time
then you know that one approach has a real risk of unrecoverable data loss.
If both approaches work 100% of the time then the risks are the same so the focus moves to costs.
You need to test using backups taken of your production databases at the times they would normally be taken with the normal user activity expected at that time. You then restore to a spare server and see if SQL Server is happy with the result.
If you have to restore multiple databases, or databases and file system data, to get your application working correctly, you also need to prevent the 'jagged edge of recovery' where different data stores are restored to different points in time.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply