Innovate without fear: unlock the hidden potential of backups

Share with

Description

Great DevOps means having the freedom to innovate. But even with CI/CD and quality gates, many teams hesitate to try something bold. When the cost of fixing breakages looms large, experimentation slows down and innovation stalls.

In this on-demand webinar, discover how integrated Salesforce backups give you the confidence to experiment, recover quickly, and keep releases moving. Senior Product Manager Aga Peryie shares real-world examples of teams using Gearset Backup to support faster, safer innovation.

You’ll learn how to:

  • Use pre- and post-deployment backups to see the impact of your release
  • Keep pipelines moving during high-stakes releases
  • Restore Salesforce metadata and data for complete recoverability
  • Build a culture where the team is confident to ship changes
  • Strengthen disaster recovery readiness and reduce RTO with backup fluency
  • Use backup insights alongside DevOps metrics to improve org health and performance

Whether you’re pushing a high-stakes deployment or running experiments in a full-copy sandbox, an integrated backup solution can work like version control for your metadata and data, helping you recover fast and innovate with confidence.

Further resources:

Transcript

Let's get started. Hi, everyone. Welcome again.

Thank you for joining our session on innovate without fear, unlock hidden potential of backups.

Today, we're going to look at how backups can go beyond being a safety net and how instead they can actively empower your teams to innovate faster with less risk and greater confidence.

But let's start with a short intro. So hi again. I'm your host, Aga Perry, and I'm a senior product manager here at Gearset. And I look after our backup and archiving solutions. And later on, you'll be hearing from my colleague, Maruf, from our customer success team who'll run for a practical demonstration of some of the concepts we discussed today.

By the way, if you do have any questions, please drop them in the q and a section, and we will do our best to answer them throughout the session. Or we might have time to answer them live also at the end.

And with all of that, let's get started.

So we all know, the pressure of moving fast in Salesforce and DevOps environments.

But every release, every change carries a risk. Your production data could be corrupted, metadata could misalign, or experiments might introduce unexpected behaviors in your lower environments and get completely out of sync with production.

So the stakes are high, and often the fear of breaking something slows us down.

And when we talk about fear here, what do we mean?

Well, sixty five percent of teams we spoke to as part of our state of Salesforce DevOps survey last year, which some of you might be familiar with, admitted that they've experienced a data loss incident in the previous year. But what is even more worrisome is that six percent were not even able to tell us whether they experienced one or not.

So think of this. Have you ever been in a situation where you didn't raise something? Sorry. So where you didn't realize something went wrong in production until your users came asking for help, and only then when you made when that made you look, you find out that a change you've introduced in a recent release, maybe even one a few weeks back, had a negative impact on your production data?

This is quite a common experience, and the lack of confidence around data impact is what causes a lot of fear in teams and especially release managers when they are about to push multiple changes into production.

So how do we keep innovating without that fear?

There are a lot of different things you can introduce to help here. But today, we will focus on the role of backups in your releases.

Traditionally, backups have been seen as an insurance policy.

Something you hope you never use and only look at in case of emergencies.

Modern DevOps, however, requires a different mindset.

Backups can be dynamic, actionable tools.

Instead of just being reactive, backups can be proactive.

Rather than than just focusing on recovery, backups give you insight, agility, and a foundation of confidence that allows teams to move faster.

So let's look at somehow at some of the ways certain Salesforce teams use backups.

Sterling from Granicus said, when something crazy gets deployed or we override something meaningful, I don't worry. I've got the latest data, so I can just restore.

And it's not just production that could be at risk.

By backing up your lower environments, like your UAT, backup helps you keep your pipelines moving.

Because of how painful a full copy sandbox refresh can be, the risk of breaking data and potentially stalling pipelines might stop you from running experiments or testing in high stakes environments.

We know Salesforce teams have to pause all development for long periods of time, anything between days or two or even four weeks, when refreshing their full copies.

