SCOM DB Backup with DPM 2010 - Question on Data Change Rate
Hi We have a small setup of SCOM 2007 R2 running with 60 agents and deployed 50 MPs. We haven't installed DW nor enabled ACS; The OpsMgr DB is located on a separate server running SQL server 2008 on W2K8 R2. We have configured the backup for OpsMgr DB using DPM 2010. It is set in Full Recovery Mode in SQL. In DPM it is configured for 15 min sync and Express Full back up to happen every night. The OpsMgr DB is of 30 GB size with data size of 2 GB. For every 15 min sync it is transferring approximately 4 MB of data and every night it transfers 500 MB of data to DPM during Full Express backup. I doubt the data change is not so huge on a daily basis. Please let me know if this is a normal behavior or how to check/track what has been changed. We have disabled AV Scan as well. Krish
April 19th, 2011 1:06pm

i'm not sure, but full recovery mode for scom is usually an overkill (u really need to restore your monitoring product to the latest second?) backup will be far less when you dont have to backup up the transaction logs.Rob Korving http://jama00.wordpress.com/
Free Windows Admin Tool Kit Click here and download it now
April 19th, 2011 1:29pm

Thanks for the quick revert Rob. It used to be in Simple recovery mode. However it still took 500MB+ data for backup every night. I agree with you on the Full recovery mode for SCOM DB. We set it for testing purpose.
April 19th, 2011 1:36pm

I'll let others here jump in and describe what they do ... but if it were me, I would not back up monitoring data. It is stale the day after you didn't use it, and who wants to restore old alerts and old state change data. The whole db will rebuild itself in 7 days (default grooming intervals in place) The backup that I would take is the one that was the system right after I got things set up and the agents all hooked up. You should also be backing up file copies of management packs and the individual override files that you create on a one-per-technology basis. So AD overrides file for all AD related workloads, ADFS overrides for all ADFS related workloads, SQL 2005 overrides, SQL 2008 overrides, Windows server OS 2008 overrides, Windows server OS 2008 R2 overrides ... etc. This way you can restore to a known "agent connected" state, validate the health of the management groups, and then re-import one at a time each of the MP MSI download sets, with the overrides for that technology one at a time. The thinking in taking this approach is that you want to get the MG back into a healthy state, then start re-introducing each of your workloads. If you restore the backup that includes all of the MP's there will be a massive config storm that could take days and days to unravel (normal, expected behavior after a DB restore). Taking the approach I describe here gets you up and running, monitoring again, with only the loss of your actual transient monitoring data equal to your grooming interval. Since you aren't DW connected, this is how I would do it if it were me.Microsoft Corporation
Free Windows Admin Tool Kit Click here and download it now
April 19th, 2011 2:53pm

just out of curiosity. Do you really think that is a plausible backup strategy? i agree about the data, that's probably not important, but i have my doubts that the scenario you describe will work in all cases. i can understand it works in small, static environments that never have been patched. But i think it will fail when you setup scom, take your snapshot and 3 years later you need to restore it. It will miss out on SQL and SCOM patches (e.g. really like to know how you think a scom sp1 db will cope with r2 cu4 rms and agents or how you think you can make a new "snapshot" when you apply a patch) and loads of agents don't exist anymore, loads of new ones have been added... This is besides the fact whether importing all mp's one by one will prevent a config storm. i think i'll need a day to import all my mp's in my environment (3000+ agents) if i wanted to have a "workable" console during the import.Rob Korving http://jama00.wordpress.com/
April 20th, 2011 3:04am

Personally I think the case for just going for some kind of empty db and importing all mps (which you should always backup regularly - automatic) is a workable way. But since you have all config etc etc in a database and it is sql and DPM is great in backing up SQL and restoring to points in time quite close to when it failed I see no reason why you would not just restore the latest database. The amount of stale data is not that big if its the backup from last night and it will get groomed out in no time, especially for a small environment, such as this. So given the choice and if I would have a backup from last night I would restore the database from backup. The other way would be a second or probably third scenario if there are no other choices. Rob makes a very valid point about the updates and changes to the db (by updates and discoveries and so on) you would have since the old sql backup. Also for larger environments it would get very interesting to try to import the mps etc like Rob said.Bob Cornelissen - BICTT (My BICTT Blog)
Free Windows Admin Tool Kit Click here and download it now
April 20th, 2011 3:17am

Going back to your question. I am not sure that 500 MB out of 2 GB would be a normal change for the opsdb for every day. But generally I just assume that if you have grooming at 7 days for all performance and event data I would expect that 1/7 th of new data is added, 1/7 th of data is deleted (groom old data) and perhaps some updates to some of the rest of the data. So if I make that very rude assumption that is 30% of the data. Of course the opsdb contains more stuff that doesnt change, so lets move it down to 25% to account for those parts. And of course DPM also uses block level changes so it could be a fraction more in the backup because the block might be bigger than the changed data, but that is not that big a difference. Wow, with those assumptions I do come to 25% and that is 500 out of 2000 MB of data in the DB. *grin*. So if you want me to guess, I could say It is very possible.Bob Cornelissen - BICTT (My BICTT Blog)
April 20th, 2011 3:23am

well it's not an "empty" db, which is the problem i guess. it's a db with very basic config data (no mp's) and hardly any data other then collected by the core mp's.Rob Korving http://jama00.wordpress.com/
Free Windows Admin Tool Kit Click here and download it now
April 20th, 2011 4:38am

Hi Bob, Dan & Rob, Thank you for all your feedbacks. Definitely helped me to identify a better backup plan. I would go with a combination of these solutions. This is what I am planning to do. First I will set the recovery mode to Simple and will schedule a weekly Express Full backup. When making changes like patching, etc I will initiate a backup before & after the change. Thanks again!
April 20th, 2011 11:41am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics