Splunk SOAR (On-premises) backup and restore overview

Splunk SOAR (On-premises) includes a tool, ibackup.pyc, to back up and restore your Splunk SOAR (On-premises) data.

Regularly back up your Splunk SOAR (On-premises) deployment to safeguard your data in these cases:

  • To restore your Splunk SOAR (On-premises) deployment in the event of a disaster
    • Restore a lost or failed file share
    • Restore a lost or failed PostgreSQL database
  • To restore data from your Splunk SOAR (On-premises) deployment to another
    • Restore data from a Splunk SOAR (On-premises) instance or cluster to a new instance or cluster
    • Restore data from a standalone instance to a newly deployed cluster
    • Restore data from a clustered deployment to a standalone Splunk SOAR (On-premises) instance
    • Rebuild a Splunk SOAR (On-premises) cluster where the Splunk SOAR (On-premises) nodes have failed
CAUTION: Save your backups in a safe place, such as one that is not on the same disk, partition, or virtual machine as your Splunk SOAR (On-premises) instance.

Supported configurations

You can backup a Splunk SOAR (On-premises) deployment using any of these configurations:

  • An unprivileged, standalone instance
  • An unprivileged instance, external PostgreSQL database
  • An unprivileged instance, external file shares
  • An unprivileged cluster

You can build Splunk SOAR (On-premises) deployments from any supported installation method. See How can Splunk SOAR (On-premises) be installed? in Install and Upgrade Splunk SOAR (On-premises).

Restrictions for backup and restore configurations

Backups can only be used to restore to systems that match certain configurations of the system that was backed up.

  • Splunk SOAR (On-premises) deployments which use an external PostgreSQL 12.9 database cannot use the backup and restore feature. You must use another solution to backup or restore your Splunk SOAR (On-Premises) deployment.
    • Splunk SOAR (On-premises) release 6.2.0 and higher use PostgreSQL 15.3. You can use the backup and restore feature if you upgrade your external PostgreSQL database to 15.x. See Set up an external PostgreSQL server in Install and Upgrade Splunk SOAR (On-premises).
  • You must use same supported operating system for both the backup and the restore target. For example, backups taken on a host running Oracle Linux 8 must be restored to a host running Oracle Linux 8. See Supported operating systems in the topic General system requirements in Install and Upgrade Splunk SOAR (On-premises).
  • If you restore a backup from a clustered deployment to a single instance deployment, Splunk SOAR (On-premises) will still have the database tables and configuration for a cluster. Those settings must be reconfigured before the new single instance of Splunk SOAR (On-premises) is ready for use. Add or remove a cluster node from Splunk SOAR (On-premises) in Administer Splunk SOAR (On-premises).
  • A backup taken on a Splunk SOAR (On-premises) deployment that is paired with Splunk Enterprise Security 8.1 or higher, must be restored to the same Splunk SOAR and Splunk Enterprise Security pair. Pair Splunk SOAR (On-premises) with Splunk Enterprise Security (On-premises) in Administer Splunk SOAR (On-premises).

Backup types

The ibackup.pyc tool is based on the open source pgBackRest project, and it supports full and incremental backups. Differential backups are not supported.

  • A full backup includes all the file sets included in the What is in a full backup? section in this topic.
  • Incremental backups contain the changes made to your deployment's PostgreSQL database and files since the last full or incremental backup was made, as well as metadata about previous backups.
  • A configuration only backup, which makes a backup of all the Splunk SOAR (On-premises) configurations. This type of backup requires downtime.
Note: For incremental backups, the metadata collected about previous incremental backups accrues cumulatively. To reset the collection of metadata, you must perform a full backup.

Backup levels and groups

Backups are created in <PHANTOM_HOME>/phantom/data/backup/. Each backup is part of a group, based on a full backup that is the base of the group, and is labeled by level.

For example, if the first backup on a Splunk SOAR (On-premises) instance is named "phantom_backup_group_0_level_0.tar". Then, the first incremental backup made is then named "phantom_backup_group_0_level_1.tar".

Each subsequent incremental backup in the same group increases by a level of one.

Additional full backups create a new group, and incremental backups based on that full backup start incrementing the level number.

Note: When you begin a new group based on a new full backup, earlier groups stop incrementing. Further incremental backups belong to the new group.

You can control the number of backup groups by using the --set-full-backup-limit argument with ibackup.pyc.

You can change the number of backup groups by running the ibackup.pyc script with a new --set-full-backup-limit argument. If you set a lower limit, backup groups are deleted, starting with the oldest group.

For example, a Splunk SOAR (On-premises) deployment is configured for backup and restore using phenv ibackup --set-full-backup-limit 3. After several weeks, three backup groups exist, each with a full backup and several incremental backups:

Group 0

  • phantom_backup_group_0_level_0.tar
    • phantom_backup_group_0_level_1.tar
    • phantom_backup_group_0_level_2.tar
    • phantom_backup_group_0_level_3.tar

Group 1

  • phantom_backup_group_1_level_0.tar
    • phantom_backup_group_1_level_1.tar
    • phantom_backup_group_1_level_2.tar
    • phantom_backup_group_1_level_3.tar

Group 2

  • phantom_backup_group_2_level_0.tar
    • phantom_backup_group_2_level_1.tar
    • phantom_backup_group_2_level_2.tar
    • phantom_backup_group_2_level_3.tar

A decision is made that the oldest backups are no longer required, so an administrator runs phenv ibackup --set-full-backup-limit 3. When the next backup runs after the new full backup limit is set, Group 0 is deleted.

What is in a full backup?

CAUTION: Only GlusterFS, XFS, ext4, and NFS filesystems are supported. Other filesystems are not backed up using ibackup.pyc.

A full backup of a Splunk SOAR (On-premises) instance contains the following file sets:

File set Files Backup path
misc_files Miscellaneous files used by Splunk SOAR (On-premises). <PHANTOM_HOME>/keystore/private_key.pem

<PHANTOM_HOME>/www/phantom_ui/secret_key.py

<PHANTOM_HOME>/www/phantom_ui/secret_key.pyc
<PHANTOM_ETC>/nginx/conf.d/default.conf
<PHANTOM_HOME>/etc/cacerts.pem
<PHANTOM_HOME>/splunk/etc/apps/splunk_httpinput/local/inputs.conf
<PHANTOM_HOME>/etc/enable
<PHANTOM_HOME>/www/phantom_ui/auth_backends/saml2_xml

apps All Splunk SOAR (On-premises) apps, excluding app_states. <PHANTOM_HOME>/apps
ssl All Splunk SOAR (On-premises) etc/ssl contents. <PHANTOM_HOME>/etc/ssl
certs All Splunk SOAR (On-premises) certificates. <PHANTOM_HOME>/etc/certs
playbooks All playbooks, excluding playbook states. <PHANTOM_HOME>/scm
nginx_keys The NGINX SSH keys. <PHANTOM_VAR>/cache/nginx/.ssh
vault All vault contents, excluding files that are still streaming to storage. <PHANTOM_HOME>/vault
app_states All Splunk SOAR (On-premises) app states, excluding apps. <PHANTOM_HOME>/local_data/app_states
playbook_states All Splunk SOAR (On-premises) playbook states, excluding playbooks. <PHANTOM_HOME>/tmp

The directory <PHANTOM_HOME> represents:

  • On an unprivileged deployment using a virtual machine image or an Amazon Marketplace Image, the directory /opt/phantom.
  • On an unprivileged deployment using the installation TAR file the directory where Splunk SOAR (On-premises) is installed.

How an incremental backup differs from a full backup

Incremental backups contain only changes to your Splunk SOAR (On-premises) deployment since the last backup was made.

Incremental backups are based on a group of backup files that begin with a full backup, then the backup files in sequence. The new file contains changes that were made since the previous backup.

An incremental backup cannot be used to restore a system on its own. It must be used with the related full backup and any intermediate incremental backups. For example:

phantom_backup_group_0_level_0.tar → phantom_backup_group_0_level_1.tar → phantom_backup_group_0_level_2.tar → phantom_backup_group_0_level_3.tar

In this example, phantom_backup_group_0_level_0.tar is the full backup that forms the base of the backup group. The files phantom_backup_group_0_level_1.tar, phantom_backup_group_0_level_2.tar, and phantom_backup_group_0_level_3.tar are incremental backups that depend on the earlier files.

An administrator can restore a Splunk SOAR (On-premises) deployment from any point in the group as long as the earlier files in the group are present.

Supported restore configurations

This table presents possible destinations for restoring a backup.

The origin of a backup can be any supported Splunk SOAR (On-premises) deployment, such as a virtual machine image or Amazon Marketplace Image.

  • The Splunk SOAR (On-premises) deployments, the origin of the backup, and the destination for the restore must be running the same version of Splunk SOAR (On-premises).
  • You cannot restore a backup from an earlier release of Splunk SOAR (On-premises) privileged instance of Splunk SOAR (On-premises) to any unprivileged instance.
Backup origin Possible backup destinations
Standalone, unprivileged instance
  • Standalone, unprivileged instance
  • Unprivileged cluster
  • Single unprivileged instance, external PostgreSQL database
  • Single unprivileged instance, external file shares
  • Unprivileged instance, external PostgreSQL database and file shares
Unprivileged instance, external PostgreSQL database
  • Standalone, unprivileged instance
  • Unprivileged cluster
  • Single unprivileged instance, external PostgreSQL database
  • Single unprivileged instance, external file shares
  • Unprivileged instance, external PostgreSQL database and file shares
Unprivileged instance, external file shares
  • Standalone, unprivileged instance
  • Unprivileged cluster
  • Single unprivileged instance, external PostgreSQL database
  • Single unprivileged instance, external file shares
  • Unprivileged instance, external PostgreSQL database and file shares
Unprivileged instance, external PostgreSQL database and file shares
  • Standalone, unprivileged instance
  • Unprivileged cluster
  • Single unprivileged instance, external PostgreSQL database
  • Single unprivileged instance, external file shares
  • Unprivileged instance, external PostgreSQL database and file shares
Unprivileged cluster
  • Standalone, unprivileged instance
  • Unprivileged cluster
  • Single unprivileged instance, external PostgreSQL database
  • Single unprivileged instance, external file shares
  • Unprivileged instance, external PostgreSQL database and file shares
Note: If you restore a backup from a clustered deployment to a single instance deployment, Splunk SOAR (On-premises) will still have the database tables and configuration for a cluster. Those settings must be reconfigured before the new single instance of Splunk SOAR (On-premises) is ready for use.