Is anyone doing stgpool backups to a dedup file copy pool? At 02:23 PM 12/20/2013, Marouf, Nick wrote: >I can second that Sergio, > Backup stgpools to copy tapes is not pretty, and is an intensive process to > rehydrate all that data. > >The one extra thing I did was split the database across multiple folder for >parallel I/O to the Database. That has worked out very well, and I currently >have it setup to span across 8 folders, with an XIV backend that can take a >beating. > > >-----Original Message----- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of >Sergio O. Fuentes >Sent: Friday, December 20, 2013 12:04 PM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] Deduplication "number of chunks waiting in queue" >continues to rise? > >Client-side dedup and simultaneous-write to a copy pool are mutually >exclusive. You can't do both, which is the only theoretical way to enforce >deduprequiresbackup with client-side dedup. I suppose IBM could enhance TSM >to do a simultaneous-like operation with client-side dedup, but that's not >available now. So, I'm not sure how the TSM server enforces >deduprequiresbackup with client-side dedup. Ever since 6.1 I have always set >that to NO anyway. I have dealt with the repercussions of that as well. >Backup stgpool on dedup'd stgpools is not pretty. > >I have made some architectural changes to the underlying stgpools and the >'backup stgpools' run pretty well, even with 1TB SATA drives. Two things I >think helped quite a bit: > >1. Use big predefined volumes. My new volumes are 50GB. >2. Use many filesystems for the devclass. I have 5 currently. I would use >more if I had the space. > >Thanks! > >Sergio > > >On 12/20/13 11:35 AM, "Prather, Wanda" <wanda.prat...@icfi.com> wrote: > >>Woo hoo! >>That's great news. >>Will open a ticket and escalate. >> >>Also looking at client-side dedup, but I have to do some architectural >>planning, as all the data is coming from one client, the TSM VE data >>mover, which is a vm. >> >>Re client-side dedup, do you know if there is any cooperation between >>the client-side dedup and deduprequiresbackup on the server end? >>I have assumed that the client-side dedup would not offer that protection. >> >>W >> >>-----Original Message----- >>From: Sergio O. Fuentes [mailto:sfuen...@umd.edu] >>Sent: Friday, December 20, 2013 10:39 AM >>To: ADSM: Dist Stor Manager >>Cc: Prather, Wanda >>Subject: Re: [ADSM-L] Deduplication "number of chunks waiting in queue" >>continues to rise? >> >>Wanda, >> >>In trying to troubleshoot an unrelated performance PMR, IBM provided me >>with an e-fix for the dedupdel bottleneck that it sounds like you're >>experiencing. They obviously will want to do their due-diligence on >>whether or not this efix will help solve your problems, but it has >>proved very useful in my environment. They even had to compile a >>solaris e-fix for me, cause it seems like I'm the only one running TSM >>on Solaris. The e-fix was very simple to install. >> >>What you don't want to do is go to 6.3.4.2, unless they tell you to >>because the e-fix is for that level (207). Don't run on 6.3.4.2 for >>even a minute. Only install it to get to the e-fix level. >> >>Dedupdel gets populated by anything that deletes data from the stgpool, >>I.e. move data, expire inv, delete filespace, move nodedata, etc. >> >>We run client-side dedupe (which works pretty well, except when you run >>into performance issues on the server) and so our identifies don't run >>very long, if at all. It might save you time to run client-side dedupe. >> >>BTW, when I finally got this efix and TSM was able to catch-up with the >>deletes and reclaims as it needed to, I got some serious space space >>back in my TDP Dedup pool. It went from 90% util to 60% util (with >>about 10TB of total capacity). What finally really got me before the >>fix was that I had to delete a bunch of old TDP MSSQL filespaces and it >>just took forever for TSM to catch up. I have a few deletes to do now, >>and I'm a bit wary because I don't want to hose my server again. >> >>I would escalate with IBM support and have them supply you the e-fix. >>6.3.4.3 I don't think is slated for release any time within the next >>few days, and you'll just be struggling to deal with the performance issue. >> >>HTH, >>Sergio >> >> >> >>On 12/19/13 11:35 PM, "Prather, Wanda" <wanda.prat...@icfi.com> wrote: >> >>>TSM 6.3.4.00 on Win2K8 >>>Perhaps some of you that have dealt with the dedup "chunking" problem >>>can enlighten me. >>>TSM/VE backs up to a dedup file pool, about 4 TB of changed blocks per >>>day >>> >>>I currently have more than 2 TB (yep, terabytes) of volumes in that >>>file pool that will not reclaim. >>>We were told by support that when you do: >>> >>>SHOW DEDUPDELETEINFO >>>That the "number of chunks waiting in queue" has to go to zero for >>>those volumes to reclaim. >>> >>>(I know that there is a fix at 6.3.4.200 to improve the chunking >>>process, but that has been APARed, and waiting on 6.3.4.300.) >>> >>>I have shut down IDENTIFY DUPLICATES and reclamation for this pool. >>>There are no clients writing into the pool, we have redirected backups >>>to a non-dedup pool for now to try and get this cleared up. >>>There is no client-side dedup here, only server side. >>>I've also set deduprequiresbackup to NO for now, although I hate doing >>>that, to make sure that doesn't' interfere with the reclaim process. >>> >>>But SHOW DEDUPDELETEINFO shows that the "number of chunks waiting in >>>queue" is *still* increasing. >>>So, WHAT is putting stuff on that dedup delete queue? >>>And how do I ever gain ground? >>> >>>W >>> >>> >>> >>>**Please note new office phone: >>>Wanda Prather | Senior Technical Specialist | >>>wanda.prat...@icfi.com >>>| www.icfi.com >>>ICF International | 443-718-4900 (o) >> >>
-- Paul Zarnowski Ph: 607-255-4757 Manager of Storage Services Fx: 607-255-8521 IT at Cornell / Infrastructure Em: p...@cornell.edu 719 Rhodes Hall, Ithaca, NY 14853-3801