locked
Item level restore moves whole database RRS feed

  • Question

  • Hello,

    We're currently in the process of migrating to SharePoint 2010 from MOSS 2007. For MOSS we used Avepoint as our backup solution, which works very well and is extremely straight forward to use. However for SharePoint 2010, from a pricing standpoint just alone, it makes more sense for us to start using DPM 2010, plus it get's high praise for it's ability to backup and restore SharePoint 2010. Which is what we've done, but we're not finding it as amazing as what we've been reading.

    Maybe we're missing something?

    At the moment there are two main things we're trying to use from DPM 2010 that's causing us the most grief, and it all relates to one thing. Whenever we want to restore anything, it could be a site to the tiniest of files, DPM wants to shift the whole database onto the server before picking out what you wanted to restore. Not only does this mean you have to wait for all the data to be copied across, but you also have to make sure you have the space available to have your database on the server twice!

    This is something that Avepoint managed to avoid somehow. Is this a simple case of DPM being a Microsoft product so has to keep strictly to best practices where Avepoint does not, or are we missing something?

    One thing that crossed my mind is that DPM 2010 has done away with the need for a recovery farm, and now does this on the fly. Is the saving on a recovery farm at the expense of fast recovery times?

     

    Tuesday, July 26, 2011 12:00 PM

Answers

  • In another post Guru described the process of the DPM item lvl restore.

    "SharePoint 2010 supports another way for granular restores called unattached recovery.  DPM 2010's item level recovery does the same when recovery farm is not used. Any content database can be attached to the farm without actually adding it to the farm. This way you can browse the items in this database and perform export and import operations of the items.  DPM does not create any new web application, instead the items in the database are present under central web application. The temporary database created during recovery will be deleted at the end of the recovery, and since it is not actually added to farm, there is no need to delete from the farm. So, you can perform item-level recoveries without recovery farm!"

    So yes you need to have free spaces, and perferably a secondary SQL instance to restore you databases to.

    But a quick read on the AAvepoint site, makes me belive that you could use their

    DocAve Recovery Manager for SharePoint to run the restore process, and safe your self a bunch of time... seems to be free of charge.

    but to your question.

    "Is the saving on a recovery farm at the expense of fast recovery times?"

    Well if you think about it, the effort and administration going into keeping the live and recovery farm completely alike, is time consuming and a pain like no other.  So I would go for yes DPM and longer recovery times is worth it on the long run, however if you have 3. party tool that can extract the data from the backups directly... I would go that way.

    Now as you have been made a victim of a coporate decision, and have to go with DPM I would look into the Docave recovery manager, and see if that could help you have disk space and time.

     

     


    Best regards Michael Thøgersen
    • Proposed as answer by mthoger Tuesday, July 26, 2011 12:52 PM
    • Marked as answer by Andrew France Tuesday, July 26, 2011 8:24 PM
    Tuesday, July 26, 2011 12:52 PM

All replies

  • There are so many factors involved here.  DPM provides the ability to recover anything on the fly while the environment is LIVE.  This means that users can still be updating content while you are restoring something.  That's a major improvement over past capabilities, but it takes some technical expense to get it done.  In order to avoid clashing with live user updates, DPM will clone the database and then allow you to pick out what needs to be restored.  That allows you free ability to tinker with that database without affecting end users in the live system.  Generally speaking, this shouldn't be a problem, but if you allowed your databases to grow out of control, then yes, you are going to have to ensure that you have lots of free space available on the SQL Server in order to get it done.

    My advice would be to ensure that your databases don't grow out of control.  Start here:  http://technet.microsoft.com/en-us/library/cc298801.aspx

     


    I trust that answers your question...

    Thanks
    C

    http://www.cjvandyk.com/blog | LinkedIn | Facebook | Twitter | Codeplex
    Tuesday, July 26, 2011 12:45 PM
    Answerer
  • In another post Guru described the process of the DPM item lvl restore.

    "SharePoint 2010 supports another way for granular restores called unattached recovery.  DPM 2010's item level recovery does the same when recovery farm is not used. Any content database can be attached to the farm without actually adding it to the farm. This way you can browse the items in this database and perform export and import operations of the items.  DPM does not create any new web application, instead the items in the database are present under central web application. The temporary database created during recovery will be deleted at the end of the recovery, and since it is not actually added to farm, there is no need to delete from the farm. So, you can perform item-level recoveries without recovery farm!"

    So yes you need to have free spaces, and perferably a secondary SQL instance to restore you databases to.

    But a quick read on the AAvepoint site, makes me belive that you could use their

    DocAve Recovery Manager for SharePoint to run the restore process, and safe your self a bunch of time... seems to be free of charge.

    but to your question.

    "Is the saving on a recovery farm at the expense of fast recovery times?"

    Well if you think about it, the effort and administration going into keeping the live and recovery farm completely alike, is time consuming and a pain like no other.  So I would go for yes DPM and longer recovery times is worth it on the long run, however if you have 3. party tool that can extract the data from the backups directly... I would go that way.

    Now as you have been made a victim of a coporate decision, and have to go with DPM I would look into the Docave recovery manager, and see if that could help you have disk space and time.

     

     


    Best regards Michael Thøgersen
    • Proposed as answer by mthoger Tuesday, July 26, 2011 12:52 PM
    • Marked as answer by Andrew France Tuesday, July 26, 2011 8:24 PM
    Tuesday, July 26, 2011 12:52 PM
  • Hi Cornelius,

    Many thanks for your reply. Your answer confirms what we already knew of DPM, and I guess what we're suffering from here is maybe DPM is still not up to pace with what we're used to from Avepoint.

    From what I've read DPM looks at SharePoint backup and recovery top down, taking importance for recovering your whole site over item level recovery. Where as it looks as though Avepoint take the reverse approach.

    Item level recovery in Avepoint takes minutes where as DPM 2010 can take over an hour. Now either AvePoint is using a highly unstable (possibly unsupported) approach to to inserting content back into a live SharePoint site without the need for a database clone, or DPM 2010 is just playing it very safe.

    I realise this is a Microsoft forum and I wouldn't expect anyone to comment on a third party product. But I guess what we're trying to weigh up here is although DPM 2010 is giant leap forward from 2007, does it even compare to AvePoint's ability to recover SharePoint content at a speed which you would expect in a production environment?

    Telling a user that they'll have to wait over an hour for a simple text file to be recovered? I'm not sure this is really acceptable. Which is why I wondered whether we're going about this the wrong way.

    That being said there's always the fact that DPM is a whole backup solution, and not dedicated to just SharePoint.

    Tuesday, July 26, 2011 1:13 PM
  • Hey Michael,

    That adds a nice alternative look at the situation we're faced with, and I will definitely take a look at DocAve.

    We always try to keep things Microsoft here. My fear for DPM 2010 with SharePoint is with all it's great new features is it scalable? We're looking at incorporating all our resources, currently on a fileshare server, into document libraries in SharePoint. If we were to solely rely on DPM as our backup solution we would need to keep 3TB of disk space free just for recovery. This sounds very wasteful to me.

    Thanks again,

    Andrew

    Tuesday, July 26, 2011 1:46 PM