CopyStorm/Restore allows you to incrementally restore records to a Salesforce sandbox. This article will show you how.
If you do not want to know how CopyStorm/Restore works, this is the only section you need to read. The instructions are:
- Open the configuration file used by CopyStorm/Restore during the original restore.
- Go to the Restore Set Editor tab and modify or add rules that control which records should be restored.
- Go to the Restore tab and click on the “Re-scan Candidates” button.
- CopyStorm/Restore will re-process the restore rules and look for additional candidates to restore.
- Click on the “Resume Restore” button.
- Records previously restored will be skipped.
- New candidates will be restored.
That’s it! You can repeat this recipe as often as you like to add new records to Salesforce.
CopyStorm/Restore keeps track of what needs to be restored and what has already been restored in a local H2 database.
- The name of the database is found on the Global Parameters tab in the “Tracker Database Name” field.
- The default name is generated by the application and unique to the configuration file.
- It can be changed to any name desired.
- The H2 database is stored in the directory:
- The H2 database tracks the mapping of a record’s ID in the CopyStorm backup to the unique ID assigned by Salesforce while restoring.
The first step of any restore is to scan the CopyStorm backup database for records matching the rules in the Restore Set. As candidates are found new records are created in the CopyStorm/Restore tracking database.
The second restore step involves:
- Finding all records in the tracking database that have not been restored.
- Restoring records and recording their corresponding Salesforce Ids in the tracker database.
- If the restore modified a Salesforce record, the Id will be the same as the tracker Id.
- If the restore added a new record to Salesforce, the restored Id and tracker Ids will be different.
Clicking on the “Re-scan Candidates” button causes CopyStorm/Restore to look for new restore candidates and put them into the tracker database.
The tricky part of this process is figuring out which records to restore and the order in which to restore them — a fundamental graph theory problem that our CTO is happy to talk about any time over a beer.