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).

CAUTION: You must use the same operating system for a backup of a Splunk SOAR (On-premises) deployment as for the deployment itself.

Note: If your deployment uses an external PostgreSQL 12.9 database, you cannot use the backup and restore feature. You must use another solution to backup or restore your Splunk SOAR (On-Premises) deployment.

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.

Documentation