DPM needs too much babysitting

[SushiSean]

Perhaps this is becuase its still Beta... but for me, it requires too much
babysitting.
Out of my 18 current jobs, 6 are on "Recovery point creation failed" and 3
are on "replica is inconsistent" state. Thats a %50 failure rate for some
reason or another.

All of the "Recovery point creation failed" errors are because DPM has run
out of free shadow copy space. There is plenty of disk space, so why DPM
doesnt autoadjust this, or forecasts the space needed ahead of time more
efficiently is beyond me.

From the "Replica is inconsisent errors" I got the exchange server with:
The replica of Storage group First Storage Group on SERVER is inconsistent
with the protected data source. All protection activities for data source
will fail until the replica is synchronized with consistency check. (ID 3106)
SERVER has been restarted without being properly shut down. (ID 111)

So fine, the box was restarted with an improper shutdown due to a system
hang. Why would DPM fail after the box is back up? Why doesn't it run the
sync job with consistency check automatically?

Another server has a bunch of VSS errors, so DPM fails. I can undertand
that this is legit. Something is wrong with the server and VSS needs to be
fixed on it before DPM succeeds.

The 3rd server with "Replica is inconsistent" error has this:
Recommended action: 1) Click on the link below to run synchronization with
consistency check.
2) If the problem persists, you may increase the USN journal size or
configure the current protection group to synchronize more often clicking on
'Modify Protection Group...'. To change USN journal size, go to the Disk
Allocation page, using the “Modify” option select the “Protected Server” tab.
Change the “Space Allocated” here.
Modify Disk Allocation ...
Run a synchronization job with consistency check...
Resolution: To dismiss the alert, click below
Inactivate alert
Description: The replica of Volume E:\ on SERVER is inconsistent with the
protected data source. All protection activities for data source will fail
until the replica is synchronized with consistency check. (ID 3106)
The Change journal has wrapped around and therefore DPM is unable to track
any more changes or may have missed some changes for the data source E:\ on
server SERVER (ID 30117 Details: Internal error code: 0x809909D1)

The failure explanation is vague and also if lack of space is the issue, DPM
should autogrow it if there is enough disk space (and there is plenty disk
space) and if the growth amount is not that significant. It should then
alert the admin via email about the auto-grow.

[Kapil Malhotra [MSFT]]

SushiSean,

We appreciate the fair evaluation of the product and your excellent
feedback.

Here are somethings which may explain behaviour OR help you not need to baby
sit DPM.

1) Auto grow functionality should be very easy for us to build but storage
is something which some admins want to have control over. You can implement
the autogrow functionality using the DPM PowerShell CLI. I can share a
sample autogrow script if you send me mail on Kapil dot Malhotra AT
microsoft dot com. If you schedule this script to run every day, you will
never need to baby sit this aspect.

2) Unclean PS shutdown: We have a volume filter which is tracking changes
and helping doing the most optimal delta tracking with no overhead on the
protected server. If the machine is powered out, we cannot guarantee
continuity since we have been unable to persist state to disk like we do on
a clean shutdown. You can schedule a daily consistency check using the
"Performance optimization" on the Protection UI to achieve this. The
PowerCLI can do the same as well and automate this. I can share that with
you as well.

3) The USN error which you are seeing is interesting. We use the NTFS USN
journal on the protected server in file replication. It would take a lot of
I/O to make it wrap. Has this volume been unsynchronized for a long time?
Does this volume have heavy I/O?

--
Thanks,

Kapil
This posting is provided "AS IS" with no warranties, and confers no rights.

"SushiSean" <Sush...@discussions.microsoft.com> wrote in message
news:D5B25DCC-97C8-4772...@microsoft.com...

[SushiSean]

Kapil,
I understand that some admins out there might want to have complete control
over anything that DPM might offer, but a whole bunch of others would be
quite content with letting DPM have a bit more responsability, such as
auto-grow under certain conditions. If this is something very easy to build
as you point out, why dont you guys implement it and then let the admin
decide whether to allow this functionality or not. That would be pretty cool.

I will email you for the power shell scripts for both the autogrow and the
consistency check one.

In regards to the USN error, yes, this server does have heavy I/O load. But
I dont recall for how long it wasnt being synchronized. My best guess about
3 or 4 days.

[SushiSean]

Kapil,
I was not able to find the UI option you mentioned to schedule daily
consistency checks.

[Kapil Malhotra [MSFT]]

