× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



The data is really for archival purposes and would be for audit purposes
mainly. So we would only need to restore some objects every now and then.

To add a bit more detail the target system is the primary system of record
and the application has been migrated from an existing box with the old VTL
to the new target system with a different VTL. But the application is the
same and would be continuing to do the same nightly backups.

The existing system will be decommissioned but the VTL is still being used
by other applications in the data center which are part of the corporate
application base but not our one.

We might want to retrieve a backup of the database taken say 6 years ago to
review an account for audit purposes and we won't have access to the
original system where the application used to run because we've migrated to
this new host.

Therefore the BRMS data has to be able to contain the right backup
metadata given they all have the same name.

There is about 24 TB of data that has to be moved and it's international so
it's not entirely feasible to ship that across the wire. But it's really
not the transport of the data that's the issue, it's maintaining the
metadata across two VTLs.

That link looks interesting. I will pass it on to our local support vendor
to see if they can use the information.

Thanks



On Wed, Dec 15, 2021, 12:00 AM Jack Kingsley <iseriesflorida@xxxxxxxxx>
wrote:

What are yout eventually plans for the aged data, is most of it for
archival/audit purposes etc. Is this to suffice some sporadic need to
restore some objects every once in a while?? I would be careful based on if
the target system is the primary system of record. You don't mention how
large this data is either. Maybe this might help in your planning.

https://www.ibm.com/support/pages/merging-brms-data-target-system-existing-brms



On Mon, Dec 13, 2021 at 6:24 PM Laurence Chiu <lchiu7@xxxxxxxxx> wrote:

I have a large amount of data on an existing VTL (IBM ProtecTier) what I
want to dump off and move to a different IBMi system and import into
that
system's VTL and integrate with the BRMS catalogue information.

The existing backup all have the same names (same nightly database and
libraries being backed up) and easily identified in BRMS by time/date of
the backup.

Because of many network constraints we plan to dump the information to
tape
using (at the moment) the DUPMEDBRM command and just stream the backups
to
many tapes.

Once we get the tapes in the new location we would import them into the
new
VTL and ideally integrate them into the new BRMS. But what is not clear
to
us is how we can export the existing BRMS information and import that
into
the new one to retain all the metadata.

So for example if we wanted a backup for a file XXXXXX taken on 1/1/2016
then we only need to look for that backup taken on that date and BRMS
would
be able to locate the right backup in the VTL and restore it. Note to
make
clear, file XXXXXX would exist thousands of time in the backup database
since it is a nightly backup of the primary database taken over several
years worth of operations.

I have asked the vendor doing the work to provide some advice but so far
they have not been particularly helpful. Any ideas from experts in this
group would be appreciated.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.