And now imagine someone has changed the data in your UAT beyond usability, and your pipeline is broken.

If you have a backup for your UAT, you can fix it. Backups give you freedom to try bold things. Examples could be even applying emergency fixes or rolling out features under tight deadlines.

And we are all familiar with those. Right?

So backups are your safety net that lets you keep shipping without hesitation.

If something goes wrong, recovery is fast and the pipeline keeps moving.

So this ability to restore the different environments can go beyond just your daily backup. One of the most powerful uses of backups is creating snapshots before or even after deployments.

These snapshots let you compare exactly what changed, both in your data and your metadata.

Instead of waiting for users to report issues, you can immediately see the impact of your release. It transforms backups into intelligence tools, not just reactive measures.

So running a backup just before a deployment also ensures that any unwelcome changes can be reversed quickly, and the data change delta is kept to a minimum.

So stick around till the end of the webinar when Maroof will show you how to do this using Gearset.

Another customer, Chris from Sage, told us combining deployments and backups is a definite bonus. Having all those tools together just makes life so much easier for us. And you might ask, why would having both on the same platform matter?

Well, the twenty twenty five survey of Salesforce teams across the ecosystem revealed a strong strong correlation between performance metrics and tool stack size.

The more tools teams used across their DevOps lifecycle, the worse their performance against DORA metrics and other key indicators.

Teams with a consolidated tool stack also shipped fewer bugs, reported fewer metadata and data instance, and recovered faster no matter their size.

Teams with a unified DevOps process show a significantly higher return on investment for Salesforce, twice as much as teams with a split release process and almost ten times as much as teams with no agreed release process. And the impact of multiple tools is felt directly by you and your team when backups are involved.

Because it is you and your team who the business comes to when something goes wrong with Salesforce data or metadata, you need to piece together what actually happened, decide what to restore, and then run the recovery.

But to do that, imagine having to switch between two or three different systems to investigate further.

Maybe only some of your teammates have access to all of your tools, or even worse, the person who does have access is on vacation.

And maybe you and your team are unfamiliar with how the tooling works even once you're in.

Now think about how this would impact the speed of your restoration, how recovering production or even your UAT would end up slower than you'd like. Projects are put on hold. Your sales team and end users are losing valuable hours of productivity.

How long is the business prepared to wait? And how much a downtime like this will cost your business?

Now imagine how much more straightforward it would be if you are using a tool you are already familiar with day in and day out. You're already logged in and you follow the same deployment process you're used to. Recovery becomes second nature, fast, predictable, and consistent.

And it helps with defining clear RTOs, which is your recovery time objectives, because they which help the business know exactly how quickly systems will be back online after an incident.

And with robust integrated backups, those recovery times are predictable.

Your team and the wider business have confidence in the face of crisis.

And we mentioned earlier how important it is to know when something goes wrong. If your team isn't actively mon monitoring for unexpected changes to their data, incidents can go unnoticed for long periods of time.

However, you're backing up your data, monitoring for unusual changes is the best way to spot a data loss quickly.

The sooner you spot an error, the quicker it can be resolved and business operations can continue.

So good backup allows to keep an eye on your storage usage and unusual data changes. Thing, record deletions, updates, new records created. Anything that's more than what you'd expect to see on a daily basis. Anything that looks a little suspicious and will need investigating.

Maintaining data integrity is crucial, and monitoring helps identifying potential corruption early.

And this brings me to another often more hidden benefit of backups, which is the data they generate.

You can track how often recoveries happen, the types of issues that trigger them, and how quickly your teams resolve incidents.

Combine those insights with your DevOps metrics like Dora, think your deployment frequency, change failure rate, and mean time to recovery, and you get a richer picture of Salesforce org health and performance.

Strong release strategy that includes your backups allows you and your teams to have a continuous improvement loop.

But backup sorry. But data is not everything a backup should care about.

