Active sites and disaster failover

After more than four years of full-scale war, the continuity of corporate information systems remains one of the main priorities for Ukrainian enterprises. Backups, geographically distributed data centers, and cloud platforms help mitigate the impact of individual failures, but they do not guarantee data consistency during complex infrastructural disruptions. Situations where multiple sites lose communication with each other, and information systems continue to accept independent transactions, are particularly dangerous. In such conditions, the correct choice of replication model, control of the primary node’s authority, quorum and fencing mechanisms, as well as proven failover and failback procedures play a crucial role.

April 2026: Business Continuity Amidst Prolonged Infrastructural Threats

In the fifth year of the full-scale Russian invasion, Ukrainian enterprises continue to operate under conditions of high physical and informational risks.

A significant portion of corporate IT infrastructure has been modernized in previous years. Companies have created remote backups, migrated individual applications to cloud environments, organized backup telecommunication channels, and deployed additional server sites. However, the presence of backup infrastructure does not yet mean full readiness for prolonged disruptions.

Power outages, data center unavailability, damage to a backbone channel, or compromise of the administrative environment can simultaneously affect multiple components of the information architecture. For large enterprises, situations where the main systems physically continue to operate but cannot exchange information are particularly challenging.

For example, the main data center remains accessible to local users but loses connection with the backup site.

An automatic monitoring system might mistakenly interpret such a situation as a complete failure of the primary node. If the backup node activates transaction acceptance, the enterprise risks ending up with two independent versions of its corporate data.

For ERP, this can mean conflicts in financial documents, inventory balances, and orders. For MDM, it means the emergence of different versions of directories.

For Data Warehouse, it means conflicting analytics that use records from different information branches.

Therefore, a modern Business Continuity strategy must consider not only server availability but also the consistency of corporate data. According to a joint RDNA5 assessment released on February 23, 2026, Ukraine’s recovery and reconstruction needs over the decade amount to nearly $588 billion. The assessment covers the consequences of the war as of December 31, 2025, and reflects the scale of damage, particularly to energy and transport infrastructure.

For corporate IT, this context means the need to plan not for a short transition period, but for the long-term operation of systems in an environment of recurring risks.

The main architectural question for April 2026: how to ensure the availability of critical information services without allowing the emergence of multiple conflicting sources of truth?

2. Active-Passive vs. Active-Active: Fundamental Difference

Various redundancy models are used in corporate practice.

The simplest in terms of recording logic is Active-Passive.

One node or site receives transactions, while a backup maintains the necessary state and is activated after a defined event.

Active-Active assumes that multiple components can simultaneously serve the workload. However, it is necessary to distinguish between Active-Active for application services and Active-Active for transactional data.

For example, two web servers can simultaneously serve users by accessing a single authoritative database.

This is a relatively common architecture.

Conversely, two independent ERP instances that simultaneously modify the same financial records present a significantly more complex challenge.

Model Comparison

For large enterprise ERPs, a single active authoritative write model often remains more practical. This does not mean Active-Active is a bad solution.

It means it should only be applied with an appropriate data model.

3. Multi-Site Architecture: Different Tiers Have Different Availability Modes

A robust enterprise architecture should not require the same redundancy model for all components.

For example, a web application can run on two sites simultaneously.

Transactional database - have a primary node and a synchronous or asynchronous replica.

Analytical storage - recover from backups and reloads.

And an enterprise archive - be stored independently with a lower priority for fast access.

Logical Architecture

• Enterprise Users and Branches
• Secure Access · Routing · Authentication Control
• Site A
• Application Services
• Primary ERP DB
• Integrations
• Platform B
• Application Services
• Standby ERP-DB
• Backup Integrations
• Data Replication · Role Control · Secure Connection
• Independent Arbitration and Switchover Control
• Quorum · Fencing · Promotion Rules · Decision Log
• Independent Backup Storage
• Historical Copies · Integrity Control · Verified Recovery Procedures

This scheme does not automatically assume that two data centers can simultaneously modify a single transactional database.

Application services can run on both sites, but writes are directed to a designated authoritative node.

This approach reduces the complexity of information consistency.

4. Synchronous Replication: Guarantees and Limitations

PostgreSQL 18 provides built-in synchronous and asynchronous replication mechanisms.

Synchronous replication allows configuring transaction commit acknowledgments from designated standby nodes.

For example, the synchronous_standby_names parameter supports prioritized selection and the ANY quorum mode.

The official PostgreSQL documentation describes the ability to wait for acknowledgment from a specific number of standby servers.

