About Restore Full Org

Restore Full Org can restore to a specific snapshot, providing the means to bring back data lost from an Org.

Restore Full Org will restore all deletions and changes across all detected objects that occurred between two selected backup snapshots. Please see below for the limitations and required conditions.

When Should Restore Full Org be Used

Restore Full Org should be used to restore data in an entire Org to a specific prior state, or to revert changes made in a given timeframe. For example, when a third-party integration corrupts or causes data loss across the entire Org. 

In most scenarios, Restore Full Org is NOT an ideal approach for disaster recovery planning. Generally, only a subset of objects (within the Org) need to be restored. Since a Restore Full Org may take a long time (in case of a large Org), it should be used only when the corruption has occurred broadly across the Org.  

As a general rule, we do not recommend using Restore Full Org, unless it’s required, since any intentional changes will be lost, and due to the amount of time required to restore a full Org.

Restore Full Org versus Repair Data Loss or Repair Data Corruption

The Restore tool provides three options for restoring data:

• Repair Data Loss - Use this option if an accidental deletion in your environment caused a cascading deletion of records and all their related records and attachments.  
• Repair Data Corruption - Use this option if only a field level data corruption has occurred in your Salesforce environment. 
• Restore Full Org/Instance - Use this option only if a broad scale corruption or loss has occurred in your Org, or if you are not certain as to the scope of the corruption or loss that has occurred in your environment.  

Full Org Restore versus Multiple Objects Restore

Multiple Objects Restore is a precision restore method for restoring multiple objects that were corrupted or lost in an org. This is the recommended method for restoring multiple objects, for the majority of data loss or corruption instances. 

Full Org Restore is preferable only when all data in an org has been corrupted or lost (or a large part of the org, with many objects/tables).    

Best Practices

Every business should have a verified disaster recovery plan to address data loss.

We recommend identifying critical objects for business operations and testing data loss scenarios in disaster recovery scenarios or drills. The data loss scenarios should be realistic and planned out ahead of time.  

As a best practice, we recommend leveraging Repair Data Loss and Repair Data Corruption instead of Restore Full Org, whenever the scope of record restore can be reduced to less than all data in the org.

As a general rule, we do not recommend using Restore Full Org, unless it’s required, since any intentional changes will be lost, and the amount of time required to restore a full org.

WARNING: Using Data Restore may revert any intended changes or 'good data' on records that exist in the destination org since no filtering options are available. Therefore, it should be appropriate for Org-wide disasters where ALL data is deemed lost or corrupted.
Please consider handling all schema changes (metadata) as well as automations, triggers, and validation rules that may prevent the insertion/update of records in the destination environment. 
Metadata Compare may be leveraged prior to running the job and the results can then be handled via an ETL tool to ensure a smoother data insertion.

NOTE: In most scenarios, Restore Full Org is not an ideal approach for disaster recovery planning. In most cases, only a subset of objects (within the Org) need to be restored. Since a Restore Full Org may take a long time (in case of a large Org), it should be used only when the corruption has occurred broadly across the Org. Another reason why we do not recommend using Restore Full Org (if it can be avoided), is because any intentional changes will be lost.

Required Conditions for Restore Full Org

When running the Restore Full Org, only two points in time (backups) are compared (to determine which data had been deleted or changed). 

Make sure that the Org being restored is still in the same environment.

Make sure that the sandbox has not been refreshed.

Limitations 

Restore Full Org:

• Will not update or insert records that are not within the two backup snapshots
• Cannot exclude specific Objects from the restore
• All changes or record deletions will be restored, regardless of whether they were done intentionally or unintentionally. Therefore, any intentional changes will also be lost.

Full Org Metadata Restore

Full Org metadata restore is not currently supported. Should the need arise to restore full org metadata, it can be accomplished by using the 'deploy via Workbench' method, which is easier than the manual process required to restore the full org in the correct order.

Our platform supports restoring the most common metadata objects: reports, dashboards, permission sets, etc. Any other issues related to restoring metadata objects can be solved with the help of our support team. 

Run Time Estimate for Restore Full Org

Estimating the total run time of Restore Full Org is difficult, since it will vary significantly from one Org to another, due to the size and complexity of the schema in the org.

Replicate Full Org

While the Restore Full Org provides a means to bring back something that was lost from the same Org, the Replicate Full Org would have to be used when moving data from one Org to another. The biggest challenges when moving data from one Org to another, are related to differences in the schema and metadata.

For more information on how to restore to a full org/instance, see here.