Which backup tool to use for Salesforce

Which backup tool to use for Salesforce

David Runciman on

Share with


Over the last few years, Salesforce teams have become increasingly aware of their need for a backup solution. But what are your Salesforce backup options? Which tools should you rely on for this all-important task? And what’s the best approach to backing up your orgs? In this article, we’ll see why most businesses look for a third-party solution, and why a growing number are integrating backups with their wider DevOps process.

Backups are needed for Salesforce — but not all backup tools are equal

In the past, far fewer businesses backed up their Salesforce orgs. Business-critical data and years’ worth of org customizations, stored as metadata, were at risk of being lost with no way to restore them quickly or reliably. Nebulous notions about data automatically being secure ‘in the cloud’ were common, and most businesses assumed Salesforce would be able to bail them out in a worst-case scenario.

Those ideas are quickly being eroded. Data loss happens all the time, as most teams have learned from first-hand experience. Disaster recovery plans are essential. Most businesses now have a plan to protect their Salesforce orgs, and are implementing disaster recovery testing.

Salesforce itself has consistently warned businesses to back up their orgs. But the native backup and restore tools on Salesforce are limited in various ways, whether you’re extracting data and metadata to create backups, or trying to restore data and metadata from backups.

Gearset DevOps Summit: Developing a long-term Salesforce DevOps mindset

Find out more

Salesforce Backup & Restore

Backup & Restore is the closest Salesforce has to a full backup solution, in that it helps you both back up and restore data. It’s a relatively new product, being launched in 2021, and seems to have had a bit of a bumpy start — Salesforce even stopped advertising it for a while.

So what are the limitations of Salesforce Backup and Restore? As well as teething issues and limited functionality, the broader problem for Backup & Restore is that having a platform-native backup solution runs counter to basic backup principles.

Of course, Salesforce segregates the storage of backup data from production data. But your point of access is the same: the Salesforce platform. If you think about the equivalent in terms of hard copy files, it’s like locking the backup copies in a different drawer of the same filing cabinet where the originals are being kept.

Using a native backup solution means you can’t access your backups during a Salesforce outage. And it means a malicious actor with access to the data in your org can more easily access your backup data as well.

Data Recovery Service

If your business has no backups in place at all, Salesforce’s Data Recovery Service is a last resort. Salesforce itself doesn’t want any customers to use this service — it even retired the service for a while. For $10,000, Salesforce will provide a CSV of whatever data it can salvage for you. The quality of that data can’t be guaranteed, and it typically takes 6–8 weeks to arrive; that’s 6–8 weeks before you’ve begun to restore anything…

Data Export

Some teams use Salesforce’s Data Export tool to export backup data. The advantage of Data Export is that you can schedule automated exports, so it’s a definite step-up from backing up manually or not at all. But you can back up once per week at most, when most businesses expect to back up daily at least.

Data Export just extracts data. Storing that data securely, paying for rapidly expanding storage needs, and ensuring compliance all rests with your team. It’s also critical to choose a backup process that works for restoring. Data Export just downloads data as a CSV file, and it’s a pretty error-prone job to restore using CSVs.

Data Loader

Data Loader can help you export and upload records. It’s not designed to be used as a backup and restore solution, but in theory it can be used to back up and restore data. In practice, it’s a very manual backup process, so easily forgotten. And it comes with all the problems of Data Export: you’re still working with CSVs.

Sandbox Refresh

If your business has a full sandbox, it may be tempting to treat the sandbox as a complete backup of your production org, since it replicates your data and metadata. Teams may think they can use Data Loader and Change Sets to migrate any lost or corrupted data and metadata in production from the sandbox environment. Salesforce’s Sandbox Refresh makes sure everything is in sync and up to date.

But this approach is deeply problematic for all sorts of reasons. Salesforce environments aren’t a stable environment for storing data and metadata: org updates and ongoing development mean change is constant. What’s more, Salesforce’s Sandbox Refresh process comes with a set of limitations that make it unsuitable for backing up.

Salesforce APIs

Salesforce has a number of APIs that can be used to migrate data and metadata, including for backup and restore purposes. The Salesforce CLI, released as part of Salesforce DX, is an option for developers who want to manually back up using Salesforce APIs, or build a process from scratch by chaining tools. Third-party tools also use Salesforce’s APIs to offer powerful solutions that work out of the box.

Most businesses choose a third-party solution for Salesforce backups

The data backup methods native to Salesforce aren’t used by businesses that want to prepare seriously for disaster recovery. Third-party backup solutions are the most popular choice for companies using Salesforce, because they allow Salesforce teams to create a viable backup and restore process that fulfills the requirements of their Salesforce data backup policy or business continuity plan.

There are many reasons why businesses tend to choose a third-party backup solution, including:

  • Automated backups run at least daily, reducing the amount of time that passes where the latest data is unprotected
  • Data is stored securely outside of Salesforce’s infrastructure and can be accessed any time
  • Costs are predictable, in contrast to the ballooning expense of a DIY approach
  • Many solutions back up both data and at least some metadata
  • Recovery times are shorter as solutions are built to support restore processes
  • A wide range of extra functionality is often available, including for compliance

Single-purpose backup solutions slow down recovery times

Teams using a solution built only for backup and restore processes struggle to make it an integral part of their workflow and typically perform less well in a disaster recovery scenario.

Imagine a team that sets up an automated backup job using a standalone solution. They have peace of mind knowing their data and metadata is being backed up, but they rarely open their backup tool. While their data integrations or releases might pose a risk to the data and metadata in their org, the team rarely back up their org on demand.

The one or two members of the team with access to the backup tool occasionally restore small amounts of data and periodically test their restore processes. During a serious data loss incident, everything depends on those members of the team being there. Even for them, the restore tools don’t feel that familiar — their progress during disaster recovery is slowed down by needing to remind themselves how their restore tools work.

While all of this might seem like an inevitable problem, and just another reason to hope you never need your backup solution, it really doesn’t have to be this way.

An even better way: backups as part of DevOps

Treating backups as part of your DevOps process is the best possible way to improve your team’s performance, both in terms of release management and disaster recovery. This is why we built Gearset as a complete DevOps solution that includes comprehensive backup and restore tooling. Bringing everything together under one roof has several advantages, such as:

  • An integrated process. Your backup and release processes are tightly integrated and all controlled from the same UI. Creating backups for development teams to work with means they can back up on demand before a risky release or integration, ensuring that the latest data is secure if anything doesn’t go to plan.
  • Shorter time to recovery. Restoring Salesforce data and metadata is tricky. Using the deployment tools you use every day makes it easier and much faster to restore data and metadata from your backup to your org. And you can follow DevOps best practice by quickly restoring to a sandbox first, checking the restored data and metadata, then deploying to production.
  • Secure collaboration. Most of the time, access to backups will be limited to a select few people for security. But when the need arises, the team lead can bring other members of the development team into the recovery process by delegating permissions to restore data. There’s no need to worry about ramp-up time, because the tool is already familiar to the whole team. Breaking down silos of teams working on release and teams working on data security is the central idea of DevSecOps.

This approach to your tools and processes may well involve a change in mindset. The team best placed to manage backups for Salesforce is the Salesforce team, because they’re the ones who really understand the complexity of Salesforce data and metadata. And they should be the ones using a tool that can handle all of that complexity.

High-performing DevOps teams are also elite performers in terms of recovery times. Backups belong with deployments, automation, change monitoring, data management and testing as part of a complete DevOps process. Businesses are finding the best answer to disaster recovery in DevOps.

The future is Salesforce DevOps

As more and more Salesforce teams adopt DevOps to streamline and accelerate their releases, it’s a good time to assess which tools will support a complete DevOps workflow that effortlessly incorporates backups. DevOps is as much about security and robust ways of working as it is about working at pace. Backups are the foundation of a secure process that should also include version control, automated testing, close collaboration, monitoring and options for rollback.

If your team is still getting the lay of the land when it comes to DevOps, you’re in an ideal position to build a mature process with backups built in from the get go. Knowing your data and metadata is secure and recoverable frees up your team to innovate with confidence and adopt new ways of working that will soon take all the stress out of releases.

Complete your Salesforce DevOps toolkit

Whether you currently have a mature process for CI/CD but nothing in the way of backup, or a backup process that’s siloed away from your release management, look again at building a comprehensive DevOps and backup strategy that brings everything together. Book a demo of Gearset today or start a free 30-day trial.

And to get a complete overview of backing up Salesforce, download our free ebook Backups for Salesforce:

Try all of Gearset for free