Call me paranoid! (was RE: APYJRNCHG)

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I proudly wear the "paranoid" tag!  If I had the window, I would do a
Save-21 every night!  Just think, in this scenario, I would have to rely
on only last night's backup in case of a total system restore, as
opposed to a SAVSYS & SAVLIB *IBM that occurred how many moons ago?  Are
you sure that these were done after the most recent PTF was installed?
Are you *sure*?  Even if you were sure, how old of a backup would you be
comfortable with?  Tape media has its lifetime limits.  If your most
recent SAVSYS & SAVLIB *IBM is two years old, would you be willing to
bet your job that it would be just as restorable as one created in the
past three months?  To those of you who haven't done a SAVSYS & SAVLIB
*IBM in the past six months, do you know where that tape is?  Yes,
"paranoid" is my middle name!

Why not do SAVSECDTA & SAVCFG every night?  Their cost is so negligible
in terms of amounts of time and tape media, it seems silly not to do
this every night.

>Sure, just so long as you understand that if you don't isolate the
journals
>off site, a site loss leaves you with just the tapes sitting in the
trunk of
>your car or whereever your offsite storage takes place.

Yes, I understand that this approach doesn't necessarily cover us in the
event of a site loss.  A site loss is a situation we're trying gain
understanding as to how it would affect our branches.  If a tornado
blows through and destroys the whole complex, we're not going to be
concerned about the inventory files.  But what about shipping and
billing information?  Has that information been relayed back to the
mainframe yet?  Obviously, one size does NOT fit all.

>>...  In other words, does the SAVCHGOBJ function handle
>>deleted objects as a "change"?
>
>No. The object is there from the full backup. SAVCHGOBJ saves any
>object, in its entirety, if it has changed at all, since the reference
data
>on the SAVCHGOBJ command, which defaults to the last full save.
>
>I can not currently think of a reason that someone should be
>uncomfortable with the SAVCHGOBJ command. ...

Well, it appears that you confirmed exactly the reason why someone
*should* be uncomfortable using the SAVCHGOBJ command as part of a
save/restore strategy.  In some environments, there could be huge
implications of files being restored from the SAVLIB but not deleted by
the restore mechanism of the SAVCHGOBJ.

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com

> -----Original Message-----
> From: R. Bruce Hoffman, Jr. [SMTP:rbruceh@attglobal.net]
> Sent: Wednesday, August 22, 2001 11:28 AM
> To:   midrange-l@midrange.com
> Subject:      Re: APYJRNCHG
>
> -----Original Message-----
> From: Bale, Dan <D.Bale@handleman.com>
> To: midrange-l@midrange.com <midrange-l@midrange.com>
> Date: Wednesday, August 22, 2001 11:07 AM
> Subject: RE: APYJRNCHG
>
>
> >We do not use SAVCHGOBJ.  I have never been comfortable with the
> >concept.  As such, I have made it a point to always to do as much of
> a
> >backup on a daily basis as possible in a given environment.  Each
> night,
> >SAVCFG, SAVSECDTA, SAVLIB *ALLUSR, SAVLIB *IBM, SAVDLO *ALL, and SAV
> >(with recommended omits).  I know I have been fortunate to have
> worked
> >in environments that give me the luxury to not have to resort to
> using
> >SAVCHGOBJ.  I have a SAVSYS backup that gets redone everytime we do
> >PTFs, or after an upgrade, or, as is mostly the case in our current
> >environment, at least once every 3 months.
>
> Ahh, the paranoid backup... ;-)
>
> Most of the shops that I work in now have auto config on and an
> ethernet or
> token ring line. Very little else in the way of configs and the
> configs very
> rarely change. If you have the window, fine. If you can't deal with a
> restore that requires you to use multiple tape sets, fine. But most
> don't
> really need the SAVCFG every night.
>
> The SAVSECDTA depends on your environment, but some smaller shops
> don't need
> this every night either.
>
> SAVLI B *ALLUSR is ok, but again, unless you are changing software or
> putting up PTFs constantly, SAVLIB *IBM is probably overkill.
>
> >
> >In our current environment, we are not journaling our production
> files.
> >We do not have the horsepower nor the DASD to support it.  Ideally, I
> >would like to add a new ASP to each of our production boxes that
> would
> >be dedicated to the journaling function.  If the primary ASP fails in
> >such a way that we have to restore everything from scratch, I'd
> restore
> >from tape, then apply journaled changes to get back to the point of
> >failure.
> >
> >Does that sound like a reasonable approach?  I know I'm short on
> >details, and I'll definitely have to read up on the subject if/when
> that
> >opportunity arises, but it seems to me that this is viable.
>
>
> Sure, just so long as you understand that if you don't isolate the
> journals
> off site, a site loss leaves you with just the tapes sitting in the
> trunk of
> your car or whereever your offsite storage takes place.
>
> >
> >Oh, the reason I am uncomfortable with SAVCHGOBJ.  (I'm sure someone
> was
> >going to ask <g>)  Can anyone tell me what happens when you do a
> >complete library save (SAVLIB) on Sunday night, delete a file from
> that
> >library on Monday, do a SAVCHGOBJ on that library on Monday night,
> have
> >the system crash on Tuesday, necessitating a restore of the SAVLIB
> from
> >Sunday night, and a restore of the SAVCHGOBJ  from Monday night?
> Will
> >the file deleted on Monday be in the library after the SAVCHGOBJ is
> >restored?  In other words, does the SAVCHGOBJ function handle deleted
> >objects as a "change"?
>
>
> No. The object is there from the full backup. SAVCHGOBJ saves any
> object, in
> its entirety, if it has changed at all, since the reference data on
> the
> SAVCHGOBJ command, which defaults to the last full save.
>
> I can not currently think of a reason that someone should be
> uncomfortable
> with the SAVCHGOBJ command. As in my previous example, it might not be
> a
> significant savings based on your environment and the volume of data
> vs the
> "touched" objects. In other words, I have seen situations where a
> SAVCHGOBJ
> still takes the same number of tape volumes and almost the same amount
> of
> time as doing a SAVLIB *ALLUSR.
>
>
> ===========================================================
> R. Bruce Hoffman, Jr.
>  -- IBM Certified Specialist - AS/400 Administrator
>  -- IBM Certified Specialist - RPG IV Developer