bob-hanes

Bob Hanes

for-everyone

For Everyone

It happens to every Salesforce admin eventually. Maybe a user ran a mass delete they didn’t mean to. Maybe an automation fired on the wrong set of records. Maybe someone used Data Loader with the wrong CSV file and overwrote half your Accounts. Whatever the cause, you’re now staring at missing data and the sinking realization that you don’t have a backup to fall back on.

You’re not alone. Roughly [60% of Salesforce organizations](https://www.techtarget.com/searchdatabackup/feature/Data-protection-experts-weigh-in-on-SaaS-backup-confusion) are running without any third-party backup solution, and [53% of SaaS users reported data loss or corruption in the past year](https://crmninjas.io/salesforce-data-loss-think-again/). So let’s skip the part where I tell you that you should have had a backup (you already know that), and focus on what you can actually do right now to recover your data.

## **First: Don’t Panic, and Don’t Touch Anything**

Before you do anything else, stop making changes. Every action you take in Salesforce — including trying to “fix” things — could make recovery harder. If an automation caused the problem, disable it immediately. If a user is still actively deleting or modifying records, revoke their access. The goal right now is to freeze the situation so you can assess the damage clearly.

Take a breath, grab a notepad, and document what you know: what was deleted or changed, approximately when it happened, which objects are affected, and how many records you think are involved. This information will be critical no matter which recovery path you end up taking.

## **Option 1: The Recycle Bin (Your 15- to 30-Day Safety Net)**

The Recycle Bin is the first place to look, and for straightforward deletions, it might be the only tool you need. When records are deleted in Salesforce, they aren’t immediately erased — they’re soft-deleted and moved to the Recycle Bin, where they sit for 15 days by default before being permanently purged.

One thing most admins don’t know: if your org still uses Salesforce Classic (or has it available), you can enable [**Extended Recycle Bin Retention**](https://help.salesforce.com/s/articleView?id=000387160&type=1) to stretch that window to 30 days. You can enable it by contacting Salesforce Support to activate the feature, or in some orgs by going to Setup &gt; User Interface and checking “Enable Extended Recycle Bin Retention.” This doesn’t help after records are already gone, but if you’re reading this before disaster strikes, it’s worth enabling now — doubling your recovery window costs nothing.

There are actually two layers to the Recycle Bin. Individual users can access their own deleted records. Admins can access the organization-wide Recycle Bin, which shows everything deleted by any user in the org. Navigate to the App Launcher, search for “Recycle Bin,” set the view to “All Recycle Bin” if you’re an admin, and start searching for your missing records.

A few things to know about the Recycle Bin that aren’t immediately obvious:

The Recycle Bin has a storage cap — it can hold up to 25 times your org’s [data storage allocation](/blog/effective-data-storage-in-salesforce-for-every-business-size) in records. So if your org has 1 GB of data storage, the Recycle Bin can hold up to 25,000 records. If the bin fills up beyond that, the oldest records get purged first.

If a parent record was deleted and it cascade-deleted its child records, you only need to restore the parent. Salesforce will automatically restore the related children along with it. So if someone deleted an Account and its Contacts disappeared, find and restore the Account first — the Contacts should come back too.

And critically: if someone used the “Hard Delete” option in Data Loader, those records bypassed the Recycle Bin entirely. They won’t be there. Same thing if a user manually emptied their Recycle Bin after deleting records — once purged, the Recycle Bin can’t help you.

## **Option 2: The Recycle Bin, But With Data Loader (For Bulk Recovery)**

If you need to restore a handful of records, clicking “Undelete” in the Recycle Bin interface works fine. But if someone deleted 10,000 Leads, you’re not going to do that one at a time.

This is where Data Loader becomes your friend. Here’s the process:

Open Data Loader and log in with admin credentials (you’ll need API Enabled and Modify All Data permissions). Choose “Export All” — this is different from a regular export because it includes deleted records that are still in the Recycle Bin. Run a SOQL query against the object you want to recover, filtering for deleted records. The query looks something like: SELECT Id, Name FROM Lead WHERE IsDeleted = TRUE. Export the results to a CSV file, review it to make sure you’re restoring the right records, and then use Data Loader’s “Undelete” operation to restore them in bulk.

You can also do this through Workbench if you prefer a browser-based tool — just enable the “Include Deleted and Archived Records” checkbox when running your SOQL query.

The important thing to understand here is that **the Undelete operation preserves the original record IDs**. The records come back exactly as they were, with their relationships intact. This is a huge advantage over re-creating records from scratch, which assigns new IDs and breaks all the existing links between objects.

One more thing: even after records are purged from the individual user’s Recycle Bin, they may still be accessible through the API for a short time before Salesforce completes the permanent purge. So even if a user says they “emptied the recycle bin,” it’s worth running that Data Loader Export All query to check.

## **Option 3: Check Your Data Exports**

This isn’t technically “without a backup,” but you might have a backup you’ve forgotten about. Salesforce’s built-in Data Export Service lets admins schedule weekly or monthly [data exports to CSV files](/blog/how-to-get-salesforce-data-into-csv-or-excel-files). The files are available for download for 48 hours after they’re generated.

Go to Setup &gt; Data &gt; Data Export and check if anyone in your org has been running scheduled exports. If you’re lucky, there’s a recent export sitting there that contains the records you need. Even if the export doesn’t have everything, partial data recovery is better than no data recovery.

The catch: if the export was generated before the deletion happened and you downloaded it, great — you can use Data Loader to re-import the records from those CSV files. If nobody downloaded the export within 48 hours, the files are gone and can’t be recovered.

Also worth checking: does anyone on the team have an old data export sitting in their Downloads folder? It sounds silly, but you’d be surprised how often this is the thing that saves the day.

## **Option 4: Check Your Sandboxes**

Here’s another source of data that people often overlook. If your org has a Full Copy Sandbox that was recently refreshed, it contains a snapshot of your production data at the time of the refresh. If the records you lost existed when the sandbox was created, they’re still in there.

To recover data from a sandbox, log into the sandbox environment, use Data Loader or a report to export the records you need, then import them back into your production org. Just keep in mind that since these records will be inserted as new records, they’ll get new Salesforce IDs. You’ll need to carefully manage the relationships between parent and child records — import parents first, get their new IDs, update the child records’ lookup fields, then import the children.

Partial Copy and Developer sandboxes don’t include all your data, so they’re less helpful here, but it’s still worth checking if they have any of the records you’re missing.

## **Option 5: Reconstruct From Related Records and Field History**

When all else fails, sometimes you can piece together lost data from what’s still in Salesforce. This is tedious and imperfect, but it’s better than nothing.

Field History Tracking, if it was enabled on the affected objects before the deletion, keeps a log of changes to tracked fields. While it won’t give you complete records, it can help you reconstruct field values. Check Setup &gt; Object Manager &gt; [Your Object] &gt; Fields &amp; Relationships &gt; Set History Tracking to see which fields were being tracked.

You can also look at related records that weren’t cascade-deleted along with the Contact. Cases are a good example. Cases have a lookup relationship to Contact rather than a cascade-delete relationship, so when a Contact is deleted, related Cases survive (the ContactId field just goes blank).

Those Cases often contain the contact name, email address, phone number, and account context you need to rebuild the Contact record. Account records, Opportunities the Contact was associated with through Opportunity Contact Roles, and any custom objects with non-cascading lookups to Contact are also worth checking.

## **Option 6: Salesforce Support (The Expensive Last Resort)**

Salesforce’s Data Recovery Service has had a complicated history. It was retired in July 2020, brought back briefly in March 2021, and then re-retired in November 2021 in favor of Salesforce’s own Backup and Restore product. But even when it was available, it was never a great option — it cost $10,000 per recovery, took 6-8 weeks, didn’t guarantee 100% data recovery, and delivered data as raw CSV files that you had to manually re-import.

As of today, the official guidance from Salesforce is to use either their native Backup and Restore tool (a paid add-on), a partner solution from the AppExchange, or your own data export files. If you’re in a truly desperate situation, it’s still worth opening a case with Salesforce Support and explaining what happened. Depending on your edition and contract, they may be able to help — but set realistic expectations about cost, timeline, and completeness.

## **What You Can’t Recover**

Let’s be honest about the limits. Some types of data loss in Salesforce are effectively permanent if you don’t have a backup:

**Overwritten data** is the big one. The Recycle Bin only catches deletions. If someone ran a Data Loader update that overwrote field values across 50,000 records with incorrect data, those original values are gone unless you have field history tracking or a backup. There’s no “undo” for an update operation.

**Metadata changes** are trickier than they appear. Deleted custom fields don’t go to the Recycle Bin — instead, they move to a “Deleted Fields” section in Object Manager, where they remain recoverable for 15 days with all their data intact. After that 15-day window, the field definition and all data in that field are permanently erased. So if someone accidentally deletes a custom field, check Object Manager &gt; [Object Name] &gt; Fields &amp; Relationships &gt; Deleted Fields immediately. Other metadata like page layouts, Flows, and validation rules don’t have this grace period and generally can’t be recovered natively — you’d need to recreate them from scratch or restore from a metadata backup.

**Files and Attachments** that were hard-deleted are typically unrecoverable. The Recycle Bin does capture deleted files, but once purged, they’re gone.

**Records older than the retention window** are permanently purged. Once the default 15 days pass (or 30 days if you’ve enabled Extended Recycle Bin Retention) and the Recycle Bin has been cycled, there’s no native mechanism to get those records back.

## **How to Make Sure This Never Happens Again**

Now that you’ve survived (or are surviving) a data loss event, you’re probably more motivated than ever to prevent the next one. Here’s what to actually do:

**Turn on the Data Export Service today.** Right now. Go to Setup &gt; Data &gt; Data Export and schedule weekly exports. It’s free, it takes two minutes, and it creates a baseline backup that could save you in a future emergency. Yes, you have to manually download the files, and yes, it’s not a perfect solution — but it’s infinitely better than nothing.

**Enable Extended Recycle Bin Retention.** If your org has access to Salesforce Classic, enable the Extended Recycle Bin Retention feature to extend the retention window from 15 to 30 days. It’s a free setting that doubles your recovery window — there’s no reason not to turn it on.

**Enable Field History Tracking on critical objects.** It won’t prevent data loss, but it gives you a paper trail that makes reconstruction possible. Focus on the objects that matter most — Accounts, Contacts, Opportunities, Cases — and track the fields that would be hardest to rebuild.

**Review permissions regularly.** Not every user needs the ability to mass-delete records. Restrict delete access through profiles and permission sets, especially for standard users. Require approval processes for bulk operations. The fewer people who can cause large-scale damage, the lower your risk. Understanding [how profiles and permissions work](/blog/sf-admin-1-year-blog-post) is essential for any admin managing data security.

**Audit your automations.** Flows, triggers, and integrations are the most common sources of accidental bulk data modification. Before deploying any automation that touches records at scale, test it thoroughly in a sandbox. And document what each automation does — when things go wrong, you need to diagnose the cause fast.

**Set up a real backup solution.** The native Data Export Service is a start, but it has real gaps — no metadata coverage, no automated restore, no incremental backups. The Salesforce ecosystem has plenty of options at every price point. Salesforce itself signaled just how critical this space is when it signed a definitive agreement to acquire Own Company for $1.9 billion in September 2024. Whether you go with an enterprise-grade platform or a [simpler, more affordable solution](/products/dbsaver), the point is to have something in place before the next incident.

**If you’re running bulk operations, back up first.** About to [merge a bunch of duplicate records](/blog/the-hidden-costs-of-duplicates-in-salesforce)? Running a large data migration? Doing a major cleanup? Take a manual backup of the affected objects before you start. A quick Data Loader export takes minutes and could save you days of recovery work.

## **The Bottom Line**

Salesforce data recovery without a backup is possible in some scenarios, but it’s never easy, it’s never complete, and it’s always stressful. The Recycle Bin covers simple deletions within a 15-day window (or 30 days with Extended Retention enabled). Data Loader can bulk-restore soft-deleted records. Old exports, sandboxes, and related records can help you reconstruct what’s been lost. But for overwrites, metadata deletions, and anything outside that retention period, you’re largely out of luck without an external backup.

The best time to set up a backup was before the deletion happened. The second best time is right after you’ve finished recovering from this one.


It happens to every Salesforce admin eventually. Maybe a user ran a…

salesforce-data-recovery-without-a-backup-what-your-options-actually-are-after-accidental-deletion

Salesforce Data Recovery Without a Backup: What Your Options Actually Are After Accidental Deletion

cloudanswers

CloudAnswers

If you’ve been managing Salesforce long enough, you’ve had “the moment.” Maybe it was a mass import that went sideways. Maybe a departing employee deleted a few too many records on their way out. Or maybe it was something quieter—a misconfigured automation silently overwriting critical field values for weeks before anyone noticed.

Whatever the scenario, the sinking feeling is the same: *do we have a backup?*

For too many organizations, the honest answer is still “not really.” And that’s a bigger problem than most admins want to admit. [53% of organizations](https://crmninjas.io/salesforce-data-loss-think-again/) using SaaS applications reported suffering from lost or corrupted data within the past **year**! Meanwhile, [roughly 60% of Salesforce users](https://expertinsights.com/backup-and-recovery/saas-backup-recovery-2025-stats) are running their CRM without any third-party backup.

Today, we’re doing something about it. We’re officially launching [DBSAVER](https://dbsaver.com/?utm_source=cloudanswers_website&utm_medium=blog&utm_campaign=announcing_dbsaver)—a simple, fast, and affordable Salesforce backup solution—to the public.

## **We’ve Been Using This Internally for Over a Decade**

Here’s the thing: DBSAVER isn’t new to us. At CloudAnswers, we’ve been using this backup solution for our consulting clients for more than ten years. When you’re a Salesforce consulting partner managing multiple orgs—running data migrations, deploying complex automations, [merging duplicate records](/blog/say-goodbye-to-salesforce-duplicates-with-cloudanswers-potential-duplicates-bulk-merge?utm_source=cloudanswers_website&utm_medium=blog&utm_campaign=announcing_dbsaver)—you learn pretty quickly that having a reliable backup isn’t optional. It’s the safety net that lets you move fast without losing sleep.

Over the years, we refined the tool to do exactly what we needed: back up data frequently, store it securely, and make it easy to find and extract when something went wrong. Nothing more, nothing less.

We recently decided it was time to open it up to everyone. If you’ve been using our [Potential Duplicates &amp; Bulk Merge](/blog/eliminate-duplicates-fast-with-bulk-merge?utm_source=cloudanswers_website&utm_medium=blog&utm_campaign=announcing_dbsaver) app, you may have already seen the DBSAVER recommendation pop up when running bulk merges. Now you can try it yourself.

## **Why Most Backup Solutions Are Overkill (and Overpriced)**

Let’s be honest about how most Salesforce orgs actually use backup: they don’t. Not because admins don’t care about data protection—they absolutely do. It’s because the existing options either cost too much, do too much, or require too much effort to justify.

The Salesforce backup market has exploded in recent years. Salesforce itself signaled just how important this space is when it [acquired Own Company (formerly OwnBackup) for $1.9 billion](https://techcrunch.com/2024/09/05/salesforce-acquires-data-management-firm-own-for-1-9b-in-cash/) in late 2024. That’s a massive bet on data protection—and it tells you something about how underserved this market has been.

But here’s the disconnect: enterprise-grade solutions like OwnBackup, Spanning, and Odaseva are built for large organizations with complex compliance requirements, sandbox seeding needs, and metadata versioning workflows. They’re powerful tools. They’re also priced per user, which means costs scale with your headcount rather than your actual data volume. For a 100-user org at $3 per user per month, you’re looking at $3,600 per year—for backup you’ll hopefully never need to use.

Most companies don’t need all of that. They need a copy of their data in case something goes wrong, and they need the ability to get it back. That’s it.

## **What DBSAVER Actually Does**

DBSAVER does exactly what its name suggests: [it saves your database](https://help.cloudanswers.com/en/articles/13064951-how-db-saver-works).

After you [sign up at dbsaver.com](https://dbsaver.com/?utm_source=cloudanswers_website&utm_medium=blog&utm_campaign=announcing_dbsaver) and connect your Salesforce org via OAuth (which takes about two minutes), DBSAVER starts running daily automated backups. It queries all your tables and stores the data securely on our infrastructure. At any point, you can search through your backed-up data and download whatever you need to restore.

That’s the whole pitch. No complex configuration. No week-long implementation. No dedicated admin required to manage it.

Here’s what you get:

- **Daily automated backups.** Set it and forget it. DBSAVER runs in the background, capturing your data every day so your recovery point is never more than 24 hours old.
- **Powerful search.** Need to find a specific record from three months ago? Search across all your backup data instantly instead of digging through CSV exports.
- **Team collaboration.** Organize your team into vaults with role-based access controls. Not everyone needs access to everything, and DBSAVER makes it easy to manage who sees what.
- **Enterprise security.** Bank-level encryption and granular access controls protect your data at rest and in transit.
- **No per-user pricing.** This is the big one. DBSAVER costs $100 per month for 400GB of backup storage, with additional storage at just $0.25 per gigabyte. That’s it. Whether you have 10 users or 500, the price stays the same.

## **The Math Speaks for Itself**

Let’s put the cost savings in perspective. Traditional Salesforce backup solutions typically charge between $2 and $5 per user per month. For a mid-sized org with 200 Salesforce users, that works out to somewhere between $4,800 and $12,000 per year.

DBSAVER? $100 per month on the monthly plan, or $1,000 per year on the annual plan. That’s up to 90% less than what you’d pay for a per-user solution—and you’re not sacrificing the core functionality you actually need.

Here’s a quick comparison:

|  | **Per-User Solution (200 users)** | **DBSAVER** |
| --- | --- | --- |
| Annual Cost | $4,800–$12,000 | $1,000–$1,200 |
| Pricing Model | Per user/month | Flat rate for up to 400 GB |
| Daily Backups | ✓ | ✓ |
| Search &amp; Recovery | ✓ | ✓ |
| Team Management | Varies | ✓ |
| Setup Time | Days to weeks | Minutes |

For organizations watching their budgets—especially nonprofits, startups, and small- to mid-sized businesses—this is a game-changer. You shouldn’t have to choose between protecting your data and staying within budget.

## **Who Should Use DBSAVER?**

DBSAVER is built for organizations that want dependable Salesforce backup without the enterprise price tag or complexity. That includes:

- **Small and mid-sized businesses** that know they need backup but can’t justify spending $5,000+ per year on a solution they’ll rarely use.
- **Nonprofits and educational institutions** operating on tight budgets where every dollar matters. You need data protection just as much as a Fortune 500 company—maybe more, since you likely can’t afford a data disaster.
- **Salesforce consultants and partners** managing multiple client orgs who need a cost-effective way to protect client data during migrations, deployments, and ongoing management.
- **Any organization currently relying on manual exports.** If your “backup strategy” involves someone remembering to run a weekly data export from Salesforce and saving CSVs to a shared drive, you already know that’s not sustainable.

## **Isn’t Salesforce in the Cloud? Isn’t My Data Already Safe?**

This is the most common misconception in the Salesforce ecosystem. Yes, Salesforce runs in the cloud. Yes, Salesforce has robust infrastructure protections. But Salesforce’s own documentation makes it clear that protecting your data is your responsibility.

Salesforce protects against *their* failures—platform outages, hardware issues, and infrastructure-level disasters. They do not protect against *your* failures—accidental deletions, bad data imports, automation errors, or malicious actions by users with admin access.

Think of it this way: your bank protects its vault, but if you accidentally shred your own documents, that’s on you. Salesforce works the same way. The [shared responsibility model](/blog/why-you-should-sync-salesforce-to-an-external-database?utm_source=cloudanswers_website&utm_medium=blog&utm_campaign=announcing_dbsaver) means you need your own backup strategy, period.

## **Getting Started Takes Two Minutes**

We designed DBSAVER to be as simple as possible to set up:

1. **Sign up** at[dbsaver.com](https://dbsaver.com/?utm_source=cloudanswers_website&utm_medium=blog&utm_campaign=announcing_dbsaver).
2. **Create a vault** to connect orgs and store data.
3. **Connect your Salesforce org** using OAuth—no API keys to manage, no packages to install.
4. **That’s it.** DBSAVER starts backing up your data automatically.

If you ever want to stop using DBSAVER, you can turn off the sync for your vault or delete the org or vault entirely to remove the data. No contracts, no lock-in.

We also offer a free trial so you can see exactly how it works before committing. Give it a spin and see for yourself.

## **What’s Next**

DBSAVER is just getting started. We’re already protecting over 1.5 terabytes of data across 341 organizations, with more than 1.3 billion rows backed up and counting. As we grow, we’ll continue adding features based on what our users actually need—not feature bloat designed to justify enterprise pricing.

If you’re already a CloudAnswers user—whether you’re using [Potential Duplicates](/blog/say-goodbye-to-salesforce-duplicates-with-cloudanswers-potential-duplicates-bulk-merge?utm_source=cloudanswers_website&utm_medium=blog&utm_campaign=announcing_dbsaver),[Report Sender](/blog/report-sender-version-2-a-major-upgrade-for-salesforce-users), or any of our other [AppExchange apps](/blog/introducing-app-reviews)—DBSAVER fits right into your toolkit. And if you’re new to CloudAnswers, welcome. We’ve been building practical Salesforce solutions since 2008, and DBSAVER is the latest example of what happens when you focus on solving real problems simply.

[Get started with DBSAVER today →](https://dbsaver.com/?utm_source=cloudanswers_website&utm_medium=blog&utm_campaign=announcing_dbsaver)

Have questions? Reach out to us at [cloudanswers.com/contact](/contact). We’d love to hear from you.


Many organizations face data loss in Salesforce, often due to lacking reliable backups. To address this, CloudAnswers has launched DBSAVER, a cost-effective bac

announcing-dbsaver-simple-affordable-salesforce-backup

Announcing DBSAVER: Simple, Affordable Salesforce Backup

Salesforce apps, powerful components, development and consulting. Our experienced team helps you to create and modify workflow processes in salesforce.

Data Recovery

Salesforce Data Recovery Without a Backup: What Your Options Actually Are After Accidental Deletion

Announcing DBSAVER: Simple, Affordable Salesforce Backup

Partners

Company

Get in touch