What to do to migrate a RTC 3.x from a machine to another
Hello,
We want to migrate our RTC 3.0 repository (jts & ccm) from one machine to another. Is there something special to do with server URI? A kind of repotools -modifyLinkURIs to execute? If yes, what is the linkTypeId value to use? Thanks in advance. |
6 answers
Ralph Schoon (63.3k●3●36●46)
| answered Feb 28 '11, 11:06 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi,
you should move the host name to the other machine. The reason is to keep the URL integrity. See http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0/index.jsp?topic=/com.ibm.jazz.install.doc/topics/c_planning_URLs.html. As far as I know there is currently no official support for changing the URI. Ralph Hello, |
Hi, Hello, Hi Ralph What happens if you used repotools export/import. I thought that would replace the machine name references in the repository (although I normally import test repositories, so I don't often work with different machine names). anthony anthony |
Ralph Schoon (63.3k●3●36●46)
| answered Mar 01 '11, 2:21 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Anthony,
as far as i know that is no solution either. You could try though and report. 8-) There are considerations to come up with something. I don't think we have it yet. And it would also break connections from other tools. Ralph Hi, Hello, Hi Ralph What happens if you used repotools export/import. I thought that would replace the machine name references in the repository (although I normally import test repositories, so I don't often work with different machine names). anthony anthony |
OK, this can be a problem for me. Today I have one production server and multiple test servers. On my production server, I have weekly full and daily incremental backups. I need to verify that these backups are working as expected and can be restored. I can't do this to my production server, so I need to do it to one of the test servers. Based on this note, I can't do that. My company will not tolerate a significant data loss, and having backups that have issues that cause the data to not be successfully restored is entirely unacceptable. The only way I can validate my backups is to take the production system offline, make an image copy of the disks, restore the backups and see if the backups are OK. If they are not, replace the saved image copy to the production disks and repeat this process until successful. This would not be possible in our environment where I am required to have my production system up, running, and available 99.1% of the time, which only allows for 1.5 hours per week (or 6 hours in a month) downtime.
We need a solution for this limitation. Jon |
Ralph Schoon (63.3k●3●36●46)
| answered Mar 15 '11, 8:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi,
you would be able to test on an isolated test system or network of test systems. We do this all the time for demos. It is just necessary to make sure there is a host name alias for the test system that matches the original from the repository so that the links don't break. You have to use isolation because the DNS will not provide the same host name to several servers. Thanks, Ralph OK, this can be a problem for me. Today I have one production server and multiple test servers. On my production server, I have weekly full and daily incremental backups. I need to verify that these backups are working as expected and can be restored. I can't do this to my production server, so I need to do it to one of the test servers. Based on this note, I can't do that. My company will not tolerate a significant data loss, and having backups that have issues that cause the data to not be successfully restored is entirely unacceptable. The only way I can validate my backups is to take the production system offline, make an image copy of the disks, restore the backups and see if the backups are OK. If they are not, replace the saved image copy to the production disks and repeat this process until successful. This would not be possible in our environment where I am required to have my production system up, running, and available 99.1% of the time, which only allows for 1.5 hours per week (or 6 hours in a month) downtime. |
The setup Ralph describes is also mentioned in the infocenter, at http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0/topic/com.ibm.jazz.install.doc/topics/c_upgrade_staging_env.html. It is in the context of performing an upgrade, but applies also to testing backups or testing changes in a staging environment.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.