We didn't do any kind of conversion since we don't have the free space. Everything is tied up in a 500TB ISILON/NFS space that is 92% full and nowhere to grow.
We created a container and the directory pointing to a 15TB internal disk space we had free. Create a new PS/Domain/MC pointing it to the container. Then we changed the MC of a Domain that is used for the DB backups from the production servers and started a new DB backups on one of the production servers. When that failed and we saw messages saying you couldn't use containers/directories for DB backup storage, we switch gears and took an MC for one of the small production servers/replicas and changed it to point to the container stgpool. We started a replication on that production server and again we saw all the incoming replica going to the nextstgpool and nothing in the container/directory That was when we tried a regular client and it worked. Maybe it is the ISP server level? Maybe it didn't like having some of the replicas in non-container pools? The lack of SSD's for DB is another reason we can't afford to use containers on production servers. Only 1-production server has 1.9TB SSD's and with replication and dedup it has quickly consumed 86% of it and we had to stop dedup. On Thu, Sep 27, 2018 at 1:56 PM Stefan Folkerts <stefan.folke...@gmail.com> wrote: > 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/ > > > -- *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/
