Choosing the Right Disaster Recovery Model in IBM QRadar (DS-App Explained)

(Design Considerations, Cost Optimisation, and Best Practices)

Overview

In real-world scenarios, organisations often discover the limitations of their disaster recovery setup only during an actual failure. Imagine facing a production because they were not fully aware of the capabilities and limitations of their chosen IBM QRadar Data Synchronisation App (DS-App) deployment model.

A common misconception is that DS-App provides complete environment replication and seamless failover. In reality, choosing the wrong deployment model can result in increased downtime, higher costs, or incomplete recovery, unexpected challenges when they matter the most.

This blog provides a detailed overview of the IBM QRadar Data Synchronisation App (DS-App) and its role in enabling a right-sized disaster recovery strategy. The focus is on:

• Types of DS-App deployment models
• DS-App architecture
• DS-App Deployment models - Comparison overview
• Key features and capabilities
• Advantages and limitations of each model
• Guidance on choosing the most suitable and cost-effective deployment option

Customers often have different expectations of the DS-App, such as assuming it provides full redundancy or eliminates downtime during major upgrades. This blog clarifies what DS-App does and does not provide, helping you make an informed decision based on your business and operational requirements.

Scope

This blog does not cover low-level technical details such as:

• Supported configurations
• Version compatibility
• Failover and failback procedures
• Known limitations or operational constraints

For detailed technical guidance, refer to the official IBM documentation:

• https://www.ibm.com/docs/en/qradar-common?topic=apps-qradar-data-synchronization-app
• https://www.ibm.com/docs/en/qradar-common?topic=app-qradar-console-only-dr
• https://www.ibm.com/docs/en/qradar-common?topic=app-qradar-hybrid-setup

Types of QRadar DS-App Configurations

The DS-App supports three deployment models:

1. One-to-One (1:1) Mapping DS-App Configuration
2. Console-Only DS-App Configuration
3. Hybrid DS-App Configuration

Each model is designed to address different business continuity and cost considerations.

DS-App Deployment Models – Comparison Overview

One-to-One Mapping – Data Synchronisation (DS-App)

Overview

The 1:1 mapping model provides maximum redundancy by maintaining a near real-time mirror of the QRadar environment across two sites.

In this model, the Disaster Recovery (DR) site is a complete replica of the Primary Site (DC). The DS App continuously synchronises live data (such as Ariel events and flows) from managed hosts of the main site (DC) to managed hosts of the destination (DR) site. Configuration and application backups are generated and synchronised once every 24 hours based on a predefined schedule.

Key Characteristics

• Continuous synchronisation of events, flows and configurations on managed hosts
• Geographically separated Primary (DC) and DR sites
• Identical architecture and scale across both environments
• High consistency during failover
• Fastest recovery time
• Manual migration of log sources is required

Key Benefits

Business Continuity Assurance
Full synchronisation and redundancy between managed hosts minimises downtime during failures.

Always-Ready DR Environment
The DR site remains fully prepared for activation at any time. No runtime restoration of configuration is required.

Seamless Failover Capability
No runtime restoration of the configuration is required on the destination site, making this model seamless during activation. 

Controlled Recovery
Main site remains untouched during failover. No configuration restore happens on the main site. 

RPO & RTO:

Lowest RTO <1 hrs to bring up the standby system during an actual disaster, and 24hrs RPO for config backup, and RPO for Ariel data is configurable for every minute, and the least interval we can set is nightly at midnight 24hrsly

Considerations

• High Infrastructure Cost
  Requires full duplication of hardware and licensing.
• Manual Actions During Failover
  Data sources may need to be manually redirected to the Active site during failover and failback
• Data Source Adjustments
  Minor changes may be required depending on ingestion methods.
• Scalability Limitations
  It may not be cost-effective for very large environments.

App Host limitations for 1:1 Deployment

• App host, QRadar Risk Manager, QRadar Vulnerability Manager, QRadar Incident Forensics mapping is not supported. 
• App Hosts can exist on both the main site and the destination site. App data is NOT synchronised between sites. Applications must be installed separately on both sites.
• Manual restore of app data backup is required on the destination site.
• Automated redirection of data sources is not possible during failover and failback.

Console-Only Data Synchronisation (DS-App)

Overview

The Console-Only DS-App configuration is a cost-effective disaster recovery solution that focuses on protecting only the most critical QRadar component—the Console.

Rather than duplicating the entire environment, this model synchronises the Console configuration and Application backups between the Primary (DC) and DR sites. All other QRadar components remain independent, significantly reducing cost and complexity.

Key Characteristics

• Only the Console is backed up and synchronised between DC and DR
• Daily configuration backups are shared automatically
• The DR Console can be activated using the most recent configuration backup
• Applications can be restored or reactivated as needed

Key Benefits

Highly Cost-Effective
No need to separate the mapping of any other managed hosts in deployment.

Ideal for Large Environments
Especially suitable where full environment replication is impractical or cost-prohibitive.

Ideal for the compliance perspective
This is useful where we need to maintain the redundancy or application availability of the Console Application

Rapid Recovery of Core Functions
The Central Management Console are restored quickly during failures.

RPO & RTO:

Highest RTO >2 hrs to bring up the standby system as Active during an actual disaster, and 24hrs RPO for config backup, and RPO for Ariel data is configurable for every minute for console Ariel data, and the least interval we can set is nightly at midnight 24hrsly

Considerations

• Redundancy scope
  Only the console has redundancy
• Application Readiness
  Applications may need to be installed or migrated in advance to the console before failover and failback.
• Limited Protection Scope
  Only the Console is protected; other components are not mirrored.
• Manual Preparation for HA Environments
  Temporary adjustments may be required if Console has a High Availability setup.

App Host Limitations for Console-Only Deployment

• Applications installed on the App host are not supported

o   Controlled DC DR Failover Limitation:
Applications hosted on App Host are not supported and need to be migrated before failover or failback.

o   During Actual Disaster:
Failover will work, and the application won’t be restored on the destination.
However, for failback, manual intervention is needed to forcefully move applications to the console. Reach out to IBM Support.

• App Host is available only on the main site. The destination site does not have an App Host.
• Applications must be manually installed on the destination console. Since it does the configuration restore during failover and failback, the RTO for this is the highest

Hybrid Data Synchronisation (DS-App)

Overview

The Hybrid DS-App configuration provides a balance between cost optimisation and high availability, making it ideal for large or distributed QRadar environments.

Instead of mirroring everything, only the same business rules of critical servers are paired between the DC and DR sites. Non-critical systems remain independent and can be redirected during failover as required.

Key Characteristics

• The same business rules of critical systems are synchronised and paired for rapid failover.
• Non-critical components remain flexible and get migrated between DC and DR.
• Only selected components fail over during incidents.
• Optimised use of infrastructure and resources.

Key Benefits

Balanced Cost and Protection
The same business rule of critical components receive full protection without unnecessary duplication.

Minimal Business Disruption
Only essential systems are switched during failover events.

Ideal for Enterprise-Scale Deployments
Designed for environments spanning multiple locations.

Rapid Recovery of Core Functions
The Central Management Console are restored quickly during failures.

Priority-Based Protection
Ensures that business-critical systems are always covered.

RPO & RTO:

Medium RTO >1 hrs to bring up the standby system as Active during an actual disaster, and 24hrs RPO for config backup, and RPO for Ariel data is configurable for every minute for console and critical data for the paired systems, and the least interval we can set is nightly at midnight 24hrsly

Considerations

• Requires Careful Planning.
  Correct identification of a single business rule of critical systems is essential.
• Partial Automation During Failover
  Some components may require manual coordination.
• Increased Complexity
  More complex than single-model approaches and requires good design governance.

App Host Limitations for Hybrid Deployment

• App Host is available only on the main site (similar to Console-Only).
• Applications must be manually configured on the destination console.
• Failover Behaviour:
  • Not supported when the main site is available, and apps depend on the App Host.
  • Supported only when the main site is completely unavailable (actual disaster) and apps are running on the App Host.
• Requires manual app migration and manual transfer of app data backup to restore apps on the destination.
  

When to Recommend Each Option

1:1 Mapping

• When maximum protection and maximum redundancy are required.
• Highest RTO
• When the budget is not a constraint
• Best suited for highly mission-critical environments where you need to protect historical data.

Console-Only

• When Disaster Recovery is only needed for a Console Application
• When cost optimisation is the priority
• Ideal for large deployments where you have a focus on bringing the console application up and running.
• Lowest RT

Hybrid Model

• When balancing cost and resilience is required
• When system criticality varies in the deployment.
• Best for distributed or enterprise-scale environments
• High RTO
• Protects the historical data of Critical servers.

Conclusion

Choosing the right DS-App deployment model is not just a technical decision—it is a business decision.

Organisations must carefully balance cost, complexity, and recovery requirements when designing their disaster recovery strategy. Each model offers distinct advantages, and the right choice depends on how critical system availability is to your operations.

By understanding the strengths and limitations of each approach, you can implement a disaster recovery strategy that aligns with your business goals and ensures resilience during real-world failures.

If you have any questions about the topics discussed or would like to explore these capabilities further, please feel free to reach out to us for a detailed discussion.

Author        – Nitin Sarode (nitin.sarode@ibm.com)
                     – Saket Nimdeokar (saket.nimdeokar1@ibm.com)
Reviewer   – Vishal Tangadkar (vishal.tangadkar1@ibm.com