How would you go about restoring your org after a data loss incident? You don’t have any viable options without backups of your data and metadata, so the first thing is to start backing up your org. But even once you have backups in place, you still need to think about your restore process ahead of any data incident.
Whenever you find yourself needing to restore large amounts of data, the chances are you’ll be working under pressure to repair your org quickly. And stressed people don’t make the best decisions. Preparing a plan of action now for restoring your org will save you from having to invent a restore process in the middle of a crisis.
Manual backups vs. a backup solution
How you back up your data and metadata will affect how you restore your org - and how well. It is possible to restore data from manual backups, but doing so is more complicated than restoring your org using a backup solution. In fact, at every stage of the restore process, teams using a backup solution will significantly outperform teams with manual backups.
The restore process
1. Assess the damage
Probably the worst thing to do after any data loss is to rush in and start restoring data straight away. If you haven’t yet understood the cause and scope of the data loss, restoring data to your org might be making matters worse by obscuring what data has been lost and causing confusion. So first make sure that the cause of data loss has been identified, contained, and eliminated.
Then you’re ready to assess the extent and nature of the damage. You need to be sure that you know exactly what has been lost or corrupted: which datasets, and which items of metadata. You should assess your backups too. Verify that the latest backups were successful and the data you plan to restore is sound. If you have backups from several points in time, which backup (or backups) do you need to use?
If you back up your data and metadata manually, assessing your backups and your org will also have to be done manually. Just clicking around to see what’s missing obviously risks failing to notice things, so you’ll want to use tools of some kind. For data, you can create custom reports in Salesforce that check the number of records in your org. It’s trickier to work out the metadata differences. While there are free open-source diff tools you can use, these can’t cope with all the nuances of Salesforce metadata.
In contrast, Gearset’s backup solution will identify the exact data and metadata that has been lost. You can analyze the data loss in Gearset, both by looking at your entire backup job and by digging into each object for granular detail.
And Gearset’s comparison tool will show you the exact metadata differences between your backups and your org. So with Gearset, you can be sure that you’ve identified everything that needs to be restored.
2. Plan how to restore what’s lost
Once you know exactly what has been lost, you’re ready to plan how you will restore that specific set of data and metadata. It helps to recognize that restoring data and metadata is essentially the same process as running a deployment, with your backups as the source and your org as the target. So you can approach restoring your org a bit like you would approach refreshing and seeding a sandbox environment.
If metadata needs to be restored, always restore that first. Then restore data. Break down the process into manageable sections. Trying to restore too much in one go will often result in lots of error messages. Restoring smaller sections at a time will make it easier to identify the cause of problems that may need troubleshooting as you go. Many errors can be avoided by working in a logical order, first restoring core objects that lots of other objects and records depend on.
If you need to restore lots of metadata, it’s usually best to restore five subsets of metadata in this order:
- Data tier. The core components that set the data structure of the org, and on top of which most other customizations are built, e.g. Custom Objects, Custom Fields, Custom Apps, Value Sets, and Picklists.
- Programmability. The custom code you’ve built on top of the platform. This is everything Apex: Classes, Components, Tests, and Triggers.
- Presentation. Your modifications that change how end users interact with the platform, e.g. VisualForce, Lightning Pages and Components, and Layouts.
- Permissions and security model. The metadata that controls users’ access to data, e.g. Field Level Security, Profiles, Permission Sets, Security Settings, Roles, and Sharing Rules.
- Other. Any other components or types. This might include Email Templates, Reports, Static Resources, Flows, Workflows and Documents.
If you need to restore lots of data - more than 100,000 records - it’s a good idea to break this up too. But the way you do this will be different depending on your backups. If you’re restoring manually from your own backups that you’ve exported from Salesforce, you might want to follow Salesforce’s advice on planning big data migrations. Salesforce recommends first working through core objects in the following order: 1. Users, 2. Accounts, 3. Campaigns, 4. Contacts, 5. Opportunities, 6. Cases, 7. Pricebooks, 8. Products, 9. Leads, 10. Contracts. The problem with this approach is the huge number of complicated relationships between your records. After you’ve restored data to all of your objects, you will need to restore all of these data relationships manually as well - an additional step that takes a lot of time and effort.
Gearset’s backup solution handles all of this complexity for you. With Gearset, you can restore data to multiple objects at once, and all of the relationships between records will be restored too. Even if you have large amounts of data, don’t break up the restore process by restoring one object at a time when using Gearset because you won’t restore the relationships between your records. Instead you can break up the data by filtering for record owner or creation date.
3. Restore to a sandbox environment first
You probably don’t deploy metadata straight to your production org without carefully testing it first. And hopefully you take great care when bulk loading data to your org, as this is one of the main causes of data loss! In the same way, when you restore data and metadata to your org, you should proceed carefully.
It’s best practice to restore metadata and data to a sandbox first, and check everything there without risking further damage to your production org. Only then should you restore everything to production, where you should check again that everything looks right. This can be assessed in the same way that you assessed the extent of your data loss, ideally with a tool like Gearset that shows you the exact data and metadata differences as discussed above.
If you’re doing everything manually, it’s tempting to skip restoring to a sandbox environment because running multiple restore jobs takes so much more time. With a backup solution, deployments are so much faster that you can afford to take a little extra time. In the heat of the moment, this can feel like it’s slowing down your recovery time. But restoring with care and avoiding mistakes is much faster overall than trying to restore so quickly that you cause more damage and confusion. When it comes to something as important as restoring your org, it’s a case of more haste, less speed.
Test your restore process
You don’t want an actual data loss incident to be the first time you’ve tried your restore process. Test your restore tools and processes in advance using a sandbox environment. And make sure you test your ability to restore both metadata and data. If you’re using a backup solution like Gearset, you can set up metadata filters and data templates in advance and practice using those to restore metadata and data to a sandbox.
Set a regular cadence for testing your restore process. Many companies aim to test their restore capability at least once a year. Of course, the more often you practice, the more prepared you’ll be. If your Salesforce team grows or changes significantly, you should test your process again sooner. You need to make sure everyone is familiar with your restore process.
It really helps if your backup solution is part of your DevOps tool, because you’ll be using the same processes and tooling to restore your orgs that you use every day for Salesforce deployments. Onboarding new members of the team will also be much simpler.
Have confidence in your ability to restore your org
Restoring an org after a data loss incident is always going to be stressful. But you should never be in a position where you have doubts about your team’s capability to restore your org accurately and effectively. Start backing up your data and metadata with Gearset, test your restore process, and have confidence in your ability to restore everything - just the way it was - in record time.
You’ll find more guidance about backups in our free ebook, Backups for Salesforce. If you want to learn more about Gearset’s backup solution, feel free to book a consultation with one of our experts, or click below to road test Gearset’s backup solution for yourself - with a free trial right now!