Use ibackup.pyc with warm standby
The warm standby and the backup and restore features require careful planning to use together.
Warm standby and ibackup features of use the Write Ahead Logging feature in PostgreSQL. When you configure a deployment to use both warm standby and ibackup, you must configure warm standby first. After restoring a deployment with ibackup, you must update the warm standby configuration.
Configuring warm standby after configuring ibackup archives all existing backups. Archiving all of the backups prevents new backups from being generated or existing backups from being used in a restore.
You can generate new backups once you run ibackup with the --setup
option.
Restore a system configured for warm standby
In a warm standby configuration, when the primary instance is restored from a backup, you must update the warm standby configuration.
Prerequisites
You need the following information to update your warm standby configuration:
- Password for the user on the secondary instance. If the user does not have a password, you must set one.
- Password for the PostgreSQL database replication user.
- Configuration information for creating the SSL certificate:
- Country code
- State code
- Organization
- Organization unit
- Domain
Restore a backup from a warm standby primary to the same instance
When you restore a backup of a warm standby primary to the same instance, the warm standby configuration must be updated.
To update the warm standby configuration, perform the following steps:
- Open a terminal session for both the primary and secondary instances. Keep these sessions open until you complete these steps.
- From the command line, SSH to your primary instance.
SSH <username>@<primary_phantom_hostname> - SSH to your secondary and warm standby instance.
SSH <username>@<warm_standby_phantom_hostname> - In both sessions, elevate to root.
sudo su -
- From the command line, SSH to your primary instance.
- On the primary instance of , perform the restore. See Restore from a backup.
- On the primary instance of , disable warm standby.
phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --primary-mode --off - On the secondary instance of , disable warm standby.
phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --standby-mode --off - On the secondary instance of , stop all services.
/<PHANTOM_HOME>/bin/stop_phantom.sh
Failing to stop these services on the secondary instance results in two active instances operating independently, polling for data and executing automated actions. This can result in data loss or other undesired results.
- On the primary instance of , configure it to be the primary instance for warm standby. You are prompted to give passwords for the user, the PostgreSQL database replication user, and the information for creating a self-signed SSL certificate.
phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --primary-mode --configure --primary-ip <primary_ip> --standby-ip <standby_ip> - On the secondary instance, configure it to be the warm standby instance.
phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --standby-mode --configure --primary-ip <primary_ip> --standby-ip <standby_ip> - On the both instances of , verify that warm standby is replicating on each instance.
phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --status
Example output from primary:
========= Processed Params ========= Instance looks like Primary DB replication configured with Standby set to: <warm_standby_ip>/32 DB replication currently streaming Vault sync configured ========= Script Done =========
Example output from secondary or warm standby:
========= Processed Params ========= Instance looks like Standby DB replication configured rsync configured ========= Script Done =========
Restore a backup from a warm standby primary to a new instance
When you restore a backup of a warm standby primary to a new instance that you want to become the new primary, you must update the warm standby configuration and move several keys to the secondary instance.
To update the warm standby configuration, perform the following steps:
- Open a terminal session for both the primary and secondary instances. Keep these sessions open until you complete these steps.
- From the command line, SSH to your primary instance.
SSH <username>@<primary_phantom_hostname> - SSH to your secondary and warm standby instance.
SSH <username>@<warm_standby_phantom_hostname> - In both sessions, elevate to root.
sudo su -
- From the command line, SSH to your primary instance.
- On the primary instance of , perform the restore. See Restore from a backup.
- On the primary instance of , disable warm standby.
phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --primary-mode --off - On the secondary instance of , disable warm standby.
phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --standby-mode --off - On the secondary instance of , stop all services.
/<PHANTOM_HOME>/bin/stop_phantom.sh
Failing to stop these services on the secondary instance results in two active instances operating independently, polling for data and executing automated actions. This can result in data loss or other undesired results.
- Copy these files from the new primary instance of to the secondary:
/<PHANTOM_HOME>/keystore/private_key.pem
/<PHANTOM_HOME>/www/phantom_ui/secret_key.py
- On the secondary instance of , set the permissions, ownership, and SELinux security contexts for the files you copied to the secondary.
- chmod 0640 /<PHANTOM_HOME>/keystore/private_key.pem /<PHANTOM_HOME>/phantom/www/phantom_ui/secret_key.py
- chown root:phantom /<PHANTOM_HOME>/keystore/private_key.pem
- chown phantom:phantom /<PHANTOM_HOME>/www/phantom_ui/secret_key.py
- restorecon /<PHANTOM_HOME>/keystore/private_key.pem /<PHANTOM_HOME>/www/phantom_ui/secret_key.py
- On the primary instance of , configure it to be the primary for warm standby. You are prompted to give passwords for the user, the PostgreSQL database replication user, and the information for creating a self-signed SSL certificate.
phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --primary-mode --configure --primary-ip <primary_ip> --standby-ip <standby_ip> - On the secondary instance, configure it to be the warm standby instance.
phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --standby-mode --configure --primary-ip <primary_ip> --standby-ip <standby_ip> - On both instances of , verify that the warm standby instance is replicating on each instance.
phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --status
Example output from primary:
========= Processed Params ========= Instance looks like Primary DB replication configured with Standby set to: <warm_standby_ip>/32 DB replication currently streaming Vault sync configured ========= Script Done =========
Example output from secondary or warm standby:
========= Processed Params ========= Instance looks like Standby DB replication configured rsync configured ========= Script Done =========
Splunk Phantom backup tools | Warm standby feature overview |
This documentation applies to the following versions of Splunk® Phantom (Legacy): 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!