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.
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 .
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 on this page.
- Incremental backups contain only the changes made to your deployment's PostgreSQL database and files since the last full or incremental backup was made.
- A configuration only backup, which makes a backup of all the configurations. This type of backup requires downtime.
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
ibackup.pyc --set-full-backup-limit 3. After several weeks, three backup groups exist, each with a full backup and several incremental backups:
A decision is made that the oldest backups are no longer required, so an administrator runs
ibackup.pyc --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?
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|
|apps||All apps, excluding app_states.||<PHANTOM_HOME>/apps|
|ssl||All etc/ssl contents.||<PHANTOM_HOME>/etc/ssl|
|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_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||
|Single privileged instance, external PostgreSQL database||
|Single privileged instance, external file shares||
|Privileged instance, external PostgreSQL database and file shares||
|Standalone, unprivileged instance||
|Unprivileged instance, external PostgreSQL database||
|Unprivileged instance, external file shares||
|Unprivileged instance, external PostgreSQL database and file shares||
Troubleshooting certificate issues
Back up a deployment
This documentation applies to the following versions of Splunk® SOAR (On-premises): 5.0.1