Conditional example:

synchronous_standby_names = 'ANY 1 (standby_a, standby_b)'
synchronous_commit = on

This mode means that at least one of the specified synchronous standbys is required to respond for the transaction to be acknowledged. However, this does not automatically guarantee zero RPO in all scenarios.

It is necessary to consider the exact commit type used, the standby node’s status, promotion rules, and the procedure for electing a new primary server. Additionally, synchronous replication increases transaction commit latency.

If the standby site is located far away, this can impact ERP performance.

Comparison

For critical systems, the choice should be determined by BIA, RPO, and performance requirements.

5. Quorum does not replace fencing

One of the most dangerous mistakes is assuming that the presence of quorum automatically eliminates the risk of split-brain.

Quorum helps the system determine if it has enough support to make a given decision. However, this does not guarantee that the old primary server has physically stopped accepting writes.

Suppose datacenter A lost connection to the replica nodes.

The system at site B decides to activate the backup server. However, local users of data center A continue to work with the old ERP.

As a result, two servers accept independent changes. To prevent this, fencing is required — a mechanism that eliminates the possibility of further writing to the old primary node.

It can be implemented through power management, blocking access to storage, node disconnection, or another proven mechanism.

In this case, fencing must be reliable even with partial network loss.

Function Distribution

The sequence of actions is most important.

The new primary node must not initiate writes without proper confirmation that the old one can no longer modify the same data.

6. Automatic and Manual Failover

Automatic switching can reduce downtime. However, its feasibility depends on the system type and the nature of the risks.

For example, automatic switching between two web servers is generally less risky than automatic promotion of a transactional ERP.

In the latter case, an erroneous decision can lead to the loss of confirmed operations or a split-brain scenario.

Therefore, for critical databases, the conditions for switching must be defined.

Comparison

For Ukrainian enterprises with potential prolonged communication disruptions, automatic failover should consider situations where the primary site is not destroyed but merely isolated.

Therefore, for some ERPs, a semi-automatic process with mandatory verification before promotion might be rational.

7. PostgreSQL: Replication Monitoring

To assess the replication status of PostgreSQL 18, the pg_stat_replication system view can be used.

SELECT
    application_name,
    client_addr,
    state,
    sync_state,
    sent_lsn,
    write_lsn,
    flush_lsn,
    replay_lsn,
    write_lag,
    flush_lag,
    replay_lag
FROM pg_stat_replication;

The query allows determining the current status of connected standby nodes.

To estimate WAL byte lag:

SELECT
    application_name,
    pg_wal_lsn_diff(
        pg_current_wal_lsn(),
        replay_lsn
    ) AS replay_bytes_behind
FROM pg_stat_replication
WHERE replay_lsn IS NOT NULL;

However, WAL byte lag cannot be automatically equated with temporal RPO. One transaction might generate significantly more WAL than another.

Furthermore, the absence of new writes does not necessarily indicate a replication issue.

Therefore, for critical systems, additional checks are necessary: standby node availability, confirmation of change application, and actual recovery tests.

8. Failback: Returning to the Primary Site

In many projects, the greatest attention is paid to failover.

However, returning to the primary site can be no less complex.

Suppose ERP has moved from data center A to data center B.

For two days, the backup site has been accepting new transactions. After data center A is restored, you cannot simply start the old primary server and redirect users back.

Its state is already outdated. It needs to be synchronized with the current authoritative node.

PostgreSQL has a tool called pg_rewind, which allows synchronizing the data directory of the old primary with the new primary after a timeline divergence, provided the relevant technical prerequisites are met.

However, pg_rewind is not a universal tool for merging two independent transaction histories. If both nodes accepted independent writes after a split-brain, separate investigation and business reconciliation are required.

Failback Control Procedure

1. Confirm which node is authoritative.
2. Disable writes on the old primary server.
3. Verify the status and availability of required WAL.
4. Synchronize or restore the old node.
5. Verify replication.
6. Perform test application operations.
7. Agree on the return with business process owners.
8. Controlledly change access routes.
9. Confirm RPO/RTO and Data Integrity.

Failback should not be performed solely because the primary site is available again.

It must be economically and technically justified.

9. Kafka 4.2 and Event System Resilience

Apache Kafka 4.2.0 was released in February 2026.

One of the important changes was the readiness of Kafka Queues (Share Groups) for production use.

This mechanism allows multiple consumers to cooperatively process messages with individual acknowledgments and redelivery tracking.

