Salesforce Backup and Recovery | SalesforceTutorial

Salesforce backup and recovery is the process of creating restorable copies of Salesforce records, files, relationships, and metadata, then using those copies to recover from deletion, corruption, faulty automation, or a failed deployment. A usable backup plan must define what is protected, how often it is captured, where it is stored, and how the team will restore related records without triggering more damage.

Salesforce protects the availability of its platform infrastructure, but customers still need a plan for business-level data loss. Salesforce documents this distinction in its guidance on backing up data for recovery. An administrator should not treat the Recycle Bin, a sandbox, or an occasional CSV export as a complete recovery system.

What Does Salesforce Backup and Recovery Protect?

A complete recovery scope contains more than rows from standard and custom objects. In an enterprise org, the protected scope normally includes four layers:

Backing up records without their metadata can leave the recovery team with CSV files that no longer match the current schema. Backing up metadata without data protects configuration history but does not recover deleted customer records. The two processes should be coordinated.

Why Is a Salesforce Data Backup Strategy Required?

Salesforce data backup strategy for user and integration errors

A Salesforce data backup strategy is primarily designed for failures inside the customer-controlled layer. Common incidents include an incorrect Data Loader update, a middleware job that writes null values, a flow that modifies the wrong record set, or a deployment that removes fields before their values are preserved.

These failures may affect thousands of records while Salesforce itself remains available. Infrastructure uptime does not reverse a valid API transaction submitted by an authorized user or integration.

Mass updates can cause valid but unwanted changes

Suppose an administrator imports a file that maps an empty spreadsheet column to Account.Customer_Tier__c. The update may complete successfully while clearing the field across the selected Accounts. Because the records were updated rather than deleted, the Recycle Bin cannot restore the previous values. Recovery requires an earlier copy of the field values and a controlled update back into Salesforce.

Metadata changes can block data restoration

A restore may fail when the original object, field, record type, or picklist value no longer exists. Before loading data, compare the backup snapshot with the target metadata. Restore or deploy the required schema first, then load parent records, child records, junction records, and files in dependency order.

What Native Salesforce Backup Options Are Available?

Salesforce lists Data Export Service, Data Loader, report exports, and Salesforce Backup among its backup approaches. The correct choice depends on the required recovery point, recovery time, record volume, file volume, and compliance controls.

How the Salesforce Recycle Bin fits into recovery

Deleted records normally remain in the Salesforce Recycle Bin for 15 days. During that period, users with the required access can restore eligible records. Salesforce also documents an Extended Recycle Bin Retention feature that can increase the period to 30 days when activated through Salesforce Support.

The Recycle Bin is an operational convenience, not a complete backup. It does not restore overwritten field values, deleted metadata, corrupted files, or records that have already been permanently removed.

Data Export Service

The Data Export Service can create downloadable exports from Setup. Depending on the export selection, the package can include CSV data and file content. Salesforce notes that Setup-based Data Export can include attachments, documents, and images, while a basic Data Loader export of file-related objects does not automatically retrieve the underlying binaries.

After downloading an export, store it outside Salesforce with access controls, encryption, retention rules, and integrity checks. A ZIP file left in a user’s Downloads folder does not provide controlled retention or operational recovery.

Salesforce Backup

Salesforce Backup supports policy-based backups and record restoration. Salesforce documentation describes creating backup policies from the Backup and Restore application and restoring records with filters such as object, change type, record ID, modification user, and backup time.

Before adopting it, confirm the licensed product version, supported data categories, restore behavior, retention settings, file handling, and the permissions required by the authenticated backup user. Product naming and packaging have changed over time, so use the documentation presented in the target org rather than relying on an older implementation guide.

Can You Build a Free Salesforce Backup?

Free Salesforce backup using native exports

A free Salesforce backup can be built with tools included in the platform, such as Data Export Service, Data Loader, reports, Metadata API, and Salesforce CLI. This approach can work for a small org when the team accepts manual recovery work and has the skills to manage exports, dependencies, files, credentials, and retention.

There is no license charge for a script that exports records through available APIs, but the process is not cost-free operationally. Someone must monitor failed jobs, protect credentials, verify completeness, store multiple restore points, and test recovery.

