This blog post is part of a series how to backup your SCOM environment.
You can find the other parts here:
- How to backup your SCOM environment
- How to backup your SCOM dbases
- How to backup your SCOM encryption key
- How to backup your SCOM IIS settings
- How to backup your unsealed management packs
- How to Document your SCOM installation
- How to Backup your Reporting
In order to keep the possibility to restore your SCOM environment in case of a disaster you need to make sure that you have a good backup of your dbases.
Your dbases keep track of all the info in your environment so it’s crucial that you don’t loose these valuable assets of your environment.
A good backup strategy of your SQL dbases is crucial as you need to make sure that you always have a recent copy at hand.
If you have a backup admin in your environment and are using a backup product like Data Protection Manager it’s best to meet up with the admin to check how his SQL backup schedule is configured. If he’s confident that he provides your backups no need to backup them twice…
If not you’ll need to perform the backup yourself.
First of all a small word about the different options you have to backup a SQL dbase (this applies to all SQL dbases and is not SCOM specific)
- Full backup: This is self explanatory actually. You take a full backup of your dbase. In case of a restore the existing dbase will be overwritten and rolled back to the point in time where the backup was taken. This consumes the most storage space.
- Incremental backup: This method backs up all the differences since the last database backup. With this method you have more flexibility to do a point in time restore. It takes less space but can be more time consuming to restore.
- Transaction log backups: With this method you just take a backup of all the changes to the dbase since the last transaction log. This method is fast and safes some storage space but can be a hassle to restore.
A good mix of the 3 methods above is a good strategy. I always take a full backup of the operations dbase once a week (datawarehouse once a month), a incremental backup once a day (for datawarehouse once a week) and Transaction log backups every 2 hours.
Again you can skip the Transaction log backups but then you risk to loose a max of 23h59m of data.
So let’s get the backups up and running:
We’re going to create the full backup schedule for Operations dbase in this example:
Connect to the dbase.
Open the tree and go to the “OperationsManager” dbase > right click > Tasks > Back Up…
- Select the OperationManager dbase
- Leave backup type at full
- Fill in a name of the backup set
- Click backup to disk and choose Add to create the file
- Set the expiration. I choose 40 days but again this can change according to your requirements.
Choose Options in the left pane and set:
Verify backup when finished
When all the settings are correctly configured choose Script button at the top of the page and choose “Script action to Job”.
This will generate a SQL job which you can schedule in the SQL agent so it can fire the backup when needed.
Name the job: In this case “Back up Database – OperationsManager_weekly”
Choose Schedules in the left pane and select New at the bottom:
When your schedule is made > click ok and the job is created.
You can check this job in the SQL Server Agent under the tree Jobs…
This is for the Weekly full of the Operation manager dbase.
You need to complete the same steps to perform the backup schedules for your other dbases.