This is part four of a five-part series on methods for backing up your Salesforce data.
Full sandboxes are a copy of your entire live Salesforce environment, including all its data and metadata. Some companies use this as an ad-hoc backup solution before major data alterations or app integrations.
Some advantages to using your full sandbox as a backup solution include:
- The UI is identical to Salesforce and is very easy to search, report, and view the records as they were at the time of “backup” (refresh).
- It’s an exact replica, with all the original audit fields, IDs, and relationships intact.
- It can be refreshed with a click of a button.
Full sandbox is not available in all editions of Salesforce – Only the Performance and Unlimited editions.
According to Salesforce’s help page, a full sandbox should be used for support performance testing, load testing, and staging. It’s 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.
Full sandboxes are typically used for development testing and training (not backup), yet some Salesforce customers consider it to be a backup and recovery solution. This is a bad approach. If you’re modifying the data and the metadata in your full sandbox, then it’s not a real backup. Companies who think that this is a real data backup strategy are just lying to themselves.
Here’s why your full sandbox is not a good backup strategy:
- 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.
Don’t backup your data in an environment meant for testing data. Use a solution that will help allow you backup your data multiple times per day and easily recover lost or corrupted data with a few clicks. With Own, you can schedule full Org backups, including metadata. Recovering your data is just as simple. Find and isolate the deleted/corrupted data, restore parent/child relationships, and restore only the corrupted data, leaving everything else intact
Next: Read Part Five: Backing Up Your Data Using Salesforce APIs