Heath from Cincinnati Works told us, a lot of tools can back up your data, but what's it going to look like when you restore it? That was when the light bulb went on.

And Heath is right. The recovery is just as important as the backup itself.

A good Salesforce backup needs to give you the ability to recover both your data and metadata because the two are deeply connected, and recovering just one without the other risks a broken and inconsistent environment.

Four, full recoverability means treating both as essential pieces to the puzzle so that your environment is truly back to a usable state after a recovery.

This is why a metadata aware backup strategy is more reliable than focusing on data alone.

And I'm not talking just about a handful of metadata types, but the full spectrum supported by the metadata API.

When you look closely, some of the tools on the market support only a fraction metadata types, and that can give you a fake sense of confidence.

When you can't recover all of your metadata easily using the same tools you use every day, then your data recovery will also be impacted.

This is not just about speed. This is also about reliability and full recoverability.

Alright. So we have the tool. We're familiar with it, and we can recover data and metadata.

And we know when something goes wrong, and that should be enough to feel confident. Right? Well, we're we're almost there.

It's important to remember that this is all more about about more than just technology.

This is about culture. And culture change doesn't happen fast, and it is more than just introducing a new solution.

It doesn't matter if you're running all these backups if your team doesn't really get the value of them.

Make sure you work with your team through a recovery drill. Maybe break something in the sandbox and show them how easy it is to restore it so that they know what to do if something goes wrong. It's best for the whole team to feel comfortable with your disaster recovery plan because when teams know when they can recover quickly and fully, they feel safe to ship changes faster and take calculated risks.

Backups create psychological safety. The assurance that even if something goes wrong, it won't be catastrophic.

That translates into more innovation, less hesitation, and better results for the business.

And I want to highlight here that this isn't about encouraging bugs or low quality deployments, but it is knowing that if you do fail, you do it fast, and you recover even faster.

Because backups help you see when a release goes wrong and helps you recover to keep your organization running.

In a previous webinar on why DevOps centric teams choose gearset, we spoke about this in a bit more detail with Nadim, who's a senior release engineer and one of our DevOps leaders.

Nadim shared his experience and how he sees the impact of backup. He said, you have resilience in your team when they are confident that if anything goes bad, they always have a time machine to go back and restore.

So if you'd like to watch catch up on this conversation, the QR code on the screen is what you can follow to go to the webinar, and you can all also share it with your colleagues. So I'll give you five seconds if anyone wants to scan it.

Cool.

Alright. So what do we want you to walk away with today?

First of all, backups are not just reactive insurance.

They are enablers of fearless innovation.

Use your pre and maybe even post deployment backups for visibility of changes and their impact. Strengthen your disaster recovery readiness and use backup insights alongside DevOps metrics like Dora to continuously improve.

And remember to protect both your metadata and data for full recoverability.

And finally, build a culture where shipping is safe and confident.

Remember, backup is so much more than just a tick box.

And you might think this all sounds great, but how do I get started? How can I start derisking my releases?

Well, we'd recommend that you start with auditing your current backup strategy.

Does your backup cover both data and metadata?

Add pre and, like I said, maybe even post deployment backups into your release workflows.

And if you're a customer of years that maybe it's an opportunity to get extra value from your high frequency backups, which focus on those top priority objects.

You should schedule your next disaster recovery drill. Don't wait for an incident to find out how your restore works.

The more familiar you and your team are with your recovery steps, the faster you will be on the day you need to do it. And Gearset customer success teams have been working with our customers to help put together disaster recovery plans. If you haven't gone over yours yet, please do reach out to us, and we'd love to help you with it.

Then you should also look at the metrics your backup data is already giving you.

Check recovery frequency, unusual data changes, and maybe even storage usage. Then decide what good looks like for you and your team and start setting benchmarks to improve against.

And make sure the rest of your team know the role that backups can play. Taking even one of these steps will bring you closer to a culture of innovation without fear.

