Restoring Salesforce Data From a Backup if You Can’t Access Your Salesforce Production Org

Recently, Salesforce Ben (Ben McCarthy, founder of the most popular Salesforce blog in the world) and Daivat Dholakia, Senior Product Manager at Spanning, discussed an interesting use case — what it would take to restore Salesforce data into an org even if your Salesforce production org is unavailable.

Here’s an edited transcript of that conversation.

Ben McCarthy: Having a good Salesforce backup available externally from Salesforce sounds like a best practice — wouldn’t every admin want that, in case Salesforce is inaccessible?

Daivat Dholakia: It seems like a best practice, but I hope I’ll persuade you that it’s not really a good answer for admins who need to keep their orgs up and running. Let’s talk about what the real risks are first.

Ben: Fair enough.

Daivat: You know, if you’re making an external backup a key part of your data protection strategy for SaaS applications, you’re preparing for about the same risk as that of a meteor striking your home.

Ben: Oh, really? That’s a big claim – what’s the source for that risk estimate?

Daivat: It’s based on research done by Lloyd’s. From 2009-2015 nearly 65% of cloud outages tracked lasted less than 4 hours; 91% lasted one day or less. Monitoring outages over six years, Lloyd’s data shows only one outage lasting more than 3 days. Therefore, I think we can infer that Salesforce would likely be up and running in much, much less time than it would take to restore your Salesforce org completely from an external backup. Although the risk is >0, based on the odds I don’t think it makes sense to spend time and money preparing for that risk.

Ben: Well, that Lloyd’s data is something I’d not seen before. But let’s say you still want to prepare for that meteor strike — how would an admin go about doing so?

Daivat: Here’s what an admin would need to do if their Production org is unavailable, and they want to restore from an external backup. They’d need to perform the following steps, in the order below, to restore backed up data into a different Salesforce org.

1. Have another production org or Full Copy sandbox available to where you’ll restore your backed up data.

Preparation is key. The org into which you plan to restore data should be clean — pre-existing data and metadata will lead to conflicts (duplicates, overwrites in error), increasing the time it takes to get the data fully restored and ready for use.Budget accordingly. You’ll need to plan to purchase licenses for your additional target production org or additional Full Copy sandbox, and ensure the stakeholder needing to approve the purchase — legal, procurement, finance — are on board. Full Copy sandboxes can cost as much as 40% of a Production org’s cost, so be prepared to provide a solid use case to get the budget needed for a spare Production org or Full copy sandbox in the very rare situation where Salesforce is unavailable for a long period of time.

2. Export metadata locally from your backups, then use Force.com IDE or other third-party tools to restore metadata into the target org.

You’ll need to restore metadata first. Before you can restore any record data, metadata (customizations) needs to be set up in your target org in order to have accurate restores.

Some developer skills may be required. If you’re a Salesforce admin, you’ll need to know how to deploy metadata.

3. Confirm your third party applications are correctly installed and configured in your target org.

You’ll need to replicate your Production Salesforce environment in your target org – including third-party apps. If you use any third-party apps, your records likely have relationships, dependencies, triggers, workflows, that require those apps be correctly installed and configured for an accurate restore.

As needed, plan for services and support for installation into your target org. This may require a new services contract for additional services hours.

4. Turn off all workflows, triggers and validation rules.

Turn them ALL off. Active workflows, triggers and validation rules can cause serious issues when restoring record data,  for example, Lead Assignment rules may assign a Lead that’s already being worked to a queue, as if it’s a new Lead.

5. Begin restoring record data from your backup into the target org.

Depending on the volume of data that you are trying to restore, and the number of API calls you have alloted by Salesforce per day, it could take days or weeks until your team can access the data they need to do their jobs.

If there are errors in the restoration, you will have to figure out which records and dependent records were not restored, troubleshoot and fix the underlying issues, and then retry restoring those records again.

Ben: That seems to be a serious amount of work — and it’s complex enough that it’s not for beginners. Have you ever tried to do what you’ve described? Do you know anyone who has?

Daivat: While I’m not a Salesforce admin or developer, I respect our customers’ expertise, and I got input on these steps from some of our larger customers. Customers who chose Spanning told me the time it would take for a Production org to be up and running from an external backup, in those rare situations when Salesforce is unavailable, could easily be weeks or more. Which means, if you take this approach, you’re really planning for a super-rare edge case — a weeks-long catastrophic failure of a proven, trusted platform. If I can be blunt, that’s a waste of time and resources.

Ben: I think the trick here is for admins and developers to balance risk versus reward. There could be a few organizations for whom reducing risk to almost zero is so important, it’d offset the work needed, though.

Daivat: If an admin is working with IT, their IT teams may have an opinion on this. Most IT teams have to assess what risk is tolerable when planning for business continuity and disaster recovery. As part of that process, they evaluate of the probability of a given risk. So while there may be a few organizations that need to prepare for a highly unlikely risk — a weeks-long period where Salesforce is unavailable — most Salesforce customers don’t need to commit resources for this very rare edge case.

Ben: You make a good point about IT teams being a source of information for Salesforce admins – and admins are increasingly part of IT at their organization, so that should be straightforward. But if after discussion with IT of the costs involved, an external backup is not mandatory…would it hurt for them to adopt a solution that serves up an external backup?

Daivat: You know I’m going to be biased on that question. I think yes, it would hurt — because it gives a false sense of security, and I believe that an in-app solution is a proven better way. Salesforce is reliable, robust, and has consistently high availability, which is part of why the team at Spanning decided to build Spanning Backup for Salesforce in-app.

We also wanted to build a backup-and-restore solution that meets more, and more valuable, use cases – including field level restores by end users on record pages within Salesforce — instead of the statistically rare edge case of Salesforce being down for days or weeks.

By being in-app, Spanning provides even more security — we leverage your org’s profiles, permission sets and security settings (like single sign-on and two-factor authentication) out-of-the-box without any additional configuration. That means there’s no risk of your login credentials being hacked through Spanning, a risk with an external backup vendor.

Ben: I can tell I’m having a discussion with a product manager who loves his product! But you do make a good argument — since the risk of Salesforce being unavailable for many days seems to be statistically a very low probability, most admins could be comfortable adopting an in-app solution.

Daivat: I know they can be comfortable doing so — we have a number of customers with more than 1,000 Salesforce seats who chose us because of the advantages being in-app provides, and of course we have many midsize and smaller customers who chose us for the same reasons — as well as for our ease of use.

Ben: This was quite an interesting discussion — while I haven’t been focused on data and metadata protection for Salesforce, I appreciate your perspective, and that data from Lloyd’s. If your readers would like to learn more about what I do focus on – Salesforce training — they can find us here.

Daivat: Thank you, Ben! At the end of the day, it’s about being prepared for real-world risks. If an admin or developer is serious about protecting mission-critical data and metadata in Salesforce, they should prepare for real needs — such as rapidly recovering from a sync error, or enabling end users to self-recover from fumble-fingered errors.

Watch a Spanning Backup for Salesforce Demo

*** This is a Security Bloggers Network syndicated blog from Spanning authored by Daivat Dholakia. Read the original post at: https://spanning.com/blog/restoring-salesforce-data-from-a-backup-if-you-cant-access-your-salesforce-production-org/