Kafka 4.2 also enhances monitoring, Kafka Streams rebalancing protocols, and dead-letter message handling mechanisms.

However, to build a resilient event-driven architecture, several different issues need to be separated. Kafka replication ensures record persistence across brokers according to configuration.

Consumer Offsets define read positions. Share Groups allow organizing specific shared processing scenarios.

Idempotency of business operations remains the responsibility of the application architecture. For example, re-receiving a shipment event should not create a second financial document.

Even if the message is reliably stored in Kafka, the ERP must control duplicates.

Example Information Flow

• ERP: confirmed transaction
• Transactional Outbox / CDC
• Kafka: replicated event log
• Idempotent integration service
• WMS / DWH / CRM
• Data Reconciliation

During recovery, the state of both Kafka and dependent systems must be considered. For example, DWH might recover to a previous point, while Kafka contains events from a later period.

In such a case, controlled reprocessing is required.

10. Data Warehouse: Analytics Recovery After Failover

The corporate data warehouse has different availability requirements than a transactional ERP.

For example, a company might tolerate temporary unavailability of complex analytics but cannot stop shipment processing.

Therefore, the DWH architecture must consider the possibility of gradual recovery.

Priorities

It is especially important not to run all ETL processes simultaneously after a long downtime. If several departments have accumulated data, mass transfer can overload the ERP or network channels.

Therefore, a managed catch-up processing procedure is needed.

It should include priorities, rate limiting, retry control, and Data Quality Gates.

11. Inter-system reconciliation after an incident

Assume ERP is restored by 10:15, WMS contains operations up to 10:20, and CRM has orders up to 10:25. If all integrations are automatically restored, there is a risk of duplicate and missed operations.

Therefore, before returning to normal operation, it is necessary to determine a consistent information state.

Example of a control table

CREATE TABLE recovery_control (
    reconciliation_id BIGSERIAL PRIMARY KEY,
    source_system VARCHAR(100) NOT NULL,
    target_system VARCHAR(100) NOT NULL,
    business_date DATE NOT NULL,
    expected_count BIGINT,
    actual_count BIGINT,
    expected_amount NUMERIC(18, 2),
    actual_amount NUMERIC(18, 2),
    status VARCHAR(30) NOT NULL,
    checked_at TIMESTAMPTZ
);

Discrepancy Search:

SELECT
    source_system,
    target_system,
    business_date,
    expected_count,
    actual_count,
    expected_amount,
    actual_amount
FROM recovery_control
WHERE expected_count IS DISTINCT FROM actual_count
   OR expected_amount
      IS DISTINCT FROM actual_amount;

A match in the number of records and sums does not guarantee complete correctness. For critical operations, it is necessary to verify document identifiers, counterparties, currency, and statuses.

This is especially true for financial and inventory operations.

12. Active Sites and the CAP Model

When discussing Active-Active, the CAP theorem is often referenced.

It describes the limitations of distributed systems regarding the simultaneous provision of consistency and availability in the presence of network partitioning. However, CAP does not mean that an enterprise must permanently choose between ‘consistency or availability’ for all its data.

Different business operations can use different models. For example, a financial payment requires strict state control.

A small delay may be acceptable for an analytical data mart. Local order drafts can operate offline with subsequent confirmation.

Practical Differentiation

The business context itself determines the acceptable trade-off. It is also important to distinguish between network availability and the ability to securely perform an operation.

Sometimes the correct solution is to temporarily deny write access to avoid creating conflicting financial data.

13. Economics of Multi-Site Architecture

Geographic redundancy incurs additional costs. The enterprise must pay for servers, storage, communication channels, backup power, licenses, and administration.

Therefore, the model must align with the criticality of business functions.

Conditional Comparison

The amounts are notional and do not represent market rates.

The comparison must include not only regular expenses but also downtime risk and operational complexity.

For example, Active-Active might be justified for a high-load customer portal.

And for an internal ERP with a relatively small number of users, Warm Standby might offer a better balance of cost and resilience.

14. Practical Scenario: A Manufacturing Enterprise with Two Sites

Let’s consider a hypothetical Ukrainian enterprise that has a primary data center, a backup site, and several production facilities.

Core Systems:

• ERP on PostgreSQL;
• WMS;
• CRM;
• Electronic Document Management System;
• Kafka;
• Corporate DWH;
• MDM.

Phase 1. BIA

The enterprise defines critical functions and acceptable RPO/RTO.

Phase 2. Architectural Map

