This is part five of a five-part series on methods for backing up your Salesforce data.
Salesforce provides Application Programming Interfaces (APIs) for running programmatic operations on data and metadata. If you’re not familiar with this term, you can think of it as a library of commands for interacting with the data in Salesforce. You can also use that API to Extract, Update, Upsert and Insert data to/from Salesforce. Those commands can be used to essentially build your own backup solution; however, this is not a recommended approach.
A company may consider creating a custom backup solution through Salesforce APIs to:
- Keep their data and/or metadata from going through an additional third party.
- Have complete control over their data and/or metadata movement.
- Move data and/or metadata to and from a third-party application or another Salesforce Org.
Using Salesforce APIs to build a backup solution might seem simple, but it’s not. When it comes to backup, there are a lot of moving parts and considerations that many companies do not think about in advance.
First of all, building a proprietary backup solution has numerous hidden costs:
- Implementing auto-discover to support custom objects.
- Keeping up with new API versions.
- Implementing a notification system for when a backup fails or completes with errors.
- Troubleshooting backup failures and errors.
- Making sure that the backup is efficient in terms of run time and consumption.
- Maintaining all this code.
- Maintaining the on-premise storage and backup files.
And that’s just the backup, what about the recovery?
How will you identify the changes/deletions across your backups? If you have many custom objects and applications and a lot of data, this could be tricky to do.
Will your restore strategy work with parent-child relationships? It’s common for a cascading delete to occur when data is deleted in Salesforce. This occurs when a parent object (or account) is deleted, then deleting all the children records related to that parent object. Given that you can’t set a record’s ID via the Salesforce APIs/tools, and relationships are based on the record ID, this can be very complex to restore.
How granular will your restore tool be? Would it support bulk Updates/Inserts? Will you be able to easily extract only the corruption that started and ended last month without overwriting all the unaffected data?
Where will your backups be located? Make sure you’re backing up your Salesforce data in a location outside of your Salesforce database so that it will be immune to any data loss scenario that could inflict damage to both your co-located primary Org & backup copy.
What about keeping up with the Salesforce’s new API versions, while supporting metadata, attachments, table-data, chatter, customer-objects, etc?
The opportunity cost incurred for attempting to implement your own API backup and recovery solution is high. Think about the time and money your technology team will waste trying to develop, maintain, monitor, troubleshoot and store all your backups. It would be better to focus your company’s valuable resources on your core business, rather than trying to develop a backup and restore tool. Isn’t that why you moved to the cloud to begin with?
Don’t settle for an expensive, basic backup and recovery solution. Let OwnBackup manage your Salesforce backup and recovery. For over three years, our expert team has been working with some of the world’s largest organizations to perfect enterprise Salesforce backup and recovery. With OwnBackup, you can schedule full Org backups, including metadata. Recovering your data is just as simple. Use visual tools to find and isolate the deleted/corrupted data, restore parent/child relationships, and restore only the corrupted data, leaving everything else intact.
Read parts one through four of this series to learn about other out of the box Salesforce backup methods, including Weekly Export, Data Loader, and Full Sandbox.
Learn more about how OwnBackup works...