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=htt
> > ps%3a%2f%2fadminmicro2.questionpro.com&umid=1CBA4B97-E233-2405-850A-A3
> > 4E51B31D92&auth=701951cf8dfb7cd99762e0f5be252082d875f1cf-9ffb57bc37088
> > 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=https%3a%2f%2fadminmicro2.questionpro.com&umid=1CBA4B97-E233-2405-850A-A34E51B31D92&auth=701951cf8dfb7cd99762e0f5be252082d875f1cf-9ffb57bc37088ff312b2517c52a2ea9888470669
> >
> ********************************************************
> 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>

Reply via email to