cancel
Showing results for 
Search instead for 
Did you mean: 

Clone Business Objects server

Former Member
0 Kudos

Hi,

We have a requirement to clone the SAP Business Objects 4.1 servers.

We are aware that SAP doesn't recommend cloning the systems as BO installer binds entries with host name and IP address during installation process (KBA 2034684).

Did anyone tried cloning the system and modified above mentioned host and IP address entries?If so,please let me know the process.

Thanks,

Krishna

Accepted Solutions (0)

Answers (2)

Answers (2)

CdnConnection
Active Contributor
0 Kudos

Krishna,

Here are couple of other link that you may be interested in to help you Clone / Backup & Restore from Server 1 to Server2.

https://blogs.sap.com/2015/08/24/how-to-restore-bi4-from-frs-cms-backup/

https://blogs.sap.com/2015/09/06/doing-a-full-install-from-bi-406-to-bi-416-and-retaining-full-conte...

Regards,

Ajay

denis_konovalov
Active Contributor
0 Kudos

Did you see this in the KBA you mentioned :

NOTE: SAP Kbase 1275068 which discusses a backup and restore strategy should strictly be used for disaster recovery situations, and NOT for cloning or side-by-side consumption. This is becasue of some recently discovered issues involving Client tools such as the Information Design Tool (IDT) which are unable distinguish between the two systems. As this procedure was never designed to support the replication of systems running side by side, like perfect clones – and thus totally indistinguishable from a client perspective, SAP recommends that this procedure is NOT to be used for Cloning BI systems.


There are no safe and reliable methods to clone the BOE servers in a side by side usage scenarios.

In scenarios where cloned BOE servers are not on the same network - use VM images and clone those instead.

0 Kudos

Hi Denis - Thank you for the imputs. I am interested to explore the last line-

In scenarios where cloned BOE servers are not on the same network - use VM images and clone those instead.

If we mirror/replicate the windos server to DR farm which is in different netwrok ( can maintain the same host name but different IP address ) . do you have any comments for this scenario ?

Thanks in Advance

denis_konovalov
Active Contributor
0 Kudos

it cannot be up and running in that location as it will cluster itself to existing one and since they both have different CMS DB's (replicated from each other) it can lead to all sorts of weird states

0 Kudos

Thank you for your quick response.

What if Windows server mirror via SRM, CMS DB mirror using datagaurd , filestore mirror via SRM to the from prouction to DR farm which will be in different data center/network. The scope is to bring the DR when the prod is down.

if we delete the references pointing to production in CMSInfoobjects, change the datasource in CCM, change the cluster name and recreate the SIA.

Do you think this works or risky ? I am considering the backup and restore option but still trying to understand how and why the mirror/cloning will fail.

denis_konovalov
Active Contributor
0 Kudos

how are you going to delete all that info if CMS DB is replicated constantly/mirrored ?

Active/Active DR doesn't work if there is network connectivity between environments.

0 Kudos

The plan is to stop the replication and no contact between prod and DR.( assuming that there is no active environment - production )

Now we have mirrored server ( same host name with different ip ), cms db, frs.

do you think this is still doable without major issues ? if this works, then we dont need manual install in DR farm. If cloning works, then this might reduce the recovery time in DR farm when the real DR situation occurs.

please suggest.

denis_konovalov
Active Contributor
0 Kudos

I'm not sure I understand all the details.
If you stop replication, then how are you going to keep the DR system up to date ?

We do not support mirroring or cloning.

If you want to have DR, I think the only option that works is Active/Passive scenario where you bring DR nodes up if regular nodes fail and when all dr and normal nodes are part of the same cluster.

0 Kudos

To perform the DR test, we will be bringing down the production server and all the replication will be disconnected so now we have only the DR server ( mirrored from production ) and cms db and frs backup. from this point the configuration steps follows to delete the prod server references and create the new node pointing to the CMS DB backup.

This is just a brainstorming for me to understand why the cloning wont work approach wont work.

Thank you for all your valuable inputs Denis ! What you said about the cloning is exactly what SAP responded to my query few days back.

denis_konovalov
Active Contributor
0 Kudos

This "we will be bringing down the production server and all the replication will be disconnected so now we have only the DR server ( mirrored from production ) and cms db and frs backup. from this point the configuration steps follows to delete the prod server references and create the new node pointing to the CMS DB backup." should work. generally. If the servers were not cloned originaly 🙂

0 Kudos

Hi Denis - what do you mean by 'If the servers were not cloned originaly'.. my approach is once the prod environment is setup, then mirror the servers to another server in DR farm (passive) which will have the same host name with different ip. do you think this will work?

Mirroring will be active from prod to DR including the cms db and frs.

In the DR situation, the mirroring and the replication will be shutdown. the server in DR, cms and frs will have the latest information.

not sure clone is different than mirrior/snap.

will this approach works without manual install in the DR farm ?

denis_konovalov
Active Contributor
0 Kudos

if you mirror, it'll mean that you have 2 nodes with same name, one in orig env and one in DR.
It'll work (maybe) if Dr nodes are not running concurrently with originals and if mirroring process is faultless.

0 Kudos

DR image will be in offline mode and it just receives the updates/refresh from prod in one way direction ( prod to dr ) and there is no going back from DR to prod when prod is live.