Back up a deployment

Your deployment is backed up using command-line tools. You do not need to take offline to do a backup.

Before you begin, check each of the following things.

• Make sure you have completed either the section Prepare for a back up or Prepare a cluster or deployment with an external PostgreSQL database, depending on your deployment's configuration.
• Make sure you have sufficient disk space to store your backup.
  • For using a local PostgreSQL database, you need approximately three times the space used by your PostgreSQL database. Most of this space is required only temporarily, and will be released once all WAL segments have been processed by PostgreSQL.
  • If you are storing your backups on another filesystem or disk, you will need space equal to all filesystem components included in your backup and the total size of your PostgreSQL database.

Deployments of Splunk SOAR (On-premises) with a PostgreSQL database size of multiple terabytes may be better served by externalizing their PostgreSQL database, and using a different backup solution. Deployments of Splunk SOAR (On-premises) in AWS that use RDS for their PostgreSQL database should not use ibackup to create backups of the Splunk SOAR (On-premises) database. Use the backup.pyc tool instead. See Backup the external PostgreSQL database with the Relational Database System (RDS).

Prepare for a backup

Before you can create backups, you must prepare by running the ibackup command with the --setup option.

You must prepare by running the ibackup command with the --setup option after any upgrade of .

During setup, ibackup temporarily stops services in order to make changes to the PostgreSQL database configuration. Services restart before setup is complete.

If your Splunk SOAR (On-premises) deployment uses a Warm Standby or if you intend to use a Warm Standby, you must configure Warm Standby before setting up backups.

1. From the command line, SSH to your instance.
   
   ssh <username>@<phantom_hostname>
2. Prepare the system for a backup.
   
   /opt/phantom/bin/phenv ibackup --setup

The command output looks like this:

[phantom@phantom bin]$ phenv ibackup --setup
Logs for this script run will be located at /opt/phantom/var/log/phantom/ibackup/ibackup_2022-02-17-22-45-24.log
Attempting to connect to Postgresql, connection errors are expected while bootstrapping ...
Setup will temporarily stop phantom
If you wish to continue, enter yes to proceed: yes
Setup complete
Logs for this script run will be located at /opt/phantom/var/log/phantom/ibackup/ibackup_2022-02-17-22-45-24.log

If the instance or cluster has been setup for backups, the tool prompts you to confirm that you wish to run setup again:

You appear to have already run setup. Re-run again ? Enter yes to proceed:

Enter yes to run the setup process again.

Running the set up again after a restore resets the state file used by ibackup and archives all existing backup files. Running it a second time before any restore actions does nothing.

Prepare a cluster or deployment with an external PostgreSQL database for a backup

For deployments where the PostgreSQL database is external to the instance or in clustered deployments, you must take additional steps to prepare the deployment for backup.

In clustered deployments, all backup commands must be issued from the same cluster node.

1. From the command line, SSH to one cluster node of your deployment.
   
   ssh <username>@<phantom_hostname>
2. Run ibackup. This step generates the db_bootstrap.tgz file.
   
   phenv ibackup --setup
3. Use SCP to copy db_bootstrap.tgz to your PostgreSQL database host.
   
   scp db_bootstrap.tgz <username>@<postgresql_hostname>:/<directory>
4. SSH to the PostgreSQL database host.
   
   ssh <username>@<postgresql_hostname>
5. Extract the db_bootstrap.tgz file.
   
   tar -xzvf db_bootstrap.tgz
6. Change directory to the setup directory created when db_bootstrap.tgz was extracted.
   
   cd setup
7. Run the extdb_backup_bootstrap script with the parameter --pgdata </path/to/postgresql/db>.
   
   python extdb_backup_bootstrap.pyc --pgdata </path/to/postgresql/db>
8. SSH to the cluster node where you ran ibackup.
   
   ssh <username>@<phantom_hostname>
9. Run ibackup to complete the setup.
   
   phenv ibackup --setup

Create a full backup

Your instance is backed up using command-line tools. You do not need to take offline to create a backup.

In clustered deployments, all backup commands must be issued from the same cluster node.

1. From the command line, SSH to your instance.
   ssh <username>@<phantom_hostname>
2. Run the following command to perform the backup.
   phenv ibackup --backup --backup-type full
   If no backups exist, a full backup is created. When a full backup exists, a new incremental backup is added to the group. If you already have a backup group and want to create a new full backup, use the --backup-type full argument.

The following sample output shows a backup being run:

[11/Dec/2022 21:24:28] INFO: Running ibackup - details will be logged to /opt/phantom/var/log/phantom/backup/backup_2022-12-11T21:24:28.706665Z.log
[11/Dec/2022 21:24:28] INFO: Attempting to connect to Postgresql ...
[11/Dec/2022 21:24:30] INFO: First backup. Performing full backup
[11/Dec/2022 21:24:30] INFO: Backing up files
[11/Dec/2022 21:25:03] INFO: Backing up database
[11/Dec/2022 21:25:17] WARNING: no prior backup exists, incr backup has been changed to full

[11/Dec/2022 21:25:58] INFO: Backup created at: /opt/phantom/data/backup/phantom_backup_group_0_level_0.tar
[11/Dec/2022 21:25:58] INFO: You should ensure this tarball is kept safe. It will be required for restore

Create a full backup for deployments with an external PostgreSQL database in RDS

Amazon Web Services RDS provides automatic backups of hosted PostgreSQL databases which are managed and restored using the management console. See Backing up and restoring a DB instance in the AWS documentation.

To back up other components, use the --fs-only option of the ibackup tool. See Splunk SOAR (On-premises) backup tools.

Create an incremental backup

The ibackup tool checks whether a full backup exists. If a full backup doesn't exist, a full backup is created. If a full backup exists, an incremental backup is created and added to the backup chain. You do not need to take offline to create a backup. If your deployment's PostgreSQL database is hosted in Amazon's RDS, you cannot use incremental backups for the database.

In clustered deployments, all backup commands must be issued from the same cluster node.

1. From the command line, SSH to your instance.
   
   ssh <username>@<phantom_hostname>
2. Change the directory to <PHANTOM HOME>/bin.
   
   cd <PHANTOM_HOME>/bin
3. Perform the backup.
   
   phenv ibackup --backup

The command output looks like this:

[11/Dec/2019 21:29:47] INFO: Running ibackup - details will be logged to /var/log/phantom/backup/backup_2019-12-11T21:29:47.549233Z.log
[11/Dec/2019 21:29:47] INFO: Attempting to connect to Postgresql ...
[11/Dec/2019 21:29:53] INFO: Backing up files
[11/Dec/2019 21:29:54] INFO: Backing up database
[11/Dec/2019 21:30:03] INFO: Backup created at: /opt/phantom/data/backup/phantom_backup_group_0_level_1.tar
[11/Dec/2019 21:30:03] INFO: You should ensure this tarball is kept safe. It will be required for restore

You can override the default behavior by using this command-line option:

phenv ibackup --backup --backup-type incr

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.