Hi Sergio,
my first server started at 6.1 so it was all server side dedup. I have not let
any
of its clients do client side. The separation based on maxsize is working as
designed.
My 2nd server started at 6.3 and I do use client side. The clients do not
react well
when a file bigger than the maxsize needs to be backed up. It gets backed up
but the client
does not reset for subsequent files which are under the maxsize. I have
adjusted to this
but making nextpools for the unlimited pool which recreate the maxsize
separation during migration
of the unlimited maxsize pool. Here is a script output of the storagepools in
one of
the newer servers -
Name Numscr DevicePoolSzGb PctUtil Migpr Next
MaxSz
- - --
BKP_1A28 DD_L1 2094.6 5.1 4 BKP_2
1.00
BKP_1B6DD_L1 2003.0 0.8 4 BKP_2
1.00
BKP_2 405 DD_L2 46062.9 52.3 1 BKP_3
1.00
BKP_3 8NDD_L3 22279.4 1.5 1 BKP_3A
BKP_3A0DD_L2 0.0 0.0 1
BKP_3B 1.00
BKP_3B121 NDD_L3 29347.5 25.2 1 BKP_4
BKP_4 0LTO5A 0.0 0.0 1
BKP_3 is unlimited but when it migrates the files separate into bkp_3a with a
maxsize of 1 GB and
bkp_3b which is unlimited. The reclaim target pool for bkp_3a is bkp_2, so
that gets all the files
I intended to dedup back together.
I reported the issue to IBM and I think it will be fixed in 6.3.5; I don't know
if it is
in 7.1, but it should be.
Copypools go to virtual volumes hosted by a small server with a small tape
library.
Since the volumes are never marked off-site, reclamation doesn't recreate the
unexpired
files from the dedup'ed primary pools. And I wouldn't want this anyway. The
point
of the deduprequiresbackup server parameter is to have a version of the file in
its
original never-ripped-apart state. I have developed a process to reclaim the
copypool
volumes in time order because they are really stored on racked tapes. The
reclaim command
would jump all over the range of volumes causing constant requests for tapes to
be entered.
I don't actually do a reclaim process, instead I issue move data commands in
the order
that the volumes were created.
Thanks,
- bill
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Sergio
O. Fuentes
Sent: Friday, November 15, 2013 12:15 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: TSM Dedup stgpool target
Bill,
Thanks for info. Just curious, are you utilizing source-side dedupe or
relying on the TSM identify to identify all your duplicates
(post-process)? How does the maxsize parameter interact with source-side
dedup? I'll have to look that up.
Eventually you have to reclaim your copy pools and based on your
hierarchies, it looks like reclamation would be feeding off from the large
4TB drives. Have you had issues reclaiming from those pools?
Thanks!
Sergio
