Zoltan, Difficult to imagine working with tsm with such small disks.
You can mount any disk system, anywhere in your environment and declare as the filespaces, for containers, or for FILE systems. We have 100 TB mounted on a system, some 2 km away from the server for containers, and 1 TB for database backups. TSM is extremely flexible concerning containerdirs, or filespaces. Just make sure to share the disks, make sure that the user running the server has full read/write access on the remote system and go. Using a mini filesystem for this operation, copying and deleting, is asking for trouble IMHO. David. -----Original Message----- From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Zoltan Forray Sent: Monday, June 27, 2022 9:01 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] AW: [ADSM-L] AW: [ADSM-L] Moving archives into containers Since I did the RESET CONVERSION against the stgpool I "converted" to container, I assume there won't be any collisions if I use the same disk filesystem/mount as both FILE and CONTAINER since I only have 1-10GB internal disk storage available? On Mon, Jun 27, 2022 at 1:50 PM Uwe Schreiber <uwe.h.schrei...@t-online.de> wrote: > Hi Zoltan, > > DB Backup to Virtual Volumes ist not working with Container Pools. > You have to use sequential Tape or sequential File Volumes. > > Regards, Uwe > > -----Ursprüngliche Nachricht----- > Von: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> Im Auftrag von > Zoltan Forray > Gesendet: Montag, 27. Juni 2022 19:43 > An: ADSM-L@VM.MARIST.EDU > Betreff: Re: [ADSM-L] AW: [ADSM-L] Moving archives into containers > > Next question - how do you perform a DB Backup via Virtual Volume if > you can't use a container and have converted the only stgpool you have > to container? > > We have 2-test ISP servers - 1-physical and 1-VM. The VM test ISP > server performs DBBackups to the physical one. After I converted the > stgpool on the physical test ISP and updated the managementclass to > point to the container, now the VM test DBBackup fails with: > > 6/27/2022 1:25:02 PM ANR2776W Transaction failed for session 6688 for > node TSMTESTVM (Linux/x86_64) - A storage pool for the target > destination is associated with a container or cloud storage pool. > > Am I missing some setting required to do this or is this simply not > allowed? > > On Mon, Jun 27, 2022 at 10:43 AM Uwe Schreiber < > uwe.h.schrei...@t-online.de> > wrote: > > > HI Zoltan, > > > > yes, as soon as the "convert stgpool" is getting started, the ISP > > server prevents any further ingest of data in the source. > > Normally before a "convert stgpool" the management class is adjusted > > accordingly, so that the clients don't have to wait until the > > convert is done. > > The "reset convertion" will "open" the pool for further ingest of > > data (or another convert). > > > > Regards, Uwe > > > > > > -----Ursprüngliche Nachricht----- > > Von: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> Im Auftrag von > > Zoltan Forray > > Gesendet: Montag, 27. Juni 2022 16:05 > > An: ADSM-L@VM.MARIST.EDU > > Betreff: Re: [ADSM-L] Moving archives into containers > > > > Thanks for the details/info. So, performing the "*RESET CONVERSION*" > > makes the source stgpool accessible/reusable. At this point, I > > assume the source stgpool is empty? I am guessing IBM did this to > > prevent client backups from landing in the source stgpool until you > > have the chance to change the managementclass to point client > > backups to the directory-container stgpool? > > > > On Mon, Jun 27, 2022 at 9:10 AM MM <michael.mal...@mm-it.at> wrote: > > > > > Hallo Zoltan, > > > > > > more infos about the undocumented (and very useful) "*RESET > CONVERSION*" > > > cmd: > > > > > > After a successful conversion the *Access:* status > > > > > > (see: q stg <your_pool_name> f=d) will be shown as "*Converted*" > > > and you can NOT backup new data into that pool any more. > > > > > > *BUT*, if you say/enter *RESET CONVERSION" <your_pool_name>*, > > > > > > you change that *Access:* status to the original *Access:* status " > > > *Read/Write*" again. > > > > > > Thats all..... > > > > > > rgds and good look Michael M. > > > > > > Zoltan Forray <zfor...@vcu.edu> hat am 27.06.2022 13:47 geschrieben: > > > > > > > > > Thanks for the suggestions and I would like more info on the > > > undocumented "reset conversion" command and what it does. > > > > > > Unfortunately, since archives are <0.1% of total occupancy, we > > > didn't separate them from the backups that roll-off to tape. But > > > these suggestions do give me lots to go on. Again, thanks for the help! > > > > > > On Mon, Jun 27, 2022 at 2:43 AM Loon, Eric van (ITOP DI) - KLM < > > > eric-van.l...@klm.com> wrote: > > > > > > Hi David, > > > > > > Of course that can be an option too, but I suggested the filepool > > > in between because Zoltan only wanted to move the archives. > > > > > > Kind regards, > > > Eric van Loon > > > Core Infra > > > > > > -----Original Message----- > > > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of > > > David L.A. De Leeuw > > > Sent: zondag 26 juni 2022 09:55 > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: Re: Moving archives into containers > > > > > > Hi Eric and Zoltan > > > > > > Maybe I missed something. Why not directly convert stgpool from > > > the tape storage pool. > > > We did this a year ago, took with us the archives and backups > > > (Spectrum Protect doesn't care) and finished the convert in a few > > > weeks (using pretty slow equipment). > > > Why the manual work ? > > > > > > David de Leeuw > > > Medical Computing Unit > > > Ben-Gurion University of the Negev Beer Sheva Israel > > > > > > -----Original Message----- > > > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of > > > Loon, Eric van (ITOP DI) - KLM > > > Sent: Friday, June 24, 2022 6:22 PM > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: Re: [ADSM-L] Moving archives into containers > > > > > > Hi Zoltan, > > > > > > I think it's an undocumented command. It's not in the manuals, nor > > > in the help, but I have used in in the past, at least in earlier > > > 8.1 > > versions. > > > Since you're constrained on disk space, moving relatively small > > > amount of clients at once to your small filepool would be an option. > > > The convert will move the data to your container pool and the > > > reset command will allow you to move the next batch of clients to > > > your filepool. > > > I know, it's a lot of manual work, but I have moved all out > > > long-term archives from our old servers into our new > > > (container-based) servers this way. > > > > > > Kind regards, > > > Eric van Loon > > > Core Infra > > > > > > > > > -----Original Message----- > > > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of > > > Zoltan Forray > > > Sent: vrijdag 24 juni 2022 16:15 > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: Re: Moving archives into containers > > > > > > Hi Eric, > > > > > > Thanks for the recommendations. I always thought the conversion > > > process required the target to be empty. Unfortunately, we simply > > > do not have sufficient free disk space to perform complete > > > conversions to containers since everything existing stgpools are > > > either on NFS/ISILON (yes I know IBM says this is not-recommended) > > > or server > internal disk. > > > Right now I created my first directory/container pool since we had > > > a(nother) hard drive failure in our 5+ year old Powervault so we > > > took this opportunity to learn directory-containers and their > limitations. > > > > > > Not sure what you mean by "reset conversion command". I couldn't > > > find anything like that in the latest 8.1.14 manual? > > > > > > On Fri, Jun 24, 2022 at 9:20 AM Loon, Eric van (ITOP DI) - KLM < > > > eric-van.l...@klm.com> wrote: > > > > > > Hi Zoltan, > > > > > > What you could do is create a file device class and move the files > > > from tape to this file device class. As soon as the files are > > > there, you can use the convert stgpool command to move the data > > > into the directory container stgpool. > > > If you do this in batches, you don't need a very large filepool. > > > After emptying your filepool, you can use the reset conversion > > > command to make the filepool available for new data. > > > > > > Kind regards, > > > Eric van Loon > > > Air France/KLM > > > > > > -----Original Message----- > > > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of > > > Zoltan Forray > > > Sent: vrijdag 24 juni 2022 14:39 > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: Moving archives into containers > > > > > > We are currently in the midst of a big project to relocate our > > > datacenter, by the end of 2023, to a new, smaller building. > > > > > > At the same time, we are actively pursuing redesigning/replacing > > > our "Enterprise Data Protection" solution which may likely move us > > > completely away from Spectrum Protect. FWIW, this project started > > > before we were told we had to move out of our existing location. > > > > > > As an absolute minimum, we need to get everything off old magnetic > > > tape > > > (3592) that we need to retain beyond 2023 (archives), since the > > > new datacenter will not have the physical space to accommodate tapes. > > > > > > Now that we have upgraded all ISP servers to 8.1.14.100/eFix 102, > > > we have started playing with directory-containers, since there is > > > now support for "protecting" containers to magnetic tape (for > > > offsite > > > > > > backups). > > > > > > > > > > With the additional directory-container support/tools, we were > > > wondering if there is a way to get backups/archives into a > > > directory-container stgpool other than during ingestion from a client? > > > > > > If we do move away from Spectrum Protect, is the only way to > > > retain long-term archives is to recover them to the original > > > platform/server and then move them to whatever long-term storage > platform we choose (i.e. > > > object, cloud)? > > > > > > -- > > > *Zoltan Forray* > > > Backup & VMware Systems Administrator Enterprise Compute & Storage > > > Platforms VCU Infrastructure 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/ > > > <https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url > > > =h > > > tt > > > ps%3a%2f%2fadminmicro2.questionpro.com&umid=1CBA4B97-E233-2405-850 > > > A- > > > A3 > > > 4E51B31D92&auth=701951cf8dfb7cd99762e0f5be252082d875f1cf-9ffb57bc3 > > > 70 > > > 88 > > > ff312b2517c52a2ea9888470669> > > > ******************************************************** > > > For information, services and offers, please visit our web site: > > > http://www.klm.com. This e-mail and any attachment may contain > > > confidential and privileged material intended for the addressee only. > > > If you are not the addressee, you are notified that no part of the > > > e-mail or any attachment may be disclosed, copied or distributed, > > > and that any other action related to this e-mail or attachment is > > > strictly prohibited, and may be unlawful. If you have received > > > this e-mail by error, please notify the sender immediately by > > > return e-mail, and delete > > > > > > this message. > > > > > > > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > > and/or its employees shall not be liable for the incorrect or > > > incomplete transmission of this e-mail or any attachments, nor > > > responsible for any > > > > > > delay in receipt. > > > > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > > Dutch > > > Airlines) is registered in Amstelveen, The Netherlands, with > > > registered number 33014286 > > > ******************************************************** > > > > > > > > > > > > -- > > > *Zoltan Forray* > > > Backup & VMware Systems Administrator Enterprise Compute & Storage > > > Platforms VCU Infrastructure 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/ < > > > > > > https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url= > > > ht > > > tp > > > s%3a%2f%2fadminmicro2.questionpro.com&umid=1CBA4B97-E233-2405-850A > > > -A > > > 34 > > > E51B31D92&auth=701951cf8dfb7cd99762e0f5be252082d875f1cf-9ffb57bc37 > > > 08 > > > 8f > > > f312b2517c52a2ea9888470669 > > > > > > > ******************************************************** > > > For information, services and offers, please visit our web site: > > > http://www.klm.com. This e-mail and any attachment may contain > > > confidential and privileged material intended for the addressee only. > > > If you are not the addressee, you are notified that no part of the > > > e-mail or any attachment may be disclosed, copied or distributed, > > > and that any other action related to this e-mail or attachment is > > > strictly prohibited, and may be unlawful. If you have received > > > this e-mail by error, please notify the sender immediately by > > > return e-mail, and delete this message. > > > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > > and/or its employees shall not be liable for the incorrect or > > > incomplete transmission of this e-mail or any attachments, nor > > > responsible for any delay in receipt. > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > > Dutch > > > Airlines) is registered in Amstelveen, The Netherlands, with > > > registered number 33014286 > > > ******************************************************** > > > ******************************************************** > > > For information, services and offers, please visit our web site: > > > http://www.klm.com. This e-mail and any attachment may contain > > > confidential and privileged material intended for the addressee only. > > > If you are not the addressee, you are notified that no part of the > > > e-mail or any attachment may be disclosed, copied or distributed, > > > and that any other action related to this e-mail or attachment is > > > strictly prohibited, and may be unlawful. If you have received > > > this e-mail by error, please notify the sender immediately by > > > return e-mail, and delete this message. > > > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > > and/or its employees shall not be liable for the incorrect or > > > incomplete transmission of this e-mail or any attachments, nor > > > responsible for any delay in receipt. > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > > Dutch > > > Airlines) is registered in Amstelveen, The Netherlands, with > > > registered number 33014286 > > > ******************************************************** > > > > > > > > > > > > -- > > > *Zoltan Forray* > > > Backup & VMware Systems Administrator Enterprise Compute & Storage > > > Platforms VCU Infrastructure 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/ <https://adminmicro2.questionpro.com> > > > > > > > > > > -- > > *Zoltan Forray* > > Backup & VMware Systems Administrator Enterprise Compute & Storage > > Platforms VCU Infrastructure 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/ <https://adminmicro2.questionpro.com> > > > > > -- > *Zoltan Forray* > Backup & VMware Systems Administrator > Enterprise Compute & Storage Platforms VCU Infrastructure 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/ <https://adminmicro2.questionpro.com> > -- *Zoltan Forray* Backup & VMware Systems Administrator Enterprise Compute & Storage Platforms VCU Infrastructure 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/ <https://adminmicro2.questionpro.com>
