Zoltan,

That is very strange, I've used the containerpool as a replication target
for filepools before with replication in place and this works fine.
It's does not work the other way around, you can't replicate a
containerpool to a filepool.
I would almost say that there was a mistake made, maybe no real storage
connected to the pool or something else that went wrong because what you
described should work.

Regards,
    Stefan


On Thu, Sep 27, 2018 at 2:35 PM Zoltan Forray <zfor...@vcu.edu> wrote:

> Stefan,
>
> Thank you for the reply. You said *"but for backup data on disk I think
> nothing beats it, maybe even in any product I've ever used."*
>
> Unfortunately, due to the overhead/requirements/demands (as other replies
> have pointed out) we can NOT use it for client/node backups since none of
> our current production ISP servers have the CPU/storage (most are 32-thread
> and NFS/ISILON storage)
>
> What we wanted to use it for was on our offsite replication TARGET server
> (which has 64-threads and 256GB RAM),  which is used primarily for
> replication of data from our onsite ISP servers as well as offsite database
> backups for the onsite ISP servers (devclass server).  When we
> tested/created a small directory/container area on internal disk on this
> server, any management class we pointed to it was rejected and the incoming
> replicas/DB backups were redirected to the NEXTSTGPOOL which was a normal,
> devclass FILE storagepool.
>
> Perhaps next year when we replace one of our local ISP servers with a much
> bigger/beefier (72-threads and 120TB internal disk storage).
>
> On Wed, Sep 26, 2018 at 6:17 AM Stefan Folkerts <stefan.folke...@gmail.com
> >
> wrote:
>
> > Zoltan,
> >
> > I'm not sure I understand your issues, we use directory containerpools
> for
> > all but a few of our Spectrum Protect customers and it's miles ahead of
> > what the fileclass-based storagepool bring in terms of performance,
> > Spectrum Protect database impact (size wise). Yes, it isn't capable of
> > certain, until then standard Spectrum Protect storagepool functions but
> for
> > backup data on disk I think nothing beats it, maybe even in any product
> > I've ever used.
> >
> > Of course you can't write Spectrum Protect database backups to it, it
> > doesn't even have a device class and it's most certainly not sequential
> in
> > any way but normal database backups are very much able to land in the
> > directory containerpool and you will enjoy enormous deduplication and
> > compression benefits, much higher net savings then when using the
> filepool
> > at any customer site I've implemented it.
> >
> > So, could you please explain what you are trying to do that doesn't work?
> >
> > Regards,
> >    Stefan
> >
> >
> > On Mon, Sep 24, 2018 at 3:49 PM Zoltan Forray <zfor...@vcu.edu> wrote:
> >
> > > Thanks for all the comments/suggestions and a somewhat consensus to
> avoid
> > > directory/containers.
> > >
> > > We decided to at least get our "feet wet" and play with
> > > directory/containers on our offsite replica-target server (which has
> the
> > > horsepower) only to realize everything we tried to use it for was
> > > not-allowed (DB backups from production servers and replication target
> > > storage pools) and everything we directed to it was redirected to the
> > "next
> > > stgpool"?
> > >
> > > So we are confused - what can you use directory/containers for at the
> > > 7.1.7.400 server level?  Only real client backups?
> > >
> > >
> > >
> > > On Tue, Sep 18, 2018 at 11:40 AM PAC Brion Arnaud <
> > > arnaud.br...@panalpina.com> wrote:
> > >
> > > > Zoltan,
> > > >
> > > > If I understood well, your storage is Isilon based : in this case do
> > not
> > > > even think of using CONTAINER pools, as performance will be horrible.
> > > > Not much time to talk about this, but to make a very long story
> short,
> > we
> > > > are about to dump/trash /resell the brand new Isilon arrays we bought
> > 8
> > > > months ago, and to replace them with direct attached storage
> > (Storwize),
> > > as
> > > > we never reached sufficient performance levels. Cases have been
> opened
> > > with
> > > > IBM and EMC as well, to no result at all, beside a suspected block
> size
> > > > issue which would refrain the Isilons to work at expected speed.
> > > > If you plan to go for such a hardware configuration, my only advice
> is
> > :
> > > > run away, as fast as you can !
> > > >
> > > > Cheers.
> > > >
> > > > Arnaud
> > > >
> > > > -----Original Message-----
> > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On
> Behalf
> > Of
> > > > Zoltan Forray
> > > > Sent: Tuesday, September 18, 2018 3:37 PM
> > > > To: ADSM-L@VM.MARIST.EDU
> > > > Subject: CONTAINER pool experiences
> > > >
> > > > 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/
> > > >
> > >
> > >
> > > --
> > > *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/
> > >
> >
>
>
> --
> *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