Salesforce backup and restore: why the Recycle Bin isn't a backup, and what native Backup actually protects

Every team that has lost Salesforce data remembers the exact moment they discovered their backup wasn’t one. A flow update that overwrote a field across 200,000 records. A data-loader job that ran against the wrong object. A managed-package uninstall that took its custom objects — and their data — with it. Someone says “restore from the Weekly Export,” and then the facts land: the export is a pile of raw CSVs with no relationships, the last one is six days old, the Recycle Bin purged itself while nobody was looking, and the paid Salesforce recovery service everyone half-remembered was retired years ago. The data isn’t coming back cleanly, and it’s Monday.

Backup is the least glamorous line item on any Salesforce program and the one that turns into an existential incident exactly once. The trap is that the platform feels like it’s protecting you — there’s a Recycle Bin, there’s an export, it’s the cloud — when none of those things is a backup in the sense that matters: point-in-time data and the ability to put it back the way it was. Here’s the shared-responsibility reality most teams learn too late, what Salesforce’s native backup actually covers, and why the restore, not the backup, is where these projects go wrong.

The shared responsibility model, stated plainly

Salesforce operates a shared responsibility model, and the half that surprises people is yours. Salesforce secures and runs the infrastructure — the data centers, the platform, the uptime. Your data and your ability to recover it are your responsibility. In data-protection terms you’re the controller and Salesforce is the processor: they keep the platform running; getting your records back after your org deleted or corrupted them is your problem to have solved in advance.

This isn’t a footnote — it’s the whole reason a backup strategy has to be a deliberate decision rather than an assumption. Salesforce will not, and contractually does not, guarantee to restore data you lost to your own bad deployment, your own integration bug, or your own admin’s mis-click. The platform’s built-in features look like they cover this. They don’t.

Why the built-ins aren’t backups

The Recycle Bin is a short grace period, not a backup. Deleted records sit there for about 15 days by default (extendable to 30 in Classic with Extended Recycle Bin Retention), and the bin is capped at roughly 25× your org’s data storage. When it fills, Salesforce auto-purges the oldest records — no alert, no warning. Most internal data loss is quiet and incremental, discovered days or weeks later, which is to say discovered after the 15-day window has already closed. A safety net with a two-week fuse is not a safety net for the failures that actually happen.

The Weekly Data Export is a point-in-time CSV dump, not a recoverable backup. The Data Export Service gives you a set of CSVs on a schedule — weekly at best on Enterprise, Performance, and Unlimited editions, and only about every 29 days on lower editions. That cadence alone means a recovery point objective of up to seven days: lose data on day six and you’re restoring to a week ago. Worse, the export is just data — flat CSVs with no relationships preserved, no metadata, no automation, and no restore tool. Putting it back means hand-writing an import that re-stitches every parent-child relationship yourself, and the export files are deleted 48 hours after Salesforce emails you the download link. It’s a compliance artifact and a rough analytical snapshot. It is not something you restore from under pressure.

And the paid last resort is gone. Salesforce used to sell a Data Recovery Service — a last-ditch, best-effort restore that cost upward of $10,000, took six to eight weeks, returned data only, and came with no guarantee of full recovery. Salesforce retired it on July 31 2020, briefly reinstated it in 2021 after customer backlash, and then retired it again once native and partner backup products existed. The message was unambiguous: backup is now something you own, not a rescue you can buy after the fact.

A backup you can’t restore relationally, on demand, to a known point in time, is not a backup — it’s a copy you’ll be forced to explain to an auditor while the real data stays gone.

What “native Salesforce backup” actually is now

In 2024 Salesforce acquired Own (formerly OwnBackup), the long-time market leader in Salesforce backup, for roughly $1.9 billion, and folded its technology into a first-party offering. Today Salesforce’s native answer centers on Backup & Recover, built on Own’s technology and sold as a Salesforce product, alongside an older Salesforce Backup managed package (renamed from “Backup and Restore”). The distinction matters when you scope, so pin down with your account team exactly which product and tier you’re buying rather than assuming one set of capabilities.

What the native product does that the built-ins don’t:

