Skip to main content

Replicating multiple records and their full data structure from a backup job

How to replicate snapshot data to another org or run a restore across multiple objects.

Written by Dario Messina
Updated today

This article walks through the data deployment flow launched from a backup job's Use snapshot option. It lets you pick objects, apply record-level filters, configure dependency traversal, and deploy to the same org (restore) or a different org (replicate), all while preserving record relationships and your data structure.

Looking to restore deleted records?

For most restore scenarios, including the common case of restoring a deleted parent record along with its child records, we recommend the Restore records with dependent objects flow. It guides you through selecting a base object and traversing its dependency tree, and suits the majority of restore use cases.

Want to restore a small amount of records?

This article is aimed at those who want to replicate and restore large numbers of records in an org. If you only want to restore a single record or a few records, you may want to use the quick data restore option in Gearset. See how here.

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.

Restoring data

Data restoration is done from the history of a data backup job. Here's the process:

  1. Click Job history on the data backup job from which you want to restore:

  2. Choose the date of the org snapshot from which you'd like to restore.

  3. Verify the state of the snapshot data before you restore from it. To do this, click the View details option.

  4. 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.

  5. Then click on Use snapshot.

  6. Click Restore snapshot data to restore to the same org, or click Replicate to deploy the data to another org:

  7. If you opted to replicate the snapshot, then select the target org to which this data will be restored, and choose the date of the snapshot being used to restore from:


  8. Click Replicate data.

    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, 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 have set any desired field-level filtering, click Next.

  11. Choose how you want to match existing records, which related objects to include, and then customize their field mapping for upserting.

    Note: You can either create new record, Upsert records or Update existing records.

  12. Choose whether 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:

  13. Click 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 when 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.

Gearset can now restore User Records. When going into the full restore route, users are now able to choose Upsert, Create and Update Existing as the options for deployment.

Did this answer your question?