10 Facts About Salesforce Backup and Recovery Software

Quick Answer

Most enterprise IT teams evaluate Salesforce backup and recovery software with incomplete information — about what native Salesforce tools actually do, what compliance frameworks actually require, and what "granular restore" actually means in practice. These ten facts close the most consequential knowledge gaps before evaluation begins — so that platform selection produces a backup architecture that holds up under regulatory scrutiny, not one that looks compliant on a vendor slide and fails during an audit.

Fact 1: Salesforce does not automatically back up your data

This is the fact that most enterprise IT teams discover at the worst possible moment — during a data loss incident or a compliance audit that asks for historical data that no longer exists.

Salesforce protects its own platform infrastructure against hardware failures, data center outages, and system-level disasters. It does not automatically back up your organization's data against the incidents that actually affect enterprise Salesforce orgs — accidental deletions, bulk import errors, integration failures that write incorrect data, and automation misconfigurations that corrupt records across entire objects.

This is not a gap or an oversight. It is documented in Salesforce's own shared responsibility model. The platform is Salesforce's responsibility. The data is yours.

The native tools Salesforce provides — Data Export Service, Field History Tracking, and the recycle bin — offer partial coverage with retention limits that do not satisfy enterprise data protection or compliance requirements. They are operational convenience tools, not enterprise backup infrastructure.

What this means for evaluation: Every Salesforce backup and recovery software evaluation should start from the baseline that native Salesforce tools are not sufficient and that a purpose-built backup platform is required. The evaluation question is which platform — not whether a platform.

Fact 2: The recycle bin is not a backup strategy

Salesforce's recycle bin retains deleted records for 15 days before permanent removal. For records deleted accidentally and noticed immediately, it provides a functional recovery path. For every other deletion scenario — records deleted weeks ago by a departing employee, records removed by a bulk operation that nobody noticed, records purged by an integration during a failed sync — the recycle bin offers nothing after the 15-day window closes.

Enterprise data loss incidents do not typically surface within 15 days. The Enterprise Strategy Group found that 73% of Salesforce data loss stems from internal incidents. Most of these incidents are not noticed immediately — they surface during quarterly reviews, during compliance audits, during customer escalations, or during handovers when someone looks for a record that should exist and discovers it does not.

Salesforce's paid Data Recovery Service is available as a last resort for permanently deleted records. It is expensive, takes six to eight weeks to execute, returns data as CSV files without relationship mapping, and does not guarantee full recovery. It is an emergency service — not a recovery strategy.

What this means for evaluation: Evaluate backup platforms on deleted record retention periods, not just backup frequency. A platform that backs up every five minutes but retains deleted records for only 30 days creates the same gap for long-delayed discovery scenarios as a platform that backs up daily.

Fact 3: Field History Tracking covers 18 months and 20 fields — not six years and all fields

Field History Tracking is the native Salesforce mechanism that compliance teams most commonly rely on for audit evidence. It logs changes to specific fields — the previous value, the new value, the responsible user, and the timestamp — and makes this history visible on individual records.

The two limits that regulated enterprises discover too late are the field count cap — 20 tracked fields per object — and the retention window — 18 months. For complex Health Cloud implementations where ePHI spans more than 20 fields on a Salesforce object, the field count cap creates audit gaps that cannot be resolved through configuration. For HIPAA's six-year retention requirement and SOX's seven-year requirement, 18 months covers less than a quarter of the required period.

These are architectural limits of the Salesforce platform — not configuration choices. No Salesforce administrator can extend Field History Tracking retention beyond 18 months or increase the field count limit beyond 20 through org settings.

What this means for evaluation: Evaluate backup platforms specifically on field-level audit history capability — whether they capture history for all fields without a count limit, and whether they retain that history for the customer-defined period without a platform-imposed ceiling. Any platform that relies on native Field History Tracking for compliance audit evidence has the same architectural limitations as no backup at all for this specific requirement.

Fact 4: Data backup and metadata backup are different — and both are required

Most Salesforce backup conversations focus on data records — Accounts, Contacts, Opportunities, Cases, custom objects. Metadata rarely comes up until a configuration incident reveals the gap.

