Disaster Recovery

Welcome to LawsonTalk. We hope you enjoy your visit.

You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free. After registration, please check your e-mail within 24 hours for an message from us, read it, and reply to it.

Join our community!

If you're already a member please log in to your account to access all of our features:

Disaster Recovery; Procedures for Disaster Recovery
Topic Started: Jan 26 2010, 11:11 AM (537 Views)
Lawsonite	Jan 26 2010, 11:11 AM Post #1
Advanced Member Posts: 42 Group: Members Member #4,726 Joined: February 15, 2008	We use 9.0.1 (Apps & Env), Aix based, Oracle 10g, Websphere is the middleware, Adam for Ldap; we use most suites from Lawson. We need to set up a disaster recovery process for Lawson apps(in a different time zone). We need to copy our primary architecture and duplicate them in the new data center. Will a simple copy suffice to bring the app up? Are there licensing considerations? Any restrictions about what needs to be installed(& not copied) i.e. cobol, websphere, java, registries, 3rd party products, Ldap pieces etc., Any thoughts/ideas on this is greatly appreciated.



area51	Jan 26 2010, 02:41 PM Post #2
Super Member Posts: 162 Group: Members Member #1,399 Joined: May 2, 2007	This is something I've been thinking about also since we upgraded a few months ago. I wanted to create something in case we needed to recreate Lawson from scratch and what we would need. I don't have it all put together but I started on some of the back scripts. 9.0.0.x env and apps, Solaris, Oracle, Websphere, Tivoli, we have most of the suites for Lawson also. A) Oracle databases: - We are 24/7 shop so it's hard to do cold backups. I've begged and pleaded to develop a HA redundant system but they never wanted to spend money on it. - So for backups I have automated daily database dumps of: Lawson schema, Gen, logan, BSI, and MSCM. Lawson runs the longest at about 2.5 hrs since this is the biggest database. - These are all saved to tape and two another system nightly. B) Lawson: - Current directories, i.e. law, gen, etc are all saved to tape nightly and on another system. - Things I need to automate: sysdump, proddmpmenus, tar all the appropriate directories for the product line(s), secdump, jobdump c) Tivoli and db2 - I currently have a script for both database dump and cold backup, unfortunately I run into the same into the same issue with the cold backups; so just dumps right now. - Directories are backed up to tape. d) Websphere - Still trying to figure out just what needs to be backed up for a rebuild. - Directories are backed up to tape. Any help with websphere would be nice, and if I missed anything else. If you have system that you are copying to then you just need to make sure that the prereq's are all setup (I have pretty everything at same version level), i.e. cobol, java, bouncy, websphere, oracle, lawson environment, etc. There is whole new fancy copy system that I just cannot figure out so this what I do when I copy over to test: 1) Backup of the test system. Seems redundant but believe me people have asked for old programs. - Sysdump of the test system. Cause you know, dev's never tell you what they are working on then one day, whamo, they need something back. - Tar (or backup however) directories of the product line. - Export data using Oracle utilities, either datapump or exp. I would generally do it just for the schema and exclude constraints, grants, and indexes. 2) Delete test product line - dbdef -- select product line and delete it oracle schema. delete gen info, BUT I don't delete the directories because sometimes we have made specific changes for somethings on the test server. 2.a)verify everything is gone from the oracle database. 3) Sysdump of production product line. Copy over to TEST. 4) tar (backup) of production product line. Copy over to TEST. 5) Copy database over to test. Wait, wait, wait, wait, wait, wait, wa :lala: 6) Sysload production sysdump file to TEST product line. 7) Run dbdef on TEST product line and hook it back up to the oracle database. 8) blddbdict and either dbreorg, or dbcreate. 9) Drop indexes via bldoraddl10 for TEST. 10) Import data using the Oracle dump copied over. 11) While number 10 is going on copy over production src, lib, Admin, metdata, backup to the TEST product line directory. 12) When #10 is done rebuild the indexes. I run two scripts at a time for this. 13) Cobcmp the product line to rebuild all the programs. I think there is a faster way to do this with timestamping but I never learned it properly. 14) Take secdump of production system and run secload to the TEST product line. 15) Reimport menus if need be also. Websphere: - If servlet's need to updated then I just go through the typical procedure. I never delete them as it is a :wwf: to reinstall them. That's all I can think of right now.



schroncd	Jan 27 2010, 11:52 AM Post #3
Lawson Technorati Posts: 689 Group: Members Member #13 Joined: January 11, 2006	There are a 100 different ways to setup a Lawson LSF9 DR - and a 1000 questions that must be asked and answered for each of them. The simplest DR system is for a monolithic system.. Turn OFF the original machine, do a mksysb (assuming AIX) on the DR system, change the IP address, change DNS to point to the new machine, them recover everything from tape. I've set up several of these for clients and they work flawlessly - but you CANNOT keep the original machine online in this scenario. I've a client who required the DR machine be online at the same time as the production server.. The DR instructions ran 50 pages - I don't recommend it..



3monkeys	Jan 27 2010, 12:35 PM Post #4
Super Member Posts: 168 Group: Members Member #240 Joined: January 13, 2006	We've done similar to what Dave describes - pretty much bringing up lawson on a leased server at a 3rd party site. We limited our test recovery to only bringing up a LID session so people could at least get to the data and do what they absolutely needed to. We didn't try for Websphere and Portal - it was too new to us at the time. Maybe next test. You could have both the production and DR servers up at the same time, if and only if you have a totally separate and duplicate network structure to allow both machines to share the same IP addresses and DNS names under one roof. It gets complicated and is definitely high risk when testing and blowing things away. One caveat re: MF Cobol - it doesn't like being restored and will complain about a corrupt license database when startiing it on the recovered server. You'll have to recreate that db and re-enter your licenses. It's a fairly simple process to do, if you can find your license keys! Good luck. Let us know what you come up with.



