Splunk® Phantom (Legacy)

Administer Splunk Phantom

Restore from a backup

You need root permissions to restore from a backup.

Backups must be restored to an instance with the same privilege level. You cannot restore a backup from a privileged instance of to an unprivileged instance or from an unprivileged instance to a privileged instance.

Backups can be used in conjunction with the Warm Standby feature for additional protection against system failure.

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

Prepare your system for restore

You must prepare your system for a restore before a deployment can benefit from a restore. Preparing your deployment is important if you are restoring data from one deployment to another deployment. To prepare your deployment for restoring, perform the following steps:

  1. From the command line, SSH to your instance or cluster node.
    SSH <username>@<phantom_hostname>
  2. Change the directory to <PHANTOM HOME>/bin.
    cd <PHANTOM_HOME>/bin
  3. Prepare the system for a restore.
    sudo phenv python ibackup.pyc --setup

When you restore a backup to the same deployment, the setup was completed as part of making the backup.

Restore your instance from a full backup

  1. From the command line, SSH to your instance or cluster node.
    SSH <username>@<phantom_hostname>
  2. Change the directory to <PHANTOM HOME>/bin.
    cd <PHANTOM_HOME>/bin
  3. Prepare the system for a restore.
    sudo phenv python ibackup.pyc --setup
  4. Copy your <number>_phantom_backup.tar from storage to the instance or cluster node you are restoring.
  5. Perform the restore.
    sudo phenv python ibackup.pyc --restore <path/to/<number>_phantom_backup.tar>

Deployments of Splunk Phantom in AWS that use RDS for their PostgreSQL database should not use ibackup.pyc. Backups must be created using the backup.pyc tool, and restored using the restore.pyc tool.

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

Deployments which use Amazon Web Services RDS to host 's PostgreSQL database cannot use ibackup.pyc to back up or restore the database and instead use a combination of the automatic backups in RDS and the older backup.pyc and restore.pyc tools. For information on using the back up and restore features of RDS, see Backing up and restoring an Amazon RDS DB instance in the AWS documentation.

  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.
    sudo phenv python restore.pyc --file <PATH/TO/BACKUP/FILE>
    In this case, you can safely ignore the deprecation warning.

The command output looks like this:

[root@phantom bin]# phenv python restore.pyc --file /opt/phantom/data/phantom_backups/phantom_backup_2020-09-09-22-49-17.tgz
[pid: 10562] [09/Sep/2020 23:03:06]   restore.py:692  WARNING: The --all option of the backup.pyc script has been deprecated. Please use the ibackup.pyc script to perform backups and restores. Documentation for the new script can be found at https://docs.splunk.com/Documentation/Phantom/4.9/Admin/BackupOrRestoreOverview. The --config option of the backup.pyc script will continue to work with ibackup.pyc.

[2020-09-09 23:03:06] The --all option of the backup.pyc script has been deprecated. Please use the ibackup.pyc script to perform backups and restores. Documentation for the new script can be found at https://docs.splunk.com/Documentation/Phantom/4.9/Admin/BackupOrRestoreOverview. The --config option of the backup.pyc script will continue to work with ibackup.pyc.


restore.pyc 2.0.0
[2020-09-09 23:03:06] Stopping all Phantom services except PostgreSQL
Stopping Supervisor daemon manager...[  OK  ]
/opt/phantom/proxy/bin/splunk_proxyd is already stopped
Stopping phantom_actiond:                                  [  OK  ]
Stopping phantom_workflowd:                                [  OK  ]
Stopping phantom_ingestd:                                  [  OK  ]
Stopping phantom_decided:                                  [  OK  ]
[2020-09-09 23:03:12] Extracting backup tarball (this may take a while)
The backup file appears to be a full backup.  This will overwrite any existing data upon restore.  Proceed? [y/N]y
[2020-09-09 23:03:21] Loading tables from backup into database
[===========================================================================] 100%
[2020-09-09 23:03:24] Deleting existing Phantom database records
[===========================================================================] 100%
[2020-09-09 23:03:31] Inserting backup rows into main tables
[===========================================================================] 100%
[2020-09-09 23:03:31] Dropping temporary archive tables used for backup
[===========================================================================] 100%
[2020-09-09 23:03:32] Finalizing transaction
[2020-09-09 23:03:32] Updating the main menu
[2020-09-09 23:03:32] Restoring specific Phantom file backups
[===========================================================================] 100%
[2020-09-09 23:03:32] Configuring NGINX SSL certificates (this may take a while)
[2020-09-09 23:03:44] Restoring Phantom subdirectories
[===========================================================================] 100%
[2020-09-09 23:04:05] Running /opt/phantom/bin/start_phantom.sh
Starting all Phantom services
Phantom startup successful
[2020-09-09 23:04:09] Resetting passwords for Splunk users
[2020-09-09 23:04:17] Done resetting Splunk user passwords
Stopping Supervisor daemon manager...[  OK  ]
Starting Supervisor daemon manager...[  OK  ]
Logs recorded in /opt/phantom/data/phantom_backups/phantom_backup_restore_2020-09-09-23-03-06.log

