Hi,
I am not sure if I understand the question. First backup -> Full Backup and only few duplicate chunks are identified by dedup process. Second Backup -> Full as well. But the identify process "mark" a lot of duplicate chunks. Then, expiration process removes the entries in the DB. Finally the reclamation process will remove the chunks deduplicated. Regards, Fran ________________________________ De: "Prather, Wanda" <[email protected]> Para: [email protected] Enviado: martes 22 de noviembre de 2011 5:40 Asunto: Stupid question about TSM server-side dedup Have a customer would like to go all disk backups using TSM dedup. This would be a benefit to them in several respects, not the least in having the ability to replicate to another TSM server using the features in 6.3. The customer has a requirement to keep their NDMP dumps 6 months. (I know that's not desirable, but the backup group has no choice in the matter right now, it's imposed by a higher level of management.) The NDMP dumps come via TCP/IP into a regular TSM sequential filepool. They should dedup like crazy, but client-side dedup is not an option (as there is no client). So here's the question. NDMP backups come into the filepool and identify duplicates is running. But because of those long retention times, all the volumes in the filepool are FULL, but 0% reclaimable, and they will continue to be that way for 6 months, as no dumps will expire until then. Since the dedup occurs as part of reclaim, and the volumes won't reclaim -how do we "prime the pump" and get this data to dedup? Should we do a few MOVE DATAs to get the volumes partially empty? Wanda Prather | Senior Technical Specialist | [email protected]<mailto:[email protected]> | www.icf.com<http://www.icf.com> ICF International | 401 E. Pratt St, Suite 2214, Baltimore, MD 21202 | 410.539.1135 (o) Connect with us on social media<http://www.icfi.com/social>
