Forum Discussion

CGLTD's avatar
CGLTD
Level 2
14 years ago

Backing up Exchange 2010 and SQL 2008 R2 using Deduplication

We are thinking of utilizing Backup Exec 2010 R3 Deduplication Option and CASO in our backup strategy. We would backup to the Dedup folder locally then perform an optimized duplication to a managed media server dedup folder at another location. There is a 50Mb dedicated connection between the two sites. Can anyone answer the following questions:

1. Does deduplication treat the Exchange Info Stores and SQL DBs like single large files or does backup exec look inside these for deduplication?

2. If I run full daily backups of Exchange (100GB) and SQL (50GB) to the dedup folder, will this data get deduped?

3. If so, When the optimized duplication job runs, will just the deduplicated Exchange and SQL data be sent to the other site? 

4. Do Exchange Incremental and Differential backups benefit from deduplication? In what ways?

5. If I currently use B2Ds for my backup destination, would it be recommended to stop using them and point all backup jobs to the Deduplication folder? Why?

  •  

    Dedup just stores the backup in a different way.  Up to the point when the data is ready to be written to the media, everything is the same whether it is to the dedup folder, B2D folder or tape.  Dedup does not do any other special processing like looking into portions of the data.  You can duplicate a backup that is stored on tape or in a B2D folder to a dedup folder and the result would be the same as if the backup that created the data targets the B2D folder.  You can safely switch your job from targeting a B2D folder to a dedup folder.
     
    All backups, whether fulls, incr/diff, can be deduped.  The benefit is reduced data storage.  The only question is whether it gets a good dedup ratio.  See the document below, in particular the section on expectations
     
    http://www.symantec.com/docs/TECH142668
     
    For BE 2010 and GRT backups, like Exchange, the optimised dedup apparently does not work so well.  The data is hydrated first and then deduped into the other dedup folder, thus increasing the time as well as the amount of data transfered.  This is supposed to be corrected in BE 2012.  For non-GRT backups, only the changed data blocks are transfered over to the other dedup folder.
     
     
     
     
  • 1. Does deduplication treat the Exchange Info Stores and SQL DBs like single large files or does backup exec look inside these for deduplication?

    Single large file.

    2. If I run full daily backups of Exchange (100GB) and SQL (50GB) to the dedup folder, will this data get deduped?

    Yes.

    3. If so, When the optimized duplication job runs, will just the deduplicated Exchange and SQL data be sent to the other site? 

    If Exchange is using GRT, NO.

    SQL, Yes.

    4. Do Exchange Incremental and Differential backups benefit from deduplication? In what ways?

    Log backups  have new data in them, which means new hashes. The dedupe rate is fairly low.

    5. If I currently use B2Ds for my backup destination, would it be recommended to stop using them and point all backup jobs to the Deduplication folder? Why?

    Switch them over in stages.

    Start with the most common data sets first, then move to more unique data, like Exchange and SQL.

     

    Side note, be sure to save yourself some headache and make the Central Admin Server your target for you opt-dupe jobs.

  • Dedupe for Vmware and file server has been great.  Dedupe for Exchange and SQL has been less than stellar in my experience for deduplication.  e.g. very low dedupe rates.  I wonder if there is an application streamer yet for those apps, perhaps in 2012?

     

  • Here are some changes in BE 2012 -

    In 2012, Opt-Dupe is available for GRT sets.

    New stream handler for Hyper-v.

  • thanks for your response

    why do you recommend using caso as trget for opt-dup?

  • In most DR scenario's, the recover time is expected to be minimal.

    Setting up the CASO at the DR center allows the server to perform all its management duties, receive and hold catalogs, as well as receive and store opt-dupe data.

    Should a disaster occur, the central admin server can perform restores from the opt-dupe data/catalogs received from an crashed MMS without having to reconfigure the backup server to function, post disaster.