Skip to main content
Nintex Community Menu Bar

Hello,

 

we are going to update from K2 5.0 to K2 5.3 and want to play it save :-)

Is there any strategy for a "rollback plan" if it does not work?

 

My current thoughts:

* shutdown all related services

* full backup for the DEV system virtual machine

* DEV DB backup

==> Update DEV system

* start all related services

==> Tests in DEV system

 

* shutdown all related services

* full backup for the QA system virtual machine

* DEV QA backup

==> Update QA system

* start all related services

==> Tests in QA system, espaecially package and deployment from DEV to QA

 

* shutdown all related services

* full backup for the PRD system virtual machine

* DEV PRD backup

==> Update PRD system

* start all related services

(==> Tests in DEV system)

 

roll back scenario 1 (Tests in DEV shows problems)

first try to fix them

but if it is not possible to fix them we have to go back by
* shutting down the services

* backup the DB

* backup the VM

* start the services

 

Does this kind of roll back work? Is this roll back strategy needed? Or is there a rollback integrated in the K2 Setup?

What about K2 5 connect? I saw that there is only K2 5.1 available - is this working with K2 5.3?

 

Has anyone positive or negative experience with this update?

 

regards

Johann

Hi  @JSC;

 

It's always advisable to checkpoint your vm, in this case you'll be able to revert back to your previous versions successfully

Please see the following link on howTos(https://blog.5nine.com/hyper-v-checkpoints-how-when-and-why-to-use-it)

 

Should you find the above alternative helpful,kindly mark such as "Accepted Solution and/or Kudo".

 

Regards;

Widson.


But if I understand it correct, I have to stop the services first *and* make a DB backup, correct?
With VM backup I meant a checkpoint 🙂
Hi,

Checkpoint create full backup of your entire machine, should something goes wrong then you can safely return to the previous working version.
I understand but the K2 database is on another virtual machine. And the SQL machine has more than one db instance running - so a checkpoint of this machine with comlete roll back is impossible because it would also roll back TST and PRD system...

Hi JSC

 

In case you dont want to do checkpoint on you vm, you can do backup of your intire database and also backup your k2 files under C:Program FilesK2 and continue with the upgrade, if  something wrong happen during your upgrade you can intall your old k2 5.0 and restore the database and also go to C:Program FilesK2 and subtitude files

 

Should you find the information from the article useful or leading you to the answer please mark as "Solution and/or Kudo", as it will assist other k2 developers with relevant information in the near future.

 

Best Regards

Elvis

 


Dear JSC,


You should definitely stop the K2 service before you perform a K2 database backup. If you have multiple K2 server nodes in a server farm, you should stop all K2 server nodes before backing up the K2 database, and before running an upgrade on any of them.


If you have a DB backup and a VM snapshot, then rolling back is as "easy" as restoring your backed up DB and VM snapshot, and starting up again. In some situations, you need to run Setup Manager in Configuration mode after a restore to get everything synced up again.


 


As an aside, if you have any concerns about your plan, I would encourage you to consider K2 Remote Services. They can do a consultation with you on your upgrade plan, and ensure you have considered the necessary points. K2 Remote Services will also perform upgrades for you, if you prefer.


 


Either way, you have the right basic idea here. Stop services, back things up, and move ahead. If anything does go wrong that you can't sort out fairly easily, restore your DB and server backups. There is not a "rollback" or "downgrade" option in the installer itself. And, of course, always log a Support ticket if needed. Your local K2 Support team is there to help ensure your success with K2.


 


Best regards,


Gail


Reply