Backup Management

Download this manual as a PDF file

This section describes how to prepare to back up your SL1 system, to define and run your backups, and to restore from different backup types.

Use the following menu options to navigate the SL1 user interface:

  • To view a pop-out list of menu options, click the menu icon ().
  • To view a page containing all of the menu options, click the Advanced menu icon ().

Types of SL1 Backups

SL1 allows you to define three types of backups for your system:

  • Configuration Backups, which include the core database tables and files required to restore an SL1 system. A configuration backup includes scope and policy information, but not performance data, data collected using configuration Dynamic Applications, events, or logs.
  • Full Backups, which include all SL1 databases and tables. A full backup does not back up the configuration files in /etc/backup.conf. As a result, PhoneHome configuration files are not backed up in a full backup; you can back up PhoneHome files and other configuration files in a configuration backup.
  • Disaster Recovery Backups, which include a full backup of the disaster recovery database for SL1 systems configured for disaster recovery (DR). The DR backup is similar to the full backup.

If you have a large SL1 system and large backup files, you have the option to perform standard configuration or full backups on the disaster recovery Database Server. This is different than performing a disaster recovery backup.

The Backup Management page (System > Settings > Backup) lets you define your backups and run them on demand.

ScienceLogic does not support vmotion or VMware Snapshots for backups of data. For backup purposes, ScienceLogic supports only ScienceLogic backups to remote storage. Be advised that vmotion and VMware Snapshots can cause SL1 outages.

Configuration Backups

A configuration backup stores a copy of the core database tables that are required to restore an SL1 system. Configuration backups use the "MySQL dump" tool to create backups.

Note the following information about configuration backups:

  • SL1 automatically retains your last seven configuration backups, but will retain only one back up per day. If more than one configuration backup is created on the same day, SL1 retains the most recent one.
  • SL1 can launch configuration backups automatically at the interval you specify.
  • During configuration backup, the ScienceLogic database remains online.
  • When the configuration backup starts, SL1 creates a temporary mount point to your remote share in /data.local/backup/remote<unix_timestamp>.
  • If you have a large system and very large backup files, you can use an alternative method to perform backups that reduces performance issues during backup. For more information, see the section Performing Config Backups and Full Backups on a Disaster Recovery Database Server.

What Does a Configuration Backup Include?

