Before every update, check the version of installed packages. The database version is particularly important.
yum info vprotect-server vprotect-node mariadb-server
rpm -qa | egrep -e "vprotect|Maria"
If the host computer has an Internet connection, use the yum command - you'll also see the new package versions provided by the repositories.
- Make sure you have the Storware Backup & Recovery database backup.
- You can use this command manually to back it up on-demand on the Storware Backup & Recovery Server:
- If Storware Backup & Recovery was installed on a virtual machine (not a physical one), it would be a good move to take a snapshot.
- After backing up the database, we should carefully stop the Storware Backup & Recovery service to make sure that we don't have any tasks running (a running task may cause problems updating the database).
- View all tasks, if you see even one on the list, clear it (wait for the ongoing tasks to finish)
- You can do this from the WebUI (it's faster)
[root@vprotect ~]# vprotect task -L
GUID Type State [%] Window start Window end Pri. Node VM/APP
------------------------------------ ------ -------- --- ---------------- ---------------- ---- ---------- -----------
e3bb2496-3928-417c-a604-8c61b64df90e Export Running 0 2020-06-19 12:27 2020-06-19 17:27 50 vPro-Local VM_01_Apine
05c1d6cc-fe3b-40fb-9811-94b976571d8e Store Finished 100 2020-06-19 12:10 2020-06-19 17:10 50 vPro-Local VM_01_Apine
cb47190d-cf10-4cf9-8d1d-418eed5accf9 Export Finished 100 2020-06-19 12:09 2020-06-19 17:09 50 vPro-Local VM_01_Apine
#To delete a task from the list
[root@vprotect ~]# vprotect task -d cb47190d-cf10-4cf9-8d1d-418eed5accf9
- Now, if you don't have any tasks on the list, you can stop the service.
[root@vprotect ~]# systemctl disable vprotect-server --now
- To make sure that no scheduler has started a task before stopping the service, let's query the database.
- If the table is not empty, start the Storware Backup & Recovery-Server service and clear the tasks again.
mysql -u root -p -e "Select * FROM vprotect.task;"
- Make sure you have MariaDB up-to-date - currently Storware Backup & Recovery by default uses version 10.4, while 10.2.31 is the minimum version supported.
- If you need to migrate between versions (for example. 10.3 to 10.4) - we recommend updating it as described here, but when you uninstall MariaDB packages you SHOULD NOT remove the Storware Backup & Recovery Server package (as a dependency) i.e. try the
--noautoremoveoption: As centos/rhel 7 do not have the --noautoremove option natively, please use the rpm method.
- Otherwise, minor MariaDB versions should be updated with
rpm -e --nodeps "MariaDB-server-YOUR_VERSION_OF_PACKAGE"
- Update the MariaDB repository to the correct version
- Install the new MariaDB-Server
yum install -y mariadb-server
- Update all other components of MariaDB
yum update -y mariadb
- Start the MariaDB engine
systemctl enable mariadb --now
- Run mysql_upgrade to update the Storware Backup & Recovery Database
mysql_upgrade --user=root --password
- If the database update is successful, now we can start with the Storware Backup & Recovery Update. Make sure you configure our new repository for Storware Backup & Recovery - new base URL:
- Update the Server (it may take a while, the service is being restarted):yum -y update vprotect-server
- If the server service was not running before update, you may also need to execute:systemctl enable vprotect-server --now
- 1.Update each Node:systemctl stop vprotect-nodeyum -y update vprotect-node
- 2.Run the script to configure the OS for Node:vprotect-node-configure
- 3.If the node service was not running before the update, you may also need to execute:systemctl enable vprotect-node --now
- 4.Log in to the web UI and check if the nodes are running.
Note: You may need to refresh your browser cache after update:
- 1.Update Cloud Server on each host with Node installed:yum update sbr-cloud-server
- 1.Update Cloud Agent on each host with Node installed:yum update sbr-cloud-agent