This series is a Merit winner of the Society for Technical Communication’s Touchstone Award.

This article is part 2 of a series written by Sovan Bin from Odaseva. This series details Odaseva and Sovan’s experiences and best-practice recommendations for anyone working with enterprise backup and restore processes. For more information about backup and recovery see part 1, part 3, and part 4 of this series.

Why would you recover Salesforce data (including metadata)?

Outside studies have found that data center failures (power outages, on-site disasters, hardware errors, etc) are one of the most common causes of data loss among data-driven applications. Fortunately, if you’re using Salesforce, we at odaseva.com have found that Salesforce will handle these types of failures appropriately, meaning you don’t have to worry about restoring the full database if there’s a data center failure.

Historically, Salesforce has had an excellent record of very high uptime. To achieve this they have configured all networking components, SSL accelerators, load balancers, Web servers and application servers in a redundant configuration. Thanks to this, Salesforce services’ disaster recovery plans are very efficient in terms of RTO (Recovery Time Objective) and RPO (Recovery Point Objective) times.

The following picture represents how Salesforce compares to traditional database technologies when dealing with different kinds of data loss.

The rest of the causes behind data loss are related to human process-driven factors (unintended user error, malicious activity, etc), which is why Salesforce recommends customers manage their own backup and restore system. In Part 1 of this series, we talked about the reasons why you would want to organize your own backup information. In this article we’ll talk about the challenges of restoring your backup information.

If you’re managing your own backup and recovery system, you’re committing time and resources to this process, and you’ll want to maximize your ROI (Return on Investment). To maximize your ROI, you want to ensure your restore process is as complete and efficient as possible. This requires addressing many challenges in the restore process, which you need to manage carefully.

Additionally, you may be able to benefit by integrating a well-planned, well-implemented restore process into other projects in your business, thereby increasing your ROI further. Consider the following uses for a restore plan that go beyond just covering your security and disaster recovery plan (DRP) needs:

• Security
  • Recover a subset of data that has been corrupted or deleted in production
• Release Management
  • Initialize a training environment with a specific set of data (business unit specific, country specific, other)
  • Automate transport of data/metadata across Salesforce environments
  • Initialize a sandbox with a set of master/technical data after refresh
  • Prepare or verify a training environment for a go live rollback strategy (data and metadata)
• Merger and Acquisition
  • Copy an org or split an org, often needed as part of a merger and acquisition process

What are the key areas a recovery solution should cover?

Once you understand the benefits of having a good recovery process, here are the things that you should take into consideration when developing your recovery strategy:

• Scope of restore is aligned with your DRP
• Recover a specific version of the data/metadata/document
• Minimize and plan for business impact of restore process
• Minimize data transformation during restore process
• Handle different types of restore processes
• Performance and time to restore
• Minimize the number of manual tasks
• Minimize the impact on current and future Salesforce application design
• Automatically solve common restore roadblocks
• Provide error logs for manual intervention

We will go into detail on each of these in follow-up articles. For now we’ll look at the steps needed for a restore process.

Single and partial restore

Depending on your restore use case, you’ll use one of the following types of restore processes:

• Single restore
• Logical partial restore

You may also be dealing with restoring from an org copy (we’ll detail the restore steps for this later in this article), which shares some common steps with the other restore processes, but isn’t used for DRP.

The general areas you will be restoring can be represented in the following picture:

Restore a single record

Use case: Recover a record (example: an event) that has been deleted or corrupted
Pros and cons: Simple and best RTO but might lose data
Duration from incident detection to incident closure: a few minutes

Here are the restore process steps needed for restoring a single record:

Restore a logical set of records

Use case: Recover a record (example: an Account) that has been deleted alongside its child records (Contacts, Opportunities, etc)
Pros and cons: Does not lose data that was created post backup. Best RPO but requires preparation and the right tools.
Duration from incident detection to incident closure: a few hours

Here are the restore process steps needed for restoring a logical set of records:

Org copy

Another process that shares common restore steps with DRP types of restore is a full Salesforce Environment organization copy. This can involve doing restore steps from a snapshot full org copy, made earlier to a sandbox. Copying an org to another production org requires a project with appropriate resources and tools.

At odesava.com, we have found that customers use full org copies for scenarios other than DRP, including the release management and merger and acquisition use cases mentioned earlier. A full sandbox copies the production org but using it as a DRP is not recommended, neither as an alternative production environment (because the related infrastructure is not meant for production usage) nor as a backup (because there’s no guarantee of data integrity of the copy, and copy is not point-in-time).

Full org copy should also not be used as a substitute to Salesforce Org Sync. Salesforce Org Sync is used for high availability scenarios and not for snapshot or backup purposes, since it will replicate erroneous data updates or data deletions in real time.

The duration from incident detection to incident closure for a full org copy can be a few days to a few weeks depending on the complexity of the org.

Here are the restore process steps needed for restoring a full org copy:

Conclusions

This article highlighted the importance of implementing a restore strategy to mitigate the risk of a partial data loss and ensure business continuity on Salesforce. The process and the tools will differ depending on whether you are aiming for a single record recovery, partial recovery, or an org copy.

The different technical challenges mentioned in the article that you might encounter during a restore process will be addressed in the rest of the series. For example, we noted that data recovery with Salesforce will more or less transform data during the process (i.e. record ID or audit fields like CreatedDate can change when restoring records). Look for the next part of this series soon and learn more about how to minimize data transformation when recovering data on Salesforce.

Related resources

Salesforce Backup and Restore Essentials Part 1: Backup Overview, API Options and Performance
Salesforce Backup and Restore Essentials Part 3: Learn from a Customer’s Experience
Salesforce Backup and Restore Essentials Part 4: Minimize Transformation when Restoring Data

About the author and CCE Technical Enablement

Sovan Bin is a Salesforce Certified Technical Architect and the CEO and Founder of odaseva.com, an AppExchange enterprise software provider based in both San Francisco and Paris, addressing the challenges of Salesforce data recovery (backup and restore) and release management (metadata comparison, sandbox initialization & data quality). He has been providing innovative solutions regarding Salesforce platform governance, security and performance since 2006.

This post was published in conjunction with the Technical Enablement team of the Salesforce Customer-Centric Engineering group. The team’s mission is to help customers understand how to implement technically sound Salesforce solutions. Check out all of the resources that this team maintains on the Architect Core Resources page of Salesforce Developers.