This is part four of a five-part series on methods for backing up your Salesforce data.
Of the four types of Salesforce sandboxes, full sandboxes most closely resemble the real deal- your live production org. Since full sandboxes are a replica of the production org, including all data such as object records and attachments, and metadata, they are ideal environments for performance testing, load testing, and staging.
In addition to these common use cases, full sandboxes are sometimes used as a data backup solution. One reason for this is that the full sandbox user interface (UI) is identical to your production UI, making it easy to search, report, and view the records as they were at the time of “backup” (refresh). In addition, since the full sandbox is an exact replica of your production environment, your “backup” will contain all of the original fields, IDs and relationships intact.
But before you go backing up all of your Salesforce data in your full sandbox, there are some important factors you need to consider.
Why Your Full Sandbox Isn’t An Effective Backup Solution
According to Salesforce’s help page, a full sandbox should be used for support performance testing, load testing, and staging. It’s also recommended that your sandbox only include the records and Chatter data needed for testing and development, rather than your entire production environment. This will help speed up the refresh time of your sandbox.
Despite this guidance, some Salesforce customers still consider full sandboxes to be a backup and recovery solution. Remember though, if you’re modifying the data and the metadata in your full sandbox, then it’s not a real backup.
More reasons to not use a full sandbox as a backup:
- It can only be refreshed every 29 days. Anything created in the last 30 days has not been backed up.
- The larger the Org, the longer it will take Salesforce to create or refresh the sandbox. Once you submit a sandbox for Create/Refresh, it goes into a queue. Depending on how long the queue is on any given day, it could take anywhere from a couple of days to a week to refresh the sandbox.
- Refreshes need to be submitted manually; and once you refresh a sandbox, the old version is gone. This means that you don’t have any historical backups beyond the last full sandbox refresh.
- Restoring data back to your production environment, while maintaining relational integrity, will be a challenge. A restore using this method will involve manual export and import of data.
- You will not be able to restore your metadata. If you’re lucky, the version of your metadata that you would like to restore will still be in your latest full sandbox version. Then, you’ll know exactly how to manually recreate those settings in your production environment.
- It can be very difficult to identify a data loss because you don’t really have any compare or discovery tools. Everything is just there as it was before.
Eliminate Data Downtime with Own
Don’t back up your data in an environment meant for testing data. Instead, use a solution that will help allow you to automatically back up your data multiple times per day and easily recover lost or corrupted data with a few clicks.
With Own Recover, you can schedule full org backups, including metadata. And recovering your data is just as simple. Find and isolate the deleted or corrupted data, restore parent/child relationships, and restore only the corrupted data, leaving everything else intact.
.png){kind=logo}
