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 Phantom 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 Phantom instance
- Rebuild a Phantom cluster where the Phantom 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 Phantom 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 .
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 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:
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 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 <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 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 |
|
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® Phantom (Legacy): 4.8, 4.9, 4.10, 4.10.1, 4.10.2, 4.10.3, 4.10.4, 4.10.6, 4.10.7
Feedback submitted, thanks!