Backing up and restoring Sisense

Backing up and restoring Sisense 

Introduction

The article is meant to be a companion to the Sisense Backup and Restore documentation. The Sisense documentation provides the details on how to backup and restore Sisense.  This article will provide additional information and give recommendations.

Application versions

This article applies to all Sisense Linux self-hosted versions.  It does not apply to any Sisense Windows versions, nor to any managed service (Sisense hosted) versions.  For Sisense-hosted versions, Sisense Cloud Operations takes care of creating all backups.

Overview 

Regularly backing up the Sisense application

• Ensures that the Sisense application can be readily restored in the case of a hardware or other system failure.  
• A backup should be taken before an upgrade.  In case there are any issues with the upgrade, the upgrade can be rolled back.
• When installing Sisense on new machines, a backup can be taken to easily migrate Sisense between the old and new infrastructure.

What is included in the backup

The following assets are included in the Sisense backup

• Branding (opt/sisense/branding) - Files related to customized branding
• Build-plugins (opt/sisense/build-plugins) - Any custom post build plugins
• Connectors (opt/sisense/storage/connectors) - Connectors in use, including any custom JDBC connectors
• Custom-certificates (opt/sisense/storage/custom-certificates) - security certificates
• Data (/opt/sisense/storage/data) - Any specialized data files that may have been added
• Emails (/opt/sisense/storage/emails) - Email templates
• External-plugins (/opt/sisense/storage/external-plugins)
• Mongo_dump - This includes backups of all Sisense MongoDB databases used to support the Sisense application.  Note that this does not include any customer-created MongoDB databases.
• Notebooks (/opt/sisense/storage/notebooks)
• Plugins (/opt/sisense/storage/plugins) include plugins included with Sisense as well as any custom plugins.
• Build Schedules - The schedules for all scheduled builds
• Server Side Plugins (/opt/sisense/storage/serverSidePlugins)
• Tenant-specific files - This includes static files related to elasticubes, such as CSV and XLSX.  Note that even if the tenants feature is not being used, there is still a system tenant where elasticube static files are stored.
• Translations (/opt/sisense/storage/translations) - Files to support Sisense in multiple languages.  Files for any additional languages would also be here.
• Usage (/opt/sisense/storage/usage) - Files related to usage analytics
• Configuration settings

Running a backup

There are two ways to run a backup.

• Using the CLI commands.  
• Using the v2.0 Backups REST API.  Note that backups done through the rest api are limited to 2GB in size.

The Sisense backup can be configured to include the elasticube data with the ‘-include-farm’ flag.  I recommend that the elasticube data not be included in the backup for routine backups.  Depending on how often the backups are run, the elasticube data will probably be out of date by the time the backup is restored to a new environment.  It is better to run builds for each elasticube to get the latest data.

Extra paths can be included in order to backup folders that are not included by default (see above).  This can be done via two methods.

• Add them through Sisense Configuration (in the admin tab).  Once in configuration, scroll down to the management section and add the paths in the ExtraBackupPaths field.  The advantage of this is that the extra paths will be included for every execution of the backup.
• The paths can also be added at run time with the -include-extra-paths yes flag and specifying the extra paths.  The extra paths will only be included for the specific execution of the backup.

By default, the Sisense backup is stored in /opt/sisense/storage/system_backups.  This folder can be accessed from the Admin/File Management GUI.  In a single-node environment, the system_backups folder can be accessed directly from the Linux host OS.  In a multinode environment, you must exec into the management pod in order to access the /opt/sisense file structure.  To do that, you can run the following kubectl command

kubectl -n sisense exec $(kubectl get pod -l app.kubernetes.io/name=mongodb -o name -n sisense) -c mongodb -it -- bash

Checking on the status of a backup

You can check on the status of an existing backup (and see other backups) through the CLI backup-list command.  The in-progress backup will show with a status of ‘Running’ in the output

si system backup-list

[ALT Text: A terminal screen shows a backup list with columns: Backup name, creation time, size, and status. Most are succeeded, one is running.]

Exporting the backup file

Since one purpose of the backup is the ability to restore the Sisense instance in case of hardware or other failure, having the backup files on the Sisense file system will be problematic in case of a system failure.  Fortunately, the Sisense backup process supports writing the backup to an s3 bucket with a flag -to-s3 true.  To configure the S3 bucket within Sisense, follow these steps.

• If you don’t already have an S3 bucket, create one in AWS.  Public access should be blocked, and a bucket policy should be set with the minimum access necessary for the S3 bucket.  A Sid of ‘AllowWriteFromSpecificIP’ or similar rule can be used to ensure that only the Sisense server can write to the S3 bucket.
• Set the configuration through the CLI.  Once you have logged into the CLI, run the following commands to set the configuration fields.

si config set -key management.S3BackupBucket -new-value <BucketName>

si config set -key management.AWSAccessKey -new-value <AccessKey>

si config set -key management.AWSSecretKey -new-value <SecretKey>

If you are not using S3 buckets, then it is best practice to copy the backup from the system_backup folder to a location outside Sisense.

Scheduling the backup

The backup can be scheduled using the CLI with the command si schedulers backup create -cron-expression <cron expression> -retention <number of backup copies to retain>.  For information on cron expression format, please see crontab guru.

Restoring from a backup

A Sisense backup file can be easily restored onto an existing Sisense installation.  If restoring the backup to a new instance, first perform a Sisense installation.  A Sisense backup can be restored to the same version of Sisense or three versions higher.

Running a restore

A restore can be run through the Sisense CLI.  The syntax is

  si system restore -name <backup-name>

The backup name is the file name without the extension tar.gz.  The name of the backup can be seen through the CLI backup list command

si system back-list