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?
Comments 6 Comments • Jump to latest comment
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.
Regards.
Randey
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.
Regards.
Randey
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?
There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."
Here are some changes in BE 2012 -
In 2012, Opt-Dupe is available for GRT sets.
New stream handler for Hyper-v.
Regards.
Randey
Would you like to reply?
Login or Register to post your comment.