DPM Drawbacks?

  • Hi.

    My server team is pushing a switch to DPM after they saw what it says it can do.

    I have a lot of questions, and we need to do a lot of testing, but was wondering if someone could shed some light on issues they've had with it so I know what to focus on.

    Things that concern me are environments with large transactions per second, potential locking/blocking within the database, etc.

    It seems like a reasonably good idea, but call me old-fashioned...But...I'd prefer to back up to a SAN/LUN and then have it mirrored and SNAPped and then backup the broken mirror, etc, etc.

    Am I being too anal? Change is good.......As long as it doesn't muck up database performance or recovery!

    Thanks,

    Mike

  • Just took a cursory look at DPM. I'm going to have to look at it further and see what it can and can't do. May actually be worth looking into here. Don't take that as an endorsement.

  • does it have a SQL agent

    i think i read about it a few months back but didn't read anything about a sql agent like netbackup

  • It has to have some sort of agent so it can connect into the database. It sounds somewhat promising since it uses the same internal process as a native SQL Backup, but we haven't tested that yet...

  • We are considering it here as well. I have watched a presentation put on for us by the Microsoft Primary Tech for DPM for the eduction sector and it looks quite interesting.

    /* Disclaimer -- I use Full/Diff/Log backups and LOVE them (I actually use Ola Hallengrens plans!) -- We are a TSM shop here and I have a decent sized cluster and do not have alot of love for the TSM TDP SQL software. I am seriously looking at DPM but ALSO we are looking at AppAssure Replay which has similar+ features but approaches it differently than DPM. I will be running these systems in parallel hopefully for at least a month if not longer to see if I am confident enough in either of them to replace standard SQL backups. As an educational customer of MS we have a campus cal-license setup so DPM is only a few hundred $$ for us so no loss if we buy it and decide to go down the appassure route which is what our networking department is leaning heavily towards. Fortunately here I have the rights I need to do the majority of the things I want to do with TSM but I know that is not the case for many out there--having been a sysadmin here in a previous life helps considerably 😉 */

    * To answer previous questions - There is only 1 agent but built into that is support for Windows, SQL, Sharepoint, and Exchange.

    * The agent looks fairly light as well.

    * Everything it does for each product utilizes the VSS service for that product.

    * when backing up SQL , how i understood it to work is

    --Makes the initial Full backup utilizing vss

    --Your important db's are kept in full recovery and it then utilizes the Log as the backup point. So if you set it at 15 minute intervals for example it takes the log backup, then truncates and stores that away in a "snapshot" so that you can then go to any point in time for however long you are storing data.

    * An extremely positive point for those looking for disaster recovery option that might have a co-location is that all you have to do is drop another MS DPM server and some storage there and then just set up replication between the 2 DPM Servers.

    db

  • We, too, are gathering more information about it. All in all, it appears to do basically everything we need...Though with a few important exceptions from what I have seen:

    1) The current version will not allow you to backup/restore between UNTRUSTED domains/networks. Apparently the next version will have a work around/fix for that.

    2) You will NOT get a Point-In-Time recovery option that is elegant. With DPM we can only restore to a 15-minute recovery point, but would not be able to restore to anything in-between those points.

    3) You will not get a transaction log backup file to archive. This means that we would not have any record of transactions that could be easily analyzed to see what happened in the database. (The Microsoft team we met with yesterday is going to get more clarification on that.

    As I said, I think it's a good tool...But...Not for everything in every environment. There are three factors that will push us not to want DPM on a database:

    1) If we need automated/frequent backup/restores across untrusted networks.

    2) If there is a business requirement to have a system recoverable to a point-in-time.

    3) If there is a security/regulartory need to have transaction log files for audit/security reasons.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply