Salesforce Backup and Restore Essentials Part 2: Restore Strategies and Processes
by Sovan Bin, June 18, 2015
This post was originally posted on Salesforce’s official Technical Library
This article is part 2 of a series written by Sovan Bin from odaseva.com. This series details odaseva.com and Sovan’s experiences and best-practice recommendations for anyone working with backup and restore processes.
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 datacenter 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:
- 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 & 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 & 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 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:
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 odesava.com] we have found that customers use full org copies for scenarios other than DRP, including the release management and merger & 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:
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.
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 & 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.