DPM 2007 and the storage pool

If you're familiar with DPM 2006, adding disks to the storage pool in DPM 2007 might be confusing because it doesn't behave the way you expect. You're not alone - a lot of you using the beta 2 version of DPM 2007 have run into this. So here's an explanation of DPM 2007 and the storage pool disks.

In DPM 2006, disks added to the DPM storage pool are reformatted and, if necessary, converted to dynamic disks. DPM 2006 uses all space on the disk in the storage pool.

In DPM 2007, DPM uses only unallocated space on disks added to the storage pool. If you add a disk to the DPM 2007 storage pool that has existing volumes on it, DPM cannot use the space in the existing volumes. To make an entire disk available to the storage pool, delete all existing volumes from the disk before you add it to the storage pool.

Comments

• Anonymous
  January 01, 2003
  Additionally there is the "custom volume" feature, meant to put allocations on specific disks. Given DPM2006 automatic volume creation using the custom feature may not be clear. You probably know that each allocation needs 2 volumes, 1 to hold the replica and another to hold recovery points or shadow copy diffs. With custom volumes you must manually create at least 2 partitions to make the feature selectable in the protection setup dialog. These partitions can be basic or dynamic, on different disks or both on the same disk and even on storage pool disks although both latter methods sort of defeat the purpose. Why would you do that? Here are some scenarios but there can be many more; (0) in relation to original post: there are small partitions you do not want to remove but desire to utilize the remaining free space for DPM. (1) Support quick restore scenarios. You may want to protect on production performance class storage so you can unmask it from DPM and mount if for production -or- use transportable snapshot scenarios to duplicate excluding protected data sources that otherwise probably share the same disk/LUN. (2) Maintain sequential nature of IO patterns of protection tasks and is recommended for Exchange data protection. Uniquely for Exchange multiple protection groups run in parallel and would create random patterns when they hit the same disk and set of spindles. Given the churn rate and mandatory ESEUTIL and several storage groups it is virtually impossible to keep jobs staggered in time. (3) Store protected data on specific storage implementation other than the normal storage pool. E.g. DPM storage has no replication but some PG's need be on different storage that is replicated, and so forth... R2