1) Click on the PG in the Protection View.
2) In the Actions Pane you will find "Optimize Performance"
3) You will find this option on the Consistency Check TAB on the dialog.

--
Thanks,

Kapil
This posting is provided "AS IS" with no warranties, and confers no rights.

"SushiSean" <Sush...@discussions.microsoft.com> wrote in message

news:92E9D223-F565-42EC...@microsoft.com...

[SushiSean]

Great! That did it.

[Matt]

I agree that this should be put in as on option to Autogrow. I am running in
to same issue. I like the ease of use and the interface overall but the
success rate is something leaving an uneasy feeling about using this in
protection.

[John McG]

I am in the same boat.
I quite like DPM, but this disk management in it is pretty grim. We can't
afford to have someone sitting monitoring the disc space and replica's all
the time. We like to work in a configure and forget environment as much as
possible. It would be ideal if you had an autogrow function that maybe threw
errors once disc space reached a use defined limit i.e. errors when only 15%
disc space free.
I am having an issue at the moment when i am setting up a new replica and
shadow volume copy, getting DPM to figure out how much space it needs, then
failing the replication because not enough disc space.

[Kapil Malhotra [MSFT]]

John/Matt,

Would the CLI based auto grow work for you? The sample scripts which ship
with RTM will have it and for Beta2, you can send me mail on Kapil dot
Malhotra AT microsoft dot com. I can share my auto grow script with you,
which you can use and even schedule if you feel comfortable with it.

--
Thanks,

Kapil
This posting is provided "AS IS" with no warranties, and confers no rights.

"John McG" <Joh...@discussions.microsoft.com> wrote in message
news:B357218B-A67E-4BED...@microsoft.com...

[John McG]

Hi Kapil,

I shall send an e-mail for the scripts thanks. But with having to use
scripts etc, it doesn't quite seem as user friendly as it possibly should be?
Thinking that the DPM should simplify backups within an organization, having
to start messing around with scripts to increase space DPM wants to use seems
a bit cumbersome, in comparison to the more conventional methods.

[Kapil Malhotra [MSFT]]

John,

Feedback taken. The inability to shrink volumes on Win 2K3 and the feedback
from admins that some data source hogging away storage is unacceptable are
some of the reasons why we didnt implement this.

The points you make are fair and I hope a scheduled powershell script will
eliminate this for good.

--
Thanks,

Kapil
This posting is provided "AS IS" with no warranties, and confers no rights.

"John McG" <Joh...@discussions.microsoft.com> wrote in message

news:0DAE75DF-4F5D-427F...@microsoft.com...

[Matt Dillingham]

I am finding the same issue and would also like to see the auto-grow
feature.

Additionally, auto-grow could be used to achieve better space
utilization, reducing wasted space. ...which is a problem I am
beginning to notice as I am putting the agent on more an more machines.

I am sure others have noticed that with many servers and each
volume/source having its own "silo" of dedicated space, you can wind up
with a lot allocated/unused. Since volumes cannot shrink and it is a
pain to micromanage the space allocations, there is a tenancy to over
allocate.

I would prefer to initially allocate space as narrowly as possible and
let an autogrow feature resize the space as needed. I believe this
strategy and solution could be usefully applied for both the shadow copy
and replica volumes.

Honestly, I think that all but the most controlling admins would prefer
this if the two choices were made clear.

Matt

[Mike]

I agree with Matt, John and SushiSean.

There absolutely needs to be an auto grow feature. I don't want to spend my
time making sure I allocated enough space for my backups. If the system needs
it and it's available, it should just expand. If you are worried about
running out of space, add another feature to email the admin that you are low
on space. It's not like hard drive space is expensive anymore. SQL server has
an auto grow feature, why can't this?

I understand you want to make this as simple and easy to use, and if that is
indeed your goal, don't make us fiddle around with scripts. If you can do it
with a script, why hide it? Just make it available in the UI. Us admins
already have enough on our plates to have to worry about finding a script to
do X or creating one if we even know how.

My 2 cents.

Mike

[Unknown]

Kapil,

Can you send me that script also?

Thanks.

Sajid Bhagat
Omicron
s...@omicrontech.net

[Balaji Hariharan[MSFT]]

Find the script at http://blogs.technet.com/dpm.

--
Thanks
//Balaji Hariharan[MSFT]

This posting is provided "AS IS" with no warranties, and confers no rights.

"s...@omicrontech.net" <s...@omicrontech.net@discussions.microsoft.com> wrote
in message news:D77AF078-1837-489C...@microsoft.com...