Lawsonite	Feb 8 2010, 11:42 AM Post #5
Advanced Member Posts: 42 Group: Members Member #4,726 Joined: February 15, 2008	This is fantastic. All the points are greatly appreciated. Along the same lines, I have one more question. We use the ADAM server to keep our user info. We use Domain controller(DC) for our Ldap connection. But currently it is running on one specific DC. If this DC goes down or is needed for Maintenance, then our systems will be down. Will the LDAP bind work at a domain level rather than a Domain controller level? If not, how big a deal is it to map the ldapbind to multiple DCs/servers? Thanks in advance.



Milo	Feb 9 2010, 02:00 PM Post #6
Rebmem Member Posts: 361 Group: Members Member #424 Joined: February 9, 2006	My 2-cents'-worth One-cent: We could not bind ADAM to more than one DC. Our DR plan is to have a Windows Admin manually change where ADAM points to. Two-cent: The MicroFocus COBOL license is always the biggest issue when it comes to a DR scenario. However last time I checked, you can download a new copy & a new key that will give you a 30-day "trial". In case of a test, 30 days is enough time to do a DR test. In case of disaster, 30 days is enough time to get a regular license from MF, or transfer your old one. Take care of your MF licenses, or all your other plans are :lala: useless.



ichiben	Feb 17 2010, 12:40 PM Post #7
Newbie Posts: 5 Group: Members Member #10,145 Joined: September 8, 2008	We are doing like Dave suggested and it seemed to work ok with the exception of Milo's caveat. I saw some compile errors related to license server - 'license corrupt because of tampering or restoration' and now we're trying to track down MF licenses. I'll do another restore and hope for flawless recovery like Dave's clients.



ichiben	Feb 17 2010, 12:41 PM Post #8
Newbie Posts: 5 Group: Members Member #10,145 Joined: September 8, 2008	I just finished the Lawson Cube Farm book last night. I recommend it for everyone on our team.



3monkeys	Feb 23 2010, 07:49 AM Post #9
Super Member Posts: 168 Group: Members Member #240 Joined: January 13, 2006	Quote: We use Domain controller(DC) for our Ldap connection. But currently it is running on one specific DC. If this DC goes down or is needed for Maintenance, then our systems will be down. Will the LDAP bind work at a domain level rather than a Domain controller level? Yes. We were originally bound to a single domain controller. Then we re-bound to just the domain and were able to use it successfully in our DR test. Regarding your MF errors, it won't work after only a restore. There are a couple more steps - lmfdbrecover and aslmdbrecover plus re-entering your license keys. I have a document that says how to do this, as part of our DR plans. If you are getting hung up here I can send it (minus our license keys, of course!). Let me know.



Milo	Feb 23 2010, 12:07 PM Post #10
Rebmem Member Posts: 361 Group: Members Member #424 Joined: February 9, 2006	Greg - just a comment -- Those 2 commands, lmfdbrecover and aslmdbrecover, must be to recover where MF hides the license keys. They have a way to hide license key info that is really, really good. In my previous job, we looked and looked for a way to spoof it, but couldn't. If you have once installed MF on a trial key, you can not uninstall it and install it as a trial again. Believe me, we tried just about everything, except de-compiling the source code (which is highly immoral if not down right illegal). Kudos to the MF people, who have made their software easy to install, easy to use, but near-impossible to circumvent the licensing.



Lawsonite	Feb 24 2010, 08:43 AM Post #11
Advanced Member Posts: 42 Group: Members Member #4,726 Joined: February 15, 2008	Greg, You wrote: "Yes. We were originally bound to a single domain controller. Then we re-bound to just the domain and were able to use it successfully in our DR test". Earlier, I had asked Lawson this question and they said it can't be bound to the domain. Anyways when you did it, did you ask your Windows admin to point to the domain before running the ldapbind process? Any other steps to think about? Also, I presume, you performed your DR test on the portal, right? Thanks in advance.



Lawsonite	Feb 24 2010, 01:14 PM Post #12
Advanced Member Posts: 42 Group: Members Member #4,726 Joined: February 15, 2008	Greg Ward, Is it okay if I send you some LDAPBIND related questions. If so, let me know the best way to reach you(email??). Thanks.



3monkeys	Mar 1 2010, 05:28 AM Post #13
Super Member Posts: 168 Group: Members Member #240 Joined: January 13, 2006	Milo: The way I understood it was each of those recover commands wipe out the "corrupt" license database and create a new, empty one for you to re-enter your valid license numbers. I say "corrupt" because the license database doesn't like being simply recovered from a backup or copied to another machine. It is pretty clever, I'll give 'em that.



3monkeys	Mar 1 2010, 05:32 AM Post #14
Super Member Posts: 168 Group: Members Member #240 Joined: January 13, 2006	Regarding my earlier post: Quote: Yes. We were originally bound to a single domain controller. Then we re-bound to just the domain and were able to use it successfully in our DR test. Technically we're not bound to the domain itself but rather to the DNS name of the AD domain. Within that domain are the three domain controllers which also happen to each be a DNS. Confused? Me too. It's good to have a network admin on your side that knows what he's doing.


« Previous Topic · UPGRADE: All other upgrades · Next Topic »