• Automated, higher-frequency backups. Rather than a weekly CSV, native backup runs automatically — daily by default, with high-frequency jobs that can run as often as every 15 minutes depending on data volume in the Backup & Recover tier. That’s the difference between a seven-day RPO and a near-real-time one.
• Records, files, and attachments — including the full content-file family (ContentVersion and its relatives) with version and sharing information, not just row data.
• Relationship-aware, granular restore. You can restore down to a single field on a single record, or a whole object, with the relationships intact — parent to child, many levels deep — and compare a backup against live data to see exactly what changed before you put anything back.
• Backups stored within the Salesforce trust boundary, which keeps them inside your existing security and compliance perimeter. The honest trade-off: keeping backups on the same platform as the live data is a single-vendor posture, so some regulated teams deliberately choose a third-party tool that lands the copy in their own cloud for isolation. Both are defensible; just make it a decision, not an accident.

One thing to be precise about: backing up data and backing up metadata are two different disciplines. Native backup’s core job is your records and files. Your configuration — objects, fields, flows, Apex, permission sets — is metadata, and the right home for metadata protection is version control. If you don’t already treat metadata as source-controlled, that’s a gap a data backup doesn’t fill; it’s the same discipline behind moving from change sets to a real DevOps pipeline, where Git is your metadata history and rollback path.

The restore is the hard part — and where teams get hurt

Here’s what the vendor demos underplay: taking the backup is easy; restoring it correctly is the entire problem. A backup you’ve never test-restored is a hypothesis, not a safety net. The failure modes are specific and they compound.

Automation re-fires on the way in. When you re-insert thousands of records, every Apex trigger, flow, workflow rule, validation rule, and duplicate rule fires again — as if the data were brand new. That means email alerts blasting customers, cascading updates rewriting related records, and validation or duplicate rules rejecting the very records you’re trying to restore. The number-one restore horror story is “we restored, and it made everything worse.” The discipline is to deactivate triggers, flows, workflow rules, and validation rules and suspend email deliverability for the duration of the restore, then re-enable them — Salesforce’s own Restore tool includes a “Disable triggers and rules” option that re-enables automation automatically when the job finishes. Use it, and know which automations it does and doesn’t cover.

Historical records can fail today’s validation rules. If you tightened a validation rule after the backup was taken, records that were valid then are invalid now, and a naive restore rejects them. This is another reason validation gets disabled during a mass restore, and a reason to keep automation changes in mind when you scope one.

Relationships have to be rebuilt in order. Salesforce inserts records with new record IDs on restore, which breaks every lookup and master-detail relationship that referenced the old IDs. Parents must be inserted before children, and deep parent-child-grandchild hierarchies have to go back in dependency order or the links dangle. The mechanism that saves you is External IDs: a custom field marked as an external ID lets a restore re-stitch relationships by a stable business key via upsert, instead of relying on internal IDs that no longer exist.

// Restoring child records against parents that came back with brand-new Ids:
// resolve the lookup by the parent's External Id, not the internal Id that changed.
for (Invoice__c inv : restoredInvoices) {
    inv.Account__r = new Account(External_Account_Id__c = inv.Legacy_Account_Key__c);
}
// Upsert on the child's own External Id so a re-run is idempotent, not a duplicate.
upsert restoredInvoices Invoice__c.External_Invoice_Id__c;

Orgs that designed external IDs in from the start restore cleanly; orgs that didn’t spend the incident hand-mapping IDs in a spreadsheet. A large restore also burns API calls and hits governor limits, so it has to be batched — one more reason the time to rehearse it is before the incident.

The takeaway: choosing a backup tool is 20% of the work. The 80% is designing your data model so it can be restored — external IDs, an understood automation-suppression path — and then actually test-restoring into a sandbox on a schedule so the runbook is proven, not aspirational. Seed those restore rehearsals with realistic, safe data using Data Mask and sandbox seeding rather than practicing on a stale copy.

What it costs, and how to think about coverage