Salesforce metadata — object definitions, field configurations, permission sets, profiles, workflow rules, validation rules, flows, and page layouts — governs how the org operates. A configuration incident that deletes a custom object, overwrites a workflow rule with a flawed deployment, or modifies a permission set incorrectly can break Salesforce functionality entirely without affecting a single data record. Recovery from that incident requires metadata backup — data backup alone is structurally insufficient.

Configuration incidents are more common than most organizations track because the consequences are not always immediately visible as data loss. A permission set change that removes access for a user group surfaces as user complaints, not as a data incident. A validation rule deployed incorrectly surfaces as users unable to save records. A flow modification that triggers incorrectly surfaces as records modified unexpectedly. All of these require metadata restore capability.

Salesforce's Setup Audit Trail captures configuration changes for 180 days but provides no restore capability. There is no native mechanism to compare the org configuration at two points in time or to restore a previous configuration state.

What this means for evaluation: Ask every backup platform vendor directly whether metadata backup runs on every backup cycle alongside data backup, and whether the platform supports visual metadata comparison between any two points in the backup history. Platforms that backup data records but not metadata leave half the org unprotected.

Fact 5: Granular restore means field-level precision — not just record-level recovery

"Granular restore" appears in virtually every Salesforce backup and recovery software vendor's marketing materials. The term covers a wide range of actual capability — from basic record-level restore all the way to field-level, value-level restore precision — and the difference matters significantly for the incidents that enterprise recovery teams actually face.

The incident that most clearly reveals the granularity gap is the bulk import error. A data loader operation maps fields incorrectly and overwrites close dates, amounts, and stage values across 10,000 Opportunity records before the error is noticed. The recovery requirement is to restore those specific field values to their pre-import state without touching any other data that changed legitimately after the import ran.

Record-level restore recovers entire records to their state at a point in time — but also overwrites any legitimate changes made to other fields on those records after the import. Object-level restore recovers all records in an object — overwriting every change made to the entire object after the restore point. Neither option produces the targeted recovery that the incident requires.

Field-level restore returns specific field values on specific records to their historical state without touching any other field or record. This is the only recovery pattern that addresses the bulk import error scenario without collateral data loss.

What this means for evaluation: Test field-level restore against your actual Salesforce org — not a demo environment — before selecting a platform. Create a test scenario where specific fields are modified across a subset of records, then execute a field-level restore targeting only those fields. Confirm that the restore returns those specific fields to their historical values without affecting other fields or records.

Fact 6: HIPAA requires six-year retention — not just backup

HIPAA's Security Rule establishes technical safeguard requirements for electronic protected health information. The Contingency Plan standard requires covered entities to create and maintain retrievable exact copies of ePHI. The Audit Controls standard requires mechanisms to record and examine activity in systems containing or using ePHI.

Both standards apply retention requirements that most Salesforce backup platforms do not satisfy by default. HIPAA requires six years of retention for documentation related to ePHI. SOX requires seven years for financial records. Most backup platforms impose their own retention limits — often much shorter — or charge premium pricing tiers to unlock longer retention.

For healthcare organizations running Salesforce Health Cloud, CRM at payers and providers, or life sciences CRM, the six-year retention requirement is not negotiable. A backup platform that retains data for 90 days, one year, or even two years leaves a compliance gap that HIPAA auditors will find.

What this means for evaluation: Ask every vendor explicitly: what is the maximum retention period your platform supports, and is there an additional cost for six-year or seven-year retention? Eliminate any platform that cannot support customer-defined retention periods matching your most stringent regulatory requirement.

Fact 7: Storage location is a compliance decision — not a technical preference

Where backup data is stored determines which jurisdiction's laws govern it, who has legal authority over it, and what happens when a government agency requests access to it.

Cloud-hosted backup platforms store your Salesforce data on vendor-managed infrastructure. GDPR data residency requirements specify that personal data of EU residents must be processed and stored within required geographic boundaries — a vendor's EU regional data center satisfies the geographic location requirement but does not answer the jurisdiction question. Under the CLOUD Act, US government agencies can compel US companies to produce data stored in foreign data centers. A cloud-hosted vendor incorporated in the US processing your EU customer data may be subject to US government access regardless of the server's physical location in the EU.

Customer-controlled storage — backup data in infrastructure the organization owns and manages, in the jurisdiction the organization's legal team has assessed — produces the clearest answer to the data sovereignty question. The organization controls the storage location, the access controls, the retention period, and the encryption keys.

What this means for evaluation: Ask every backup vendor: at any point during backup or restore operations, does your infrastructure have access to our data? Cloud-hosted platforms will say yes. Document the answer and have your legal team assess it against your specific regulatory framework before making a selection.

Fact 8: Recovery Time Objective and Recovery Point Objective must be tested — not assumed

Recovery Point Objective is the maximum data loss an organization can tolerate — determined by backup frequency. Recovery Time Objective is the maximum time to restore data and resume operations — determined by recovery speed.

Most organizations document RPO and RTO in their backup policy without testing whether their backup infrastructure can actually achieve them under production conditions. An RPO of five minutes documented in policy but backed by a platform that runs daily backups is a liability — not a protection. An RTO of four hours documented in policy but backed by a restore process that requires a data engineering team, a vendor support ticket, and three days of waiting is an organizational risk, not a recovery plan.

Both objectives need to be tested quarterly in a sandbox environment against realistic data volumes and realistic restore scenarios. Test results — actual backup frequency verified against platform logs, actual restore time measured from initiation to completion — are the evidence that compliance auditors request when assessing whether the documented RPO and RTO are achievable.

What this means for evaluation: During platform evaluation, measure actual restore time for the restore scenarios you are most likely to face in production — individual record restores, field-level restores across hundreds of records, object-level restores for objects with your production record counts. Compare measured restore time to your RTO requirement before selecting a platform.

Fact 9: Non-technical restore access reduces recovery time more than restore speed

The fastest restore engine in the market does not help if the person who needs to execute a recovery has to file an IT ticket, wait for a data engineer, or contact vendor support before a restore can begin. In compliance incident response — where recovery time directly affects regulatory exposure and business operations — the organizational bottleneck is often larger than the technical bottleneck.

Non-technical restore access means that compliance managers, Salesforce administrators, and legal team members can execute targeted restores through a visual interface without data engineering support. When a compliance manager can identify an affected record, select the restore point, and initiate the restore in three minutes — rather than filing a ticket and waiting three hours — the effective recovery time drops by 95% without any improvement in restore engine speed.

Most Salesforce backup and recovery software alternatives — including OwnBackup, Spanning, Druva, and Odaseva — have varying levels of non-technical restore accessibility. Evaluating this capability in the context of your organization's incident response workflow reveals practical recovery readiness that technical benchmarks alone do not capture.

What this means for evaluation: During platform evaluation, have a non-technical team member — a compliance manager or Salesforce administrator — attempt to execute a targeted restore using only the platform's documentation. Measure whether they can complete the restore without data engineering assistance. This test reveals the practical recovery readiness that your organization has, not the theoretical recovery capability of the platform's restore engine.

Fact 10: Backup compliance requires documented testing — not just backup logs

A backup that has never been tested is an assumption. HIPAA's Contingency Plan standard requires covered entities to test and revise their contingency plans — not just implement them. GDPR's Article 32 requires organizations to regularly test, assess, and evaluate the effectiveness of their technical measures.

Both frameworks require documented test results — specific test scenarios, specific outcomes, specific recovery times, and specific gaps identified and remediated. A compliance auditor who asks for recovery test documentation and receives backup job logs is receiving evidence of backup frequency, not evidence of recovery capability. The distinction matters: backup frequency demonstrates that data is being captured. Recovery testing demonstrates that captured data can actually be restored correctly.

The documentation gap is the most common finding in Salesforce backup compliance assessments for organizations that have backup infrastructure in place. They back up correctly. They have never tested whether the backup restores correctly. And they have no documentation to produce when an auditor asks.

What this means for evaluation: Ask every backup platform vendor whether they support sandbox restore for testing — restoring to a non-production environment so that recovery tests can be executed safely against real backup data. Ask whether every restore operation generates an immutable audit log that serves as documentation of test execution. Sesame Software supports both — sandbox restore for safe testing and immutable audit logging of every restore operation stored within the customer's own environment.

How Sesame Software satisfies all ten facts

Sesame Software's Salesforce backup and recovery software addresses every gap that these ten facts identify — in a single customer-hosted platform that requires no code and deploys in under an hour.

Automated backups as frequently as every five minutes — not daily snapshots. Deleted record retention for the customer-defined period — not limited to 15 days. Complete field-level audit history with no field count limits and customer-defined retention periods — not capped at 20 fields and 18 months. Metadata backup on every cycle with Metadata Compare and Metadata Restore — not just data records. Granular point-in-time restore at the record, field, and value level — not just record-level recovery. Customer-defined retention periods supporting six-year HIPAA and seven-year SOX requirements — no platform-imposed ceiling. Customer-controlled storage in the customer's own environment — no Sesame Software infrastructure in the data path. Sandbox restore support for safe recovery testing. Immutable audit logging of every backup and restore operation stored within the customer's own environment. Non-technical restore access through the visual interface for compliance managers and Salesforce administrators.

For organizations evaluating OwnBackup alternatives and other Salesforce backup and recovery software — Own, Spanning, Druva, Odaseva, Veeam — the evaluation criteria that these ten facts define eliminate cloud-hosted platforms for organizations where customer-controlled storage is a compliance requirement, and eliminate platforms without field-level restore precision for organizations that need to recover from bulk import errors and automation incidents without collateral data loss.

With 23+ years of enterprise data management expertise and a customer base that includes Procter & Gamble, Bank of America, and the U.S. Government, Sesame Software scales to enterprise data volumes without performance degradation — and without billing surprises, thanks to predictable connector-based annual pricing that never grows with your record counts.

If you're ready to take back control of your Salesforce data protection strategy, talk to a Sesame Software data expert today.

Salesforce Backup and Recovery Software FAQs

Does Salesforce automatically back up enterprise data?

No. Salesforce protects its own platform infrastructure against hardware failures and data center outages under the shared responsibility model. It does not automatically back up your organization's data against user error, accidental deletion, integration failures, or data corruption. Data Export Service, Field History Tracking, and the recycle bin provide partial operational coverage — none constitute enterprise backup and recovery software with compliance-grade retention.

What is the difference between data backup and metadata backup in Salesforce?

Data backup captures the records stored in Salesforce objects — Accounts, Contacts, Opportunities, Cases, and custom object records. Metadata backup captures the org configuration — object definitions, field configurations, permission sets, profiles, workflow rules, validation rules, and flows. Both are required for complete enterprise Salesforce data protection. A metadata incident can break Salesforce functionality without affecting a single data record — and recovery from that incident requires metadata restore capability that data backup alone cannot provide.

How long should Salesforce backup data be retained for HIPAA compliance?

HIPAA requires six years of retention for documentation related to ePHI. SOX requires seven years for financial records. Your backup platform must support retention periods that satisfy the most stringent applicable requirement without platform-imposed ceilings. Sesame Software supports customer-defined retention periods with no platform maximum — organizations configure retention to match their regulatory requirements rather than working within vendor defaults.

What does granular restore actually mean for Salesforce backup?

In practice, granular restore means the ability to restore specific field values on specific records to their historical state without touching any other field or record — field-level restore precision. This is the recovery capability required for bulk import errors that overwrite specific field values across large record sets. Platforms that support only record-level restore overwrite legitimate changes to other fields on the same records during recovery. Field-level restore is the surgical precision that production incident response requires.

What are the best OwnBackup alternatives for enterprise Salesforce data protection?

For organizations where customer-controlled storage is a compliance requirement, OwnBackup's cloud-hosted architecture disqualifies it from consideration — backup data is processed and stored on OwnBackup's infrastructure with no customer-hosted deployment option. Sesame Software is the primary OwnBackup alternative for organizations requiring customer-hosted deployment, field-level restore precision, and customer-defined retention periods. For organizations without strict data residency requirements, Spanning, Druva, and Odaseva offer functional cloud-hosted alternatives with varying levels of compliance coverage.

Why does recovery testing matter for Salesforce backup compliance?

HIPAA's Contingency Plan standard requires covered entities to test and revise their contingency plans — not just implement them. GDPR's Article 32 requires regular testing and evaluation of technical measures. Both require documented results — specific test scenarios, outcomes, recovery times, and gaps remediated. An untested backup is an assumption, not a compliance control. Recovery testing produces the documented evidence that compliance auditors request when assessing whether backup infrastructure is genuinely effective.

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