top of page
Sesame Software

Salesforce Backup and Recovery Checklist: 5 Things to Evaluate

  • Aug 4
  • 7 min read

Most Salesforce backup and recovery vendors say the same three things: automated backups, easy restores, enterprise-ready. None of that tells you anything you can actually act on. Every vendor in this space uses nearly identical language on their homepage, and that language is designed to sound reassuring rather than to give you something you can test.

A homepage feature list won't tell you what you need to know if you're evaluating a Salesforce backup and recovery platform for a large, high-volume org. You need a checklist that reflects where these tools actually break down at scale, not a list of features that sound good in a sales deck. The gap between what a vendor claims and what a platform can actually deliver under enterprise conditions is usually invisible until you're already relying on the tool during an incident, and by then it's too late to ask the right questions.

Below are the five things to evaluate. We've ordered them by how often they cause problems, so you know exactly what to ask on your next vendor demo. Each one maps to a specific failure mode we see repeatedly in enterprise Salesforce environments, and each one has a concrete question you can ask a vendor to get a real answer instead of a marketing response.

1. Restore Speed (Not Just Backup Frequency)

Restore speed is the single most common point of failure at enterprise scale. Plenty of backup tools look fast in a demo. But a demo usually runs against a few thousand records. Enterprise Salesforce orgs hold millions of records across dozens of custom objects. That's when restore performance really counts, and it's exactly the scenario most vendor demos are designed to avoid showing you.


What to ask a vendor:

  • How long does it take to restore 1 million+ records?

  • Do restores run in the background, or does the process lock the org?

  • What happens to user access and automation while a large restore is running?


Backup frequency is marketing. Restore time determines your actual recovery time objective (RTO) when something goes wrong. If a vendor can't give you a concrete number for a large-scale restore, flag that gap before you sign anything. Ask for a reference customer running a comparable data volume, and ask that customer directly about their actual restore times during a real incident, not a controlled test environment.


It's also worth asking whether restore speed degrades as your org grows. A platform that restores quickly today at 2 million records might behave very differently at 10 million. Vendors rarely volunteer this information unless you ask directly, so push for benchmarks at your current volume and at a projected volume three to five years out.


2. Relational Integrity

In Salesforce, almost nothing exists in isolation. Opportunities link to accounts. Accounts link to contacts. Custom objects often connect to several other objects at once, sometimes across multiple layers of parent-child relationships that mirror your actual business processes.


A backup tool that restores a record without restoring its relationships leaves you with orphaned records. These are records that technically exist but aren't linked to anything. Orphaned records break reports, automation, and any downstream process that depends on that relationship. A restored opportunity that's no longer linked to its account isn't really restored. It's a data integrity problem wearing the appearance of a successful recovery.


Test this before you buy. Ask the vendor to walk you through a parent-child restore scenario, not just a single-record restore. A vendor that can't answer this clearly hasn't handled relational integrity at scale. Push further: ask what happens when a restore touches a custom object with five or six layers of relationships. Ask whether the platform validates relationships after a restore completes, or whether it simply assumes success once the records are written back.


This matters more the longer your org has been customized. A five-year-old enterprise Salesforce instance with dozens of custom objects and validation rules is a much harder relational integrity problem than a clean, out-of-the-box org, and vendors that only test against simple data models often struggle here.


3. Data Control (Where Does Your Backup Actually Live?)

This surprises enterprise buyers later, usually during a security review. Ask directly: where does our backed-up data physically live?


Some vendors copy your Salesforce data onto their own servers. That means your data now exists in two places: your Salesforce org and their infrastructure. You have to secure, audit, and account for both. For regulated industries, that expands your compliance scope significantly, since your security team now needs visibility into a third party's infrastructure, not just your own environment.


Customer-controlled storage avoids this problem. That includes on-prem storage, your own cloud account, or a hybrid setup where you control the destination. If data residency, GDPR, HIPAA, SOX, or CCPA compliance matters to your organization, don't assume. Ask the vendor to confirm exactly where they store your data and who can access it, and get that answer in writing as part of your contract, not just as a verbal assurance during a sales call.


