I have found that upgrading within a major release, EG: 7.1.0 to 7.1.1, 7.1.2 to 7.1.3, etc works transparently. If upgrading that results in a version of DB2 changing (like v7 to v8) additional consideration needs to be made that has not yet been captured in my `upgrade` option below. (Upgrading from v7 to v8 failed for me because of DB2 issues that I wasn't able to resolve - DB2 changed versions between 7 and 8.)
After the upgrade Spectrum Protect is smart enough to realise that it has been upgraded and will do a one time schema update.
> * As always, make sure you have a back-out plan, in case things go pair shaped. Docker itself provides a great back-out option, especially if you use it with persistent Docker Container storage that can exploit snapshots and reverting (or directly accessing) a snapshot.
In the example below, I'm using Linux LVM snapshots to provide my backup option. Spectrum Scale would also be a good choice.
ANR2234W This command will halt the server; if the command is issued from a remote client, it may not be possible to restart the server from the remote location.
> **NOTE**: Don't use `docker stop` to stop your SP server.
> By default docker sends a SIGTERM signal to the containers process 1 and then waits 10 seconds for it to die. If it hasn't died, it will then send it a SIGKILL.
> While you can control the timeout between the SIGTERM and SIGKILL signal and you can even control which kill signal is sent, during the upgrade, you want to make sure Spectrum Protect shuts down cleanly. Jump on an admin client and issue `HALT`
If you can snapshot your persistent storage that you provide to the SP Docker Container, that will save you doing a "restore db" if something goes pair shaped.
<small>**NOTE**: You can see the console by running `docker logs -f spectrumprotect` to make sure the upgrade works as expected. Once you see success, you can delete the container with `docker rm -v spectrumprotect`.</small>
```bash Expected Output
[root@host]# docker logs -f spectrumprotect
DB2 installation is being initialized.
Total number of tasks to be performed: 4
Total estimated time for all tasks to be performed: 309 second(s)
Task #1 start
Description: Setting default global profile registry variables
Estimated time 1 second(s)
Task #1 end
...
The execution completed successfully.
For more information see the DB2 installation log at "/tmp/db2iupdt.log.5".
I did this on the lab server, and while admittedly it doesn't have much data - the whole "upgrade" process took 12 minutes after the DB backup was complete - and that was with me documenting it for this wiki. So it could have been quicker!
> If something did go pear shaped, then revert your snapshot (or if it is read only, copy the files back to the original path) and then start your container with the original image (the old version) of SP. It should start up as normal as if it was only shut down temporarily.
> If you really have problems, you have that backup to recover from! Start the container with the `restore <PASSWORD>` option - you'll need a DBDIRS.TXT file as well in the instance home directory. More info on recovering [here](recover).