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



Hi Larry and Rob

thanks for the suggestions.

I am thinking that the only way to make the vSCSI shared drive approach
work would be to have a drive with an auto loader (obviously), but that
means the backups to any given drive would have to be done sequentially.

Fiber via a switch sounds like the rolls royce approach, but pretty handy
to have a handle on that scenario.

Have you by chance played with saving a library or two to virtual tape then
transferring that to another partition to be written to tape (I seem to
remember Rob doing this) ? How does BRMS track this kind of operation ?

My thinking here is that I may be able to save a set of libraries during
the week to virtual tape then do a more complete save on the weekends. The
LPARS I am dealing with are primarily devoted to QA/Dev and Test, so there
may be a case for a limited backup during the week.

Thanks for the responses so far.


On Thu, Aug 1, 2013 at 11:51 PM, DrFranken <midrange@xxxxxxxxxxxx> wrote:

So you have the simple (Carl) and the more complicated but automated
(Rob) to pick from or be somewhere in between.

BRMS is the right answer for this environment especially since you
already have and are using it. I believe that the library with multiple
drives is also the correct answer because as Rob mentioned you can have
extra tapes in there for holidays and partitions that might start
overrunning one tape.

Having the library connected with fiber via a switch is also in your
best interest because the drives are then connected to all partitions
all the time. If you connect directly to the fiber cards or use SAS
attached tape now you need to do DLPAR to move the tapes around. This
introduces another whole set of challenges.

If the LPARs are truly small then you could hook the tape drives to the
host partition and share them through vSCSI connections to the clients.
Each could have their own or could share drives. You only need to vary
off the drives when not in use. Issue here is that the clients only see
a 'Drive' not a 'Library' so BRMS will be somewhat handcuffed.


- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 7/31/2013 2:55 PM, Evan Harris wrote:

Hi All


just wondered how people were approaching the challenge of backing up
multiple guest LPARs when hosted on i.

I have a scenario where there are a few i on i partitions using BRMS as a
backup solution with a couple of single tape drives. I'm currently
exploring what options there are for backup were there more partitions,
say
6 to 8 on the same machine. Clearly having multiple single tape drives
becomes "challenging", especially as BRMS won't append tapes saved on
another system.

One option is to get an autoloading drive and share it round (none of the
partitions are huge), another would be to get a library with a number of
drives.Virtual tape might even be an option though I've struggled to see
how this would solve any problems other than timing issues at the expese
of
addign more storage.

I'm curious as to what others are doing and what drawbacks/advantages
they
believe go with the approach they are using.

Any comments or advice welcome.

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

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.