We wondered about that too. But then we setup a desktop as a client/node and it backed up into the container just fine. IMHO, getting rid of the node and its backups was unnecessarily complicated but we finally deleted it and the directory/container.
On Thu, Sep 27, 2018 at 8:43 AM Stefan Folkerts <stefan.folke...@gmail.com> wrote: > 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/ > > > -- *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/