SFDC backup limitations of CSV-only exports

An SFDC backup based only on CSV files usually has these gaps:

• Lookup columns may contain Salesforce IDs that differ between environments.
• Parent records must be restored before dependent child records.
• Polymorphic relationships, such as some activity links, require additional mapping.
• Files require both metadata records and binary content.
• Deleted fields and objects must be recreated before their data can be loaded.
• Flows, validation rules, triggers, duplicate rules, and roll-up logic can change the restored records.
• A CSV does not prove that every expected object and row was exported.

Use checksums, row counts, export logs, and restore runbooks to reduce these risks.

How Should You Back Up Salesforce Metadata?

Salesforce Metadata API can retrieve customization information, including supported object definitions, layouts, Apex classes, permission sets, and other metadata types. Store retrieved metadata in a controlled repository or immutable backup location so that a known org state can be reconstructed.

A manifest-driven Salesforce CLI retrieval can be used for a repeatable snapshot:

# Authenticate using the method approved by your security team.
# Avoid storing a user's password or access token in the script.

sf project retrieve start \
  --target-org production-backup \
  --manifest manifest/package.xml \
  --output-dir backups/metadata/2026-07-17

The package.xml manifest must list the metadata types and members required by the recovery plan. Metadata API does not expose every item in an org in the same way, and some settings require related features or specific API versions. Review the official Metadata API type coverage when building the manifest.

Do not assume that a retrieve of * captures the complete org. Test the package by deploying it to a scratch org, sandbox, or other approved recovery environment.

How Do You Design a Salesforce Backup Schedule?

Define the recovery point objective

The recovery point objective, or RPO, is the maximum acceptable age of the data used for recovery. If the business can tolerate losing no more than one hour of Case updates, a weekly export does not meet the requirement. The capture frequency must be shorter than or equal to the approved RPO, with allowance for failed jobs.

Define the recovery time objective

The recovery time objective, or RTO, is the target duration for restoring the service or dataset after an incident is declared. RTO includes incident analysis, backup selection, metadata preparation, data transformation, import execution, validation, and business approval. It is not only the time required to run an import.

The values in this table are examples, not Salesforce limits. Business owners, security teams, compliance teams, and architects must approve the actual objectives.

Backing Up Salesforce Data Step by Step

Backing up Salesforce data before a deployment

1. Identify the change scope. List affected objects, fields, files, automation, integrations, and metadata dependencies.
2. Capture metadata. Retrieve the current production components with Metadata API or Salesforce CLI.
3. Export affected records. Include record IDs, external IDs, relationship keys, audit fields available to the running user, and fields changed by the deployment.
4. Preserve file content. Confirm that the export includes the binary files, not only ContentDocument or ContentVersion metadata.
5. Record counts and checksums. Save object counts, extraction timestamps, query definitions, job IDs, and file hashes.
6. Store the snapshot outside the org. Apply encryption, access controls, retention rules, and deletion policies.
7. Validate the backup. Open the archive, parse the CSV files, compare row counts, and test a representative restore.
8. Approve the rollback plan. Define who can declare a rollback and which automation will be disabled or bypassed during recovery.

Example SOQL scope for a targeted Account backup

SELECT Id,
       Name,
       AccountNumber,
       Customer_Tier__c,
       OwnerId,
       ParentId,
       LastModifiedDate,
       SystemModstamp
FROM Account
WHERE LastModifiedDate = LAST_N_DAYS:7
ORDER BY SystemModstamp ASC

This query is suitable only when the recovery scope is limited to recently modified Account records and the running user can access every required field. A backup integration must account for object permissions, field-level security, API query limits, pagination, deleted records, and records outside the seven-day filter.

For large datasets, use an API and extraction method designed for the volume. Do not run one SOQL query per record. Bulkify custom extraction logic and monitor API consumption.

How Do You Restore Salesforce Data Safely?

1. Stop the source of corruption

Pause the integration, scheduled flow, batch job, user process, or deployment that caused the incident. Restoring records while the faulty process remains active can corrupt the recovered values again.

2. Determine the incident boundary

