How to clone a CLM installation?
We have RTC/RRC 4.0.6 on Windows via Tomcat7 service, in a TEST env, which is a pre-PRD env, where we verify evey modification or addition prior to implementation in PRD; and a PRD env.
We are trying to build a third env, a real sandbox for POC and we happen to get it in time to test our next upgrade, to 5.0.2,
My strategy is to take advantage of existing PRD data to populate the new sand box hence:
- Clone PRD installation & SQL Server 2012 DBs to sandbox to a sandbox sbx_appServer and sbx_DBserver respectively.
- DBA clone PRD DBs to sbx_DBserver with same credentials in same TEST domain.
- We zip PRD installation and unzip it on sbx_appServer.
- Using the exact same access URI via DNS spoofing with the hosts file.
- So we only need to change the DB's URLs to the new sbx_DBserver in the properties files.
Once 4.0.6 is running:
- Upgrade to 5.0.2
- Once upgraded: We will experiment with the move server feature and/or reverse proxy to see if we are able to use a distinct URL for each environment.
Have never installed from scratch or cloned an installation to a pristine env, I wonder if this is a sound plan. Would appreciate any input or advice.
Would it be better and faster to clone than to install 4.0.6 from scratch then run setup to use same URIs and point to new DB server ?
If having issues with cloning, would running setup at that point help ?
Accepted answer
The root cause of the issue was my stupidity of forgetting to shut down the apps (duh!) while zipping the install area.
Comments
Also, you should only copy the files that need copying e.g. reinstall the products and then deploy the backup over them.
Reasons for file too long are the Windows architecture. If you do a fresh install and copy the backup over, that should not happen. Plus you know your backup strategy works.
Thx Ralph,
Learning the hard way, not only on copying but also on expecting cloned DBs on a silver platter (like before) complete with access, same account, sane passwd; also on trying to replace encrypted passwd with new raw passwd in the properties files instead of getting RTC up lame, but with DB connection to input/encrypt new passwd : Got there more than 2 weeks behind schedule
2 other answers
- Don't use windows ZIP. Use 7zip.
- Install the product on the other server, if you can't just use the VM image there and have file name length problems.
- If you can't use the VM, restore a backup of your production data on the new server See: https://jazz.net/wiki/bin/view/Deployment/BackupCLM
-
Make sure there is no way that the new machine can connect to the old server - isolated environment as suggested in the product help. (By host file manipulaion for example.
-
You can ask support for a server rename key and do an URI change, if you want to use the copy of the prod server in the network for testing.
Comments
long TRUONG
Feb 05 '15, 8:56 p.m.First obstacle: Tomcat files too long (believe to be the name not the path) to be compressed; e.g.
long TRUONG
Feb 05 '15, 10:52 p.m.Am doing a direct server to server copy, these files (over 2000 of them) cannot be copied either, and they have to be skipped. Wonder if that is because they are NTFS junction points which cause infinite loops.
<o:p> </o:p>