{page-title}
{color:windowtext}In certain scenarios it is possible to damage the Server Backup Manager internal database, resulting in a Backup Manager that fails to start. Causes for H2 database damage include (but are not limited to) disk or file system corruption, memory exhaustion during key transactions, or allowing the system to run out of disk space. {color}{color:windowtext} {color}
{color:windowtext}This article will guide you through restoring the H2 database from a backup copy. {color}{color:windowtext} {color}
{info}{color:windowtext}Before performing this task, it is recommended that the Server Backup Manager be placed into into{color} {color:windowtext}[Maintenance Mode|ServerBackupManager:Manager Options]{color}{color:windowtext}, to reduce the chance of data corruption.{color}
{color:windowtext}Once all running and queued tasks have completed, you may safely stop the Backup Manager service.{color}{info}
h2. Solution
----
By default, the Server Backup Manager takes an automatic nightly backup of the internal H2 database. The H2 database stores internal data for users, groups, task history and other information.
{color:windowtext}Without the internal H2 database the manager will not function.{color}{color:windowtext} {color}{color:windowtext}The H2 database directory along with the backups are stored in the data directory of the installation path. From the Linux command prompt the commands below can used to view and restore the damaged H2 database.{color}{color:windowtext} {color}
{color:windowtext}The command below shows the live h2 directory along with the two available backups. {color}{color:windowtext} {color}
{code}# ls -l /usr/sbin/r1soft/data/
drwx------ 2 root root 4096 Jan 5 18:00 h2
drwx------ 2 root root 4096 Jan 2 02:00 h2-backup-current
drwx------ 2 root root 4096 Jan 1 02:00 h2-backup-old
----------
h2 = Current (active) database
h2-backup-current = The most recent system backup
h2-backup-old = The oldest system backup
{code}
{color:windowtext}Rename and replace the h2 directory t{color}{color:windowtext}o restore a backup copy of the H2 database:{color}{color:windowtext} {color}
{color:windowtext}{*}{+}1. Change directories to the R1Soft data folder:+{*}{color}
{color:windowtext}\# cd /{color}{color:windowtext}usr{color}{color:windowtext}/{color}{color:windowtext}sbin{color}{color:windowtext}/r1soft/data{color}{color:windowtext} {color}
{color:windowtext}{*}{+}2. Make a backup of the original h2 directory:+{*}{color}
{color:windowtext}\# mv /{color}{color:windowtext}usr{color}{color:windowtext}/{color}{color:windowtext}sbin{color}{color:windowtext}/r1soft/data/h2 h2.backup{color}{color:windowtext} {color}
{color:windowtext}{*}{+}3. Choose a backup and copy it as the h2 folder :+{*}{color}
{color:windowtext}\# cp -{color}{color:windowtext}rv{color}{color:windowtext} h2-backup-current h2{color}{color:windowtext} {color}
{color:windowtext}{*}{+}4. Verify the new h2 is in place:+{*}{color}
{color:windowtext}\# ls \-l /{color}{color:windowtext}usr{color}{color:windowtext}/{color}{color:windowtext}sbin{color}{color:windowtext}/r1soft/data{color}{color:windowtext} {color}
{color:windowtext}{*}{+}5. Restart the SBM service:+{*}{color}
{color:windowtext}\# {color}{color:windowtext}systemctl{color}{color:windowtext} restart {color}{color:windowtext}sbm{color}{color:windowtext}\-server{color}{color:windowtext} {color}
{color:windowtext}Or{color}{color:windowtext} {color}
{color:windowtext}\# /{color}{color:windowtext}etc{color}{color:windowtext}/{color}{color:windowtext}init.d{color}{color:windowtext}/{color}{color:windowtext}cdp{color}{color:windowtext}\-server start.{color}{color:windowtext} {color}
{color:windowtext}The Server Backup Manager should now start as normal with the backup h2 database in place.{color}{color:windowtext} {color}
{note}After performing these steps, some fields like Policy/Protected Machine status(Success/Failure), Task History, Report Previews will be reset. This is expected behavior as this information is not included in the nightly system backup.{note}
{kb-related-articles}
{color:windowtext}In certain scenarios it is possible to damage the Server Backup Manager internal database, resulting in a Backup Manager that fails to start. Causes for H2 database damage include (but are not limited to) disk or file system corruption, memory exhaustion during key transactions, or allowing the system to run out of disk space. {color}{color:windowtext} {color}
{color:windowtext}This article will guide you through restoring the H2 database from a backup copy. {color}{color:windowtext} {color}
{info}{color:windowtext}Before performing this task, it is recommended that the Server Backup Manager be placed into into{color} {color:windowtext}[Maintenance Mode|ServerBackupManager:Manager Options]{color}{color:windowtext}, to reduce the chance of data corruption.{color}
{color:windowtext}Once all running and queued tasks have completed, you may safely stop the Backup Manager service.{color}{info}
h2. Solution
----
By default, the Server Backup Manager takes an automatic nightly backup of the internal H2 database. The H2 database stores internal data for users, groups, task history and other information.
{color:windowtext}Without the internal H2 database the manager will not function.{color}{color:windowtext} {color}{color:windowtext}The H2 database directory along with the backups are stored in the data directory of the installation path. From the Linux command prompt the commands below can used to view and restore the damaged H2 database.{color}{color:windowtext} {color}
{color:windowtext}The command below shows the live h2 directory along with the two available backups. {color}{color:windowtext} {color}
{code}# ls -l /usr/sbin/r1soft/data/
drwx------ 2 root root 4096 Jan 5 18:00 h2
drwx------ 2 root root 4096 Jan 2 02:00 h2-backup-current
drwx------ 2 root root 4096 Jan 1 02:00 h2-backup-old
----------
h2 = Current (active) database
h2-backup-current = The most recent system backup
h2-backup-old = The oldest system backup
{code}
{color:windowtext}Rename and replace the h2 directory t{color}{color:windowtext}o restore a backup copy of the H2 database:{color}{color:windowtext} {color}
{color:windowtext}{*}{+}1. Change directories to the R1Soft data folder:+{*}{color}
{color:windowtext}\# cd /{color}{color:windowtext}usr{color}{color:windowtext}/{color}{color:windowtext}sbin{color}{color:windowtext}/r1soft/data{color}{color:windowtext} {color}
{color:windowtext}{*}{+}2. Make a backup of the original h2 directory:+{*}{color}
{color:windowtext}\# mv /{color}{color:windowtext}usr{color}{color:windowtext}/{color}{color:windowtext}sbin{color}{color:windowtext}/r1soft/data/h2 h2.backup{color}{color:windowtext} {color}
{color:windowtext}{*}{+}3. Choose a backup and copy it as the h2 folder :+{*}{color}
{color:windowtext}\# cp -{color}{color:windowtext}rv{color}{color:windowtext} h2-backup-current h2{color}{color:windowtext} {color}
{color:windowtext}{*}{+}4. Verify the new h2 is in place:+{*}{color}
{color:windowtext}\# ls \-l /{color}{color:windowtext}usr{color}{color:windowtext}/{color}{color:windowtext}sbin{color}{color:windowtext}/r1soft/data{color}{color:windowtext} {color}
{color:windowtext}{*}{+}5. Restart the SBM service:+{*}{color}
{color:windowtext}\# {color}{color:windowtext}systemctl{color}{color:windowtext} restart {color}{color:windowtext}sbm{color}{color:windowtext}\-server{color}{color:windowtext} {color}
{color:windowtext}Or{color}{color:windowtext} {color}
{color:windowtext}\# /{color}{color:windowtext}etc{color}{color:windowtext}/{color}{color:windowtext}init.d{color}{color:windowtext}/{color}{color:windowtext}cdp{color}{color:windowtext}\-server start.{color}{color:windowtext} {color}
{color:windowtext}The Server Backup Manager should now start as normal with the backup h2 database in place.{color}{color:windowtext} {color}
{note}After performing these steps, some fields like Policy/Protected Machine status(Success/Failure), Task History, Report Previews will be reset. This is expected behavior as this information is not included in the nightly system backup.{note}
{kb-related-articles}