A configuration backup includes:

  • Scope and policy information, but not performance data, data collected using configuration Dynamic Applications, or events.
  • By default, the following files are backed up during a configuration backup:
    • /etc/backup.conf
    • /etc/corosync/corosync.conf
    • /etc/drbd.d/r0.res
    • /etc/drbd-proxy.license
    • /etc/hosts
    • /etc/my.cnf.d/silo_mysql.cnf
    • /etc/nginx/*
    • /etc/phonehome/*
    • /etc/php-fpm.d/*.conf
    • /etc/postfix/main.cf
    • /etc/silo.conf
    • /etc/siteconfig/*
    • /etc/ssh/*.key
    • /etc/ssh/*.pub
    • /etc/sysconfig/network-scripts/ifcfg-*
    • /etc/sysctl.d/*
    • /etc/systemd/system/mariadb.service.d/*.conf
    • /opt/em7/nextui/nextui.conf
    • /usr/libexec/postfix/main.cf
    • /var/log/em7/*
  • All files and folders specified in /etc/backup.conf. If you have additional files that you want to include in configuration backups, you can include them in the file /etc/backup.conf. For more information, see the section on Adding Files to Include in Configuration Backups.
  • The following databases:
    • master. Includes system-level settings for SL1, Dynamic Application definitions and alignments, run book automation and action policies, monitoring policy definitions, and credentials.
    • master_access. Includes user account information, access keys, and access hooks.
    • master_ap2. Includes files from the new UI, including files from Business Services.
    • master_biz. Includes asset information, dashboards, distribution lists, document templates, IT Service policy information, organization information, product SKU information, RSS feeds, ticketing information, and user preferences. By default, configuration backups do not include the ticket_external_requests table from the master_biz database.
    • master_custom. Includes GUI customizations, dashboard widget definitions, and PowerPack files.
    • master_dev. Includes information associated with device records, excluding performance data, data collected using configuration Dynamic Applications, events, or logs.
    • master_dns. Includes DNS information.
    • master_events. The configuration backup includes only the event_suppressions table from this database. This table stores event suppression settings.

    • master_filestore. Includes information about files, PowerPacks, and notes. By default, configuration backups do not include the tables metadata_system_package, metadata_system_patch, storage_system_package, and storage_system_patch .

    • master_platform. Includes information about ScienceLogic appliances.
    • master_reports. Includes custom report definitions.
    • mysql. Contains the configuration settings for the MariaDB database.
    • scheduler. Includes all instances of scheduled items: reports, discovery sessions, etc.
    • sysinfo. Contains the configuration settings for High Availability, Disaster Recovery, and PhoneHome Collectors.

Full Backups

A full backup creates a complete backup of the ScienceLogic database. Full backups use a built-in tool call MariaBackup.

Note the following information about full backups:

  • SL1 can launch full backups automatically at the interval you specify.
  • During a full backup, the ScienceLogic database remains online.
  • If you have a large system and very large backup files, you can use an alternative method to perform backups that reduces performance issues during backup. For more information, see the section Performing Config Backups and Full Backups on a Disaster Recovery Database Server.

What Does a Full Backup Include?

A full backup includes all databases and tables.

A full backup does not back up the configuration files in /etc/backup.conf. As a result, PhoneHome configuration files are not backed up in a full backup; you can back up PhoneHome files and other configuration files in a configuration backup.

For very large SL1 systems, ScienceLogic recommends you use a SAN with snapshot technology to backup and restore data.

If your SL1 System uses AWS RDS (remote database), the Full Backup option is disabled.

Disaster Recovery Backups

Disaster recovery backups are similar to full backups, but are available only for SL1 systems that are configured for disaster recovery (DR).

DR backups temporarily stop replication, mount the database, and run a full backup of the DR database. The process then re-enables replication and performs a partial resynchronization from the primary.

Note the following information about DR backups:

  • DR backups use 'tar' to create a copy and compress the /data.local/db directory.
  • During DR backup, the primary ScienceLogic database remains online.
  • DR backups are not available on two-node high availability (HA) clusters.

What Does a Disaster Recovery Backup Include?

Disaster recovery backups include all configuration data, performance data, and log data.

If your SL1 System uses AWS RDS (remote database), the DR Backup option is disabled.

The Workflow for Backing Up and Restoring SL1

The workflow for backing up SL1 is:

  1. Plan the backup.
  2. Create a backup credential.
  3. Configure the backup.

Once the backup file has been created, should you ever need to restore that backup, the workflow is:

  1. Mount the backup (NFS and SMB shares only).
  2. Restore the backup.
  3. Retain the backup (full and DR backups only).

Planning for SL1 Backups

Before creating a backup of your SL1 system, you must determine the following:

  • The external system or service to which the backup will be stored. Your options are:

    • NFS file share

    • SMB file share

    • S3 storage service

    • It is the responsibility of the system administrator for the external system to create any necessary entries in /etc/fstab required to allow the SL1 system to access the share as root.

  • The hostname or IP address of the system or service to which the backup will be stored.

  • The directory to which you will write the backup.

Creating Backup Credentials

To configure a backup, you must include a credential that allows SL1 to write to the external systems where you will store the backups. There are two types of credentials that you can create for this task:

The sections below describe how to create both credential types.

Creating an S3 Backup Credential

You can use an S3 storage service to store configuration backups for SL1. To do so, you will need to create a credential that enables SL1 to connect to the S3 service. SL1 includes an S3 Backup credential type, which uses field names and terminology specific to S3 services, that you can use to connect with your S3 service.

SL1 supports the use of Amazon Web Services (AWS) or MinIO for S3 backup storage.

To define an S3 backup credential:

  1. Go to the Credentials page (Manage > Credentials).
  2. Click the Create New button and then select Create S3 Backup Credential. The Create Credential modal page appears.
  3. Supply values in the following fields:

  • Name. Type a unique name for the credential. Can be any combination of alphanumeric characters, up to 64 characters.
  • All Organizations. Toggle on (blue) to align the credential to all organizations, or toggle off (gray) and then select one or more specific organizations from the What organization manages this service? drop-down field to align the credential with those specific organizations. For more information about credentials and organizations, see the section Aligning Organizations With a Credential.
  • Timeout (ms). Type the time, in milliseconds, after which SL1 will stop trying to communicate with the S3 storage service.
  • Provider. Select the S3 storage provider you want to use to store the backup. Choices are Amazon Web Services (AWS) S3 and Minio Object Storage.
  • Access Key ID. Type the Access Key ID for the S3 account on which you want to store the backup.
  • Secret Access Key. Type the Secret Access Key for the S3 account on which you want to store the backup.
  • Endpoint. Type the URL of the S3 endpoint. The endpoint URL should not include the bucket name.
  • Region. Select the region of the S3 endpoint.
  • Bucket. Type the name of the S3 bucket on which you want to store the backup.
  • Encryption Password. Type the encryption password for the backup file.
  • Encryption Salt. Type the encryption salt used to safeguard the backup file encryption password.
  1. Click Save & Close.

If you would like to test your credential using the Credential Tester panel, click Save & Test. For detailed instructions on using the Credential Tester panel, see the Using the Credential Tester Panel section.

Creating a Basic/Snippet Backup Credential

If you are backing up your SL1 system to a platform other than an Amazon Web Services S3 bucket, you must create a Basic/Snippet backup credential that allows SL1 to write to the external backup systems.

To create a Basic/Snippet backup credential:

  1. Go to the Credentials page (Manage > Credentials).
  2. Click Create New and select Create Basic/Snippet Credential. The Create Credential modal appears. If you are using the classic SL1 user interface, go to the Credential Management page (System > Manage > Credentials), click the Actions button, and select Create Basic/Snippet Credential to use the Credential Editor modal.
  3. Define values in the following fields:
    • Name. Name of the credential. Can be any combination of alphanumeric characters.
    • Organization. Select All Organizations or select an organization from the drop-down.
    • Hostname/IP. The hostname or IP address.
    • Port. This field is deprecated. Backups will not use this field.
    • Timeout (ms). This field is deprecated. Backups will not use this field.
    • Username. Username to use when connecting to the external system. If you are backing up to NFS-remote, this field is not required.
    • Password. Password to use when connecting to the external system. If you are backing up to NFS-remote, this field is not required.
  1. Click Save & Close.

Configuring Backups

This section describes how to configure SL1 backups.

Depending on the backup type, this process might include multiple steps:

  1. Include additional files or directories (configuration backups only).
  2. View the included databases and tables (configuration backups only).
  3. Define the configuration, full, or disaster recovery backup options.

When you define the backup options, you must determine the external storage protocol and directory on which the backup will be stored. You have the following storage options:

  • NFS mount
  • SMB mount
  • S3 storage service

You cannot store backups on the SL1 Database Server or All-In-One Appliance.

Adding Files to Include in Configuration Backups

All files and directories that are specified in /etc/backup.conf are included in configuration backups. If you have additional files or directories that you want to include in configuration backups, you can edit the /etc/backup.conf file to include them.

To add files or directories that you want to include in configuration backups:

  1. Either go to the console of the SL1 appliance or use SSH to access the server.

  2. Enter the following at the command line:

    sudo vi /etc/backup.conf

  3. Move the cursor below the line that says, "Custom files can be added below this line".

  4. Make the following updates based on what you want to include:

  • To add a file, enter the full directory path and filename.
  • To add a directory or folder, enter an asterisk (*) instead of a filename after the full directory path.
  1. Save your changes and quit the file (:wq).

Viewing the Databases and Tables Included or Excluded from a Configuration Backup

This section applies only to users who are running a version of SL1 prior to 11.2.0. If you are running SL1 11.2.0 or later, you can determine which databases and tables are included or excluded in configuration backups by going to the Backup Management page (System > Settings > Backup) and clicking Advanced Settings in the Configuration Backup pane. For more information, see the section on Defining a Configuration Backup.

This process does not apply to full or disaster recovery backups.

The Database Tool page is available only in versions of SL1 prior to 12.2.1 and displays only for users that have sufficient permissions to access the page.

To see which databases and tables are included in configuration backups in your environment:

  1. Navigate to the Database Tool page (System > Tools > DB Tool). The Database Tool page displays only for users that have sufficient permissions to access that page.

  2. In the Select Database field, select Master.

  3. In the "SQL Query" field, enter this query:

    SELECT backup_db_list FROM 'system_settings_backup' WHERE id = 1

To see which databases and tables are excluded in configuration backups in your environment:

  1. Navigate to the Database Tool page (System > Tools > DB Tool).

  2. In the Select Database field, select Master.

  3. In the "SQL Query" field, enter this query:

    SELECT backup_cb_table_exclude FROM 'system_settings_backup' WHERE id = 1

Defining a Configuration Backup

To define and schedule a configuration backup:

  1. Go to the Backup Management page (System > Settings > Backup).

  2. In the Configuration Backup pane, provide values in the following fields:

    • Every. Together with the Interval field, specifies the frequency of the backup.

    • Interval. Together with the Every field, you must specify how frequently SL1 should automatically execute a configuration backup. Your choices are:

      • Disabled. Configuration backups are disabled. If you want to run on-demand configuration backups only, you do not need to change this setting.
      • Day. SL1 will execute configuration backups daily as specified (for example, every 2 days).
      • Week. SL1 will execute configuration backups weekly as specified (for example, every 2 weeks).
      • Month. SL1 will execute configuration backups monthly as specified (for example, every 1 month).
    • Start Time / Date. If you enabled configuration backups, you must specify the start time. You must specify the date on which you want configuration backups to begin, as well as the time of day you want the backups to run. For example, you might want to run configuration backups during a maintenance window late at night. Click the field to open a calendar and time selector.
    • Timezone. Optional. Specify the timezone to use when running a backup. The default is UTC. Use the drop-down list to select the timezone.
    • Configuration Credentials. Select the credential you created for SL1 to use to connect to your external system (NFS, SMB, or S3). For more information, see Creating a Backup Credential.
    • Configuration Protocol. Specify the type of external system where the configuration backup will be stored. Choices are:
      • NFS-Remote. When you select this option, SL1 stores the configuration backup on an NFS share. If you select the NFS-remote option, and your NFS share is hosted on a Solaris system, you must perform the steps listed in the Additional Configuration for Solaris NFS Mounts section.
      • SMB-Remote. When you select this option, SL1 stores the configuration backup on an SMB share.
      • S3. When you select this option, SL1 stores the configuration backup in an S3 bucket.
    • Configuration Subdirectory. Specify a directory on the NFS or SMB share or S3 service in which you would like to store the configuration backup. When entering the subdirectory path, include the leading slash ("/"). On the remote share, the current Unix time will be appended to the directory name to ensure the directory name is unique each time the backup runs. You will need this value as well as your backup credential information and any mount options that you specify in step 3 below if you mount the backup to an NFS or SMB share.
    • Configuration Backup on DR. Select this checkbox if you want to perform configuration backups from the Disaster Recovery Database Server. This alternative method to backing up SL1 can reduce performance issues during backup for users with large systems and very large backup files. For more information, see the section on Performing Configuration and Full Backups on the DR Database Server.

  1. To access additional configuration options for this backup, click Advanced Settings. The set of advanced options that appears are the same fields that you would have populated using SQL queries in versions of SL1 older than 11.2.0. These advanced fields refer to the column names in the SL1 Database:

    • backup_smb_mount_options

    • backups_nfs_mount_options

    • backup_cmd_options

    • comp_cmd_options

    • backup_db_list (JSON)

    • backup_cb_table_exclude (JSON)

      For more information about these Advanced Settings, contact ScienceLogic Support.

      You will need the values from the mount option fields as well as your backup credential information and the value you entered in the Configuration Subdirectory field in step 2 above when mounting an NFS or SMB share.

  2. Click Save. SL1 will execute the configuration backup at the specified interval, starting on the date you specified in the Start Time / Date field and using the time you specified in the Start Time / Date field.

  3. To run the backup immediately, click the Backup Now button under Configuration Backup in the Immediate Backup section of the Backup Management page. SL1 will run the backup immediately, as well as running the scheduled backup you configured in this procedure.

Defining a Full Backup

Full backups include all databases and tables. SL1 automatically launches this backup at the frequency and time you specify.

To define and schedule a full backup:

  1. Go to the Backup Management page (System > Settings > Backup).

  2. In the Full Backup pane, provide values in the following fields:

    • Every. Together with the Interval field, specifies the frequency of the backup.
    • Interval. Together with the Every field, specifies how frequently SL1 should automatically execute a full backup. Your choices are:
      • Disabled. Full backups are disabled.
      • Day. SL1 will execute full backups daily as specified (for example, every 2 days).
      • Week. SL1 will execute full backups weekly as specified (for example, every 2 weeks).
      • Month. SL1 will execute full backups monthly as specified (for example, every 1 month).
    • Start Time / Date. If you enabled full backups, you must specify the start time. You must specify the date on which you want configuration backups to begin, as well as the time of day you want the backups to run. For example, you might want to run configuration backups during a maintenance window late at night. Click the field to open a calendar and time selector.
    • Timezone. Optional. Specify the timezone to use when running a backup. The default is UTC. Use the drop-down list to select the timezone.
    • Full Credentials. Select the credential you created for SL1 to use to connect to your external system (NFS, SMB, or S3). For more information, see Creating a Backup Credential.
    • Full Protocol. Specify the type of external system where the full backup will be stored. Choices are:
      • NFS-Remote. When you select this option, SL1 stores the backup on an NFS share. If you select the NFS-remote option, and your NFS share is hosted on a Solaris system, you must perform the steps listed in the Additional Configuration for Solaris NFS Mounts section.
      • SMB-Remote. When you select this option, SL1 stores the backup on an SMB share.
      • S3. When you select this option, SL1 stores the backup in an S3 bucket.
    • Full Subdirectory. Specify a directory on the NFS or SMB share or S3 service in which you would like to store the full backup. When entering the subdirectory path, include the leading slash ("/"). On the remote share, the current Unix time will be appended to the directory name to ensure the directory name is unique each time the backup runs. You will need this value as well as your backup credential information and any mount options that you specify in step 3 below if you mount the backup to an NFS or SMB share.
    • Full Backup on DR. Select this checkbox if you want to perform full backups from the Disaster Recovery Database Server. This alternative method to backing up SL1 can reduce performance issues during backup for users with large systems and very large backup files. For more information, see the section on Performing Configuration and Full Backups on the DR Database Server.
    • Full Retention Period. Specify in days how long you want SL1 to keep full backups before deleting them. SL1 will keep the number you specify, plus one additional backup. The default is 0. This field displays in SL1 version 11.2.0 and later. If you are running a version prior to 11.2.0, you can specify the retention period for full backups using the Database Tool.

  3. To access additional configuration options for this backup, click Advanced Settings. The set of advanced options that appears are the same fields that you would have populated using SQL queries in versions of SL1 older than 11.2.0. These advanced fields refer to the column names in the SL1 Database:

    • backup_smb_mount_options

    • backups_nfs_mount_options

    • backup_cmd_options

    • comp_cmd_options

      Also, the Custom mariabackup Options field lets you specify one or more custom backup options. For details on these options, see https://mariadb.com/kb/en/mariabackup-options/.

      For more information about these Advanced Settings, contact ScienceLogic Support.

  4. Click Save. SL1 will execute the full backup at the frequency and time you specified in the Every, Interval, and Start Time/Date fields.

  5. To run the backup immediately, click the Backup Now button under Full Backup. SL1 will immediately run the backup and will still run the backup at the frequency and time you specified in the Backup Frequency and Start Time fields.

Defining a Disaster Recover Backup

To define and schedule a DR backup:

  1. Go to the Backup Management page (System > Settings > Backup).

  2. In the DR Backup pane, provide values in the following fields:

    • Every. Together with the Interval field, specifies the frequency of the backup.

    • Interval. Together with the Every field, you must specify how frequently SL1 should automatically execute a DR backup. Your choices are:

      • Disabled. DR backups are disabled. If you want to run on-demand DR backups only, you do not need to change this setting.

      • Day. SL1 will execute DR backups daily as specified (for example, every 2 days).

      • Week. SL1 will execute DR backups weekly as specified (for example, every 2 weeks).

      • Month. SL1 will execute DR backups monthly as specified (for example, every 1 month).

    • Start Time/Date. If you enabled DR backups, you must specify the start time. You must specify the date on which you want DR backups to begin, as well as the time of day you want the backups to run. For example, you might want to run DR backups during a maintenance window late at night. Click the field to open a calendar and time selector.

    • Timezone. Optional. Specify the timezone to use when running a backup. The default is UTC. Use the drop-down list to select the timezone.

    • DR Credentials. Select the credential you created for SL1 to use to connect to your external system (NFS, SMB, or S3). For more information, see Creating a Backup Credential.

    • DR Protocol. Specifies where SL1 should store the DR backups. Choices are:

      • NFS-Remote. When you select this option, SL1 stores the DR backup on an NFS share. If you select the NFS-remote option, and your NFS mount is hosted on a Solaris system, you must perform the steps listed in the Additional Configuration for Solaris NFS Mounts section of this chapter.
      • SMB-Remote. When you select this option, SL1 stores the DR backup on an SMB share.
      • S3. When you select this option, SL1 stores the DR backup in an S3 bucket.

    • DR Subdirectory. Specify a directory on the NFS or SMB share or S3 service in which you would like to store the DR backup. When entering the subdirectory path, include the leading slash ("/"). On the remote share, the current Unix time will be appended to the directory name to ensure the directory name is unique each time the backup runs. You will need this value as well as your backup credential information and any mount options that you specify in step 3 below if you mount the backup to an NFS or SMB share.

    • DR Retention Period. Specify in days how long you want SL1 to keep DR backups before deleting them. SL1 will keep the number you specify, plus one additional backup. The default is 0. This field displays in SL1 version 11.2.0 and above. If you are running a version prior to 11.2.0, you can specify the retention period for DR backups using the Database Tool.

  3. To access additional configuration options for this backup, click Advanced Settings. The set of advanced options that appears are the same fields that you would have populated using SQL queries in versions of SL1 older than 11.2.0. These advanced fields refer to the column names in the SL1 Database:

    • backup_smb_mount_options

    • backups_nfs_mount_options

    • backup_cmd_options

    • comp_cmd_options

      For more information about these Advanced Settings, contact ScienceLogic Support.

  4. Click Save. SL1 will execute the DR backup at the frequency and time you specified in the Backup Frequency and Start Time fields.

  5. To run the backup immediately, click the Backup Now button under DR Backup. SL1 will immediately run the backup and will still run the backup at the frequency and time you specified in the Backup Frequency and Start Time fields.

Mounting Backup Files

If your backup is stored in an NFS or SMB share, then you must mount the backup before you can use it to restore your SL1 system. This section describes how to mount these two share types.

Mounting NFS Shares

Before beginning this process, you should have the following information:

  • The IP address that is defined in the backup credential
  • Based on which type of backup files you are mounting, the mount directory that is defined in the Configuration Subdirectory, Full Subdirectory, or DR Subdirectory field on the Backup Management page (System > Settings > Backup)
  • Based on which type of backup files you are mounting, the value from the Configuration NFS Mount Options, Full NFS Mount Options, or DR NFS Mount Options field, which you can access by clicking Advanced Settings on the Backup Management page (System > Settings > Backup)

To mount a remote NFS share:

  1. Either go to the console of the Database Server where you want to restore the backup, or use SSH to log in to the Database Server, and log in as user em7admin.

  2. Start a tmux session, if necessary:

    tmux

    If you are running a version of SL1 that starts tmux by default, you can skip this step.

  3. Open the /data.local/db directory:

    sudo cd /data.local/db

  4. Execute the following command to mount the remote NFS share:

    sudo /bin/mount -t nfs <IP from backup credential>:/<subdirectory> /mnt -o <NFS mount options>

    where:

    • <IP from backup credential> is the IP address you defined in your backup credential.
    • <subdirectory> is the mount directory that is defined in the Configuration Subdirectory, Full Subdirectory, or DR Subdirectory field on the Backup Management page (System > Settings > Backup) to store the backup.
    • <NFS mount options> is the value from the Configuration NFS Mount Options, Full NFS Mount Options, or DR NFS Mount Options field, which you can access by clicking Advanced Settings on the Backup Management page (System > Settings > Backup).

    For example:

    sudo /bin/mount -t nfs 10.64.70.63:/backups /mnt -o lookupcache=none

  5. After entering one of the above commands, if you are prompted to provide a password, enter the password that you defined in your backup credential.

Mounting SMB Shares

Before beginning this process, you should have the following information:

  • The IP address and username that is defined in the backup credential
  • Based on which type of backup files you are mounting, the mount directory that is defined in the Configuration Subdirectory, Full Subdirectory, or DR Subdirectory field on the Backup Management page (System > Settings > Backup)
  • Based on which type of backup files you are mounting, the value from the Configuration SMB Mount Options, Full SBM Mount Options, or DR SMB Mount Options field, which you can access by clicking Advanced Settings on the Backup Management page (System > Settings > Backup)

To mount a remote SMB share:

  1. Either go to the console of the Database Server where you want to restore the backup, or use SSH to log in to the Database Server, and log in as user em7admin.

  2. Start a tmux session, if necessary:

    tmux

    If you are running a version of SL1 that starts tmux by default, you can skip this step.

  3. Open the /data.local/db directory:

    sudo cd /data.local/db

  4. Execute the following command to mount the remote SMB share:

    sudo /bin/mount -t cifs //<IP from backup credential>/<full subdirectory> /mnt -o user=<username from backup credential>,<SMB mount options>

    where:

    • <IP from backup credential> is the IP address you defined in your backup credential.
    • <username from backup credential> is the username you defined in your backup credential.
    • <subdirectory> is the mount directory that is defined in the Configuration Subdirectory, Full Subdirectory, or DR Subdirectory field on the Backup Management page (System > Settings > Backup) to store the backup.
    • <SMB mount options> is the value from the Configuration SMB Mount Options, Full SBM Mount Options, or DR SMB Mount Options field, which you can access by clicking Advanced Settings on the Backup Management page (System > Settings > Backup).

    For example:

    sudo /bin/mount -t cifs //10.64.70.48/Lab_Backups /mnt -o user=administrator,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=600,gid=607,setuids,noperm,sec=ntlm,vers=1.0

  5. After entering the command, if you are prompted to provide a password, enter the password that you defined in your backup credential.

Restoring Backups

This section describes how to restore the following backup types:

 To complete the restore steps, you must be familiar with how to edit a file using the vi text editor. If you need assistance with these steps, please contact ScienceLogic Support.

Restoring a Configuration Backup from an S3 Bucket

If you have performed configuration backups, you can restore your system from a configuration backup in the event of data corruption or other failure. The configuration backup file contains one SQL (.sql) file for each database that was included in the configuration backup.

The following steps assume that the Database Server to which you are restoring the backup has not been previously configured and is on the same revision number as the Database Server that was used to create the backup file.

These steps assume that the Database Server to which you are restoring the backup has not been previously configured and is on the same platform revision number as the Database Server used to create the backup file.

To restore a database using configuration backup files that were stored on an S3 storage service:

  1. Either go to the console of the Database Server where you want to restore the backup, or use SSH to log in to the Database Server.

  2. Log in as user em7admin and assume root user privileges by using the following command:

    sudo -s

  3. Execute the following commands at the command line to uncompress the backup file, where <new_subdirectory> is a directory you create that will be the destination for your uncompressed files:

    mkdir /data.local/db/<new_subdirectory>

    cd /data.local/db/<new_subdirectory>

    For example:

    mkdir /data.local/db/my_backups

    cd /data.local/db/my_backups

  4. Run the following commands:

    export RCLONE_CONFIG_BACKUP_BUCKET_ACL="private"
export RCLONE_CONFIG_BACKUP_CHUNK_SIZE="128Mi"
export RCLONE_CONFIG_BACKUP_TYPE="s3"
export RCLONE_CONFIG_BACKUP_UPLOAD_CONCURRENCY="4"
export RCLONE_CONFIG_BACKUP_PROVIDER="<--- Provider --->"
export RCLONE_CONFIG_BACKUP_ACCESS_KEY_ID="<--- Access Key ID --->"
export RCLONE_CONFIG_BACKUP_SECRET_ACCESS_KEY="<--- Secret Access Key --->"
export RCLONE_CONFIG_BACKUP_ENDPOINT="<--- Endpoint URL --->"
export RCLONE_CONFIG_BACKUP_REGION="<--- Region --->"
export RCLONE_CONFIG_CRYPT_TYPE="crypt"
export RCLONE_CONFIG_CRYPT_DIRECTORY_NAME_ENCRYPTION="false"
export RCLONE_CONFIG_CRYPT_FILENAME_ENCRYPTION="off"
export RCLONE_CONFIG_CRYPT_REMOTE="backup:/<--- Bucket --->/<--- Folder --->"
export RCLONE_CONFIG_CRYPT_PASSWORD="`rclone obscure '<--- Encryption Password --->'`"
export RCLONE_CONFIG_CRYPT_PASSWORD2="`rclone obscure '<--- Encryption Salt --->'`"
rclone cat crypt:<--- File Name without the .bin --->|pigz -d|tar xv
  5. Your target directory now contains configuration backup files. Copy these backup files to their original locations. For example:
    cp -r opt /
cp -r var /
cp -r etc /
cp -r usr /
  6. To restore a database, execute the following command using the username of a user that has administrative privileges in MySQL:
    silo_mysql <name_of_database> -u <username> -p<password> < <name_of_database>.sql

    Do not include a space between -p and the password.

    For example, to restore the database "master" as the user "root" with the password "examplepassword", perform the following command:

    silo_mysql master -u root -pexamplepassword < master.sql

  7. To restore all the databases that are included in the backup file, repeat step 5 for each .sql file.
  8. Re-license the Database Server using the standard licensing procedure. For details, see the section licensing a Database Server.

Restoring a Configuration Backup from a Remote NFS or SMB Share

If you have performed configuration backups, you can restore your system from a configuration backup in the event of data corruption or other failure. The configuration backup file contains one SQL (.sql) file for each database that was included in the configuration backup.

The following steps assume that the Database Server to which you are restoring the backup has not been previously configured and is on the same revision number as the Database Server that was used to create the backup file.

To restore a database using the configuration backup file:

  1. Either go to the console of the Database Server where you want to restore the backup, or use SSH to log in to the Database Server.

  2. Log in as user em7admin and assume root user privileges by using the following command:

    sudo -s

  3. Execute the following commands at the command line to uncompress the backup file, where <new_subdirectory> is a directory you create that will be the destination for your uncompressed files:

    mkdir /data.local/db/<new_subdirectory>

    cd /data.local/db/<new_subdirectory>

    For example:

    mkdir /data.local/db/my_backups

    cd /data.local/db/my_backups

  4. Execute the following command to extract the backup into your directory, where <full path and filename for backup.tgz> is the location and name of your backup file:

    pigz -dc <full path and file name for backup.tgz> | tar xv

    For example:

    pigz -dc /mnt/db1_config_2021-02-01_21-00-00.tgz | tar xv

  5. Your target directory will now contain one SQL file for each database included in the backup. Copy the configuration backup files to their original locations. For example:

    cp -r opt /
cp -r var /
cp -r etc /
cp -r usr /

  6. To restore a database, execute the following command using the username and password of a user that has administrative privileges in MySQL:

    7. silo_mysql <name_of_database> -u <username> -p<password> < <name_of_database>.sql

    Do not include a space between -p and the password.

    For example, to restore the database "master" as the user "root" with the password "examplepassword", perform the following command:

    silo_mysql master -u root -pexamplepassword < master.sql

  7. To restore all the databases that are included in the backup file, repeat step 6 for each .sql file.

  8. Re-license the Database Server using the standard licensing procedure. For details, see the section licensing a Database Server.

Restoring a Full Backup from an S3 Bucket

These steps assume that the Database Server to which you are restoring the backup has not been previously configured and is on the same platform revision number as the Database Server used to create the backup file.

To restore a SL1 system using a full backup file from an S3 bucket:

  1. Either go to the console of the Database Server where you want to restore the backup, or use SSH to log in to the Database Server.
  2. Log in as user em7admin and then assume root privileges:

    sudo -s

  3. Execute the following commands:

    Executing this command will stop the database. SL1 will not be operational until you complete the restore procedure.

    4. siloctl stop --full
systemctl stop mariadb
rm -rf /data.local/db/*
cd /data.local/db/
export RCLONE_CONFIG_BACKUP_BUCKET_ACL="private"
export RCLONE_CONFIG_BACKUP_CHUNK_SIZE="128Mi"
export RCLONE_CONFIG_BACKUP_TYPE="s3"
export RCLONE_CONFIG_BACKUP_UPLOAD_CONCURRENCY="4"
export RCLONE_CONFIG_BACKUP_PROVIDER="<--- Provider --->"
export RCLONE_CONFIG_BACKUP_ACCESS_KEY_ID="<--- Access Key ID --->"
export RCLONE_CONFIG_BACKUP_SECRET_ACCESS_KEY="<--- Secret Access Key --->"
export RCLONE_CONFIG_BACKUP_ENDPOINT="<--- Endpoint URL --->"
export RCLONE_CONFIG_BACKUP_REGION="<--- Region --->"
export RCLONE_CONFIG_CRYPT_TYPE="crypt"
export RCLONE_CONFIG_CRYPT_DIRECTORY_NAME_ENCRYPTION="false"
export RCLONE_CONFIG_CRYPT_FILENAME_ENCRYPTION="off"
export RCLONE_CONFIG_CRYPT_REMOTE="backup:/<--- Bucket --->/<--- Folder --->"
export RCLONE_CONFIG_CRYPT_PASSWORD="`rclone obscure '<--- Encryption Password --->'`"
export RCLONE_CONFIG_CRYPT_PASSWORD2="`rclone obscure '<--- Encryption Salt --->'`"
time rclone cat crypt:<--- Full Backup File Name without the .bin --->|pigz -d|mbstream -vvv -x -C .
  4. Execute the following command, where <directory for data extraction is the directory you created in the previous step:

    more /<directory for data extraction>/backup-my.cnf

  5. Locate the line that looks like the following. Copy or write down the exact text that appears, such as:

    innodb_data_file_path=ibdata1:354M;ibdata2:500M:autoextend:max:8925M

  6. Execute the following command to edit the /etc/my.cnf.d/silo_mysql.cnf file:

    vimysql

  7. Add the line you copied in Step 5 to the mysql.siteconfig file, such as:

    innodb_data_file_path=ibdata1:354M;ibdata2:500M:autoextend:max:8925M

  8. Save the file and exit the editor:

    :wq

  9. Execute the following command to build the updated configuration file:

    vimysql -f

  10. Execute the following commands:

    The following process can take a long time to complete. To ensure the command is not interrupted, you should run the command in a "tmux" session.

    To do so: 

    • Open a tmux session:

      tmux

    • Execute the following commands:

      mariabackup --prepare -use-memory=<80% of available memory> --target- dir=/data.local.db

      cd /data.local/db

      chown -R mysql.mysql *

      systemctl start mariadb

    These commands assume you have changed directories to the directory that contains the extracted backup files. If you want to run these commands from a location other than the location of the extracted backup files, then you must enter a value after "target-dir=" to point to the directory where the extracted files are located. To learn more about MariaBackup, see https://mariadb.com/kb/en/full-backup-and-restore-with-mariabackup/.

    Depending on the size of the backup, the mariabackup command might take a long time to complete.

  11. Because a full database restoration requires the database username and password, you must check the MariaDB username and password that are stored in the silo.conf file.

    If the backup was taken from an SL1 system installed from or upgraded to version 11.3.0 or later, the username will be clientdbuser.

    If the backup was taken from an SL1 system that was installed from or last upgraded to a version prior to 11.3.0, the username will be root.

    • To check the username and password in the silo.conf file, enter the following command:

      visilo

    • Check (and if necessary, update) the values in the dbuser, dbpasswd, and ap_pass fields in both the [LOCAL] and [CENTRAL] sections.

    • Save and close the file:

      :wq

      Upon saving, visilo will validate that the MariaDB passwords work. If the passwords fail, ensure that you are entering the correct ones. If the passwords are unknown, you must perform the password recovery and reset procedure described in the section Changing the MariaDB Password on SL1 Appliances.

  12. Restart SL1:

    siloctl start --full

  13. Re-license the Database Server using the standard licensing procedure. For details, see the section Licensing a Database Server.

    The start process from step 12 will fail and restart until your SL1 system is licensed. This is expected behavior.

Restoring a Full Backup from a Remote NFS or SMB Share

The following steps assume that the Database Server to which you are restoring the backup has not been previously configured and is on the same revision number as the Database Server that was used to create the backup file.

To restore a SL1 system using a full backup file from an a remote NFS or SMB share:

  1. Either go to the console of the Database Server where you want to restore the backup, or use SSH to log in to the Database Server, and log in as user em7admin.

  2. Stop MariaDB on the Database Server to which you are restoring the backup and remove the existing files in the /data.local/db directory that is used by MariaDB:

    • Execute the following command:

      sudo siloctl stop --full

      Executing this command will stop the database. SL1 will not be operational until you complete the restore procedure.

    • Wait for all services to stop, and then run:

      sudo systemctl stop mariadb

    • After MariaDB stops, run:

      sudo sh -c 'rm -rf /data.local/db/*'

  3. On the Database Server to which you are restoring the backup, extract the database files from the backup files into the /data.local/db directory.

    This process can take a long time to complete. To ensure that the command is not interrupted, you should run the command in a tmux session. You can start a tmux session by running the tmux command.

    • Mount the remote NFS or SMB share.

      • If you are mounting a remote NFS share, run the following command:

        sudo /bin/mount -t nfs <IP from backup credential>:/<full subdirectory> /mnt -o <full NFS mount options>

        where:

        • <IP from backup credential> is the IP address you defined in your backup credential.

        • <full subdirectory> is the directory on a remote NFS, SMB, or S3 mount that you specified in the Full Subdirectory field on the Backup Management page (System > Settings > Backup) to store the backup.

        • <full NFS mount options> is the value from the Full NFS Mount Options field, which you can access by clicking Advanced Settings on the Backup Management page (System > Settings > Backup).

        For example:

        sudo /bin/mount -t nfs 10.64.70.63:/backups /mnt -o lookupcache=none

      • If you are mounting a remote SMB share, run the following command:

        sudo /bin/mount -t cifs //<IP from backup credential>/<full subdirectory> /mnt -o user=<username from backup credential>,<full SMB mount options>

        where:

        • <IP from backup credential> is the IP address you defined in your backup credential.

        • <full subdirectory> is the directory on a remote NFS, SMB, or S3 mount that you specified in the Full Subdirectory field on the Backup Management page (System > Settings > Backup) to store the backup.

        • <username from backup credential> is the username you defined in your backup credential.

        • <full SMB mount options> is the value from the Full SMB Mount Options field, which you can access by clicking Advanced Settings on the Backup Management page (System > Settings > Backup).

        For example:

        sudo /bin/mount -t cifs //10.64.70.48/Lab_Backups /mnt -o user=administrator,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=600,gid=607,setuids,noperm,sec=ntlm,vers=1.0

      After entering one of the above commands, if you are prompted to provide a password, enter the password that you defined in your backup credential.

    • To extract the backup file into your directory, run the following command:

      sudo sh -c 'pigz -dc <full path and file name for backup.gz> | mbstream -x -C /data.local/db/'

      where <full path and filename for backup.gz> is the location and name of your backup file.

      For example:

      sudo sh -c 'pigz -dc /mnt/db1_full_2021-02-01_21-00-00.gz | mbstream -x -C /data.local/db/'

    Optionally, you can create a new tmux session to continue with other tasks while the backup file unpacks in the background:

    • Press "Ctrl + b", type ":new", and then press "Enter". This opens a new tmux session.

    • You can continue to monitor the progress in the original session. After the mbstream command is complete, run the following command:

      watch -n1 'ps -ef |grep "[m]bstream";'

    • You can use "Ctrl +B" and then type "s" to show all tmux sessions and switch between them.

  4. Update the MariaDB configuration:

    • Look up the maximum size limit for the tablespace file from the last time the backup was taken:

      sudo grep "autoextend:max" /data.local/db/backup-my.cnf

    • Copy or write down the output exactly as it appears. You will need this output in a later step. For example:

      innodb_data_file_path=ibdata1:354M;ibdata2:500M:autoextend:max:8925M

    • Execute the following command to open the MariaDB configuration:

      sudo vimysql

    • In the editor, find a line that is similar to the "innodb_data_file_path" output from the example above and replace it with the line you copied or wrote down from that step.

    • Save the file and exit the editor:

      :wq

  5. Ensure that the database files are point-in-time consistent:

    mariabackup --prepare --use-memory=<80% of available memory> --target-dir=/data.local/db

    Depending on the size of the backup, the mariabackup command might take a long time to complete.

  6. Ensure you have proper ownership on the files:

    sudo chown -R mysql:mysql /data.local/db/*

  7. Start MariaDB on the target Database Server:

    8. sudo systemctl start mariadb

  8. Because a full database restoration requires the database username and password, you must check the MariaDB username and password that are stored in the silo.conf file.

    If the backup was taken from an SL1 system installed from or upgraded to version 11.3.0 or later, the username will be clientdbuser.

    If the backup was taken from an SL1 system that was installed from or last upgraded to a version prior to 11.3.0, the username will be root.

    • To check the username and password in the silo.conf file, enter the following command:

      sudo visilo

    • If needed, update the values in the dbuser, dbpasswd, and ap_pass fields in both the [LOCAL] and [CENTRAL] sections.

    • Save and close the file:

      :wq

      Upon saving, visilo will validate that the MariaDB passwords work. If the passwords fail, ensure that you are entering the correct ones. If the passwords are unknown, you must perform the password recovery and reset procedure described in the section Changing the MariaDB Password on SL1 Appliances.

  9. Restart SL1:

    sudo siloctl start --full

  10. Re-license the Database Server using the standard licensing procedure. For details, see the section licensing a Database Server. The process from step 9 will fail and restart until your SL1 system is licensed. This is expected behavior.

Restoring a DR Backup from an S3 Bucket

These steps assume that the Database Server to which you are restoring the backup has not been previously configured and is on the same platform revision number as the Database Server used to create the backup file.

 To complete these steps, you must be familiar with how to edit a file using the vi text editor. If you need assistance with these steps, please contact ScienceLogic Support.

To restore a Database Server using a DR backup file from an S3 bucket, perform the following steps:

  1. Either go to the console of the Database Server where you want to restore the backup or use SSH to access the Database Server.
  1. Log in as user em7admin and sudo to the root account:

    sudo -s

  1. Execute the following commands:

Executing this command will stop the database. SL1 will not be operational until you complete the restore procedure.

    siloctl stop --full
systemctl stop mariadb
rm -rf /data/db/*
cd /data/db
export RCLONE_CONFIG_BACKUP_BUCKET_ACL="private"
export RCLONE_CONFIG_BACKUP_CHUNK_SIZE="128Mi"
export RCLONE_CONFIG_BACKUP_TYPE="s3"
export RCLONE_CONFIG_BACKUP_UPLOAD_CONCURRENCY="4"
export RCLONE_CONFIG_BACKUP_PROVIDER="<--- Provider --->"
export RCLONE_CONFIG_BACKUP_ACCESS_KEY_ID="<--- Access Key ID --->"
export RCLONE_CONFIG_BACKUP_SECRET_ACCESS_KEY="<--- Secret Access Key --->"
export RCLONE_CONFIG_BACKUP_ENDPOINT="<--- Endpoint URL --->"
export RCLONE_CONFIG_BACKUP_REGION="<--- Region --->"
export RCLONE_CONFIG_CRYPT_TYPE="crypt"
export RCLONE_CONFIG_CRYPT_DIRECTORY_NAME_ENCRYPTION="false"
export RCLONE_CONFIG_CRYPT_FILENAME_ENCRYPTION="off"
export RCLONE_CONFIG_CRYPT_REMOTE="backup:/<--- Bucket --->/<--- Folder --->"
export RCLONE_CONFIG_CRYPT_PASSWORD="`rclone obscure '<--- Encryption Password --->'`"
export RCLONE_CONFIG_CRYPT_PASSWORD2="`rclone obscure '<--- Encryption Salt --->'`"
time rclone cat crypt:<--- Full Backup File Name without the .bin --->|pigz -d|mbstream -vvv -x -C .
rclone cat crypt:<--- File Name without the .bin --->|pigz -d|tar xv

This process can take a long time to complete. To ensure the command is not interrupted, you should run the command in a "tmux" session.

  1. Execute the following command, where <directory for data extraction> is the directory you created in the previous step:

    more /<directory for data extraction>/backup-my.cnf

  2. Locate the line that looks like the following. Copy or write down the exact text that appears, such as:

    innodb_data_file_path=ibdata1:354M;ibdata2:500M:autoextend:max:8925M

  3. Execute the following command to edit the /etc/my.cnf.d/silo_mysql.cnf file:

    vimysql

  4. Add the line you copied in Step 5 to the mysql.siteconfig file, such as:

    innodb_data_file_path=ibdata1:354M;ibdata2:500M:autoextend:max:8925M

  5. Save the file and exit the editor:

    :wq

  6. Execute the following command to build the updated configuration file:

    vimysql -f

  7. Execute the following commands:

    mariabackup --prepare --target-dir= <-use-memory=<80% of available memory>

    cd /data.local/db

    chown -R mysql.mysql *

    systemctl start mariadb

    These commands assume you have changed directories to the directory that contains the extracted backup files. If you want to run these commands from a location other than the location of the extracted backup files, then you must enter a value after "target-dir=" to point to the directory where the extracted files are located. To learn more about MariaBackup, see https://mariadb.com/kb/en/full-backup-and-restore-with-mariabackup/.

    Depending on the size of the backup, the mariabackup command might take a long time to complete.

  1. Because a full database restoration requires the database username and password, you must check the MariaDB username and password that are stored in the silo.conf file.

    If the backup was taken from an SL1 system installed from or upgraded to version 11.3.0 or later, the username will be clientdbuser.

    If the backup was taken from an SL1 system that was installed from or last upgraded to a version prior to 11.3.0, the username will be root.

    • To check the username and password in the silo.conf file, enter the following command:

      visilo

    • Check (and if necessary, update) the values in the dbuser, dbpasswd, and ap_pass fields in both the [LOCAL] and [CENTRAL] sections.

    • Save and close the file:

      :wq

      Upon saving, visilo will validate that the MariaDB passwords work. If the passwords fail, ensure that you are entering the correct ones. If the passwords are unknown, you must perform the password recovery and reset procedure described in the section Changing the MariaDB Password on SL1 Appliances.

  1. Execute the following command to restart SL1 and the database:

    siloctl start --full

  1. Re-license the Database Server using the standard licensing procedure. For details, see the section Licensing a Database Server.

The process from step 12 will fail and restart until your SL1 system is licensed. This is expected behavior.

Restoring a DR Backup from a Remote NFS or SMB Share

To restore a Database Server using a DR backup file, perform the following steps:

NOTE: These steps assume that the Database Server has not been previously configured.

  1. The Database Server to which you are restoring the backup must be at the same revision number as the Database Server that created the backup file.
  2. Either go to the console of the Database Server where you want to restore the backup or use SSH to access the Database Server.
  3. Log in as user em7admin and sudo to the root account:

    sudo -s

  4. Execute the following commands:

    5. Executing this command will stop the database. SL1 will not be operational until you complete the restore procedure.

    siloctl stop --full

    systemctl stop mariadb

    rm -rf /data/db/*

  5. Execute the following commands, substituting the full pathname of your backup file:

    6. cd /data/db

    pigz -dc <full path and name to backup file.tgz> | tar xvf –

    mv /data/db/data/db/* .

    rm -rf /data/db/data

    cp /data/db/etc/my.cnf.d/silo_mysql.cnf /root/silo_mysql.bak

    rm -rf /data/db/etc

    chown -R mysql:mysql /data/db/*

  6. Execute the following commands to restart SL1 and the database:

    7. siloctl start --full

    systemctl start mariadb

Retaining Backups

This section describes how to retain full and DR backups.

Retaining Full Backups

This section applies only to users who are running a version of SL1 prior to 11.2.0. If you are running SL1 11.2.0 or later, you can set the retention value in the Full Retention Period field on the Backup Management page (System > Settings > Backup). For more information, see the section on Defining a Full Backup.

The Database Tool page is available only in versions of SL1 prior to 12.2.1 and displays only for users that have sufficient permissions to access the page.

To specify the number of full backups to retain in SL1 versions prior to 11.2.0:

  1. Go to the Database Tool page (System > Tools > DB Tool).
  2. In the SQL Query field, enter the following:

    3. UPDATE master.system_settings_backup SET backup_retention = <number of backups to retain> WHERE id = 2

  3. For example, the following command would retain five full backups, the last four plus the current backup:

    4. UPDATE master.system_settings_backup SET backup_retention = 4 WHERE id = 2

  4. Click Go. SL1 will create an entry in /var/log/em7/silo.log when a backup is deleted.

Retaining DR Backups

This section applies only to users who are running a version of SL1 prior to 11.2.0. If you are running SL1 11.2.0 or later, you can set the retention value in the DR Retention Period field on the Backup Management page (System > Settings > Backup). For more information, see the section on Defining a Disaster Recovery Backup.

The Database Tool page is available only in versions of SL1 prior to 12.2.1 and displays only for users that have sufficient permissions to access the page.

To specify the number of DR backups to retain in SL1 versions prior to 11.2.0:

  1. Go to the Database Tool page (System > Tools > DB Tool).

  2. In the SQL Query field, enter the following:

    UPDATE master.system_settings_backup SET backup_retention = <number of backups to retain> WHERE id = 3

  3. For example, the following command would retain five DR backups, the last four and the current backup:

    4. UPDATE master.system_settings_backup SET backup_retention = 4 WHERE id = 3

  4. Click Go. SL1 will create an entry in /var/log/em7/silo.log when a backup is deleted.

Additional Configuration for Solaris NFS Remote Shares

To use the NFS-remote backup protocol with an NFS share hosted on a Solaris system, you must configure the Solaris system to allow the backup process to change file ownership permissions. To do this:

  • In /etc/dfs/dfstab on the Solaris system, you must specify that the fully-qualified domain name of the Database Server or All-In-One Appliance can access the NFS file system as root. For example:

    share -F nfs -o sec=sys,root=database.sciencelogic.local -d "ScienceLogic Backup Share" /export/home/backup

  • In /etc/defaults/nfs on the Solaris system, include the line NFSMAPID_DOMAIN=<domain of Database Server or All-In-One Appliance>. For example:

    NFSMAPID_DOMAIN=ScienceLogic.local

You can test this configuration by mounting the NFS file system from the console of your SL1 appliance, creating a new file on the file system using the "touch" command, and then executing the command "ls -la". If the Solaris system is configured correctly, the output of the ls command will indicate that the new file was created and is owned by the "root" user.

Performing Configuration and Full Backups on the DR Database Server

Users with large systems and very large backup files can use an alternative method to back up SL1: Performing backups from the disaster recovery Database Server. The benefit to this alternative method is that it reduces performance issues during the backup procedure.

It is important to note the differences between a disaster recovery backup and a configuration or full backup on the disaster recovery Database Server:

  • A disaster recovery backup is a method for backing up the Disaster Recovery system.
  • A configuration or full backup performed on the disaster recovery Database Server is an alternative method to backing up SL1.

Unlike the disaster recovery backup, which uses tar to make a compressed copy of the /data/db directory, performing a configuration backup from a disaster recovery Database Server uses the MySQL Dump tool and backs up the same data as described in the section on Configuration Backups.

Performing a full backup from a disaster recovery Database Server uses the MariaBackup tool and backs up the same data as described in the section on Full Backups.

During a configuration backup or full backup from a disaster recovery Database Server:

  • The disaster recovery Database Server does not appear active to any other SL1 appliances.
  • No applications or services can connect to the disaster recovery Database Server.

To perform a full backup on the disaster recovery Database Server:

  1. Follow the instructions in the section on Creating a Credential.
  2. Follow the instructions in the section on Configuring Backups.
  3. Depending on the type of backup you are defining, select the Configuration Backup on DR or Full Backup on DR checkbox.
  4. Complete the remaining fields on that page as needed, and then click Save.
  5. If necessary, follow the instructions in the section on Mounting Backup Files.
  6. To restore the backup, follow the instructions in the section on Restoring Backups.

After you define configuration or full backups on the Disaster Recovery Database Server, you should disable any other existing backups. However, you can continue to use standard DR Backup to back up your Disaster Recovery system.

Configuration Backup on a Disaster Recovery Database Server

To perform a configuration backup on the Disaster Recovery Database Server:

  1. Go to the Backup Management page (System > Settings > Backup).
  2. In the Configuration Backup pane, select the Configuration Backup on DR checkbox.
  3. Complete the remaining fields on that page as needed, and then click Save.
  4. Follow the instructions in the section on Creating a Credential.
  5. Following the instructions in the section on Defining a Configuration Backup.
  6. To restore the backup, follow the steps in the section Restoring a Configuration Backup.

 If you enabled configuration backups on the Disaster Recovery Database Server, you should disable standard configuration backups.

Full Backup on a Disaster Recovery Database Server

To perform a full backup on the Disaster Recovery Database Server:

  1. Go to the Backup Management page (System > Settings > Backup).
  2. In the Full Backup pane, select the Full Backup on DR checkbox.
  3. Complete the remaining fields on that page as needed, and then click Save.
  4. Follow the instructions in the section on Creating a Credential.
  5. Following the instructions in the section on Defining a Full Backup.
  6. To restore the backup, follow the steps in the section Restoring a Full Backup.

 If you enabled full backups on the Disaster Recovery Database Server, you should disable standard full backups.