× 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.



Apparently TAPVRT01 is not support via NFS, just optical only. Is this
only doable then for PTF's and or like .ISO's.


On Fri, Apr 5, 2013 at 9:57 AM, Jack Kingsley <iseriesflorida@xxxxxxxxx>wrote:

ok.


On Fri, Apr 5, 2013 at 9:51 AM, <rob@xxxxxxxxx> wrote:

There is no 'restore'. I don't ftp a save file of my virtual tape image
catalogs. I ftp the image catalog entries directly.

Object . . . . . . : /vrtclg/VRT001
Size of object data in bytes . . . . . : 29780029601
Allocated size of object . . . . . . . : 29787947008
Takes about 41 minutes to do the save to virtual tape. It's all stream
files being saved, no qsys.lib type stuff.
Takes about 1 hour and 20 minutes to ftp the data.
Takes 23 minutes to dupe the tape from image catalog to physical media.

If I combined the save and the transmission by using NFS instead of doing
the transmission offline I can guarantee that the outage of what I backup
will increase from the 45 minutes. Unless you can guarantee that NFS will
be faster than my local disk drives.
Size % %
Unit Type (M) Used Busy
1 4327 52923 62.8 1
2 4327 52923 62.8 1
3 4327 52923 62.8 1
4 4327 52923 62.8 1
5 4327 70564 62.8 1
6 4327 70564 62.8 1

Keep in mind, that modern tape drives may actually be faster than saving
to disk. You're talking about utilizing two different busses, etc. The
tape drive has one user at a time using it versus disk having multiple
users (system tasks, etc) all sending the disk arms all over the place.

We did not do it to save time. We did it to do a remote backup, get the
'tape' over here and then we send it off to Iron Mountain. Please, no
offers to sell me VTL devices at this time.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Jack Kingsley <iseriesflorida@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 04/05/2013 09:22 AM
Subject: Re: NFS and remote image catalogs/saves ?
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Rob, yes, that is what I would like to know. If it adds an hour to the
save would that be worth it to maybe forgo what you do today with it being
local and then FTP'd. Then what does it on the restore side as well.


On Fri, Apr 5, 2013 at 9:14 AM, <rob@xxxxxxxxx> wrote:

We save to local virtual tape image catalogs. Then we ftp them to
another
system. Then we dupe them to tape. And actually BRMS keeps track of
which physical tape has a save of which particular object on the source
system.
We've not tried NFS. Actually I'm pretty new at NFS. I am using it now
on a few lpars and it gets the job done.

The question becomes, does it slow down the actual save? If so, is it
significant enough to justify more local disk to speed up the process?
We
bring up the services denied during the actual save, after the save is
done but before we start ftping the data over. So our outage window
does
not include the transfer time.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Jack Kingsley <iseriesflorida@xxxxxxxxx>
To: Midrange Systems Technical Discussion <MIDRANGE-L@xxxxxxxxxxxx
,
Date: 04/05/2013 08:49 AM
Subject: NFS and remote image catalogs/saves ?
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Has anyone did much with this, is it to slow. I am looking to use this
for
daily saves. I know that 6.1.1 is a requirement on both sides.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.