And now my colleague, Maruf, will take you for a short demo how you can use Gearsight right now to implement some of these changes. Maruf, over to you.

Thank you very much, Aga. Just sent a request to share my screen, and, hopefully, you folks can see I guess that pipeline's here. Could you just confirm that's popped up?

It has. Yes. If you don't see it, it might be in, like, a different tab, but it is there.

Amazing. Thank you very much. Okay, folks. So let's set the scene. Today, I'm taking on the role of a release manager.

Getting a production release ready is one of the most critical parts of my day. I need to make sure that everything goes smoothly, but also I wanna make sure that I have a safety net in place in case anything does go wrong. So let's take a look at how gearset can give me the peace of mind and confidence ahead of my release.

So right here in my gearset pipelines, I can see all the open pull requests against my production environment alongside the release that I'm preparing at the moment.

Now in order for me to deploy this release, I need to make sure that all the pre deployment steps have been actioned.

If you take a closer look at some of my pre deployment steps here, you can see that I have some instructions to deactivate flows and, email delivery triggers. Now these steps will impact my metadata and how it will interact post deployment. But what about the impacts this release could have on my potential data? Now there's no way to deactivate unwanted changes to data, but being able to restore data should an unwanted change occur will certainly boost my confidence in this release. But in order for me to do so, I need to make sure that I have the most, most recent data backed up in my production environment. So I'm gonna go ahead and add this as a pre deployment step.

Just gonna pop a little note on here for myself to run a backup before the deployment.

You'll notice at the top of this page, Giza is showing me the last time this production environment's data was backed up. This was shortly after midnight this morning.

Now by clicking into this link here, I'll be taken to this backup jobs history.

You'll notice in the bottom right hand corner, I can see that this daily backup's next run is tomorrow morning at twelve AM.

It's now five twenty PM here in the UK, so that's a whole working day's worth of changes made by our end users, which I risk losing should this release have an impact. So I'm gonna go ahead and back up now.

Now as you can see while this backup is in progress, I have a log of all the previous backups for this environment.

This is showing me on a daily date on a daily basis the data difference from my previous backup, including what's new, what's been changed, and what's been deleted.

Earlier on, spoke about the importance of a metadata aware backup strategy. And here as part of my job's history, I can also track the changes to metadata over time.

Gear set will indicate in each backup run if, if the metadata is identical or if there are differences.

And when there are differences, Gear set will flag what's new, what's changed, and what's been deleted just as it did for the data.

We spoke earlier about how gear sets backup allows allows you to keep an eye on the storage usage. So by heading over to the data dashboard and selecting the org that I want to assess, I'm also I can see how much data how much of my, storage limits I've used and how that's changed over time.

I am also presented with a breakdown of the fastest growing objects over time. So if I'm to come across anything that I didn't expect to see here, going back to the backup job history can help me investigate further and stay on top of what's happening within my orgs.

So I'm gonna head back to the backup jobs history.

You'll see here that this job is still running. And how long a backup job will take to run can really depend on the size of the org. So what many of our customers do is utilize their high frequency, high frequency backups.

So the high frequency backup is a smaller backup containing up to ten object types. This will run much faster, but will still give me the added confidence ahead of the release.

Now I'm gonna go ahead and assume that this is completed and head back to my gear set pipeline.

Once this backup run has completed, what you'll see here is this will change to the most recent most recent backup.

And with that reassurance in mind and providing I've carried out all of these steps, I'm gonna go ahead and click ticked on all of my predeployment steps. And now I'm in a position to deploy this release with reassurance.

I know that I'm ready to deploy this release with the additional confidence that if any unwanted changes occur, I'm in a position to restore up to date data.

Thank you, Marv. That was great.

Great.

So that was everything, that we had prepared for you today. So thank you so much, everyone, for joining and engaging with the session.

So if you like what you heard here today and you would like to find out more, you can also scan this QR code, to book time with our wonderful team.

So thank you very much for your time today.