|
Hi, re savchgobj: I'll have a full backup on sunday and daily savchg. If I loose the system on saturday I'll need 6 different tapes to do the reload, right? What happens if one of the daily tapes is damaged? As Murphy says, it sure will be the monday tape... Oliver > -----Ursprüngliche Nachricht----- > Von: R. Bruce Hoffman, Jr. [SMTP:rbruceh@attglobal.net] > Gesendet am: Mittwoch, 22. August 2001 17:28 > An: midrange-l@midrange.com > Betreff: 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 > > "America is the land that fought for freedom and then > began passing laws to get rid of it." > > - Alfred E. Neuman > > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com
As an Amazon Associate we earn from qualifying purchases.
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.