How to Choose a Salesforce Backup Solution: 10 Evaluation Criteria

To choose a Salesforce backup solution, start with restores. Then work through metadata coverage, backup frequency, API use, where the copies sit, retention, restore testing, the audit trail, access and price.

Pick two Salesforce backup solutions for the shortlist and test both in a sandbox. Do it before anyone signs anything.

If you're the Salesforce admin or IT lead running the evaluation, what follows turns a Salesforce backup solutions comparison into 10 questions, a scorecard and a two-week test plan.

(Still deciding whether you need third-party backup tools at all? Read our Salesforce backup solutions overview and the shared responsibility model first.)

Why Salesforce native tools usually don't settle it

The baseline for Salesforce data backup is the Data Export Service. It gives you CSV files once every 7 days at best. Some editions only get it monthly.

Salesforce's own backup guidance calls data integrity and protection a shared responsibility. In other words, Salesforce data protection is partly on you.

Then there's the Salesforce Recycle Bin, which holds records after an accidental deletion for 15 days by default. Salesforce Support can extend that to 30 days.

Useful, but only for deletions. When a bad data load overwrites values, nothing lands in the Recycle Bin, and protecting against that kind of data loss and human error is what a dedicated backup solution is for. Our backup and recovery guide covers the full background.

The 10 criteria at a glance

Take this table of backup evaluation criteria into your vendor calls. Each row has the question to ask and the answer that should worry you.

1. How granular can a restore get?

Make every vendor show you their backup capabilities and recovery options in a live org, because slides don't count. We'd want to see three restores: a single field across lots of records, one deleted record plus its child records, and a whole object put back the way it was at a set time.

The first one is the test that matters most. Picture a simple human error, like a Data Loader job with the wrong column mapping that overwrites the owner on thousands of Accounts.

You need those owner values back without losing everything else your team changed that day. Our post on field-level recovery walks through how that works.

While you're at it, ask whether the tool can compare a backup with the live org and restore only the differences. That keeps valid data where it is.

2. Does it rebuild relationships?

Re-importing CSV files creates new record IDs. Every child record that pointed at the old ID breaks, and someone ends up remapping them by hand.

Ask about automation too. Do Flows, triggers and validation rules fire during a restore, and can you switch them off while it runs?

3. Which metadata does it cover?

Salesforce records alone won't get an org working again. The Salesforce metadata behind them (custom objects, layouts, Flows, Apex, permission sets) is configuration data, and it needs copies as well. Back up metadata along with your data.

Some of it can't be backed up through the API at all. Salesforce keeps a list of unsupported metadata types that the Metadata API can't retrieve or deploy, and changes to those are made by hand in each org.

Get a written metadata backup coverage list from each vendor. Then check it against the features your org actually uses.

4. Backup frequency and your RPO

Your Recovery Point Objective (RPO) is the amount of data loss, measured in time, that you can live with. NIST contingency planning guidance sets it through a business impact analysis, so the owner of each set of business-critical data gets a say.

Look for scheduled, automated backups for each Salesforce object, plus incremental backups. At a minimum that means automated daily backups, and busy objects should be able to run more often than static ones.

A tool that only offers one automated daily backup for every object has already picked your RPO for you.

5. How much API capacity will it use?

Backups that read through the Salesforce Platform APIs draw on the same daily API allocation as every other integration in the org.

The numbers: an Enterprise Edition org gets 100,000 requests a day, plus 1,000 for each full Salesforce license. The total moves with your license count, and an org with 200 full licenses ends up with about 300,000 calls a day for everything.

Ask for an estimate for a full and an incremental backup of your org. Put it next to what your marketing sync and ERP integration already burn through.

6. Where do the backup copies live?

If the backup data lives in the same place as the original, one bad day can take out both. CISA backup guidance has a handy rule of thumb here, the 3-2-1 rule: keep three copies, use two kinds of media, and put one somewhere off-site.

Raise these data protection questions early:

• Location: which region are the copies in, and do you get a say?
• Encryption: is the data encrypted in transit and at rest? And whose keys are they, yours or the vendor's? Our post on backup encryption covers what to check.
• Immutability: could a compromised admin account delete or change the backups? Our post on immutable backups covers ransomware and other cyber threats.
• Deployment: can backups sit in the vendor's cloud, or in infrastructure you control?

7. Can retention follow your compliance rules?

SEC Rule 2-06 has audit firms keep audit and review records for 7 years. On the healthcare side, the HHS audit protocol puts HIPAA documentation at six years.

GDPR runs the opposite direction: under the right to erasure, personal data has to go without undue delay. If you're covered by GDPR or HIPAA, your backup tool has to play by those rules too. Ask the awkward question out loud, then: an erasure request lands, so what happens to the copies already sitting in backup?

