backup and restore overview

includes a tool, ibackup.pyc, to back up and restore your data.

Regularly back up your deployment to safeguard your data in these cases:

• To restore your 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 deployment to another
  • Restore data from a 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 instance
  • Rebuild a cluster where the nodes have failed

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 deployment using any of these configurations:

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

You can build deployments from any supported installation method. See Install using the Amazon Marketplace Image in Install and Upgrade .

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

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 configurations. This type of backup requires downtime.

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

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 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?

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

A full backup of a instance contains the following file sets:

File set	Files	Backup path
misc_files	Miscellaneous files used by .	<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 apps, excluding app_states.	<PHANTOM_HOME>/apps
ssl	All etc/ssl contents.	<PHANTOM_HOME>/etc/ssl
certs	All 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 app states, excluding apps.	<PHANTOM_HOME>/local_data/app_states
playbook_states	All playbook states, excluding playbooks.	<PHANTOM_HOME>/tmp

The directory <PHANTOM_HOME> represents:

• On a privileged deployment the directory /opt/phantom.
• 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 for the user account that runs .

How an incremental backup differs from a full backup

Incremental backups contain only changes to your 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 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 deployment, such as a virtual machine image, RPM-based installation, or Amazon Marketplace Image.

• The deployments, the origin of the backup, and the destination for the restore must be running the same version of .
• You cannot restore a backup from a privileged instance of to an unprivileged instance or from an unprivileged instance to a privileged instance.

Backup origin	Possible backup destinations
Standalone, privileged instance	Standalone, privileged instance Privileged cluster Single privileged instance, external PostgreSQL database Single privileged instance, external file shares Privileged instance, external PostgreSQL database and file shares
Single privileged instance, external PostgreSQL database	Standalone, privileged instance Privileged cluster Single privileged instance, external PostgreSQL database Single privileged instance, external file shares Privileged instance, external PostgreSQL database and file shares
Single privileged instance, external file shares	Standalone, privileged instance Privileged cluster Single privileged instance, external PostgreSQL database Single privileged instance, external file shares Privileged instance, external PostgreSQL database and file shares
Privileged instance, external PostgreSQL database and file shares	Standalone, privileged instance Privileged cluster Single privileged instance, external PostgreSQL database Single privileged instance, external file shares Privileged instance, external PostgreSQL database and file shares
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

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.