DPM 2010 SP1 - GFS approach? RRS feed

  • Question

  • Hello,

    I have a DPM 2010 SP1 server installed at a customer site, They have a 3-Node Hyper-V cluster and I have setup both bare-metal as well as SQL/File/Sharepoint/Hyper-V server backups with short term backup to iSCSI SAN storage. The retention time for all these jobs are 7 days. Now the customer wants a GFS (Grand Father Son) approach. With a Montly period apart from the 7 day retention period, they do not have a tape backup device attached to this DPM server. I was thinking about setting up a different iSCSI storage device to use for the GFS jobs as the space needed for this is not available in the current SAN storage. How do I best configure this approach ? 

    Thx /Tony
    Tuesday, August 23, 2011 2:43 PM

All replies

  • Thre are a coupld of options and some limitations that will impact how you achieve this.

    One option is to use a virtual tape device such as filestreamer for long term protection and to get your more traditional GFS backup approach. This will use a lot of space on disk as each 'virtual tape' will be the size of your data unless you use differentlal backups - which increases risk of data loss if one virtual tape file becomes corrupt.

    The other option is to introduce a secondary DPM server which will allow you to create retention of data with a different retention period (also a failover method of continued data protection if your primary DPM server fails)
    The drawbacks in this method are related to the regularity of the backup of data. For application data sets you need to follow a daily 'sync' schedule - but you could retain the data up to 448 days with a single daily recovery point (dependent on your rate of daily change and if you have enough disk space). The benefits are that you have over a years worth of daily disk based recovery available - nice selling point.
    For file data you can alter the 'sync' frequency and limit this to once weekly to obtain a retention period of up to 64 weeks of data (can someone at Microsoft provide the option to remove the 64 file snapshot limitation from DPM please).

    I don't know of any other way to achieve a traditional GFS style backup without starting to use other third party solutions.

    Hope this helps.


    Tuesday, August 30, 2011 7:09 AM
  • Hi Danny,

    Thanks for your reply.

    I have actually benn laborating with a trial of Firestreamer and it seems to do the job well.Do you have any experience of Firestreamer when it comes to stability and compatibility with DPM ? The level of support ?

    I have also looked into some External Tape Libraries, naturally the pinpoint with that option is to get backup tapes offsite...which is not an option with firesteamer as it´s fully virtual right ?

    And when counting the size needed to achieve GFS I´m a bit pussled, if say I now have a protection group for the fileshare which has a 7 day retention period and the details look like much space do you think will be needed for this Protection Group to get 30day retention ? I don´t fully understand the details of replica , recovery points etc. I mean what do I count as the space it has allocated for the current 7 day retention? And is it as easy as just count the 7days * 4 to achieve the 30day allocation ?

    The Status of the Protection Group

    The status of one of the protected shares within the Protection Group

    Thx /Tony
    Tuesday, August 30, 2011 7:35 AM
  • Firestreamer stores its data in virtual tape files, these would be transportable as a tape was - you'd just have to copy these to another location or store the server doing the firestreamer backups in an off-site location.

    The replica volume will be very similar in size to the size of data that you are protecting. So in the case of the protected share image your replica volume is the space allocated to DPM for your data size to grow to, in this caase about 211 GB - your actual data is about 156 GB. If you add or delete data to this share, this volume used will increase and decrease to match the data on your replica volume. When you create the volume for file data you can use the calculate option to more closely match this to the amount of data on the volume - from memory DPM adds a 25% overhoad for growth.

    The recovery point volume is essentially the amount of change data that takes place for that data source. This will change for every company and even for each data type (Exchange and SQL the ones to look out for, based on their daily log change). In this case DPM has allocated 200 GB of data for the recovery point volume and has used just over 3 GB for 25 recovery points. So to get a rough indication (because people in the company won't change data the same everyday and could go ahead and dump a 5GB disk image on the server which the recovery point volume would need to track), you can take the recovery point volume used, divide by the number of recovery points to get an average of change data per recovery point and multiply by the required number of recovery points - so something like 3.48/25*56 plus some overhead (if you want to maintain 56 recovery points for this data allowing a few recovery points for overhead). In this case I'd look at shrinking the recovery point volume if using DPM 2010 to allow you to use that space in the storage pool for other backup if required.

    Hope this explains it a little. Remember once you go to tape, either physical or virtual using firestreamer you are going to be back to traditional calcs for tape size

    Tuesday, August 30, 2011 10:05 PM