Yeah, I do it regularly, at least once a week. We also have a replication server, but I like the security of having them on tape too. I usually run the reclamation after the backup is done.
Martha On 10/22/2014 12:29 PM, Prather, Wanda wrote:
Hi Martha! Has the storage pool been backed up to a copy pool? If the DEDUPREQUIRESBACKUP option is set to YES (default), reclaim can't happen until the BACKUP STGPOOL is done. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Michael Roesch Sent: Wednesday, October 22, 2014 12:08 PM To: [email protected] Subject: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe Hi Martha, have you run "query content" on some of the volumes to see, if they are really empty? Michael On Wed, Oct 22, 2014 at 5:47 PM, Martha M McConaghy < [email protected]> wrote:We just installed TSM 7.1 during the summer and have been working on migrating our backups over from our old v5.5 system. We are using deduplication for our main storage pool and it seems to work great. However, I'm concerned about how it is using the "volumes" in the storage pool. Since we never ran v6, I don't know if this is "normal" or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on the list and see if any of you have some insight. Our dedupe storage pool is dev class FILE, of course. It is set up to acquire new scratch "volumes" as it needs over time. Originally, I had the max scratch vols allowed at 999, which seemed reasonable. After about a month, though, we hit that max and I had to keep raising it. When I query the volumes belonging to this pool, I see many, many of them in full status, with pct util=0: Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status ------------------------ ----------- ---------- --------- ----- -------- /data0/00000B55.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000B8F.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000BCF.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000BD6.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000C16.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000C2A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000C63.BFS DEDUPEPOOL FILE 49.9 G 100.0 Full /data0/00000C72.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000C79.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000C84.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000C8C.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000C93.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000C9A.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000CA1.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full /data0/00000CB3.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full Literally, hundreds of them. I run reclamations, but these volumes never get touched nor reclaimed. Seems to me that they should. I've gone over the admin guide several times, but have found nothing touching on this. We just applied the 7.1.1.0 updates, but that has not helped either. If I do a move data on each, they will disappear. However, more will return to take their place. Anyone seen this before, or have any suggestions? Martha -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
-- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601
