Why is DPM Using a lot of space for Recovery Point Volume?

By zwar_the_one ·

We have a secondary DPM server setup, which also (amog other primary DPM stuff) backups primary DPM's
database DPMDB. The database is around 1,2 GB large. The retention rate is
set to 31 days and the recovery point is made every day at 10.00 p.m. (one
recovery point per day). The strange thing is, right now the backup uses 29,11
GB for the recovery points, having only 3 active recovery points from which
the data can be restored. I really don't get this! Why does DPM not delete
unneeded data for recovery points and how can I delete them manualy (I have tried out pruneshadowcopy.ps1, with no success)? And why are only
three recovery points active (for the last 3 days) if the retention rate is
31 days? This is present only by DPMDB, other databases from DPMs SQL server
(e.g. master, model, msdb etc.) work as expected and are in the same PG as DPMDB.

Primary DPM uses it's own SQL server, which is used only for DPM data.

Thank's for help!

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

.... there's more ...

by zwar_the_one In reply to Why is DPM Using a lot of ...

Please correct me if I am wrong! If I understand the DPM model for backing up data correctly, then it creates a replica, which is beeing synchronised with the actual data and is allways in the current state. Plus DPM writes all changes for specific points in time to the Recovery Point Volume. Thus max size for Recovery Point Volume is number_of_recovery_points * replica_size. In my case the replica is around 1,2 GB large, so max expected recovery point size would be 31 * 1,2 GB = 37,2 GB. This means 30 GB of used space is even less than needed in worst case.

Still why are there just 4 recovery points all of the sudden? A week ago, there were around 24 active recovery points! Is such behaviour connected with some errors with pruneshadowcopies.ps1 which is run by DPM daily? Our secondary DPM runs in a virtual environment with 2,5 GB RAM dedicated for it (it's less then recommended for DPM, but the secondary DPM is used for backing up just primary DPM data, and does not deal with a large ammount of protected data, so nobody minds if it's working a bit slower as in optimal case scenario).

Related Discussions

Related Forums