AW: Disaster Recovery - how good are your plans?

Hello,

well, there _is_ a big difference between a well planned migration/upgrade
and a disaster recovery. In about
12 years of AS400 we have gone through several (B60-D60-320-620-820)
hardware upgrades (not even mentioning
release updates). So we have learned how to plan such an upgrade - but we
still always had problems during these
upgrades (Murphy at his best). Failing 3590 in the middle of the upgrade or
a faulty console cable..

Anyhow, you also have to consider resources. Had our disaster happened 3
weeks ago, we would have had a real 
problem, as 3 of 5 AS400 people had been on vacation.

We run several application packages (finance, production and distribution).
We do seperate backups by application,
so we can run night-processing on app A while saving data from app B (but
all backups go to the same tape).
We did a complete restore in tape sequence.

But we now plan to restore by application (i.e. first completely restore
distribution- that's most important). I guess we
could have been a day faster for only restoring distribution (which is our
bread-and-butter business).
But this needs careful planning as it is a lot more complicated than doing a
simple SAVE 21.

Regards,

Oliver

> -----Ursprüngliche Nachricht-----
> Von:  Henrik Krebs [SMTP:hkrebs@hkrebs.dk]
> Gesendet am:  Montag, 13. August 2001 09:43
> An:   midrange-l@midrange.com
> Betreff:      Re: Disaster Recovery - how good are your plans?
> 
> I've never done a _disaster_ recovery  (knock knock), but that very
> fact once led the auditor to demand a full scale test. It was way back
> on an model B35, so the exact timing has no interest any longer.
> Beeing unable to get a spare AS/400 to do the test on, I was forced to
> initialize all disks and do it on the production machine. Not that I
> was very motivated! I trusted the backup and found no reason to waste
> time testing (X-ref of save times vs modifications and testing a
> restore of different objects was done all the time). But I _did_ learn
> something from the test and changed my backup: We did not save access
> paths (neither before nor after the test), so even with a slow tape
> there were waiting time. What I learned was, that a careful planning
> of the save sequence and a well prepared plan for the restore sequence
> was essential in order to be 'up and running' with the key systems
> much earlier.
> 
> At the test I could release the key systems for users after about 80%
> of the restore time has passed.
> 
> After adding a field 'sequence' to the backup table and redoing the
> recovery instruction my estimate was that the users could start using
> a slow but running system after maybe 60% of the time. This difference
> might mean one whole production day! Review the object sizes and the
> files's RECOVER() parameter,
> 
> So option 21 on 'GO SAVE' is far from optimal. Review the object sizes
> and the files's RECOVER() parameter, differentiate the save commands
> taking the restore in consideration, split objects in libraries
> depending of where and when used etc.
> 
> Henrik
> http://hkrebs.dk
> 
> 
> --------------------------------
> 
> From: oliver.wenzel@cibavision.novartis.com
> To: MIDRANGE-L@midrange.com
> Subject: Disaster Recovery - how good are your plans?
> Date: Sun, 12 Aug 2001 13:03:59 +0200
> Reply-To: midrange-l@midrange.com
> 
> Hello,
> 
> as I'm sitting here waiting for the PTFs to install I'm wondering how
> good
> everybody's disaster recovery plans are?
> 
> We had to do a complete system reload on monday due to the crash of a
> mirrored disk pair. The call to IBM went
> out on monday morning 7am and were finished with the reload on
> wednesday
> morning 2am.
> 
> Have you ever had to do a complete reload? How did it go? What kind of
> backup do you do? Journalling?
> 
> We were very lucky that the crash happened on a sunday evening. Friday
> night
> backup had gone well and no jobs
> were running on the weekend (except some reorgs). So we had a clean
> database...
> 
> Good luck
> 
> Oliver
> 
> 
> 
> 
> _______________________________________________
> This is Midrange Systems Technical Discussion (MIDRANGE-L)
> 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