Disaster recovery dashboard

The Disaster recovery dashboard provides a centralized view of the QRadar® Data Synchronization environment readiness before you initiate Failover or Failback operation.

Overview

The dashboard automates the validation of critical system checks that are required for successful disaster recovery operations and helps users identify potential issues before you perform Failover or Failback operation. You can use the dashboard to understand the current health status of the environment instead of manually verifying multiple configurations and dependencies.

Purpose

Disaster recovery dashboard helps to ensure that the environment is ready for Failover or Failback operation. The dashboard runs the required prechecks and provides clear visibility into system health status.

The dashboard displays the status of each disaster recovery check in an individual tile. Each tile represents a specific validation and shows whether the check status is Success, Warning, or Failed.

Prerequisites

The Disaster recovery dashboard is available in the following applications:
  • QRadar 7.6.0 and later
  • Data Synchronization app 4.0.0 and later

The dashboard is accessible after console pairing is completed. After you upgrade to Data Synchronization app 4.0.0, you must pair the console again if it was previously paired with an earlier version of the Data Synchronization app. This action helps to ensure that the dashboard functions correctly.

Disaster recovery checks

The Disaster recovery dashboard performs the following checks:
Compatibility check for QRadar version
Validates that the QRadar versions that run on the main site and destination site are compatible for disaster recovery operations.
Configuration check for main site and destination site
Verifies required main site and destination site configurations, such as 1:1 mapping, console-only or hybrid setup, and ensures consistency between QRadar and Data Synchronization app configurations.
Availability check for main site and destination site
Verifies main site and destination site accessibility and availability.
Connectivity status between main site and destination site hosts
Displays deployment topology and validates host pairing status, connectivity, and readiness of paired and unpaired hosts.
API connectivity check
Validates API communication between the main site and the destination site.
Location check for application deployment
Verifies that required applications are deployed on the QRadar console and not on an app host.
High availability configuration check
Validates that high availability configuration is not present on the restoration site before you perform Failover or Failback operation.
Backup validation check
Ensures that valid required backups are available for restoration.

Check status and troubleshooting

After all disaster recovery checks run, each check tile displays the following status:
Success
The validation is completed successfully and no action is required.
Warning
The check requires attention but does not block the Failover or Failback operation.
Failed
The check identifies an issue that must be resolved before proceeding.

For each failed or warning check, the dashboard displays the related issue details along with troubleshooting steps. Users can review the recommended actions and resolve the issues before you start disaster recovery operations.

The Host Connectivity check provides filters based on status and issues, allowing users to quickly identify specific concerns. Applied filters are reflected in both the graphical view and table view for better visibility and faster troubleshooting. The Host Connectivity check also displays a list of identified issues. Users can select an issue to view the corresponding troubleshooting steps and recommended actions to resolve it

Refresh behavior and operation status

You can refresh the dashboard to run all disaster recovery checks again and retrieve the environment status.

When the refresh operation is initiated:
  • A status panel displays the message to inform users that the disaster recovery checks are currently running.
  • The status panel indicates that users must wait until all checks are completed before you start any further actions.
  • The Refresh, Activate Destination Site, and Failback to Main Site buttons are disabled while the disaster recovery checks are in progress. This precaution prevents triggering multiple refresh operations or initiating disaster recovery operations with incomplete validation results.
  • After all disaster recovery checks are completed:
    • The status panel is updated with the check execution status.
    • The Refresh, Activate Destination Site, and Failback to Main Site buttons are enabled based on the environment health status.
    • The Last Updated Time option is refreshed to reflect the check execution time.
    • Updated check results are displayed on the individual disaster recovery check tiles.

Failover and Failback operations

You must complete the following actions as a prerequisite for Failover or Failback operation:
The Disaster recovery dashboard helps to directly initiate Failover or Failback operation from the dashboard. The following two options are available:
Activate Destination Site
Starts the Failover operation
Failback to Main Site
Starts the Failback operation

If any disaster recovery check is in a Failed state, the corresponding action button is disabled to prevent starting disaster recovery operations on an unhealthy environment.

If users still need to initiate Failover or Failback operation despite failed checks, they can browse to the Activate destination site/Failback to main site link from the menu. However, you must review and resolve the failed checks before you proceed with the Failover or Failback operation.

During Failover or Failback operations, the status panel displays the current operation progress as follows:
Failover
When Failover is in progress, activation is in progress
Failback
  • When Ariel sync is in progress, the Ariel data synchronization to the main site is in progress. The synchronization process might take some time depending on the volume of data that is transferred. Check the status again after some time.
  • For Console-only and hybrid workflow: When Ariel syncs completed and restoration is in progress, Ariel data synchronization to the main site is completed successfully. The main site restoration process is currently in progress and may take some time to finish. Check the status again after some time.
  • For Console-only and hybrid workflow: When Failback is completed, the failback process has completed successfully. Perform reactivation from the main site, followed by a deployment. You might observe pairing-related issues while reactivation is still pending. After reactivation, allow sufficient time for synchronization and pairing to stabilize before you validate the overall system health.
Note: Reactivation of the main site is performed from the main site.

Handling main site unavailability

If the main site is unreachable:

  • During prechecks before Failover, main site-related checks are skipped and displayed as Warning because the unavailability is expected during a disaster scenario.
  • During prechecks before Failback, main site-related checks are displayed as Failed because the main site must be available before falling back to the main site.