Disaster Recovery Patterns

Cloud DR ranges from a minimal pilot light to a fully live multi-site design. IZO™+ Multi Cloud Connect gives each pattern the same thing: a private, predictable replication path and a network that fails over deterministically, so your recovery time depends on your application, not on the link.

What this is

Disaster recovery is about two numbers: RTO (Recovery Time Objective), how quickly you must be running again, and RPO (Recovery Point Objective), how much data you can afford to lose. The tighter both are, the more you keep running in the recovery site – and the more the pattern costs. This page maps the common patterns onto IZO™+ Multi Cloud Connect.

The patterns

Pattern	What runs in the recovery cloud	Relative RTO	Relative RPO	Relative cost
Pilot light	Core data replicated; minimal always-on services; compute scaled up on failover	Hours	Low–minutes	Lowest
Warm standby	A scaled-down but running copy of the whole stack	Minutes–tens of minutes	Low	Medium
Multi-site active-active	A full, live copy serving traffic	Near zero	Near zero	Highest

Pilot light keeps only the essentials warm – typically the database, replicated continuously – and brings the rest of the environment up when disaster is declared. Warm standby runs the entire stack at reduced scale so failover is mostly a matter of scaling out. Multi-site active-active is the design on page 13.2, used as a DR posture: nothing to “bring up” because it is already live.

How IZO™+ Multi Cloud Connect supports it

Replication is the traffic that never stops, so it belongs on a private path where latency and jitter are predictable. An IZO™+ Multi Cloud Connect Direct connection carries replication between your primary site and the recovery cloud; the resiliency tier you choose (Standard, High or Maximum) should match how catastrophic the failure you are protecting against is. Protecting against a rack or link failure is Standard; protecting against loss of a whole metro is Maximum, with paths diverging across regions.

At failover, the network must move quickly and cleanly. BGP with active/backup weighting means the recovery path is pre-established and simply promoted – there is no new circuit to turn up under pressure. Design the failover to be routing-driven so that declaring a disaster does not also mean rebuilding connectivity.

Example

A general insurer protects its claims platform with a warm-standby design in Google Cloud. The production database replicates continuously over an IZO™+ Multi Cloud Connect Direct connection to a scaled-down copy of the platform in the recovery region. Twice a year the insurer runs a failover test by promoting the recovery site; because the private path and BGP failover are already in place, the exercise validates the application, not the network.

MCC components in this architecture

DR is usually a Direct, dual (Primary/Standby) build; the standby path is pre-provisioned so failover is a routing change, not a new order:

IZO™+ Multi Cloud Connect Direct (private MPLS underlay):

Fabric Port ×2 – primary and standby on-ramps.
Virtual Cloud Connection ×2 – a live and a pre-provisioned standby landing on the recovery cloud.

IZO™+ Multi Cloud Connect Flex (internet underlay with an in-path VNF):

Fabric Port – the on-ramp where your network meets the service (Hosted or Dedicated; L3 Private access is typical). Present in every solution. (×2 for HA)
Edge Connect – the short leg that carries traffic from the Fabric Port to the VNF.
VNF (optional) – whatever the DR design needs an in-path function.
Virtual Cloud Connection ×2.

From the IZO™+ Multi Cloud Connect side, this architecture uses dual Fabric Ports + dual Virtual Cloud Connections with the standby path pre-built; the Tata Communications-billed parts run to the Virtual Cloud Connection, while the recovery cloud’s port/attachment and egress sit on your cloud bill.

Considerations

Pre-provision the standby - Keep the recovery path’s Fabric Port and Virtual Cloud Connection built and peering so declaring a disaster promotes a route rather than ordering connectivity.
Match the tier to the failure - Standard (in-metro dual) protects against link/rack loss; Maximum (cross-region/multi-metro) protects against loss of a whole metro. See Geo-Redundancy & Multi-Metro Failover.
Replication path - Replication never stops – put it on a Direct private path and size for it continuously.
RTO/RPO are relative bands here - Confirm any published or contractual RTO/RPO and DR SLA with the product team before quoting numbers.
Cost - Roughly a doubling of connectivity components for the standby; the recovery cloud’s compute can stay minimal until failover (pilot light).

What’s on the cloud side

The recovery environment and its cloud connection are created in the cloud provider’s console. This page covers how the private replication path and failover are delivered on the Tata Communications side; for the cloud-side connection request and routing, see the relevant per-cloud section.