Very strange, I can only say that I have done this sequence at least 5 times. First, you upgrade/migrate the replication target to the containerpool, then the source. I've never had any issues with data not landing in the pool so I really expect there was some anomaly happening there or a misconfiguration of sorts.
For me the containerpool has been one of the biggest improvement on Spectrum Protect on the server side since replication was introduced and I can only think of Virtual Environments for VMware multi-session restores being more important that the containerpool for my customers. As long as your using SSD's for the database (I think that's as good as a must-have) and have the compute power/memory to run the pools they are really worth the effort of looking at again because I'm sure you can do what you want, you can use the containerpool as a replication target from other pools on other servers running replication-compatible versions of Spectrum Protect. On Thu, Sep 27, 2018 at 4:27 PM Zoltan Forray <zfor...@vcu.edu> wrote: > 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/ >
