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




IMO, the important thing about save and restore on 'i' is that it actually
works! It may seem more complex at face value, but once you've made the
effort to implement it, it truly does work. We (including the Windows guy
here) just DO NOT have the same level of faith for our save restore of our
Windows oriented items.... no where near the same level of faith. The
only Windows oriented restores we're 100% confident with are our IXS hosted
Windows servers.




"Ingvaldson,
Scott"
<SIngvaldson@guid To
eone.com> "Midrange Systems Technical
Sent by: Discussion"
midrange-l-bounce <midrange-l@xxxxxxxxxxxx>
s@xxxxxxxxxxxx cc

Subject
06/07/2007 09:57 RE: Backup strategy
AM


Please respond to
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>






Hi Lukas -

Please take this in the spirit that it's intended, perhaps it's not IBM
that's lazy in this case. :)

We've been running SWA backups for around ten years here, both natively
and using BRMS and done numerous DR restores without issue. The parts
of the system that require restricted state backups are small and rarely
change. We have 15 minutes of daily downtime to quiesce the system and
reach the SWA checkpoint and 30 minutes once a month for the SAVSYS.

Your "complicated" restore process should be: STRRCYBRM OPTION(*SYSTEM)
ACTION(*RESTORE)

There are lots of resources here that can help you, and there's no
reason that your DR process should not be straightforward and
uncomplicated.

Regards,

Scott Ingvaldson
System i Administrator
GuideOne Mutual Insurance Company

P.S. For comparison:

Model 810, 4 GB main storage, Domino and a Linux guest partition
System ASP . . . . . . : 226.6 G
% system ASP used . . : 69.0969 <-- I Swear I didn't make this up!
Total . . . . . . . . : 1355 G
Current unprotect used : 11096 M
Maximum unprotect . . : 26126 M


-----Original Message-----
From: Lukas Beeler [mailto:l.beeler@xxxxxxxxxxx]
Sent: Thursday, June 07, 2007 6:56 AM
To: Midrange Systems Technical Discussion
Subject: RE: Backup strategy

BRMS console was a nasty hack that required manual interaction with the
system - thus, completely unusable for deployment. With V5R4, BRMS can
finally do all the stuff on it's own.

Quote:
However, you must start the console monitoring function on the system
console prior to leaving the machine to operate in unattended mode.

SWA is, for all intents and purposes, unusable - it has complicated
requirements for restores and also doesn't work correctly with legacy
programs that are not transaction safe. Thus, SWA is not an option (at
least for us).

And hey, Windows can do all this without any downtime, and without any
special configuration or waiting for V5R4. IBM is just lazy.

-----Original Message-----
From: midrange-l-bounces+l.beeler=dataline.ch@xxxxxxxxxxxx
[mailto:midrange-l-bounces+l.beeler=dataline.ch@xxxxxxxxxxxx] On Behalf
Of Pete Massiello
Sent: Thursday, June 07, 2007 12:30 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Backup strategy

You have been able to do unattended backups for some time using BRMS and
the console mode, you don't need to be at V5R4. I have one of my
clients set up, where we go into Console mode, and they then leave.
There is a job on the standard job scheduler that submits, and then BRMS
does a full system save.

Since when does *ALLUSR need to be in restricted state? I have been
using that for 17 years, and it does not require a restricted state.
It's for that reason that I like using both *ALLUSR and *IBM as neither
will require a restricted state. *NONSYS requires a restricted state.

In addition, you can use Save While Active. I have accounts where we
are backing up using BRMS, Save While Active, almost 1.6 TB of data each
night, and we have very LITTLE downtime.

Pete

Pete Massiello
iTech Solutions
http://www.itechsol.com

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Lukas Beeler
Sent: Thursday, June 07, 2007 1:12 AM
To: Midrange Systems Technical Discussion
Subject: RE: Backup strategy

We're using BRMS to handle our saves to a tape library.

Currently, we save the complete IFS, and *ALLUSR libraries every night
(yes, that means restricted state - so it's also V5R4 only).

Every Sunday, we do an automatic unattended save 21 equivalent using
BRMS (only possible on V5R4). After that the System IPLs.

Yes, this methodology brings a lot of downtime with it, and i would like
to do all my backups online - but's currently not possible with i5/OS.

SWA seems to be something done _really_ halfway, as it is a giant hassle
to restore and get to work. Gotta love Windows's Shadow Copy Backups.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx on behalf of as400
Sent: Thu 07.06.2007 06:52
To: midrange-l@xxxxxxxxxxxx
Subject: Backup strategy

We're currently reviewing our backup strategy.
What I would be interested to hear is how other shops handle the QUSRSYS
library.

- Do you back it up as part of your nightly saves?
- If not, how often do you back it up?
- How do you back it up?
(e.g. SAVE21 only, SWA, or shutting down everything holding locks
within it, then SAVLIB)?

Somewhat related: Job Q1PSCH (PM/400 scheduler) is holding a lock within
QUSRSYS. Is there an easy way to stop/start this job for backup
purposes?

Thanks,
Moe

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



-----------------------------------------


DISCLAIMER:
This message and accompanying documents are covered by the
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, and
contains information intended for the specified individual(s) only.
This information is confidential. If you are not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
document in error and that any review, dissemination, copying, or
the taking of any action based on the contents of this information
is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail, and delete the
original message.

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