Identify affected objects, fields, record IDs, users, and timestamps. Compare a known-good snapshot with the current org. Avoid replacing an entire object when only one field on a limited record set is wrong.

3. Prepare metadata and reference data

Restore missing objects, fields, record types, picklist values, and permissions before loading dependent records. Verify that external IDs used for mapping remain unique.

4. Control automation

Review flows, Apex triggers, validation rules, duplicate rules, assignment rules, and integration callbacks. Use approved bypass controls rather than deleting automation. Restrict the bypass to the recovery user and recovery window, and log its activation.

5. Restore in dependency order

A common sequence is reference data, parent records, child records, junction records, activities, sharing records where applicable, and files. Preserve a mapping between original IDs and newly created IDs when records cannot be undeleted and must be inserted.

6. Validate the result

Compare record counts, field values, relationship counts, ownership, sharing access, roll-up values, and file availability. Ask business owners to validate representative records before the incident is closed.

How Do CRUD, FLS, and Sharing Affect Backup Jobs?

A backup process sees only the data available to its authenticated context unless the product or integration uses permissions that provide wider access. An incomplete permission model can silently produce an incomplete backup.

• Use a dedicated integration user where the architecture permits it.
• Grant only the permissions required to read the protected objects and fields.
• Review object permissions, field-level security, record visibility, file access, and API access.
• Protect the authentication method with the same controls used for other privileged integrations.
• Monitor permission changes that could reduce backup coverage.

Salesforce Trailhead recommends a dedicated authenticated user for Salesforce Backup connections and assigning the permissions needed for the protected data. Apply least privilege while ensuring that the approved backup scope is complete.

For Apex-based export or restore utilities, explicitly enforce sharing and CRUD/FLS according to the intended security model. Apex running in system context can access data differently from the user interface, so security behavior must be designed rather than assumed. See the Salesforce security model and Salesforce permission sets tutorials for related configuration guidance.

What Should a Salesforce Recovery Test Include?

A backup is not proven until the team restores it. Schedule recovery exercises based on system criticality and after material changes to the data model, file architecture, integration landscape, or backup product.

Record every manual step during the exercise. Convert repeated steps into scripts or runbook procedures, but retain approval gates for destructive operations.

Common Salesforce Backup and Recovery Errors

• Using a sandbox as the only backup: sandbox refreshes can overwrite the copy, and sandbox data may be masked, partial, or outdated.
• Exporting only primary objects: a Case backup without related EmailMessage, ContentDocumentLink, or custom child records may not satisfy the recovery requirement.
• Ignoring files: exporting file record metadata without file binaries creates an incomplete archive.
• Skipping metadata: deleted fields and record types can prevent data from loading.
• Keeping one restore point: corruption may remain unnoticed until the only retained snapshot already contains it.
• Restoring into active automation: flows and triggers may update, reject, or duplicate imported records.
• Using Salesforce IDs as the only relationship key: inserted records receive new IDs, so external IDs are often required for repeatable mapping.
• Not testing permissions: the backup user may lose access to a new object or field, producing a partial snapshot.
• Failing to test recovery: a completed export job does not prove that the archive can meet the stated RTO.

Salesforce Backup and Recovery Checklist

• Document the data, metadata, file, and relationship scope.
• Assign business owners for each protected process.
• Define and approve RPO, RTO, retention, and deletion requirements.
• Select native exports, Salesforce Backup, custom API extraction, or another approved method.
• Use a dedicated authenticated user where appropriate.
• Monitor job failures, coverage changes, storage capacity, and credential expiry.
• Encrypt backup data in transit and at rest.
• Keep multiple restore points in an access-controlled location outside the production org.
• Retrieve metadata before significant deployments.
• Create a dependency-aware restore sequence.
• Define an automation bypass that is restricted and audited.
• Run recovery tests and measure actual RPO and RTO results.

For related implementation steps, see the guides to Salesforce Data Loader, SOQL queries, and Salesforce deployment planning.

Frequently Asked Questions

Official Salesforce References

• Back Up Data for Recovery
• Back Up Data with Salesforce Backup
• Restore Records with Salesforce Backup
• Metadata API Developer Guide
• Backup and Recover Basics on Trailhead