MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » November 2012

Re: Backing up guest partitions



fixed

No I was referring to a restore of a guest saved by an option 21 to a
standalone server.

On Wed, Nov 28, 2012 at 8:28 AM, <rob@xxxxxxxxx> wrote:
So, you're saying that a RST of the server storage space on a new system
would be a waste of time?
Rather curious, I have some unload/reload's coming...


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: Evan Harris <auctionitis@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 11/27/2012 02:26 PM
Subject: Re: Backing up guest partitions
Sent by: midrange-l-bounces@xxxxxxxxxxxx



You would rebuild via the "Recover your server to a different system"
instructions I would think.

On Wed, Nov 28, 2012 at 7:30 AM, <rob@xxxxxxxxx> wrote:
1: We have production systems with guested partitions. Back when we
were
running iSeries we did the dedicated controlling lpar but not on i on
Power.

2: Is the SRM able to be restored on to a different system, or, does
that
not matter on a guested lpar? Kind of handled by a traditional restore
when it asks you if you are restoring to a different system.


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: Evan Harris <auctionitis@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 11/27/2012 01:17 PM
Subject: Re: Backing up guest partitions
Sent by: midrange-l-bounces@xxxxxxxxxxxx



You make a couple of good points.

I actually have two distinct situations I am thinking about:
- A Hostingg partition that has no purpose other than to host some
guest partitions
- A production host partition hosting a dev partition

I've also been considering whether to factor in the possibility that
I might in the case of a disaster want to restore my guest to a
different system entirely. I think this is unlikely but at this stage
I am keeping it in mind. Most likely I will write the DR plan to
exclude such a possibility.

Restoring the storage spaces in their entirety means some time is lost
restoring libraries I know that I will overwrite. Of course their is a
considerable saving in time and complexity of the recovery process so
this may well be worth it.


On Tue, Nov 27, 2012 at 7:02 AM, <rob@xxxxxxxxx> wrote:
Currently we have the time, and our guest partitions are not all that
significant, to do a full system save, including all, on both the
guests
and the host. Interesting idea though. I might mull that over.

In the case of catastrophe I would think recovering the guested system
as
a storage space would negate the need to to a restore of the guest.
And,
would be faster, and more inclusive. Why more inclusive? Well, your
BRMS
information, last save date (as updated by the full system save of the
guest), /tmp type stuff used by save/restore, etc would be included.
The
only additional stuff would be any guest saves done between the full
system save of the host and the damage to the object(s) you are trying
to
restore.
And a simple RST of the guested space on the host is MUCH easier than
the
step-by-step recovery from the full system save of the guest.

A save of the guest does allow for granularity of restore. For
example,
restoring one library to make a test library.

What is the rule of thumb of backup planning? Plan for how you'd
complete
your restore. The fastest COMPLETE restore of a guested lpar is by a
RST
of the storage space. (unless your host is also hosted, and backed up,
by
VIOS [of which I don't know scat]).

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: Evan Harris <auctionitis@xxxxxxxxx>
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>,
Date: 11/26/2012 12:33 PM
Subject: Backing up guest partitions
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Hi All

I have been considering the various options for backing up guest
partitions and wondered what other people do.

In my case I am considering backing up the individual hosted
partitions using a quarterly option 21 and a backup strategy tailored
to the use of each guest. I further plan to back up the host
periodically, or as the host changes to capture the full system
configuration. My current thinking is to have a full outage every 6
months. On one backup I will back up up everything, guest storage
(/QPFNWSSTG) included. On the other backup I am thinking of simply
backing up the host and the server descriptions but excluding the
/QPFNWSSTG directory to save time; I am still thinking this through. I
am trying to get to a situation where I can recover a system either
with the hosts intact, or with the hosts to be recovered separately or
not at all.

In the instance where I backup up the guests with individual backup
regimes I am trying to get a balance between preserving the guest
configuration on the host but at the same time avoiding having to save
and restore the network storage spaces when I will (potentially) be
overwriting the bulk of the storage during the guest recovery process.

While considering this I also wondered if while doing a full system
save the guest would remain operational if I took the option not to
end all servers. I'm not in a position to easily test this so I
wondered if they could remain operational. I'm starting to to think
this might be OK.

So what do others do ? What strategies do you have for backing up
hosting and hosted and hosted partitions ? What recover plans are your
backup strategies supporting ?

--

Regards
Evan Harris
--
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.




--

Regards
Evan Harris
--
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.




--

Regards
Evan Harris
--
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.









Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact