Yes, there is a metadata table that is populated that understands the parent-child relationships. The -recover command navigates those relationships, such that the product knows the parent objects must be restored before the children. Lookup relationships are restored before anything.

Yes, it would be naive to think otherwise. Restore has to be selective and thoughtful, otherwise you’d just be destroying current data with the backup.

There is a control field on every row of every table. For a full restore, you can set it to ‘R’ on the Account object and run a -recover command, which follows all the related records. This is the simplest case. You can also include or exclude specific fields, and reload objects in any order that you want, as long as you load the parent objects first.

We have example scripts used to condition the control flags in the records and handle the business logic in Salesforce, such as adding only one side of the SHARE relationship or excluding one of the Price, Total Amount, or Quantity fields in Opportunities and letting Salesforce calculate that other value. Salesforce is full of business rules, and some organizations create data validation rules, workflows or Apex triggers that limit the ability to simply copy data to Salesforce.

Salesforce is not like a single file where you can just set it back to yesterday’s version.  Anyone who promises a “one button restore” isn’t being realistic.

Yes, but it would be naive to think that it doesn’t require carefully though out decisions and preparations to make so the new records fit into the target org, such as

• Is the target org empty or does it contain existing users, products, and other slowly changing data? On professional service engagements, our team has used mapping tables to marry up the business keys in the source or with the target records by their Salesforce ID in the target org. Unique business keys are required to make this work smoothly.
• How do you want to detect and handle duplicates? If you are merging business units, how do you determine if you have a common customer and which record “wins” in that event?

Yes. For example, for a restore operation with 5 levels deep, restore some Accounts, with their related Cases containing Tasks that include Attachments, without losing all of the different Chatter feeds. The -recover command will determine all the object relationships, maintain pointer fields in the children after creating the parent record, defer circular relationships where necessary, and finally update the circular relationships. We have multiple patents awarded and pending on this process.

You can

• specify a small number of objects in the -set command (-set Account -set Contact -set Opportunity)
• create a list of objects in an upload.config.[name] control file and use a -setGlobal command, referencing that particular named file
• use a -recover command, which will recover all the children and their parent-child and recursive relationships

For any of these, you can exclude objects with an exclude.config.[name] file.

You can further exclude objects by their type (Standard, Custom, Share, Team, Tag, History).

Yes. There is a button you can press in the user interface that will gracefully cancel any job with full two-phase of all transactions in Salesforce and status flags in the database. This makes restores fully restartable without creating duplicates in Salesforce.

We do not create foreign key constraints because it would prevent copying records if they were done out of order, as you would get constraint violations if the child was copied before the parent. Also, some of the relationships (such as the ParentID of Attachment) point to multiple objects.

Yes. The relationship fields are stored in the database. When records are restored, the relationship fields are updated for all the child records as the parent records get new Salesforce ID’s. This is a patented process that allows one-pass restore of related data, including recursive relationships.

Contact.AccountID –> Account.ID

Contact.ReportsToID — Contact.ID

Even multi-level relationships are supported (Account1 has Contact1 as its child, which has Account2 as its child in a custom relationship).