Why Salesforce backup and restore tools belong with DevOps

David Runciman on

Share with


Over the last few years, Salesforce teams have become increasingly aware of their need for a backup solution. Now that Salesforce has unveiled Backup & Restore, it’s clear just how seriously users should take disaster recovery on the platform.

While the announcement of Salesforce Backup & Restore has prompted many teams to think again about their vulnerability to data loss, in this post we’ll explain why adopting a platform-native, standalone backup solution runs counter to basic backup principles and DevOps best practices.

The necessity of backup and restore tools for Salesforce

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.

A developer worried by data loss

Those ideas are quickly being eroded by the truth that data loss happens all the time, and there’s no automatic solution to the problem. Many teams have learned this the hard way: through experience. Thankfully, many others have learned from vendors of backup solutions in the ecosystem, and Salesforce itself has consistently warned businesses to back up their orgs.

Salesforce’s recent release of Backup & Restore brings another option to the table for businesses wanting to safeguard their business data and all their customizations on the platform. This is a welcome development. Other platform-native tools, such as Data Export, have serious limitations that make them a poor choice for businesses. And by Salesforce’s own assessment, its Data Recovery Service shouldn’t be treated as a backup solution.

The arrival of Backup & Restore is an unmissable signal to Salesforce users that backups are essential, and that you must have a viable strategy for restoring data if your backups are to have any real value. Avoiding the cost of data loss, as well as the cost of downtime, is essential for every business using the Salesforce platform.

Problems with a native, standalone backup solution

Salesforce’s launch of Backup & Restore has opened up the conversation and got people thinking about their readiness for data loss incidents or even a disaster scenario. But there are two good reasons why businesses continue to choose other solutions.

1. A native backup solution is an unnecessary risk

There are significant drawbacks to using a backup solution built within the platform you’re backing up. 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.

2. Standalone backup solutions slow down recovery times

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

To illustrate this problem, picture 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 feature 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.

Backups are 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. That’s 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, of which the most important are:

  • Data access. You can safely access your backup data at any time, even during a Salesforce outage. The backup data is stored in the same AWS data centers trusted by Salesforce, but on separate servers with a separate point of access.
  • An integrated process. Your backup and release processes are tightly integrated and all controlled from the same UI. Team members can run backups 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.

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.

The missing piece of a jigsaw puzzle

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 process that brings everything together. Book a demo of Gearset to find out how you can get backup with all the power of DevOps.

Ready to get started with Gearset?