3 modern ways to back up your Salesforce sandbox before refreshing it (in 2023)

The other day I enjoyed this interesting thread from Andrew Pelc about how he could retrieve an old sandbox after refreshing it by logging a case with Salesforce support.

💡
Remember! Refreshing a sandbox is a 2 step process. 1) your sandbox is deleted, and 2) a new version is created from.

Your old version will cease to exist permanently, and your work-in-progress will be gone. Yes, gone!

This prompted me to search what ways one can back up their sandbox before refreshing it, and I was shocked that the few answers online refer to 3 methods, all of which are old as S-controls (sorry if you didn't get that reference; you are not that old in the ecosystem 😉).

So I decided to document 3 modern ways to back up your Salesforce sandbox before you wipe it out with a refresh.


Sponsored by Salto

CPQ Deployments, CI/CD, Impact analysis, and more

30-day free trial here

First way: Why?

Ok, this is not a way. But before jumping into backing up your sandbox, I recommend you pause and think, why am I in this situation? How come I have work in progress, and I need to refresh the sandbox? Why do I need to refresh it?

It could be that there are some new features that your colleagues deployed to production, and they never went into your sandbox. In this case, why not deploy those changes from production back into your sandbox? This is known as a back-promotion in Salesforce CI/CD terminology.

Another reason could be that you want your work-in-progress to be done in the latest release, so you want to refresh your sandbox so that it falls on a release preview instance. If this is your scenario, remember you can also use the Apex Hammer Testing process to run your apex tests on both the current and next release and spot any issues.

If, after reviewing these 2 options, you decide you still want to back up your sandbox, then read on.

First way (the real one): Clone the sandbox

By far, the easiest way to back up your sandbox is to clone it. By cloning the sandbox, you create a new one with the exact same metadata as the current one.

Then, you can refresh your original sandbox.

After the original sandbox is refreshed, use a change set to move the changes from the cloned sandbox over to the original one.

Second way: Download a change set with sfdx

Another way to back up your Salesforce sandbox before refreshing it is to create an outbound change set and add all the changes you want to back up.

Once the change set is created, you can download its contents with sfdx (really).

Here's the command you need to run

sfdx force:source:retrieve -n [MyChangeSetName]

This is a good option if you are not interested in backing up the entire sandbox but just some metadata that is part of a project or feature you are working on.

Once the sandbox is refreshed, connect to it with sfdx, and run the following command to deploy the change set contents back to it

sfdx force:source:deploy -p [folder-where-changeset-was-retrieved]

Third way: Download the entire sandbox with sfdx

The third way is similar to the previous one, except here, we retrieve the entire metadata of your Sandbox.

I actually wrote an article about this recently, so I'll just point you to it

How to retrieve your entire Salesforce metadata with 2 commands
You can list and retrieve all the metadata in your org with 2 commands, perfect for uploading it to a Git repo and start practicing CI/CD

The gist is you only need to run this sfdx command

sfdx force source manifest create --fromorg [your org alias] --manifestname=allMetadata --outputdir manifest

That said, I got some feedback from the community that this command times out if your org is huge.  I also found that some of the metadata that is retrieved cannot be deployed back 🤷.

For this reason, I recommend options 1 and 2 first.

Fourth way (bonus): Use an appexchange app for metadata backup

The final way to back up your sandbox is to use an app from the Salesforce appexchange.

I'll use the example of Salto. When I connect my org to a Salto workspace, I can tell it to retrieve all the metadata in my org.

Once the metadata is here, I can refresh my sandbox and delete it if I want to. The metadata will remain in the workspace.

Salto workspace keeps all my org's metadata

Once I have my newly refreshed sandbox, I can connect it to the same Salto workspace and just click Deploy.

Everything that was in the original sandbox will be deployed to the new one.

This is a great option for admins or other users who are not too keen on using the Salesforce CLI and sfdx (options 2 and 3).

There are other apps in the appexchange that provide similar capabilities for metadata backup. The point of this section is to show that other options exist that may be easier for some folks.

That's it! Now go refresh your sandbox in peace!

Subscribe for exclusive Salesforce Engineering tips, expert DevOps content, and previews from my book 'Clean Apex Code' – by the creator of HappySoup.io!
fullstackdev@pro.com
Subscribe