Your Saturday routine is fine, but you can do a real GO SAVE/21 if you want. There is an option on the command to delay up to 24 hours so you can have someone on Friday submit the command to run on Saturday.
I would suggest for Mon-Thu you do a SAVSECDTA (very fast) and then break it up a little:
- Save while active of your production data libraries. As production data is what changes the most and is the most critical to restore, I prefer to back it up with a separate save command and do it before any other libraries.
- SAVCHGOBJ for everything else, omitting the data libraries. If you aren't comfortable with SAVCHGOBJ the go ahead & do a save while active for *ALLUSR and omit the production data libs you just saved.
- If you use DLOs, save those.
- If you use the IFS, save those directories.
Use save while active when possible. You may find you have zero downtime (just reduced performance) for the daily save.
For the Mon-Thu backups, specify UPDHST(*NO). That way each night's backup is a differential from the last full backup. A full system restore is thus the prior Saturday's 21 + the most recent daily.
You can also specify DTACPR(*MEDIUM) for data compression. *MEDIUM has negligible CPU impact but reduces the amount of data to be written to tape (and if your tape drive/interface is a bottle neck it may further improve performance). Further, if your tape media is high enough capacity you may be able to get more than one daily on a tape by appending.
As Rob noted, check to see if you are entitled to BRMS. It takes a little effort to learn but once done you get a lot of flexibility, media management, and that very useful recovery report.
Our backups are evolving but we've gone to monthly for the 21 saves as the OS & IBM stuff just does not change much. Then, depending on the environment we do a daily SAVSECDTA, save while active of the data libraries, and a differential save of everything else including the IFS as we use it a lot. We don't use DLOs.
We're actually going to take it a step further and take even more advantage of having MIMIX. For production partitions we'll do the monthly 21 followed by daily saves of the journal receivers only. The replica partition will get the differential save (and a monthly 21). Thus we will have uptime except for a few hours a month during the 21 save. Restoring from receivers is a pain but the odds of needing to do so in an HA environment are small; it's really more to recover from 'oops' situations that system recovery.
--
John A. Jones, CISSP
Sr. Analyst, Global Information Security
Jones Lang LaSalle, Inc.
Voice: +1.630-455.2787
FAX: +1.312.601.1782
Email: john.jones@xxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of JDHorn@xxxxxxxxxxxxxx
Sent: Wednesday, September 24, 2008 5:02 PM
To: midrange-l@xxxxxxxxxxxx
Subject: backup scenario
We are trying to increase our uptime window - especially monday-friday.
Does the following backup scenario seem complete?
saturday afternoon in restricted state run from the system console
(can't do an actual save21 because no one is in on saturday to put it
in)
savsys
save all *nonsys
save dlo
save remainder of ifs - chgperiod(*all) updhst(*yes)
mon-thu in an non-restricted state run from a jobscde.
savsysinf
savsecdta
savcfg
savlib *ibm
savlib *allusr
savdlo
save remainder of ifs - chgperiod(*lastsave) updhst(*no)
This would seem to create a 2 tape restore scenario (saturday and
yesterday).
is the savsysinf/savsecdta/savcfg/sav *ibm every day overkill?
Missing anything?
Thanks
Jim Horn
This email is intended only for the person or entity
to which it is addressed and may contain information
that is privileged, confidential or otherwise protected
from disclosure. If you are not the named addressee
or an employee or agent responsible for delivering
this message to the named addressee, you are not
authorized to read, print, retain copy, and disseminate
this message or any part of it. If you have received this
message in error please notify us immediately by email,
discard any paper copies and delete all electronic files
of this message.
This email is intended only for the person or entity
to which it is addressed and may contain information
that is privileged, confidential or otherwise protected
from disclosure. If you are not the named addressee
or an employee or agent responsible for delivering
this message to the named addressee, you are not
authorized to read, print, retain copy, and disseminate
this message or any part of it. If you have received this
message in error please notify us immediately by email,
discard any paper copies and delete all electronic files
of this 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.
This email is for the use of the intended recipient(s) only. If you have
received this email in error, please notify the sender immediately and then
delete it. If you are not the intended recipient, you must not keep, use,
disclose, copy or distribute this email without the author's prior
permission. We have taken precautions to minimize the risk of transmitting
software viruses, but we advise you to carry out your own virus checks on
any attachment to this message. We cannot accept liability for any loss
or damage caused by software viruses. The information contained in this
communication may be confidential and may be subject to the attorney-client
privilege. If you are the intended recipient and you do not wish to receive
similar electronic messages from us in the future then please respond to the
sender to this effect.
midrange.com
