First published on TECHNET on Jul 08, 2010
Assume we have some sort of scenario where protection is continued on new storage pool and are left with old storage pool that contains data but is no longer relevant. You could develop the idea to re-use old storage pool disk space to enlarge the new storage pool and may even be part of a migration plan.
Never re-introduce old storage pool volumes with formerly protected data to a DPM server that already protects those data sources on other storage! This is not about DR scenarios to recover protected data but about accidental doubling of protected data volumes!
To re-use disk space of old storage pool ensure volumes are destroyed and old disk space is exposed as raw disk space!
If you import ‘foreign’ volumes using disk manager that used to be DPM storage pool you may end-up with one or both of the following issues;
- DPM once knew these volumes and will automatically associate with known but already protected data sources (see scenario below). From here onward if you ever need to “DPMSYNC –reallocate” all volumes are recreated and may induce the next bullet which is not easy to clean-up.
- The import increases the number of volumes on the system and could push it over the 90% level at which point DPM2010 will no longer create or extend allocations (warning level is 70%). Existing protection continues for as long as current space allocation allows. When DPM re-associated the imported volumes you could easily push beyond the 600 volume limit with the same result.
You now need to remove the surplus volumes and restore DPMDB from just before this unfortunate exercise. But what are the surplus volumes and the good volumes associated with the same data sources amongst hundreds? You don’t want to go into this and better prevent it.
“I get that but why is this happening in the first place?”
Well, the same mechanism that makes your life easy after restoring DPMDB or [re]protect inactive data sources preserving existing data or rebuild storage pool from tape, has this side effect on a ‘not supposed to happen’ scenario.
“But I can’t imagine how I would get into such a situation?”
It did happen and here is why –in essence- this wasn’t such a stupid idea after all except if it wasn’t for the above…
You have primary and secondary protection and secondary DPM is to move to another site on new hardware. You are also facing an upgrade and make a plan,
of course using the DPM upgrade advisor
. You stop secondary protection and in-place upgrade the primary, all happily chunks along. So far so good and you build the secondary from scratch on new hardware, that too happily chunks along as planned, we love it when a plan works, right?
Enlarging storage pool for DPM workloads you did not have room for earlier with the now surplus storage seems like a good idea. So you expose the former storage pool and import the foreign volumes to become accessible … hey, what are these alerts for?
“ID: 32065, Alert - LDM database size has exceeded the error threshold”
How is that, I didn’t even get that far in creating new protections did I? Well, not in DPM but your volume import action using disk manager did… This is exactly what DPM2010 prevents you from doing. So, let’s make sure we do not defeat that by other means…
