Banking is one industry where downtime is never just an IT problem. When a bank’s core systems become unavailable, even for a few hours, the consequences are immediate. Customers cannot access accounts. Transactions fail. Branch operations halt. And regulators take notice.
For Indian banks, the stakes are particularly high. The RBI has clear requirements around business continuity and disaster recovery. Non-compliance is not just an operational risk. It is a regulatory one. Yet many Indian banks, particularly mid-sized private banks, cooperative banks, and small finance banks, are running disaster recovery architectures that were designed for a different era. Tape backups. Manual failover processes. Recovery timelines measured in days rather than hours.
What the RBI Actually Expects
Two Numbers Every Bank IT Leader Must Know: The RBI’s Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices sets clear expectations for business continuity and disaster recovery.
At the center of these requirements are two metrics:
- Recovery Time Objective (RTO) refers to how quickly systems must be restored after a disruption. How long can the bank afford to be down?
- Recovery Point Objective (RPO) refers to how much data the bank can afford to lose. If systems fail at 3 pm, can you recover to 2:55 pm or only to last night’s backup?
What Regulators Look for During Audits
A DR plan that has never been tested is not considered adequate by the RBI. Banks are expected to conduct regular DR drills and produce evidence of successful recovery under realistic conditions, typically at least once annually for full failover and more frequently for critical system components.
The Three Layers of a Strong DR Storage Architecture:
Layer 1: Primary Storage with High Availability
The first layer of disaster recovery begins at the primary data center. High availability storage with built-in redundancy ensures that hardware failures at the component level do not cause outages. Redundant storage controllers, redundant power supplies, and RAID configurations protect against individual disk or component failure without data loss or downtime.
For transaction-intensive core banking workloads, all-flash storage from vendors like Dell, HPE, Lenovo, or Everpure provides the performance and redundancy required. This layer protects against component failures. It does not protect against site-level events like power failures, flooding, or fire at the primary data center.
Layer 2: Synchronous Replication to a Near-Site DR Location
Zero Data Loss for Critical Systems – The second layer involves real-time replication of critical banking data to a secondary location, typically within the same city or metropolitan area. Synchronous replication means every write to the primary storage system is simultaneously written to the secondary site before being confirmed. This delivers an RPO of effectively zero. No data is lost even if the primary site fails.
For Indian banks, this near-site DR location is typically a Tier III or Tier IV data center facility within 50 to 100 kilometres of the primary site.
Layer 3: Asynchronous Replication to a Remote DR Site
Protection Against Regional Disasters – The third layer protects against regional events like floods, earthquakes, or large-scale power failures that could affect both the primary and near-site DR location simultaneously.
Asynchronous replication to a geographically distant location, typically in a different seismic zone at least 250 to 500 kilometers from the primary site, ensures that even a significant regional event does not result in permanent data loss. The trade-off with asynchronous replication is a small data lag between the primary and remote DR sites, typically measured in seconds to minutes. This makes the RPO for the remote site slightly higher than zero, but manageable for most banking workloads.
Common DR pairings for Indian banks include Mumbai primary with Hyderabad DR, Bangalore primary with Chennai DR, and Delhi primary with Bangalore DR.
Where Brilyant Can Help
Designing a disaster recovery storage architecture that meets both operational requirements and RBI compliance expectations requires technical depth and regulatory awareness in equal measure. Brilyant works with Indian banks to assess existing DR capabilities, identify gaps against regulatory requirements, and design storage architectures that deliver the RTO and RPO targets their business demands.
From high-performance primary storage and synchronous replication solutions using Dell, HPE, Lenovo, and NetApp infrastructure, to hybrid cloud DR architectures built on AWS, Azure, and Google Cloud with India-region data residency, our team brings the expertise banking DR projects require. We also support DR testing programmes, helping banks design, execute, and document regular failover tests that satisfy RBI audit requirements and give leadership genuine confidence in their recovery capabilities.
Frequently Asked Questions
What RTO and RPO should Indian banks target for core banking systems?
For banks with large retail customer bases, RTOs of four hours or less and RPOs as close to zero as possible are strong targets for core banking systems. These should be validated through regular DR testing, not assumed based on vendor specifications.
Is cloud-based DR compliant with RBI guidelines?
Yes, provided the cloud DR environment uses India-based data center regions and all data remains within India. Banks should review their cloud DR architecture against current RBI IT governance guidelines before deployment.
What is immutable backup storage and why do banks need it?
Immutable backup storage creates backup copies that cannot be modified, encrypted, or deleted for a defined retention period, even by administrators with full system access. It protects backup data from ransomware attacks, which increasingly target backup systems specifically to prevent recovery.
How often should Indian banks test their disaster recovery systems?
Full DR failover tests should be conducted at least once annually. Component-level and partial failover tests should be conducted quarterly for critical systems. All tests must be documented with results reviewed by senior leadership.