Ask, too, what happens to your data if you terminate the contract. Some vendors retain a copy of your data even after you've moved to a different platform, which creates a long tail of compliance exposure most buyers don't think to ask about until it's already a problem.


4. Deployment Model

Can the platform run on-premise, in the cloud, or both at once? Most enterprise IT teams are mid-migration. Some systems run on-prem, others already run in the cloud, and the transition between the two often takes years rather than months. A backup tool that only supports one deployment model forces a workaround, or adds a second tool to your stack just to cover the gap.


What to ask:

  • Is hybrid deployment supported natively, or is it a workaround?

  • What changes operationally if you migrate from one model to the other later?

  • Does switching deployment models require a new contract, a data migration, or a re-implementation?


A platform that only works in one deployment model today can become a liability in eighteen months when your infrastructure strategy shifts. Ask the vendor to describe, specifically, what a customer's migration from on-prem to cloud (or the reverse) actually looks like in practice, including downtime, data movement, and any features that behave differently across deployment models.


5. Pricing Structure

Easy to overlook, expensive to ignore. Some backup platforms price based on data volume. That means your bill grows every year as your Salesforce org grows, often without warning, and often faster than your budget cycle accounts for.


What to ask: is pricing fixed annual, or does it scale with storage or record count? If it scales, get actual numbers at 2x and 5x your current data volume. Don't settle for today's quote. Ask the vendor to model out a five-year cost projection based on your org's historical data growth rate, not a flat estimate based on current volume.


It's also worth asking what counts toward the pricing calculation. Some vendors count every field, every attachment, and every historical snapshot toward your total volume, which can make a seemingly reasonable per-record price balloon quickly once retention periods and metadata are factored in.



The 5-Point Checklist, Recap

#

Evaluate

Ask the Vendor

1

Restore speed

How long to restore 1M+ records? Does it lock the org?

2

Relational integrity

Walk me through a parent-child restore.

3

Data control

Where does backup data physically live?

4

Deployment model

Native hybrid, or a workaround?

5

Pricing structure

Fixed annual, or scales with volume? Ask for 2x and 5x.

Score any Salesforce backup vendor against these five criteria. You'll quickly know whether it's built for enterprise scale, or just looks that way in a demo. None of these five questions require a vendor to reveal proprietary technology or trade secrets. They simply require the vendor to be specific about how their platform behaves under real enterprise conditions, which is exactly the information a homepage or a sales deck won't give you.

If a vendor hesitates on any of these five questions, or answers in general terms rather than specifics, treat that as useful information in itself. The vendors who are confident in their architecture tend to answer these questions directly, with real numbers and real customer examples, because they've already solved these problems at scale.

Salesforce Backup and Recovery FAQs


Does Salesforce back up my data automatically?

No. Salesforce handles the availability of its infrastructure. Backup and recovery is your responsibility. That means protecting against accidental deletion, bad automation, or a bad data load. Native tools and third-party platforms exist specifically to close this gap, and relying solely on Salesforce's infrastructure guarantees leaves this responsibility unaddressed.

Backup frequency is how often the tool takes a snapshot. Restore speed is how long it takes to bring data back after something goes wrong. For enterprise orgs with millions of records, restore speed determines actual downtime during an incident. Backup frequency doesn't. A vendor that backs up your data every five minutes but takes twelve hours to restore a million records hasn't solved your actual risk.

It's how a restore preserves parent-child relationships, like correctly linking an opportunity back to its account. Losing relational integrity creates orphaned records that break reports and automation, even though the tool technically "restored" the data. This is one of the most common gaps buyers miss during evaluation, since a restore can look successful in a summary report while leaving relationships broken underneath.

Some can, some can't. Confirm whether the vendor natively supports hybrid deployment before you choose a platform. Don't wait to discover a limitation after implementation, when switching platforms means re-doing a project you thought was already finished.

This depends on your organization's tolerance for data loss, often described as a recovery point objective (RPO). Organizations with high transaction volumes or frequent automation changes typically need backups running multiple times per day, or near-continuous backup, to keep their RPO within an acceptable range. Ask any vendor you're evaluating how their backup frequency options map to your specific RPO requirements, rather than accepting a generic daily backup as sufficient by default.


Found this post helpful? Share it with your network using the links below.



bottom of page