3 min. Read
System Center Data Protection Manager (SCDPM) is an enterprise-class Microsoft backup solution that helps protect many loads. The configuration of this backup solution is based on security groups. A security group contains multiple data sources that have the same configuration, such as the duration of the backup (short-term or long-term) and the retention goal.
DPM can save the backup to disk (disk-to-disk or D2D), tape library (disk-to-disk or D2T), or Microsoft Azure (disk-to-cloud or D2C). These supports can be confused with high availability: so it is possible to perform D2D2D backup, D2D2T or D2D2C. Best backup practice is called the 3-2-1 strategy and states:
- At least 3 copies of your information.
- 2 songs that are local but in different media.
- 1 copy (third copy) stored outside.
By default, DPM at midnight checks all existing backups to see if any of them are outside the retention target based on the day you specified when you created the security group.
In this quick blog post, I’ll share with you how DPM manages short-term conservation goals for protection groups.
The way DPM manages the retention goal is due to the days you specified when you created or edited the security group.
For example, you have a protection group (PG) set for 14 days of short-term storage. This does not mean that DPM will start deleting backups that are 14 days older, but instead will search for successful backups for 14 days.
I want to explain it simply with the following example:
- Create a protection group (PG) for 10 days of storage.
- From day 1 to day 9, all daily backups will be performed successfully.
- On day 10, the backup failed. Due to the current retention target (10 days), backups have not yet been deleted.
- Day 11 backup is successful. At midnight, DPM checks all existing backups to see if any of them are out of storage. It finds 10 backups created on separate days, and the goal of the protection group is 10 separate days. Because they are within the boundary. Backups are not deleted.
- Day 12 failed again. At midnight, DPM checks all existing backups to see if any of them are out of storage. It finds 10 backups created on separate days, and the PG target is 10 separate days. Because they are within the boundary. Backups are not deleted.
- Day 13 backup was successful. At midnight, DPM checks all existing backups to see if any of them are out of storage. It finds 11 backups created on separate days, and the PG target is 10 separate days. The backup created on day 1 during cutting will be deleted.
Nevertheless, the list below contains 18 backups. The explanation above would make us keep 14, but we have 4 extra backups. The reason is that DPM counts separate days. So if you have 10 backups created on the same day, they are counted on one separate day.
In the next screenshot, I highlighted 4 backups made on the same day. That’s why we now have 18 restore points instead of 14.
In addition, if there were days when the backup failed, then the backup for that day is missing and therefore the oldest backup date is more than the 14-day retention goal.
Once again, DPM does NOT count backups on a calendar day to delete them, but to successfully separate backup days. Note that the same concept applies Microsoft Azure backup server as well.
Hopefully the explanation above sheds light on how DPM manages the target of the protecting group.
Want to know more about System Center Data Protection Manager and how to create a hybrid cloud service solution? Check out my recently published book here: Microsoft System Center Data Protection Manager Cookbook.
With this book on your side (over 450 pages) you will learn the world of backup System Center Data Protection Manager and Microsoft Azure backup server deployment and management by learning tips, tricks, and best practices, especially when it comes to advanced level tasks.
Thanks for locking my blog.
If you have any questions or feedback, please leave a comment.