Salesforce does not publish official list pricing for its native backup — it’s quote-based, so you’ll get a number from your account team rather than a web page. Third-party estimates commonly cite something in the neighborhood of $10 per user per month for the native backup, but treat that as an indicative partner figure, not a Salesforce-published rate, and expect longer retention, higher backup frequency, and metadata coverage to move the price. Because it’s typically licensed per Salesforce user, the cost tracks your headcount rather than your data volume — which cuts both ways depending on whether you’re user-heavy or data-heavy.

Scope coverage around two numbers you should decide deliberately: your recovery point objective (how much data you can afford to lose, which sets backup frequency) and your recovery time objective (how fast you must be back, which sets how rehearsed and tooled your restore is). A four-times-a-day backup with an untested restore runbook has a great RPO and a terrible RTO — and RTO is the one that hurts during the incident. Retention is the third dial: keep enough history to recover from slow corruption you notice late, not just yesterday’s mistake.

What to actually do

You don’t need a six-month project to stop being one bad deployment away from permanent loss. In order:

1. Accept the shared-responsibility reality and stop treating the Recycle Bin and Weekly Export as a backup. They are not.
2. Stand up a real backup — Salesforce’s native Backup & Recover or a reputable third-party tool — with a frequency that matches the RPO you can actually live with.
3. Back up metadata too, through source control, because a data backup won’t restore your configuration.
4. Design for restore: external IDs on the objects that matter, and a documented, tested automation-suppression path.
5. Test-restore into a sandbox on a schedule. An untested backup is a guess. This is the single highest-leverage habit, and the one everyone skips.

The failure this prevents is not exotic. Most Salesforce data loss is internal — accidental deletion, a failed integration, a botched deployment — and it’s usually discovered after the built-in safety nets have already timed out. Even Salesforce’s own infrastructure has permanently lost customer data in a rare incident. The org that recovers in an afternoon and the org that spends three weeks reconstructing relationships by hand differ by exactly one thing: whether the restore was designed and rehearsed before it was needed. Backup is where you find out whether your Salesforce technical debt includes the kind that only bills you once — catastrophically — and it’s cheap insurance against the one incident that doesn’t get a second take.

Understanding the basics

Is the Salesforce Recycle Bin or Weekly Export a backup?

No. The Recycle Bin holds deleted records for only about 15 days by default (30 in Classic with Extended Retention) and auto-purges the oldest records once it hits roughly 25× your data storage — with no warning — so it’s already empty by the time most internal data loss is noticed. The Weekly Data Export produces flat CSVs at most weekly (about every 29 days on lower editions), with no relationships, no metadata, no automation, and no restore tool, and the files are deleted 48 hours after they’re generated. Both are useful for other purposes, but neither gives you a point-in-time copy you can relationally restore on demand — which is what a backup is.

Does Salesforce back up my data for me?

Only the platform, not your data recovery. Under Salesforce’s shared responsibility model, Salesforce secures and operates the infrastructure while you are responsible for backing up your data and being able to restore it. Salesforce also retired its paid last-resort Data Recovery Service (which cost over $10,000 and took six to eight weeks with no guarantee), so there’s no after-the-fact rescue to buy. You need your own backup — Salesforce’s native Backup & Recover, built on the Own (formerly OwnBackup) technology it acquired, or a third-party tool — configured before you need it.

Why do Salesforce restores go wrong?

Because re-inserting records re-triggers automation and breaks relationships. On a mass restore, triggers, flows, workflow rules, validation rules, and duplicate rules all fire again — sending emails, cascading updates, and rejecting the records you’re restoring — so you have to disable automation and suspend email during the restore (Salesforce’s Restore tool has a built-in option for this). Restored records also get new record IDs, which breaks lookups and master-detail links unless you use External IDs to re-stitch relationships by a stable business key, and parents must be restored before children. The fix is to design external IDs in advance and test-restore into a sandbox regularly, so the runbook is proven before a real incident.

---

Not sure whether your org could actually recover from a bad deployment or a rogue mass-update? Talk to us — setting up backup that matches your real RPO, designing the data model so it can be restored, and rehearsing the runbook before you need it is the work we do. A quick Org Health Scorecard is a fair place to see where the data-protection gaps sit.