Restore your system from an incremental backup

Before restoring your system from an incremental backup, you must prepare the system. See Prepare your system for restore.

Incremental backups contain only the changes to your instance since the last full backup or previous incremental 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 backups.

The sequence looks like this:

  1. Create a full backup called phantom_backup_group_0_level_0.tar.
  2. Create an incremental backup called phantom_backup_group_0_level_1.tar, which is based on phantom_backup_group_0_level_0.tar.
  3. Create a second incremental backup called phantom_backup_group_0_level_2.tar, which is based on phantom_backup_group_0_level_1.tar and phantom_backup_group_0_level_0.tar.

Use the sequential files to restore your system in the following ways:

  • You can restore phantom_backup_group_0_level_0.tar alone.
  • You cannot restore phantom_backup_group_0_level_1.tar without phantom_backup_group_0_level_0.tar.
  • You cannot restore phantom_backup_group_0_level_2.tar without phantom_backup_group_0_level_0.tar and phantom_backup_group_0_level_1.tar.

Restore the incremental backup

  1. From the command line, SSH to your instance or cluster node.
    SSH <username>@<phantom_hostname>
  2. Change the directory to <PHANTOM HOME>/bin.
    cd <PHANTOM_HOME>/bin
  3. Prepare the system for a restore.
    sudo phenv python ibackup.pyc --setup
  4. Copy the backup group and the incremental-level tar files from storage to the instance or cluster node you are restoring.
  5. Perform the restore. Enter the file name of the last incremental backup file you want to restore.
    sudo phenv python ibackup.pyc --restore < phantom_backup_group_<#>_level_<#>.tar >

Determine whether the system restore was successful

A successful restore outputs information to the console. 

[root@phantom bin]# phenv python ibackup.pyc --restore /opt/phantom/data/backup/phantom_backup_group_0_level_0.tar 
[06/Feb/2020 20:10:15] INFO: Running ibackup.pyc - details will be logged to /var/log/phantom/backup/ibackup_2020-02-06T20:10:15.089127Z.log
[06/Feb/2020 20:10:15] INFO: Attempting to connect to Postgresql ...
[06/Feb/2020 20:10:17] INFO: Checking filesystem backup state at /opt/phantom/data/ibackup/repo/fs
[06/Feb/2020 20:10:17] INFO: Restoring this backup requires utilizing 9.11334507138% of the total volume capacity
[06/Feb/2020 20:10:17] INFO: Available: 45901836288 , Required: 2008317952.0
[06/Feb/2020 20:10:21] INFO: Attempting to connect to Postgresql ...
psql: ERROR:  pgbouncer cannot connect to server
[06/Feb/2020 20:10:21] INFO: Retrying ...
[06/Feb/2020 20:10:22] INFO: Attempting to connect to Postgresql ...
psql: ERROR:  pgbouncer cannot connect to server
[06/Feb/2020 20:10:22] INFO: Retrying ...
[06/Feb/2020 20:10:24] INFO: Attempting to connect to Postgresql ...
psql: ERROR:  pgbouncer cannot connect to server
[06/Feb/2020 20:10:24] INFO: Retrying ...
[06/Feb/2020 20:10:28] INFO: Attempting to connect to Postgresql ...
psql: ERROR:  pgbouncer cannot connect to server
[06/Feb/2020 20:10:28] INFO: Retrying ...
[06/Feb/2020 20:10:36] INFO: Attempting to connect to Postgresql ...
[06/Feb/2020 20:10:38] INFO: Extracting backup file /opt/phantom/data/backup/phantom_backup_group_0_level_0.tar
[06/Feb/2020 20:11:08] INFO: Restoring files to filesystem
[06/Feb/2020 20:11:17] INFO: Attempting to connect to Postgresql ...
[06/Feb/2020 20:11:27] INFO: Restore complete

After restoring your system, you must run sudo phenv python ibackup.pyc --setup again before you can make new backups.

Last modified on 08 September, 2021
Back up a deployment   Splunk Phantom backup tools

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

Acrobat logo Download manual
Acrobat logo Download this page

Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters