We have 2 validated Baan instances on 2 baan servers located in separate places. Both instances are technically and functionally unrelated. In the eventuality of any disaster at any single location we want to be able to use Baan at both locations for Both baan instances on a single server . We are ok lesser no. of user during that period.

For this purpose we wish to create both the instances on both servers . In real time we may keep the other non-running instance stopped as users will never work on the same . At the day end jobs execute following
1. Export backup of All tables (SQL server for backward incompatible restores )
2. baandb full back
3. Complete BSE zip file (except tmp folder) .

All these moves immediately to the target server at the night . In target server we may restore it only at the time it's needed . There is enough hdd space for BSE and database files in both servers.

Hardware / database failures have been taken care off with realtime log backups each 15 mins. So at any point we loose max 15 mins of data. The problem is for larger disaster at any single location.

With these scenario, we wish to create 2nd instance of Baan on both server and install only environment and then use above backup files for restore at appropriate location. Is there anything wrong with this . Do we need to take care off anything specially. Is there any need for revalidation at any place .

Also another alternative is to use license server of the validated server (changing license6.1) and install baan on a new server . Which one u would recommend .

As far as I can remember, it is easy to create a second instance on a server: create a new BSE (possibly from a restore in your case) and change the relevant entries in the $BSE/lib directory's files. To log on, use either environment variables (suppose this is for UNIX and ba6.1 only!) or the BSE variable in the login program to point the users to the correct instance. For license issues, you could point both instances on a server to the active daemon using the license6.1 file.

Having been out of the field for a while, I stand corrected, but this is the approach I would follow to get the results...

Thanks for the reply . I too remember lot of thread about more than 1 instance on same machine.

I just want to know the experiences of any people in Win2k3 using SQL 2000/5 for Baan IV for keeping a separate baan instance with DB out of physical location of actual usage .

One operational issue of good connectivity in our case is solved by way of fiber optic backbone. So the headache of transferring bulky data realtime at night doea not exist.

Hi Hitesh,
You didnt mention anything about how long it would take for your temp system (Baan Second Instance) to kick in after a disaster. Whats your Disaster Recovery SLA?
&
In target server we may restore it only at the time it's needed.

Why not restore your full db backup (that you copy at night to the remote target server) right after the copying process is over. This would speed up your recovery process. It wouldnt be a bad idea to copy and restore hourly differentials to your (remote) second instance as well. That would just leave you with the job of restoring the transaction logs since the last differentials.

sk

For small hardware / software problems , the system has to be available immediately ie 0 down time. This has already been taken care off through system state back , online backups , cluster , etc .

But for bigger problems at the location level, the priority is data availability , restorability and usability rather than continuity of full fledged operations . Continuity of of Baan with low license count is acceptable and higher downtime could be tolerated (as there may more important things to take care off than just Baan) .

Applying logs in real time is not possible because of different database versions SQL 2000 & 2005. Further we dont want to burden operational system realtime log application. I think it's possible to apply logs from 2000 to 2005 which I'll test it . Further the baan DB is different in both versions ( viz baandb and baanenvdb) .