After the future removal of the classic playbook editor, your existing classic playbooks will continue to run, However, you will no longer be able to visualize or modify existing classic playbooks.
For details, see:
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:
- An unprivileged, standalone instance
- An unprivileged instance, external PostgreSQL database
- An unprivileged instance, external file shares
- 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 |
| 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 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 is installed.
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 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 an earlier release of privileged instance of to any unprivileged instance.
| Backup origin | Possible backup destinations |
|---|---|
| Standalone, unprivileged instance |
|
| Unprivileged instance, external PostgreSQL database |
|
| Unprivileged instance, external file shares |
|
| Unprivileged instance, external PostgreSQL database and file shares |
|
| Unprivileged cluster |
|
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.
| Renew IdP certificates | Back up a deployment |
This documentation applies to the following versions of Splunk® SOAR (On-premises): 5.5.0, 6.0.0, 6.0.1, 6.0.2, 6.1.0, 6.1.1, 6.2.0, 6.2.1, 6.2.2
Download manual
Feedback submitted, thanks!