Dependencies between applications, databases, and channels are formed.

Phase 3. Replication

For ERP, the mode is selected according to business requirements.

Phase 4. Fencing

A proven mechanism for excluding the old primary node is implemented.

Phase 5. Controlled Failover

Performing test switchover.

Stage 6. Data Reconciliation

ERP documents, inventory balances, and integration messages are being checked.

Stage 7. DWH Recovery

ETL processes and reprocessing are being controlled and launched.

Stage 8. Failback

The old primary node is synchronized with the new authoritative state.

Stage 9. Business Acceptance

Process owners confirm operability.

Stage 10. Documentation

Actual RPO/RTO and issues are recorded in the report.

This is a hypothetical scenario, not a description of a specific implemented project.

15. 90-Day Implementation Roadmap

For enterprises with critical production, testing must be conducted in a way that does not endanger people or technological processes.

16. Geographic Resilience KPI

Metrics should be checked regularly.

The mere configuration of replication does not guarantee disaster recovery readiness.

17. Risks and Common Mistakes

Active-Active without data analysis. Simultaneous application launch does not imply multi-writer safety.

Absence of fencing. Old primary can continue accepting writes.

Excessive trust in automatic failover. Network isolation does not equal physical server loss.

Incorrect RPO assessment. WAL byte lag is not a direct time metric.

Replication instead of backup. Logical errors can propagate to replicas.

Unprepared failback. Returning the old server can lead to loss of new transactions.

Insufficient Kafka control. Broker availability does not guarantee correct business operation execution.

Ignoring MDM. After a failure, directories from different systems may diverge.

Absence of Data Reconciliation. Technical recovery does not prove the correctness of business records.

Excessive complexity. The most complex architecture is not necessarily the most reliable for a specific team.

18. Intecracy Group Competencies

Ensuring the geographical resilience of corporate information systems requires a combination of infrastructure, integration, and data management competencies.

Data Management IG (dmig.com.ua) specializes in ETL, MDM, Data Quality, Data Warehouse, Data Lake, Data Governance, and corporate analytics. These competencies can be used to restore integration flows, verify the consistency of corporate data, protect historical information resources, and control Data Quality after switching.

IQusion IT (iqusion.com) represents system integration, electronic document management, Business Process Management, and business process automation. These competencies are important for restoring end-to-end processes, approvals, documents, and application integrations between sites.

As of November 2026, Softline IT lists corporate network deployment, server infrastructure, and data storage systems among its services. These areas can provide the physical foundation for primary and backup data centers, network connectivity, and reliable data storage.

As of November 2026, SL Global Service lists cloud migration, virtualization, and hybrid cloud design among its services. These competencies allow for consideration of geographically distributed environments, backup computing resources, and hybrid deployment models.

The combination of specializations can provide a comprehensive approach to information resilience, without implying the existence of specific confirmed implemented wartime projects.

Availability without consistency does not guarantee business continuity

In the fifth year of the full-scale war, Ukrainian enterprises must continue to develop resilient information architecture.

Geographic redundancy, cloud technologies, and automatic failover can mitigate the consequences of physical incidents.

However, an increase in the number of active sites creates additional complexity.

This is especially true for transactional systems, where different nodes should not independently modify the same business information without a proper coordination model.

Therefore, Active-Active must be applied consciously.

For application services, it can provide high availability.

For transactional databases, it requires specialized protocols or limiting writes to a single authoritative node.

Quorum, fencing, and a controlled promotion procedure play an important role.

Replication does not replace independent backup.

After a disaster, the enterprise must be able to return to a previous usable state and restore not only the server but also the business integrity of the information.

Failback remains particularly important.

Returning to the old primary site should not lead to the loss of transactions created while the backup site was operational.

A separate recovery strategy is needed for corporate DWH and analytics, which considers historical data, ETL, checkpoints, and the possibility of reprocessing.

Furthermore, the solution must be economically justified.

Not every enterprise requires a complex multi-writer architecture.

In many cases, a simpler Active-Passive model with proven failover will provide better resilience at a lower cost.

The main conclusion of April 2026: a resilient enterprise architecture should ensure not the maximum number of active servers, but the preservation of a single authoritative information state and controlled recovery of critical business functions.

For the Data Management IG, this means strengthening the role of data management in high-availability projects.

Data Replication, Data Quality, MDM, ETL Recovery, and Data Governance become integral components of Business Continuity.

It is their combination with a reliable infrastructure that allows the enterprise to maintain manageability during complex and repeated disruptions.