You want retention you can set object by object, plus a legal hold that freezes records while litigation is open. Moving old records out of the org altogether is a different job, and it's the point where data archiving and backup start to overlap. Write down what you decide in your retention policy.

8. Can you test restores safely?

A backup you've never restored from is a hope, not a plan. The tool needs to let you restore into a sandbox, then hold the result up against production data field by field.

Put a stopwatch on it and compare against your Recovery Time Objective (RTO), largest object first. Whatever you find out belongs in your disaster recovery plan.

One more: can it apply data masking to sensitive fields on the way in? You'll want that for sandbox seeding as well.

9. Audit trail and restore permissions

Salesforce's Setup Audit Trail only reaches back over the past 180 days, which isn't much help a year later. So the backup tool has to keep its own trail: who ran each restore, what it touched, who signed off.

And lock the tool down with role-based permissions and multi-factor authentication. A junior admin shouldn't be able to roll back production alone, and large restores should need a second person to approve them.

10. What it costs as you grow

Find out what the bill is tied to. It could be Salesforce users, orgs, storage volume or some mix of the three.

Model it three years out. Include data growth, any new Salesforce environments and acquisitions that are already on the roadmap.

Then check what the base price covers, such as archiving, sandbox seeding and extra storage. Our post on backup pricing walks through the usual models.

Do you need backup and archiving in one tool?

Not really the same job. Backup is a copy you can restore from, whereas data archiving takes old records out of the live org altogether, and Salesforce says that can shrink your storage footprint.

Score archiving under criterion 7 so it doesn't get lost. Whichever way you go, run both from one data management plan, so backup and archive never disagree about what's kept or for how long.

Who should be part of a Salesforce backup evaluation?

Bring in more people than the Salesforce admin, and bring them in early. Admins should drive the proof of concept, and they should have their hands on the keyboard for the restore workflows, because watching a vendor click through tells you very little.

Security gets the shortlist the day it exists, along with your data security questions (encryption, who owns the keys, access controls, where backup data physically lives). Compliance and legal should confirm each tool meets your compliance requirements, retention periods and legal hold included.

Then there are the business owners. How much data loss can sales live with, and what about finance? Their answers set the RPO and RTO for the critical data in each area, while IT checks the tool fits your wider disaster recovery plan and finance gets a three-year cost model well before anything is signed.

Common mistakes in a Salesforce backup comparison

Five to avoid:

• Judging tools on backup speed. A fast backup process is half the test at best; the other half is whether you can restore data quickly and cleanly after real Salesforce data loss.
• Testing in a Developer sandbox. It copies your metadata but no production data, so run restore tests in Salesforce environments closer to production, like a Partial Copy or Full sandbox (our guide to sandbox types compares them).
• Forgetting metadata. Skip metadata protection and a bad release that deletes a field leaves your restored data with nowhere to go.
• Ignoring the API budget. The backup shares the org's daily API allocation with every integration, so check API use after the first run and again a few weeks later.
• Leaving security until the end. Data protection reviews belong at the shortlist stage, which is when security and compliance should get the questions from criterion 6.

How do you score your shortlist?

A weighted scorecard stops whoever liked the last demo best from deciding for everyone. Each criterion gets a weight (all of them together add up to 100), each backup solution gets a 1 to 5 on every criterion, and then you multiply, add and compare the totals.

The suggested priorities below assume a regulated org. Move them around to fit your own risks.

What should a Salesforce backup proof of concept include?

Two weeks, a full sandbox, your own Salesforce data and your top two tools.

Week 1: back it up, then break it

Kick off one full backup and one incremental, and write down the API calls each one burned. Then do some damage. Simulate an accidental deletion of a parent record with children, overwrite one field on a few thousand records and edit a Flow.

Week 2: restore and review

Now recover data for each change you made, timing the recovery process as you go. Check that relationships, field values and automation all came back right. Finish by exporting the audit log and trying a restore as a non-admin user, which shows whether the permissions actually hold, then hand the lot to security.

Score both tools on the same day with the same people in the room. Whatever RPO and RTO you actually hit go straight into your Salesforce backup policy.

Where does Flosum Backup & Archive fit?

Flosum Backup & Archive is our own tool, so put it through the same tests as everything else. It runs automated backups of your Salesforce data and metadata, picking up files and attachments as well, and jobs can run on a schedule, incrementally or at high frequency depending on the RPO you've set.

Restores can target a point in time at field, record or full-org level, and object relationships come back intact. So if one field goes bad, that field (or the handful of records it hit) is all you put back, and the rest of the org stays exactly as it is. Older records can move into lower-cost archive storage that you control.

Backups can be hosted by Flosum or in your own cloud, with encryption keys you hold. If you're switching tools, our Flosum vs Own comparison lays out the main differences.

FAQs

Ready to put a backup tool through these tests? Book a personalized demo to see how Flosum restores Salesforce data and metadata on your own org.