Well,  if you run out of space,  options nearly always were to move data to 
LTO, now options are to buy an expansion to an existing storage array, which 
cost slightly more than lto.  

-----Original Message-----
From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Zoltan Forray
Sent: Tuesday, September 18, 2018 10:33 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [External] Re: [ADSM-L] CONTAINER pool experiences

Thanks for the tip.  Should not be an issue for us since this will be on the 
Replication Target server only - for now.....

On Tue, Sep 18, 2018 at 10:14 AM Solomon Miler <smi...@jri-america.com>
wrote:

> Dedup containers do not support  'migrate / export / move node '.    The
> only way to get rid of data :  expire / delete node.
>
> We are on 8.1.1.0
>
>
> Solomon Miler
> Senior Data Protection Engineer, VP
> --------------------------------------
> Desk: 201.577.313
> Cell  :  917.287.2332
> smi...@jri-america.com
>
>
>
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of 
> Golbin, Mikhail
> Sent: Tuesday, September 18, 2018 9:50 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: [External] Re: [ADSM-L] CONTAINER pool experiences
>
> Container pools work but you don't have defrag functionality until 
> 8.1.4 - which means it does not release the space it no longer uses.
> Also you don't get much if any benefit from dedup if you commingle 2 
> or more container pools into one on the replica.
> For example you have 2 servers doing backups, storing data in 
> container pools and both replicating to one offsite server.
> Each container pool is about 20Tb and there is a lot of overlap - the 
> storage pool usage on the offsite will be close to 40Tb, rather than 
> 25Tb that it would have been if dedup worked properly
>
> On Tue, Sep 18, 2018 at 9:37 AM Zoltan Forray <zfor...@vcu.edu> wrote:
>
> > We are investigating using CONTAINER pools for our offsite replica 
> > server vs the current FILE method which is killing us with the 
> > constant dedup, reclaims, etc.
> >
> > So, what are the "gotchas' ?   We are still at V7.1.7.400 so I figure we
> > will have to do without any new features added in the V8 branch. But 
> > is it problematic enough at V7 to avoid it?
> >
> > Your thoughts?  Experiences?
> >
> > --
> > *Zoltan Forray*
> > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator 
> > Xymon Monitor Administrator VMware Administrator Virginia 
> > Commonwealth University UCC/Office of Technology Services 
> > www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing 
> > victim - VCU and other reputable organizations will never use email 
> > to request that you reply with your password, social security number 
> > or confidential personal information. For more details visit 
> > http://phishing.vcu.edu/
> >
> >
>
> --
> Mikhail Golbin
> bus (908)635-5705
> cell (908)210-3393
> RMD IT Client Services
>
> *******************************************************************
>
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they 
> are addressed. If you have received this email in error please notify 
> the sender by replying to this email and then delete it from your 
> system.
>
> No reliance may be placed upon this email without written confirmation 
> of its contents and any liability arising from such reliance without 
> written confirmation is hereby excluded.
>
> JRI America
>
> *******************************************************************
>
>

--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor 
Administrator VMware Administrator Virginia Commonwealth University UCC/Office 
of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be 
a phishing victim - VCU and other reputable organizations will never use email 
to request that you reply with your password, social security number or 
confidential personal information. For more details visit 
http://phishing.vcu.edu/

Reply via email to