Gearset's data backup jobs provide comprehensive data restore capability. |f any data is lost, corrupted, or otherwise changed in an org, you can easily use a snapshot from your backup job to restore that data to its previous state while maintaining the data relationships and your data structure.
Restoring metadata before you restore data
Records can only be restored correctly if the underlying metadata (configuration) between the backup snapshot and your org is consistent. If there have been significant changes to your org's metadata and data, we recommend you restore the metadata first, then the data. This will reduce the chances of unexpected data deployment errors.
You can see how to run a metadata restore from a data backup job here.
Want to restore a single record?
This article is aimed at those who want to restore large numbers of records in an org. If you only want to restore a single record or a small number of records, you may want to use the quick data restore option in Gearset. See how here.
Data restoration is done from the history of a data backup job. Here's the process:
View detailson the data backup job from which you want to restore.
Choose the date of the org snapshot from which you'd like to restore.
Verify the state of the snapshot data before you restore from it. To do this, click the
Once you've confirmed the snapshot data is in a suitable state, click on the row for the snapshot you'd like to restore from to expand it out.
Then click on
Restore snapshot datato restore to the same org, or click
Replicate snapshotto deploy the data to another org.
If you opted to replicate the snapshot, then confirm in the resulting dialog that you want to
Replicate the data, select the target org to which this data will be restored, and choose the date of the snapshot being used to restore from.
You'll now run through a data deployment in Gearset's data loader, with the source of the deployment being the snapshot from the data backup job and the target being the org to which you're restoring.
The steps to follow are listed below, but for more in-depth information about how the data loader works, see our support documents here.
9. In the column on the left side, select which objects you'd like to restore the records for by checking the box next to their name. You can search and filter for objects.
When a parent object is expanded, which you can do by clicking on it, Gearset checks for and lists any dependencies that can then be included within your data subset.
Gearset will then traverse the dependency graph to determine any further indirect dependencies necessary to deploy records from the selected objects.
For each object, you can enter optional filtering by field values to control exactly which records are restored. For example, if you want to restore a single specific record, you can filter by its Salesforce record ID as in the screenshot below.
10. Once you've chosen which objects you wish to restore, and set any field-level filtering, click
11. Choose how you want to match existing records, which related objects to include, and then customize their field mapping for upserting.
12. Choose whether or not you'd like the data deployment to continue if it hits an error deploying a record.
If you choose to continue deploying remaining records, the remaining deployment steps will continue to execute if a deployment step fails, ignoring the errors encountered and deploying as many of the records as possible.
Or, if you want the deployment to stop in the event of an execution step error, select the
Stop deploying remaining records option.
NEXT to move to the pre-deployment summary.
Gearset will create and list out the steps we’re about to take in your data deployment.
You'll be able to see the object records to be deployed and the actions Gearset will take to retrieve them, such as fetching, including, creating, and upserting, as well as the field count and any applied filters.
14. Click on
DEPLOY DATA to deploy the selected data to the target org.
When the deployment is running, each stage will mark as completed and show you how many records have been processed in each step.
Once it has completed, the deployment will be stored in your data deployment history in the app.
Learn more about data deployment history here.
15. Verify that the records have been restored to your org as expected.
Restore Audit fields
By default, when restoring deleted records originally created many months ago, the Created Date and Last Modified Date on the restored records will be set to the date of the deployment. This could be problematic where users build reports analyzing data by Created Date.
However, if the "Create Audit Fields" permission is enabled in the target org, and the user performing the restore has this permission, then inserting the Created Date and Last Modified Date should be possible.
Note: With these permissions, users can fill audit fields on record creation only through API tools. Future edits (updates) cannot be made.