Loading

B2C Commerce Disaster Recovery (DR) Infrastructure, RTO/RPO, and Customer Responsibilities FAQ

Publiseringsdato: Aug 13, 2026
Beskrivelse

Key Facts

  • RPO: Production realm data replicates to the secondary DR POD every 30 minutes — up to 30 minutes of data may be lost in a DR event.
  • RTO: Recovery period target is 8 hours; most recoveries complete within 24 hours.
  • DNS: If your storefront uses the eCDN CNAME, no DNS changes are needed during failover.
  • Customer action required: The DR POD's outbound IP must be allowlisted at all third-party integrations before a DR event — the most common cause of extended recovery time.

 

Real-World Example

A B2C Commerce merchant's primary POD experiences a data center power failure at 3 AM. Their storefront goes down completely. Here is what happens:

  • T+0: Platform Operations detects the outage. Because the failure is physical, the DR decision is made within 1 hour.
  • T+1hr: Salesforce begins failing over all realms on the affected POD to secondary DR PODs in a geographically separate data center. The storefront remains down during failover.
  • T+9hr (target): Failover completes. Salesforce confirms Production and Business Manager are accessible on the DR POD.
  • Customer verification: The merchant tests the storefront, places a test order, and verifies integrations — payment processor, fulfilment, fraud tool.

If the merchant had not allowlisted the DR POD IP: The payment processor rejects connections from the new outbound IP. Checkout fails for all customers, adding 2–4 hours of downtime.
Data impact: Orders or data changes in the 30 minutes before the outage may not be present on the DR POD. The merchant reconciles these manually afterward.

Løsning

DR Infrastructure and Secondary POD

B2C Commerce maintains a secondary DR POD for every primary Production POD. Key facts about the DR infrastructure:

  • The secondary DR POD is located in a geographically separate data center from the primary POD, but within the same geographical region (for example, both in the US East region but in different data centers)
  • The secondary POD is a mirror of the primary POD — it runs the same B2C Commerce platform version and configuration
  • Salesforce tests the availability of the B2C Commerce service to the Production instance on the DR POD for all customers and works with customers to resolve latent networking connectivity issues specific to their DR POD

Your DR POD's outbound IP address must be allowlisted at all third-party integrations before a DR event occurs. To find your DR POD number and outbound IP address, refer to:

 

Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

Recovery Point Objective (RPO) — how much data can be lost: B2C Commerce replicates customer production realm data (database and file system, including storefront data such as catalogs) to the secondary DR POD every 30 minutes. In a DR event, up to 30 minutes of data changes may not be present on the DR POD after failover. How long recovery takes:

  • Recovery period target: 8 hours
  • Expected recovery timeframe: within 24 hours in most cases
  • B2C Commerce makes no representation that recovery is possible in a set period of time — recovery duration is difficult to predict and depends on the nature and scope of the outage.

These targets apply to the B2C Commerce platform infrastructure. Recovery of externally integrated services (DNS for non-eCDN customers, fulfilment systems, payment processors) is not included in the B2C Commerce DR plan and is the customer's responsibility.

 

DR Event Definition and Decision Timeline

A DR event is defined as platform downtime without any known and reasonable recovery time. Salesforce Platform Operations decides whether to commence DR procedures based on the expected recovery time of the primary POD.

ScenarioDR Decision Timeline
POD unrecoverable for a very long time (e.g., physical power/network failure at data center)DR procedures may commence within 1 hour
Known recovery time exists and is shorter than the time required to move all realms to DR locationsSalesforce may wait several hours for the primary POD to recover rather than initiating DR

Salesforce reserves the right to modify DR plans as necessary to meet evolving business and customer needs. 

 

Customer Responsibilities During a DR Event

The B2C Commerce DR plan covers the platform infrastructure. The following are customer responsibilities during and after a DR event: 

ResponsibilityDetails
DR POD IP allowlistingAllowlist the secondary DR POD's outbound IP at all third-party integrations before a DR event. If not done in advance, integration connections will fail upon failover.
Data backupCustomers are fully responsible for backing up their own data. Follow Scheduling Instance Backups procedures.
Integration notificationsNotify external integrations (payment processors, OMS, fulfilment systems) about the move to the secondary POD.
Integration recoveryDetermine and execute the recovery method for each integration point. B2C Commerce DR does not cover external integrations.
Custom solution testingTest custom storefront functionality and all unique external integrations after DR failover completes.
DNS (non-eCDN customers)If your storefront does NOT use the eCDN CNAME, DNS changes may be required to point to the DR POD. DNS recovery is not included in B2C Commerce DR plans.


Flere ressurser
Knowledge-artikkelnummer

000391449

 
Laster
Salesforce Help | Article