Thanks Rajiv, that makes sense when you explain it like that – the wording in the building blocks guide is a little unclear on that point.
Do you have any other tips on how to get a smooth migration from one MA to a new one? My concern is that the data on the existing 5 mount paths gets allocated evenly across the mount paths on the new library – we have a large (8tb or so) client where I’m especially concerned that with the initial aux copy we may end up with some of the mount paths being full and others being almost empty.
Paul
From: commvault < at > yahoogroups.com [mailto:commvault < at > yahoogroups.com]
On Behalf Of Rajiv Kottomtharayil
Sent: 15 January 2012 21:18
To: commvault < at > yahoogroups.com
Subject: Re: [commvault] Auxcopy & Dedupe Question (migrating MA's)
I would never take a working configuration and change it. If you are deploying a brand new Storage Policy, then yes do create a DDB per Application type ( eg 1 For Filesystem, 1 for Exchange DB, 1 for Oracle etc). Now you can point newer FS/ Exchange/Oracle Storage Policies to this Global DDB.
Global DDB has 2 use cases
1. Remote office solutions
2. You have many storage policies for similar application types due to varying retention criteria all going to similar set of MediaAgents
Global DDB is not meant to be
1. A large DDB for all you storage policies across application types
In your case, if you are happy with the way things are working, dont change it.
-Rajiv
On Jan 15, 2012, at 3:52 PM, Paul Hutchings wrote:
Hi Rajiv, thanks for the reply and info.
In the June 2011 building blocks white paper it says “A Global Deduplication Storage Policy (GDSP) should be used instead of a standard deduplication storage policy whenever possible.” which I took to mean that Commvault were now recommending a GDSP in place of multiple DDB’s - did I misunderstand what the guide meant?
In our situation we have a VMWare Storage Policy, a SP which contains our FS iDA’s and our Exchange iDA, and a couple of other small FS iDA Storage Policies – each primary copy has its own DDB.
Sounds like you’re suggesting to stick as we are now with one DDB per storage policy definined on the new copy similar to what we have now?
Thanks,
Paul
From: commvault < at > yahoogroups.com ([email]commvault < at > yahoogroups.com[/email]) [mailto:commvault < at > yahoogroups.com] ([email][mailto:commvault < at > yahoogroups.com][/email])
On Behalf Of Rajiv Kottomtharayil
Sent: 15 January 2012 15:27
To: commvault < at > yahoogroups.com ([email]commvault < at > yahoogroups.com[/email])
Subject: Re: [commvault] Auxcopy & Dedupe Question (migrating MA's)
Couple of questions
1. Why are you moving to a Global Dedupe Policy. Remember that overall scale of a single Dedupe policy is still limited. Global Dedupe policy is best used when you are planning to have multiple remote sites send data to a central data center and you want minimum data to flow over the WAN. If you create a single Dedupe policy across different application types, you will not see any benefit and infact cause harm with exploding the DDB quicker.
I strongly recommend 1 DDB per Application Type (which could be global in Nature). This means you get best Dedup ratio and scale is controlled.
Once you create a new Storage Policy, there will be a new baseline written and you should account for that in your storage planning.
Setting the Mountpath to Spill and Fill will distribute the data evenly. But more important set Randomization option on Storage ! Policy ( on by default for Disk Target). This ensures that data does not accumulate on a single stream and ensures that Auxcopy performance is optimal.
I would also recommend reaching out to our Account Team and talk to them on best practices on Dedup. Our documentation has this covered under Building Block
http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/features/dedup_disk/building_block.htm
Remember 1 single Global Dedup Policy is not a good idea. Split by Application Types. Applications dont dedup against each other anyway.
Rajiv
On Jan 15, 2012, at 7:06 AM, Paul Hutchings wrote:
I have a maglib with 5 mount paths, and I need to migrate the data to a new MA which will have more, smaller mount paths.
I'm also planning on moving to a global dedupe policy.
My understanding is that the correct way to migrate is to:
Create the global dedupe policy
Create a new aux copy which is associated with the global dedupe policy
This should result in all the data on the maglib, which is for the current primary copy, being copied to the new MA and being "re-deduplicated" using the global dedupe policy - is that correct?
Also my current mount paths are very large. On the new MA I intend having more (10-20) smaller (1tb or so) mount paths.
If the new MA is set to "spill and fill" will the existing source data be spread evenly across all of the mount paths on the new MA?
My current MA was originally setup to fill and spill so things aren't quite as balanced as I would like them - the hope is to be able to have all of the spindles in the new MA working for me rather than just a few that might have the backup data of our largest (8tb or so) iDA's on them.
Hopefully those questions make sense but I'm happy to clarify, and would be grateful for any suggestions or advice.
Thanks,
Paul
--
MIRA Ltd
Watling Street, Nuneaton, Warwickshire, CV10 0TU, England
Registered in England and Wales No. 402570
VAT Registration GB 100 1464 84
The contents of this e-mail are confidential and are solely for the use of the intended recipient. If you receive this e-mail in error, please delete it and notify us either by e-mail, telephone or fax. You should not copy, forward or otherwise disclose the content of the e-mail as this is prohibited.
***************************Legal Disclaimer***************************
"This communication may contain confidential and privileged material for the
sole use of the intended recipient. Any unauthorized review, use or distribution
by others is strictly prohibited. If you have received the message in error,
please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
__._,_.___
Reply to sender ([email]paul.hutchings < at > mira.co.uk?subject=RE%3A%20%5Bcommvault%5D%20Auxcopy%20%26%20Dedupe%20Question%20%28migrating%20MA%27s%29[/email]) | Reply to group ([email]commvault < at > yahoogroups.com?subject=RE%3A%20%5Bcommvault%5D%20Auxcopy%20%26%20Dedupe%20Question%20%28migrating%20MA%27s%29[/email]) |
Reply via web post |
Start a New Topic
Messages in this topic (5)
Recent Activity:
Visit Your Group
Commvault Documentation here:
http://documentation.commvault.com/
MARKETPLACE
[url=http://global.ard.yahoo.com/SIG=15odd9hoi/M=493064.14543979.14562481.13298430/D=groups/S=1707277520:MKP1/Y=YAHOO/EXP=1326723930/L=2dda9610-403d-11e1-9f23-4b4c5370f1d8/B=TGzlA9BDRy8-/J=1326716730387013/K=BH0dmZjIoXPx2lKNluqZ8g/A=6060255/R=0/SIG=1194m4keh/*http://us.toolbar.yahoo.com/?.cpdl=grpj]Stay on top of your group activity without leaving the page you're on - Get the Yahoo! Toolbar now.[/url] if(window.yzq_d==null)window.yzq_d=new Object(); window.yzq_d['TGzlA9BDRy8-']='&U=13c0fotun%2fN%3dTGzlA9BDRy8-%2fC%3d493064.14543979.14562481.13298430%2fD%3dMKP1%2fB%3d6060255%2fV%3d1'; [img]http://us.bc.yahoo.com/b?P=2dda9610-403d-11e1-9f23-4b4c5370f1d8&T=1ch1j9ilr%2fX%3d1326716730%2fE%3d1707277520%2fR%3dgroups%2fK%3d5%2fV%3d2.1%2fW%3dH%2fY%3dYAHOO%2fF%3d1604702412%2fH%3dY29udGVudD0iR287V2lkZ2V0cztQb2RjYXN0cztNb2JpbGU7RmxpY2tyO0dyb3VwcztBdWN0aW9ucztTbWFsbF9CdXNpbmVzcztCcmllZmNhc2U7RmluYW5jZTsiIGRpc2FibGVzaHVmZmxpbmc9IjEiIHNlcnZlSWQ9IjJkZGE5NjEwLTQwM2QtMTFlMS05ZjIzLTRiNGM1MzcwZjFkOCIgc2l0ZUlkPSI0NDUyNTUxIiB0U3RtcD0iMTMyNjcxNjczMDQzMTIyMyIg%2fQ%3d-1%2fS%3d1%2fJ%3d693E8962&U=13c0fotun%2fN%3dTGzlA9BDRy8-%2fC%3d493064.14543979.14562481.13298430%2fD%3dMKP1%2fB%3d6060255%2fV%3d1[/img]
Text-Only ([email]commvault-traditional < at > yahoogroups.com?subject=Change Delivery Format: Traditional[/email]), Daily Digest ([email]commvault-digest < at > yahoogroups.com?subject=Email Delivery: Digest[/email]) • Unsubscribe ([email]commvault-unsubscribe < at > yahoogroups.com?subject=Unsubscribe[/email]) •
Terms of Use
.
[img]http://geo.yahoo.com/serv?s=97359714/grpId=7450851/grpspId=1707277520/msgId=5436/stime=1326716730/nc1=4507179/nc2=4025321/nc3=4836037[/img]
__,_._,___
