It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×10,908
×7,383
×4,288
×3,952
×2,338
×1,381
×267

question asked: Apr 10 '13, 2:31 p.m.
question was seen: 7,997 times
last updated: Apr 11 '13, 11:12 a.m.

Related questions

FAQ - How this Forum works

Rollback / Downgrade from CLM 4.01 to 3.0.1.4

2
Ron Charron (21●1●2●4) | asked Apr 10 '13, 2:31 p.m.
retagged Apr 10 '13, 4:34 p.m. by Max Bridges (241●2●6)
We are in the process of planning a migration from CLM 3.0.1.4 over to 4.01.
We need to plan a roll-back strategy (i.e.: roll-back to 3.0.1.4 in case of a failed change, for whatever reason).

Does anyone have a procedure/pointers/experience with a version roll-back?

WebSphere server (on one server), Oracle database (on another).

Thanks
Ron

3 answers

Most liked answers|Newest answers|Oldest answers ↑

2
permanent link
Indradri Basu (1.8k●1●5●14) | answered Apr 10 '13, 2:43 p.m.
edited Apr 10 '13, 3:01 p.m.
Hi Ron,

Consider reading this article to understand what are the important things to backup. I believe restoring the databases, index files, your application server profile configuration and application configuration (the .../server/conf folder) are essentially needed to be restored. If you have additional components in your topology then they probably needs to be considered as well.

Hope this helps

Comments
Max Bridges commented Apr 10 '13, 4:33 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

One of the keys to that article in this case would be Backing up and restoring the Jazz Team Server.

0
permanent link
Chris Ryan (157●3●24●28) | answered Apr 10 '13, 2:48 p.m.
I'm interested in this as well.

Assuming that we have all of that backed up that you mentioned, Indradri, can we restore those to a 3.0.1.4 instance?  As I understand it, the database schema has changed in CLM 4.0.1, so would it be possible to restore a database?
Comments
Clement Liu commented Apr 10 '13, 2:53 p.m.

You would need to take a database backup (ask your DBA to take it on the DB side) first before you run the repotools command. 

Indradri Basu commented Apr 10 '13, 2:54 p.m.

Hi Chris,

During the upgrade process you need to run the upgrade scripts which makes some changes in the application databases but incase there is a need to rollback, if you restore your databases from a backup which was taken before starting the upgrade process, your databases should be back to what is was prior to the upgrade.

Kevin Ramer commented Apr 10 '13, 3:08 p.m.

One thing to note: Installing another version of CLM ought to go into another location so the basics of the previous version should remain intact.  i.e. updated files would go into the new 4.0.X install.  Most important is the database backup.

Chris Ryan commented Apr 10 '13, 3:10 p.m.

This makes sense, if we wanted to revert to the same state of the data when we were in 3.0.1.4.

But, what if we wanted to keep the data/source code, work items, etc...for the month that they used 4.0.1, but then realized we wanted to 3.0.1.4 back but wanted to keep the work we've done.

Is there any way to avoid data loss for the month that the users were active during 4.0.1?

Clement Liu commented Apr 10 '13, 4:02 p.m.

Hrm... don't think there is any script to help you downgrade the database schema from 4.0.1 to 3.0.1.4. You might want to raise a PMR to IBM Support to have this answer. 

Indradri Basu commented Apr 10 '13, 4:25 p.m.

Chris, I am curious to know what problems would you anticipate for which you need to rollback to a earlier version after a planned and successful upgrade.

But to answer your question and as per my understanding some data may not fit back to the earlier release even if you plan to export it back, after rolling back to the earlier version.
Hope this helps

showing 5 of 6 show 1 more comments
1
permanent link
Sean G Wilbur (872●1●24●21) | answered Apr 11 '13, 12:44 a.m.
JAZZ DEVELOPER
edited Apr 11 '13, 12:48 a.m.
   I think this is more of a process question than a product function, check out the article noted by Indradi as a complete backup is all you need to restore to a point in time. If you upgrade and find out you have problems, there is no way to keep any new data from 4.x and downgrade that to 3.x, you will need to restore to a backup from the 3.x timeframe.

In the case of an upgrade and having a fall back strategy, it sounds like you are planning on removing the 3.x install, installing 4.x, and they doing the upgrade. There is not special sauce to roll back, if the 4.x upgrade fails or you run out of time, the answer is remove the 4.x bits, install 3.x and restore your dbs/indices/configs.

 Lots of customers are doing this using different machines/vms so the cutover turns into a backup, dns update, and upgrade from the server perspective. That tends to simplify the fall back, to reversing the dns change and db restore, but this is really only practical if you are virtual or happen to be upgrading hardware at the same time.

  -Sean

 
Comments
Ron Charron commented Apr 11 '13, 11:12 a.m.

Thanks Sean,  we'll be keeping our 3.0.1.4 around for a safe period.
Because of the changes in the db schemas, and with intent to be able to salvage any new record edits in the 4.0.1 environment made before roll-back, it doesn't look like we could just bring over the db used in the 4.0.1 back over to the 3.x environment.
So, alternatively, I am wondering about a strategy such as daily xml exports in the 4.0.1 environment (during the period we agree to ensure roll-back capability) a possible work-around allowing us to go back to 3.x, then re-import the xml files into the old db (so we don't loose the new work).

Your answer

Register or to post 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.