Switching deployment control back to the main site from the destination site

When your main site is ready, switch deployment control back to the main site from the destination site.

Take fresh backups on both the main and the destination sites. After a backup is generated, the system transfers the generated backup to another site. Open the Backup and Recovery screen to check whether the transferred backup is visible. If the transferred backup is not visible, refresh the Backup and Recovery screen.

Failback is the restoration operation to the main site when you no longer require the destination site to replace the main site's operation. When you fail back to the main site, the Ariel copy process copies the Ariel data that was collected. The data comes from the time that the destination site was activated until the end of the hour when the failback process initiated.

The time that the failback process takes can vary based on the following conditions:

The length of time the destination site was active.
The amount of data that was collected on the destination site while it was active.
The bandwidth available between the destination site and the main site.

Ariel copy accepts only time to the nearest hour. The time when failback starts is rounded down to the nearest hour. 9:15 AM is saved as 9:00 AM in the Ariel copy profiles. Ariel copy synchronizes that entire hours worth of data; for example, from 9:00 AM to 9:59 AM.

In this failback process, Ariel sync is completed and receives a notification that the Ariel copy is complete on the destination site. After Ariel sync completion, restoration automatically starts on the main site with the latest backup that was taken after activation on the destination site and transferred to the main site. After the main site restoration completes, the restoration starts on the destination site.

Tip:

If the main site wasn’t available during activation (activation scenario 1), the latest backup from the destination site that the admin initiated before activation is restored on the destination site during the failback process.

If the main site was available during activation (activation scenario 2), the latest main site backup that was transferred to the destination site is restored on the destination site during the failback process.

Activate the destination site.
1. In the QRadar® Console on the destination site, click Admin > Data Synchronization app.
2. Open the app menu and select Failback to main site.
3. Click Perform failback and then confirm.
4. Point all data sources that were directed to the destination site back to the main site.
5. On the main site QRadar Console, run the script /opt/ibm/si/dr/bin/dr_clear_seal_files.sh on the hour that the failback was completed to allow for data to be properly synced between sites.
Reactivate the main site.
1. In the QRadar Console on the main site, click Admin > Data Synchronization app.
2. Open the app menu and select Reactivate main site.
3. Click Reactivate and then Next .
4. On the Admin tab for both the main site and destination site, click Deploy Changes. The main site is now active.

After completion of activation, the pairing connection between both the sites is removed. To establish the pairing connection again, you must run the following pairing commands from both the sites:

In the QRadar Console on the main site, run the following script:
```
/opt/ibm/si/dr/bin/dr_create_ssh.sh -i <destination_site_ip>
```
.
In the QRadar Console on the destination site, run the following script:
```
/opt/ibm/si/dr/bin/dr_create_ssh.sh -i <main_site_ip>
```
.

Attention: Apps (installed console or AppHost) are not restored or migrated during the failback or failover operation. You can restore these apps by using the following steps:

If apps are on the console, back up your app data by running the app-volume-backup.py backup script. Then, transfer on the other console, initiate a failover or failback operation, and restore the apps manually by running the script app-volume-backup.py.
If apps are on AppHost, move all installed apps to the console, and take the data backup of apps by running the app-volume-backup.py backup script. Then, initiate a failover or failback operation so the AppHost moves from the main console to DR and from DR to the main console without apps. As a last step, restore the apps manually by running the script app-volume-backup.py.

If any apps are found in an Error state after restoration is complete or after the failover or failback operation, restart the apps by using the qappmanager utility (/opt/qradar/support/qappmanager).