November 8, 2010 at 12:34 pm
Anyone here have any experience or knowledge dealing with Microsoft’s DPM (Data Protection Manager) product to backup & recover SharePoint installs (which includes the SharePoint DB's as well as the Web farms SP Uses)?
We are using DPM 2010 (just switched a few months back from DPM 2007) to do all backup types from Exchange to SQL Server to our SharePoint 2010 Farm. All of our SQL Serve4r DB’s (except for those used by SharePoint) are managed thru DPM’s SQL Protect method and the SharePoint Web Farm and related DB’s (Content DB’s and other wise) are managed thru DPM’s SharePoint Protect method.
In addition we are using VMWare to host most of the serves involved with the SharePoint stuff from the webservers that run the SP Farm to the SQL Server instance that hosts the DB’s.
If in this kind of setup where you use DPM for recovery, if DPM was reporting problems with on of the SP Databases would you expect the Database Team Member (the one who does the DBA/Design work to investigate the DPM Recovery issues or would you have the SharePoint/VMware admin take point and refer back to the DB whenever anything specific to SQL Server came up?
I tried to look into the problem but all the its I’m getting one the error are referring back to VM technology and or SharePoint tech and not anything to do with native SQL Server recover technology.
Kindest Regards,
Just say No to Facebook!November 8, 2010 at 12:38 pm
YSLGuru (11/8/2010)
Anyone In a mixed (non-Native SQL) Recovery setup who best to take the lead on investigating errors
Always remember Rule #4 which states "DBA are responsible for database recoverability" so, DBA has to take the lead - no doubt about it. 😉
_____________________________________
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.November 8, 2010 at 12:49 pm
PaulB-TheOneAndOnly (11/8/2010)
YSLGuru (11/8/2010)
Anyone In a mixed (non-Native SQL) Recovery setup who best to take the lead on investigating errorsAlways remember Rule #4 which states "DBA are responsible for database recoverability" so, DBA has to take the lead - no doubt about it. 😉
That’s easy to say when you are using SQL Servers backup technology even if you are suing it via one of the third party apps like those from Red-gate and similar.
The SharePoint development team decided to say to heck with the DBA "we'll do it the way we like" and so when you have SharePoint in place, at least 2010 you have all kinds of joy and wonders to taunt you each day.
Let me ask you this, if in an IT Shop you have hardware guys handling hardware and Sysadmin handling the network and a DBA handling the database and a backup fails because the network is done or a piece of hardware fails, would you say the DBA should go fix each of those since the backup is the DBA's job or would it be more apt to say the DBA lets the right team member know, the hardware guy or the sysadmin so they can do what they do best and once they've fixed it on tehir end they then hand it off back to the DBA?
Kindest Regards,
Just say No to Facebook!November 8, 2010 at 12:54 pm
YSLGuru (11/8/2010)
PaulB-TheOneAndOnly (11/8/2010)
YSLGuru (11/8/2010)
Anyone In a mixed (non-Native SQL) Recovery setup who best to take the lead on investigating errorsAlways remember Rule #4 which states "DBA are responsible for database recoverability" so, DBA has to take the lead - no doubt about it. 😉
That’s easy to say when you are using SQL Servers backup technology even if you are suing it via one of the third party apps like those from Red-gate and similar.
The SharePoint development team decided to say to heck with the DBA "we'll do it the way we like" and so when you have SharePoint in place, at least 2010 you have all kinds of joy and wonders to taunt you each day.
Let me ask you this, if in an IT Shop you have hardware guys handling hardware and Sysadmin handling the network and a DBA handling the database and a backup fails because the network is done or a piece of hardware fails, would you say the DBA should go fix each of those since the backup is the DBA's job or would it be more apt to say the DBA lets the right team member know, the hardware guy or the sysadmin so they can do what they do best and once they've fixed it on tehir end they then hand it off back to the DBA?
mmmhhh I think I failed to convey the message, you are the DBA then you are responsible for database recoverability then you take the lead each time something affects recoverability. You don't have to personally fix it but you cannot walk away from your responsiblity, if database crashes and can't be recovered, that's on you no matter what caused the issue.
_____________________________________
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.November 8, 2010 at 1:09 pm
PaulB-TheOneAndOnly (11/8/2010)
YSLGuru (11/8/2010)
PaulB-TheOneAndOnly (11/8/2010)
YSLGuru (11/8/2010)
Anyone In a mixed (non-Native SQL) Recovery setup who best to take the lead on investigating errorsAlways remember Rule #4 which states "DBA are responsible for database recoverability" so, DBA has to take the lead - no doubt about it. 😉
That’s easy to say when you are using SQL Servers backup technology even if you are suing it via one of the third party apps like those from Red-gate and similar.
The SharePoint development team decided to say to heck with the DBA "we'll do it the way we like" and so when you have SharePoint in place, at least 2010 you have all kinds of joy and wonders to taunt you each day.
Let me ask you this, if in an IT Shop you have hardware guys handling hardware and Sysadmin handling the network and a DBA handling the database and a backup fails because the network is done or a piece of hardware fails, would you say the DBA should go fix each of those since the backup is the DBA's job or would it be more apt to say the DBA lets the right team member know, the hardware guy or the sysadmin so they can do what they do best and once they've fixed it on tehir end they then hand it off back to the DBA?
mmmhhh I think I failed to convey the message, you are the DBA then you are responsible for database recoverability then you take the lead each time something affects recoverability. You don't have to personally fix it but you cannot walk away from your responsiblity, if database crashes and can't be recovered, that's on you no matter what caused the issue.
Paul,
Thanks for replying (I forgot to mention that last time). Unless you've had to deal DPM 2010 + Sharepoint 2010 running on Virtual Servers its hard to appreciate just how complicated Microsoft has made things for SQL Server with DPM & Sharepoint. Did you know Sharepoint auto-creates Databases las often and with jsuat as little reason why as little kids do things that always have the asnwer "I dunno know" ?.
Seriously though, I wasn’t asking about who should be responsible for whether the Recovery plan in place was working or failing but who should take the lead in investigating a problem in a mixed technology situation in which the majority of the mix was not SQL Server specific but relevant to SharePoint or some other tech?
It’s about using the right resource in an effective way. Recently our IT Admin who is a VMWare guru had to implement something related to Active Directory and part of it required quering one of our databases. That project was his responsibility but when it came to working on the query that Active Directory needed he asked me to do it. This made sense because
A) I could do it in far less time, and
B) the resulting query would most likely be more efficient (not to mention accurate) then what he would have put together.
In that example the IT Admin never transferred his responsibility to someone else but he did make the most use of the resources at hand.
Now in the case of DB Recovery, this gets very muddy when you mix different recovery types together but that’s exactly what DPM does. And even when DP<M does just SQL Server Databases and not SharePoint + SharePOint DB’s, it does not do backups like SQL Server nor like the SQL Server tools vendors. This difference has its ups sometimes but it also has its downs.
So in closing it’s a question of not who should be responsible for making sure the recovery gets done but who should be the lead to investigate the issues when it goes outside the bounds of SQL Server?
I hope that makes more sense than the original post.
Kindest Regards,
Just say No to Facebook!November 8, 2010 at 1:37 pm
YSLGuru (11/8/2010)So in closing it’s a question of not who should be responsible for making sure the recovery gets done but who should be the lead to investigate the issues when it goes outside the bounds of SQL Server?
DBA is responsible for recoverability, DBA leads investigation and makes sure whatever is broken gets fixed no matter if it involves Storage, Networking, Third party tools and/or Flying saucers. 🙂
_____________________________________
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.Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply