How to Back Up Salesforce Data: A Business Guide

A sales director at a Johannesburg technology company discovers on a Monday morning that 4,000 account records have been deleted. A junior administrator ran a bulk delete operation on the wrong object on Friday afternoon. The records have been in the Recycle Bin — which Salesforce empties after 15 days — and it has been 17 days. The data is gone.

This scenario, and variations on it, is more common than Salesforce users realise. The platform is designed for reliability and performance — not for the kind of point-in-time recovery that business continuity actually requires. Understanding what Salesforce retains, and where it stops, is the first step to protecting your CRM data properly.

What Salesforce Does and Does Not Retain

Salesforce includes several built-in data protection features. They are more limited than most users assume.

The Recycle Bin

Deleted records go to the Recycle Bin, where they can be restored by users or administrators for up to 15 days. After 15 days, the Recycle Bin is emptied and the records are permanently deleted.

The gap this creates: If data is deleted and the deletion is not discovered within 15 days — which happens regularly with bulk operations, integration errors, or departing employees acting maliciously — there is no recovery path through the Recycle Bin.

Data Export Service

Salesforce's Data Export Service allows administrators to schedule weekly or monthly exports of all CRM data to CSV files, which are made available for download. If downloaded and stored externally, these exports provide a recovery point.

The gaps this creates: Exports are available weekly at best — meaning up to 7 days of changes may be missing from the most recent export. The export must be actively downloaded and stored by an administrator — if the download step is missed, the export expires and is no longer available. Exports cover data records but do not include metadata, configuration, custom settings, or Salesforce automation rules. Restoring from a CSV export to a live Salesforce org is a manual, time-consuming process with significant risk of data mapping errors.

Salesforce Backup (Paid Add-On)

Salesforce offers a paid backup add-on that provides daily automated snapshots of your org data with restore capability. It covers standard and custom objects, files, and attachments.

The gaps: Daily snapshots mean up to 24 hours of data may be lost. The add-on does not cover all Salesforce metadata, configurations, or Apex code. Pricing is per-org per-month and can be significant for large orgs.

The Data Loss Scenarios Salesforce Cannot Recover From

Mass Deletion by a User or Integration

Bulk operations in Salesforce — whether run by a user through the Data Loader, triggered by a workflow error, or caused by a faulty integration — can delete thousands of records in seconds. If the deletion is not detected within 15 days, the Recycle Bin provides no recovery.

This is the most common Salesforce data loss scenario we encounter. The pattern is consistent: an integration is updated, a mapping error causes the wrong records to be deleted or overwritten, the problem is not discovered immediately, and by the time it is found the Recycle Bin window has passed.

Departing Employee Malicious Action

A departing employee with Salesforce administrator or data management privileges can delete accounts, contacts, opportunities, and other critical records before their access is revoked. If this is discovered after the 15-day window — or if the records were overwritten rather than deleted, bypassing the Recycle Bin entirely — the data is unrecoverable through native Salesforce tools.

Field-Level Overwrite

If data in a Salesforce field is overwritten — rather than the record being deleted — there is no native recovery path at all. The Recycle Bin only applies to deleted records, not overwritten field values. If a bulk update replaces correct field values with incorrect ones, or if an integration writes incorrect data to a field, the original values are permanently lost unless an external backup captured them.

This is a particularly insidious failure mode because it does not produce an obvious error. The records still exist. They just contain wrong data. The problem may not be discovered until the incorrect data causes operational problems — by which time the original values are long gone.

Sandbox Promotion Errors

In development and staging workflows, changes tested in a Salesforce sandbox can sometimes be promoted to production in ways that overwrite or corrupt production data. Recovering from a sandbox promotion error without a full point-in-time backup of the production org requires manual reconstruction of every affected record.

POPIA and CRM Data

Salesforce organisations hold personal information: customer names, contact details, correspondence, deal history, and often sensitive commercial information. Under POPIA, this data is subject to the same security safeguard requirements as any other personal information your organisation processes.

The security safeguards condition requires appropriate technical measures to prevent loss and unlawful destruction of personal information. Relying solely on Salesforce's 15-day Recycle Bin and weekly data export does not constitute appropriate measures for personal information of the volume and sensitivity typically held in a CRM.

A POPIA data subject access request for a contact's full interaction history — or a breach investigation that requires determining what data existed in the CRM at a specific point in time — cannot be satisfied if the relevant records have been deleted beyond the Recycle Bin window.

Third-Party Salesforce Backup: What to Look For

A purpose-built Salesforce backup solution connects to your org via Salesforce's APIs and takes automated daily (or more frequent) snapshots of all your CRM data, storing copies externally. Key capabilities to evaluate:

Coverage: Backs up all standard and custom objects, files, attachments, and ideally metadata and configuration as well. Metadata backup means you can restore not just the data but the structure of your org.

Frequency: Daily backups provide a maximum 24-hour data loss window. For high-velocity sales environments where significant data is created and modified daily, more frequent snapshots reduce that window further.

Granular restore: The ability to restore a single record, a set of records, or a specific field value — not just a full org restore. Granular restore is essential for the partial-data-loss scenarios (a bulk delete, a field overwrite) that represent the majority of Salesforce data loss incidents.

Point-in-time recovery: Restore your org to its state at any point within the backup retention window — not just the most recent snapshot. This is critical for the delayed-discovery scenario where a data loss event is not detected for days or weeks.

Comparison and audit: The ability to compare your current org state to a historical snapshot and identify what changed. This is essential for diagnosing integration errors and malicious actions.

Retention window: At minimum 30 days, ideally 90 days or longer. The 15-day Recycle Bin window is already too short for many discovery patterns; your backup retention should significantly exceed it.

Druva for Salesforce

Montana Data Company deploys Druva's SaaS backup platform, which includes Salesforce backup alongside Microsoft 365 and other SaaS applications. Druva backs up Salesforce data daily, stores it in immutable cloud storage, and provides granular point-in-time restore with a configurable retention window.

For organisations already using Druva for Microsoft 365 backup, adding Salesforce backup is a configuration change within the same platform and management console — not a separate product procurement.

If your organisation uses Salesforce and has not yet assessed your backup coverage for the platform, a gap analysis will tell you specifically what your current exposure is and what a properly configured solution would change. Most Salesforce data loss incidents we encounter could have been recovered from in hours with a third-party backup in place, and were instead weeks-long reconstruction projects without one.