Regular backup of application database ensures that the data is available for restoration in case of computer crashes, virus infection, hard drive failure, physical computer damage, and other scenarios. Storing backed-up data in a different file share is generally accepted as good practice.
Backend database of Storage Operations Manager (SOM) is PostgreSQL. SOM maintains seven days of capacity data and two days of performance data in its database. Historical data from the device is stored in SOM’s reporting solution which will be discussed later in this blog. Though SOM keeps only limited historical data in SOM database, SOM has many configuration data, such as:
Device discovery details such as IP Address and credentials
Any user defined or edited Data Collection Policy and Data Collection Level
Any user defined Node Groups
Performance Collector Group and Performance Data Collection Policy
Storage Tier rules
Any user defined Tenant and Security Group
Configured users along with user group
Custom settings of application server (JBOSS, etc.).
Collecting this set of data takes time and configuring them in SOM takes a bit of time as well. It is important that database and these configuration data is backed up regularly.
IMPORTANT NOTE: Backup schedules used in this blog are for illustration purposes only. Please consult your organization’s backup policy to find backup schedules of SOM and Operations Bridge Reporter (OBR).
Backup of SOM configuration files and database
On a Windows SOM server, you can accomplish weekly backup of SOM configuration and database by:
Rename the attached SOM_backup_script_windows_batch_file.txt to a .bat file. Ensure that you mention a suitable directory name/path to variable “Backup_Directory”.
Search for “Task Scheduler” in Start Menu and open it.
Figure: 1Figure: 1
Figure: 2Figure: 2
From the left-side pane of “Task Scheduler” window, right-click on “Task Scheduler Library” and select “Create Basic Task…” to create a scheduled job. This opens “Create Basic Task Wizard”.
Provide suitable values in “Name” and “Description” fields.
Figure: 3Figure: 3
Select “Weekly” as task trigger or another suitable interval. Input the additional details about the interval.
Figure: 4aFigure: 4a
Figure: 4bFigure: 4b
In the “Start a Program” screen, browse and select the batch script that was created before.
Figure: 5Figure: 5
In the “Finish” screen, check “Open the Properties dialog for this task when I click Finish” checkbox and click on “Finish” button.
Figure: 6Figure: 6
In the scheduled job ‘Properties dialog’ window, select “Run whether user is logged on or not” option from ‘Security Options’ section and check “Do not store password. The task will only have access to local computer resources” and “Run with highest privileges” checkboxes.
Figure: 7Figure: 7
Go to “Settings” tab and check “Run task as soon as possible after a scheduled start is missed” & “Stop the task if it runs longer than <suitable number of hours>” checkboxes. Click on “OK” button to apply the change and complete the scheduled task creation.
Figure: 8Figure: 8
Newly created Scheduled task is now shown in the “Task Scheduler” window.
Figure: 9Figure: 9
Ensure that the zip file created in this process is stored in reliable storage.
On a Linux SOM server, one can accomplish weekly backup of SOM configuration and database by:
Rename the attached SOM_backup_script_linux_sh_file.txt to a .sh file. Ensure that you mention a suitable directory name/path to variable “Backup_Directory”.
Make the script executable
chmod +x <complete file path of the script>
As an example, let’s say I want to execute the script created above every Sunday at 1500 hrs. If so, create a .txt file with the following text:
# Minute Hour Day of Month Month Day of Week Command
# (0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)
0 2 12 * * /script1
0 15 15 5 7 <complete file path of the script created above>
Now create cron job by running the following command –
# crontab <complete file path of the .txt file created above>
If you are returned to the shell prompt without any error or message, you are all set.
You can list the configured cron jobs by:
# crontab -l
Restore of SOM configuration files and database (Windows and Linux)
Majority of the configuration files can be restored on a different SOM CMS but restoring of database is supported only to the same SOM server where the backup was taken.
To restore configuration files and/or database:
Locate the latest or appropriate backup zip file. Unzip the content.
Identify configuration files to be restored.
Stop SOM JBOSS service using “ovstop -c somjboss”
Configuration files which were copied straight-away from various folders during backup (e.g., custom.properties, LicFile.txt, licensing.logging.properties, nnm*.properties files, ovjboss.jvmargs, jboss-logging.xml, and version, etc.) needs to be restored selectively.
Use “somsecurityinfoimport.ovpl” to import ‘SOM_Security_Info.zip’ back into the system that was backed up using somsecurityinfoexport.ovpl.
Configuration files (e.g., SOM_Discovery_Settings.xml, SOM_Data_Collection_Policies.xml, SOM_Node_Group_Settings.xml, SOM_Created_Hosts.xml, SOM_Monitoring_Policies.xml, SOM_Storage_Tier_Rules.xml, and SOM_Asset_Configuration_Data.xml) that got exported via an .ovpl file, can be imported back using it’s “import” function.
Use “somrestoreembdb.ovpl” to restore database. Note that database restore is supported only on the same server & installation where the backup was taken from. If there is a different need, contact SOM support.
At the end of restore process, run “somproviderlist.ovpl -all > Latest_SOM_Provider_List.txt” and compare it with “SOM_Provider_List.txt” file present in the backup zip that has been restored.
Start SOM JBOSS service back using “ovstart -c somjboss”.
Check if the SOM URL is accessible and has data/configuration that has been restored.
Backup and restore operations in SOM’s reporting solution (Operations Bridge Reporter)
Now let us discuss Operation Bridge Reporter (OBR) that stores historical data of devices being monitored in SOM. Default data retention period of OBR is: 90 days of raw data, 1 year of hourly data, and 5 years of daily data; user can change these retention periods. In addition to massive set of reportable data, there are many important OBR components that needs to be backed up on a regular basis.
The “Disaster Recovery Guide” for HPE Operations Bridge Reporter has concise steps to backup and restore important OBR components. For Linux, refer to sections of Chapter 2 and 3. You may create a cronjob to backup important OBR components regularly as shown above for SOM server. Please note that this script does not handle Vertica database which is the columnar database that OBR uses to store data.
Backup and restore operations of Vertica database (Operations Bridge Reporter data warehouse)
Vertica has a built-in comprehensive tool “vbr.py” that provides various maintenance activities such as backup and restore. It provides multiple backup options such as full backup, incremental backup, etc. HP Vertica supports restore actions only to the same exact version of HP Vertica that created the backup.
Refer to the “Backing up and Restoring the database” section of the Vertica “Administrator’s Guide” for detailed and complete steps. A simplified set of steps for backup and restore that you can follow for single-server OBR with Vertica as database is given below:
Open a Secure Shell session to OBR server and you may log into it with the ‘Vertica DBA’ user that was created during OBR Post-Install configuration steps. Any ‘dbadmin’ Vertica user will work but not ‘root’.
Create a configuration file, which is one-time activity till a change is needed, by running the following command and provide suitable input:
# /opt/vertica/bin/vbr.py --setupconfig
Snapshot name (backup_snapshot): <suitable name for backup; e.g., fullbak1>
Number of restore points (1): <no of backup archive; e.g., 2>
Specify objects (no default):
Vertica user name (verticadba): <vertica dbadmin user; e.g., verticadba>
Save password to avoid runtime prompt? (n) [y/n]: y
Password to save in vbr config file (no default): <verticadba password>
Backup host name (no default): 127.0.0.1
Backup directory (no default): /home/verticadba/backups
Config file name (fullbak1.ini):
Password file name (no default value) (no default):pwdfile