Prime 3.1 upgrade to 3.2 backup restore question

[jwornstaff]

I'm looking to upgrade our primary standalone Prime server 3.1 to 3.2. In reading the release notes they indicate an inline upgrade is possible, however it goes through the instructions of backing up current 3.1 server and moving the backups to remote storage, etc, etc.

However if you read the the 3.2 Guides on backups and restores, it says that 3.1 backups can not be applied to the 3.2 virtual or physical appliances.

So what the heck is the point in backing the operational 3.1 server if I can't reapply or restore to 3.2, if that is truely the case.

And does the inline upgrade wipe the the current 3.1 server configs or does it preform the migration/converstion automatically so that a restore of the old data is not neccessary required, unless it would happen to fail?

And what happens if the 3.1 to 3.2 inline upgrade goes wrong and how can I restore the backups?

Anyone have any insight, previous experience, thoughts?

[marce1000 · Accepted solution]

 - You need to make an application backup to a remote repository  , to have a backup when the upgrade fails. Restores can only be done within the same (minor) version trail (indeed), not from 3.1 to 3.2.  3.2 does not so much 'change configs' but changes the database format, and probably other things.  Why the  hell would I need a backup if the upgrade goes wrong ?   That is a good question because it leaves the  current machine in an undefined state. You will have to re-install it, with a virgin 3.1, then do a restore, then an upgrade (again) , providing also that the cause of the failure could be established. What I did was to clone a VM , and change the ip, and do an upgrade on the clone , for instance. On an appliance this path will not be possible.

M.

[jwornstaff]

Thanks for the info and reassurance. I wasn't sure if anyone would get what I was trying to say/ask. Cisco never seems to make it easy. It's easy if it works as advertise but if it goes wrong theny you are screwed trying to rebuild. Had this happen with a WAAS Central Manager appliance, inline did not work and wiped the the database, ended up rebuilding from scratch.

But back to the VM clone, I was wondering if a clone or snapshot would function correctly, if brought up as live version if primary server got hosed up during upgrade....did you have any issues with license, database, etc?

[marce1000]

 You won't have any issue, but I did the reverse, work with the clone (or a previous backup-snapshot of the VM) for the upgrade then your source machine is still in tact and functional while the upgrade is done on 'another' host (and it can remain that way if that task would fail) . Later if it all worked , this one can become the 'primary prime....'..

M.

[Brett]

I have ran into some issues with an upgrade and restore on 3.2.  It hasn't caused any real issues, just something to be aware of.  Upon the upgrade to 3.2, an I/O database error can pop up when the upgrade is happening, and when you do ncs start and stop.

The important thing to note is bugs will transfer between 3.1 and 3.2.  For example if you are encountering the bug where you can not delete ASR1002 routers, it will have the same issue in 3.2.  Also be aware if you have mutliple Prime servers at the same code level, verify the user task list as they can be different even if they are running on the version of Prime.

[fabianwickman]

I was under the impression that you could restore a 3.2 version of PI to a clean 3.3 install of PI... ? 

[fabianwickman]

From admin guide:
https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-3/quickstart/guide/bk_Cisco_Prime_Infrastructure_3_3_0_Quick_Start_Guide.html

"If you are upgrading from a Prime Infrastructure 3.1.x, or 3.2.x virtual machine, you should create a new virtual machine with the same deployment configuration option you used previously (for example, Express, Express-Plus, Standard, or Professional), back up your existing virtual machine, and then restore it on the new virtual machine"