Salesforce keeps its platform running, but recovering from your own data mistakes is mostly your job. A sound plan backs up both records and configuration on a schedule that matches how much change you can afford to lose. It also keeps copies outside the production org and proves, in a sandbox, that you can restore them with relationships intact. The hard part is rarely taking the backup. It is putting thousands of linked records back correctly.
Doesn't Salesforce already back up our data?
Salesforce protects its own infrastructure, but it does not undo changes your users, automations or integrations make. Its help guidance tells customers to build a routine backup strategy of their own.
Think of it as two layers. Salesforce runs the data centers, replication and service recovery that keep the platform available. If a bad import overwrites ten thousand phone numbers, though, the platform faithfully stores the wrong values. From Salesforce's point of view, nothing failed.
The history here confuses many buyers. Salesforce announced in 2020 that it would retire its paid Data Recovery Service, a slow, last-resort restore handled by support. It reversed that decision in 2021 after customer pushback. Since then it has launched its own backup products and points customers toward them and partner tools. Do not build a plan around a support-led recovery. Ask your Salesforce account team whether any such service is offered today and on what terms.
What usually causes Salesforce data loss?
Most incidents come from inside the org: well-meaning people and systems doing the wrong thing at scale. Outages and attacks happen too, but internal mistakes are the more common cause in our experience.
- Bad imports and mass updates, such as a spreadsheet with shifted columns or a wrong match key.
- Integration bugs that overwrite fields on every sync, or create and delete records in loops.
- Automation errors, where a flow or trigger change rewrites values on every record it touches.
- Deletes that cascade, because removing a parent in a master-detail relationship takes its children too.
- Malicious or careless actions by users, including departing staff who export or remove records.
- Metadata changes, such as deleting a field or changing a picklist, which can drop data along with the setting.
| Incident | How you'd notice | What you need to restore | Prevention |
|---|---|---|---|
| Bad import or mass update | Users report wrong values; field history shows one user changing many records at once | Prior field values for affected records, matched by record ID | Test loads in a sandbox, keep a pre-load export, limit who can run bulk tools |
| Integration overwrite | Values flip back after each sync; integration user appears in field history | Point-in-time field values plus a paused integration | Field-level ownership rules, error alerts, integration user with narrow permissions |
| Automation error | Spike in changed records soon after a deployment | Field values from before the release, then a fixed automation | Release testing and review, plus a backup taken before each deployment |
| Mass or cascade delete | Missing records, broken related lists, Recycle Bin filling up | Parent and child records with relationships rebuilt | Restrict delete permissions, avoid hard delete, monitor delete volumes |
| Departing or malicious user | Unusual exports or deletes in audit and event logs | Deleted or altered records, plus an access review | Prompt deprovisioning, least-privilege access, event monitoring where licensed |
| Deleted field or changed metadata | A field, value or layout disappears; reports break | Metadata from source control and the data the field held | Source control, change review, a data export before removing fields |
What can native Salesforce tools recover on their own?
Native tools cover small, recent mistakes well and large incidents poorly. Know each one's limits before you rely on it.
- Recycle Bin: deleted records stay for a limited window, documented as fifteen days, and the oldest drop out sooner if the bin reaches its capacity limit. It does nothing for overwritten values.
- Field history tracking: records old and new values for tracked fields, which helps you see what changed. Standard history is kept for a limited period and covers only fields you chose to track.
- Data Export Service: produces CSV files of your records on a schedule. Salesforce documents weekly exports for Enterprise, Performance and Unlimited editions and monthly exports for most others.
- Data Loader and report exports: useful for a quick manual snapshot before a risky data project.
The export service has gaps that matter in a crisis. Salesforce says files stay downloadable for 48 hours and vanish when a new export is queued. There is no service level for completion. Formula and roll-up fields are excluded, and files are included only if you select them. Someone must download and store each export, or it is gone.
What does Salesforce's own backup product add?
Salesforce sells a paid backup add-on that takes automated copies and offers guided restores. Names and packaging have changed several times, so confirm the current offer with your account team.
Salesforce's help site currently describes Backup & Recover Next alongside an earlier Backup and Recover version. Before that, a managed package called Backup and Restore was renamed Salesforce Backup. Salesforce's product page describes daily backups of data, metadata and files, and the help pages describe point-in-time, field-level and previewed restores. Which version you can buy, and what each covers, depends on your contract and edition.
What kinds of third-party backup tools exist?
AgentExchange (formerly AppExchange) and independent vendors offer several styles of tool. The right fit depends on restore needs, not on how backups are taken.
- Dedicated backup and restore platforms with scheduled snapshots, comparison views and guided record restores.
- DevOps and release tools that add metadata and data backup to their deployment features.
- Broader SaaS backup suites that cover Salesforce alongside other cloud applications.
- Do-it-yourself pipelines that copy data to your own warehouse through the API.
Press every vendor on four points. Where is the copy stored, and who can reach it? Can it rebuild parent-child links on restore? How fast can you find one changed field across a million records? And what does a restore into a sandbox look like?
Why do we need metadata backup as well as data backup?
Records depend on the fields, objects, picklists and automation that define them. Restoring data into an org whose configuration has changed can fail or land values in the wrong place.
The cleanest metadata backup is source control. When every change is deployed from a version-controlled repository, you can see who changed what and redeploy an earlier version. Our release management guide covers that workflow. Backup tools can also snapshot metadata, which catches changes made directly in production that never went through a repository.
How often should we back up, and how fast must we recover?
Set two targets in plain terms: how much recent change you could lose, and how long the business can wait. Those answers set backup frequency and drive tool choice.
The first target is often called the recovery point objective, or RPO. If losing a day of updates is tolerable, a daily backup may be enough. If the sales team logs hundreds of changes an hour, it is not. The second is the recovery time objective, or RTO. A service team that cannot see case history has a shorter tolerance than a marketing team waiting for a report. Set targets per object group rather than one figure for the whole org. Always take an extra snapshot before a major load, deployment or integration change.
Why is restoring harder than backing up?
A backup is a flat copy of rows. A restore must rebuild a web of record IDs, lookups and parent-child links in the right order, without retriggering automation.
Salesforce assigns a new ID to any record you recreate. Every child that pointed at the old parent must then be remapped to the new one. Restore order matters: accounts before contacts, contacts before cases, and so on through the hierarchy. Automation will fire on restored records unless you bypass it, which can send emails or update integrations. Overwritten values are a different job from deleted records. Here you update existing rows by ID, ideally only the fields that changed.
How do we test that a restore actually works?
Run restores in a sandbox on a schedule, using real backup copies. A restore you have never performed is a hope, not a plan.
Pick realistic scenarios from the incident table, such as a cascade delete of one account hierarchy. Time each one and check related lists, owners and attachments afterward. Record the steps that needed workarounds, then fold them into the runbook. Repeat after major releases, since new objects and automation change the restore order.
How should files, attachments and backup copies be protected?
Files often hold the most sensitive content and the most storage, so decide deliberately whether to include them. Treat every backup copy with the same controls as production.
Backing up files can multiply storage and transfer costs, yet contracts and signed forms may be the hardest data to replace. Many teams include files linked to key objects and exclude bulky low-value content. A backup holds every record you own, so encrypt it, restrict access to a small named group and log who opens it. Check that its storage location satisfies your privacy and industry rules. Remember that data deleted for a privacy request may still sit in older backups. Our security review checklist covers access controls on the live org.
How is backup retention different from archiving?
Backup retention decides how far back you can roll; archiving decides where old records live permanently. They answer different questions and need separate policies.
Keep backup versions long enough to catch slow-surfacing problems, such as a bad sync noticed at quarter end. Do not rely on backups as the long-term home for closed records that you must keep for compliance. Our data archiving and retention guide covers that side.
What belongs in a Salesforce recovery runbook?
A runbook turns a stressful incident into a sequence of known steps. Write it before you need it and keep it outside Salesforce.
- Who declares an incident, and who approves a restore into production.
- How to stop the damage: pause the integration, deactivate the flow or freeze the user.
- How to size the impact with field history, audit logs and backup comparisons.
- The restore order for your key objects and how automation is bypassed during the load.
- Validation checks, user communication and a short review afterward.
What should phase one include?
Start with coverage and one proven restore. Refinement can follow once the basics work.
- List critical objects and agree on loss and downtime targets with each business owner.
- Put automated daily backups of data and metadata in place, stored outside the org.
- Move configuration changes into source control if they are not there yet.
- Run one sandbox restore of a parent-child hierarchy and write the runbook from it.
- Review delete and bulk-data permissions, and add pre-load snapshots to your release checklist.
If a recent incident prompted this, our managed services team can help you size the gap. We can also test a first restore and make backups part of routine operations.
