# How are recovery points physiсally represented?

• ### Question

• Colleagues!

I'm curious how recovery points are represented physically in DPM?

I know that there is recovery point volume allocated per each datasource (without co-location) and recovery point volume allocated for multiple datasources that belong to multiple protection groups (with co-location) (am I right??)

I can obtain recovery points sizes via both DPM management console and DPM shell but I cannot understand where are recovery points stored.

Consider simple example: we want to calculate overall datasource used space.

Overall datasource used space = Shadow Copies Used Space +  Sum of Recovery points sizes + Replica used space;

BUT

If you calculate overall datasource used space this way it will be more than space allocated. And of course this is weird.

Picking up the  details I've understood that Sum of recovery point sizes are very big and it is the cause of very large result (

Overall datasource used space = Shadow Copies Used Space + Replica used space  gives the correct values).

Conclusion: recovery points have sizes but they contradict with other datasource allocation figures.

1. What does rec point size mean?

2. Where are rec points physically stored?

Nickolay

Thursday, December 16, 2010 6:48 PM

• Hi,

Answering in reverse order to help simplify the answer.  Recovery points are delta, block level changes done to the replica volme between recovery point times  and are saved on the recovery point volume as files in the "system volume information" folder.  The recovery points are nothing more than chunks of files that have changed between one recovery point time to the next.  So - depending on how much data churn there is on the files wer're protecting, and the frequency of the recovery points,  a recovery point can containg a new MB of data, or a few or hundreds of GB.

So - this is your correct answer Overall datasource used space = [Shadow Copies Used Space + Replica used space]

The total storage "USEd" for any given data source is seen in the DPM console while highlighting the data source in question. The Sum of the Replica used space and recovery volume used space is the total used space.  If you over allocate the recovery point volume (There is a lot of space allocated, but not much used) in DPM 2010 you can shrink the recovery point volume once you have close to the number of recovery points you configured for that PG.

Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
Friday, December 17, 2010 10:45 PM

### All replies

• Hi,

Answering in reverse order to help simplify the answer.  Recovery points are delta, block level changes done to the replica volme between recovery point times  and are saved on the recovery point volume as files in the "system volume information" folder.  The recovery points are nothing more than chunks of files that have changed between one recovery point time to the next.  So - depending on how much data churn there is on the files wer're protecting, and the frequency of the recovery points,  a recovery point can containg a new MB of data, or a few or hundreds of GB.

So - this is your correct answer Overall datasource used space = [Shadow Copies Used Space + Replica used space]

The total storage "USEd" for any given data source is seen in the DPM console while highlighting the data source in question. The Sum of the Replica used space and recovery volume used space is the total used space.  If you over allocate the recovery point volume (There is a lot of space allocated, but not much used) in DPM 2010 you can shrink the recovery point volume once you have close to the number of recovery points you configured for that PG.

Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
Friday, December 17, 2010 10:45 PM
• Thank you, Mike!

Very clear!

Nickolay

Tuesday, December 21, 2010 10:45 AM
• I've drilled down into System Volume Information folder and saw that RPs are not only deltas. At least 1 RP on RP volume is FULL BACKUP (it is rather large) - or I've misled...

Or this big file in SysVolInfo folder is what we call "shadow copy"? And all small (relatevely) files are RPs?

Mike, can you clarify this points?

Thanks!

Nickolay

Thursday, December 23, 2010 4:33 PM
• Hi,

All shadow copies (recovery points) are deltas, so consider the following.

Time1 - We protected a 100GB Volume with 50GB used, Initial replica is 50GB.
Time2 - We create a snapshot (RP) - Nothing is in the snapshot, just a blank 300mb sparce file.
Time3 - We synchronize and as a result, we changed 3 GB of data, and we deleted 10GB of files on the replica - the 3GB of changed data gets moved to the RP volume and the 300mb file grows to 3GB.  The deleted files do not get copied to the shadow copy until those sectors are overwritten.
Time4 - DPM creates a RP, so now the system volume information folder has ~3GB RP file and a new 300mb sparce file.
Time5 - We synchronize and as a result, 5GB of new files get transfered to DPM and written to the Replica volume.  Those new files overwrote the same sectors of the files that were deleted from the replica at Time3, as a result, ~5GB gets written to the recovery point volume and grows the 300mb file to ~5GB.
Time6 - DPM creates a RP, so now the system volume information folder has another new ~5GB RP file.  So now we have ~8GB is the recovery point volume.  a ~3gb RP, a ~5GB rp and a new 300mb sparce file for the new active recover point.

As file data gets overwritten on the replica as a result of synchronizations (or consistency checks), the new RP file gets written to.  RP file size will vary greatly depending on how much data changed between recovery point times.

Again, all recovery points are deltas.  You can test this for yourself by making RP on DPM server, make a change on PS, then make a new recovery point after synchronization, then repeat.  Look at the resulting shadow copy files in the system volume information folder on the recovery point volume.

Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
Monday, December 27, 2010 6:04 PM