Salesforce supports backup and restoration in case something happens to the production servers/instance(say disaster). We do not how long this will last/ how long it takes to get the system perfectly up again.

How do we provide an alternative to the client in case the production org goes down for some reason? Yes we would need to regularly backup and store data. But how exactly can we ensure that the client business still runs even though production org is down? Can we build another org which is same as production and can be used when something makes the production org as unfunctionable? Does it make sense to create a production like org for disaster recovery?

What would be the ideal way to manage disaster recovery in Salesforce from development end?

2 Answers 2


I'm going to assume you're referring to this feature of Salesforce:

Sync to a Secondary Salesforce Organization

With Organization Sync, you can set up a secondary, synced Salesforce organization which users can access whenever your primary organization is experiencing downtime or maintenance.

Ultimately, it comes down to making a business decision on whether you're getting an adequate return on your investment to justify the added expense and overhead to support maintaining a 2nd org in order to have the convenience of being able to switch over to a 2nd org during Salesforce downtime or outages. Clearly, there's a lot of additional admin and developer support required to maintain a second org. You need to be willing to test and maintain it to assure you can use it when needed.

Sync to a Secondary Organization has a number of limitations. These limitations need to be taken into consideration before deciding whether this a option you to seriously consider. Some of those limitations are things like the following:

Organizational Limitations

  • To use Organization Sync, you must purchase a secondary Salesforce org and its accompanying user licenses.
  • The primary and secondary orgs must be the same organization type (for example, production or sandbox) and edition.
  • To avoid inconsistent behavior, both orgs must have the same limits and settings. If the limits of the primary org have been adjusted, contact Salesforce to have the same changes made in the secondary org.
  • To avoid Duplicates Detected errors, Salesforce recommends turning off duplicate management in secondary orgs.

Note: Organization Sync is designed to support a two-org setup but can be configured to work for more than two orgs.

Unsupported Objects and Features

  • Auto-numbered fields aren’t synced, but you can implement a workaround.
  • If you’ve enabled the option to sync feeds and audit fields, audit fields don’t appear in the list of publishable fields because they’re automatically synced. Audit fields are only synced when a record is copied from one org to another (for example, during a bulk sync). If an audit field on a synced record is updated, that update is not reflected in the linked org.
  • Rich text area (RTA) fields aren’t synced.
  • Formula fields and roll-up summary fields can’t be published because their values are determined by other fields’ values (There's a workaround that needs to be implemented in the secondary organization).
  • Lookup fields to unpublished objects aren’t automatically published because publishing such fields can cause syncing errors.
  • Callout fields such as geolocation fields aren’t synced.
  • Only certain objects can be published in Organization Sync. For a list, see Which Objects Can Be Published?.
  • Certain types of metadata aren’t supported. For a list, see Which Types of Metadata Are Synced?.
  • Supported metadata is only synced in one direction, from the primary to the secondary org.
  • LiveAgent, Salesforce Knowledge, Portals, and Communities aren’t supported.
  • Managed packages aren’t synced. If you wish, you can install a package on both organizations to keep the user experience consistent.
  • Chatter file posts larger than 2 GB aren’t synced.
  • Chatter topics, groups, and likes aren’t synced.
  • In synced Chatter posts, user mentions aren’t clickable.
  • Chatter file versions aren’t supported.

Automation and Data Structure

  • Multi-level lookups with more than one level are only synced during bulk syncs.
  • Apex triggers, processes, and workflows aren’t duplicated from one org to the other because duplicate automation can lead to looping updates or errors. You'll need to adapt your existing triggers, processes, and workflows for the secondary org.

Syncing Limitations

  • Users are only synced in one direction, from the primary to the secondary org.
  • A bulk sync can only copy records that were last created or modified no more than one year before the bulk sync date.
  • If the secondary org contained records before you established a connection between the two orgs, those pre-existing records in the secondary org aren’t auto-connected to matching records in the primary org.
  • Salesforce does not recommend using a two-way sync for some objects and fields and a one-way sync for others.

Thanks to Mirrorforce, salesforce has three data centers in North America for disaster recovery and backup purposes. Normally, we use the servers in California, but if a major disaster occurred that prevented normal operation of the data center for a significant period of time, Salesforce can redirect traffic to one of the other centers. They are mirrored in real time, so no more than a few seconds worth of data would be lost. The DNS cutover would take approximately four hours, about the time of a normal maintenance window.

Of course, this only protects the service itself. If you were to accidentally deploy something that wiped out all of your custom fields or something, you could lose a significant amount of data. For that purpose, it's recommended that you perform weekly backups of your data (Setup > Data Management > Data Export), as well as backing up your Salesforce configuration. You can do this with a Sandbox that you refresh periodically for your metadata, or you can use a third-party service like GearSet or GitHub to periodically back up your important configuration and code.

  • 2
    "We" use servers in California? Do you work for Salesforce now?
    – Adrian Larson
    Jul 29, 2017 at 14:30
  • 5
    @AdrianLarson lol, "we" the clients. Although salesforce.com does want me as a bit more than an MVP.
    – sfdcfox
    Jul 29, 2017 at 14:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .