Admins at large enterprises often choose to backup their Salesforce data to cloud or on-premise storage in a SQL database. This in essence mirrors your Salesforce data to another platform.
You can backup to SQL in a few different ways:
1. Import your Salesforce Weekly Export files into SQL. This is by far the most time-consuming method as you must process each file individually into the related SQL table.
2. Write custom script to export your data from Salesforce to SQL. To implement this method, you will need to have a SQL Admin set it up and potentially diagnose any issues that may come up in the future.
3. Backup to SQL with a third-party data integration tool. This is the most common solution companies use to backup their Salesforce data to SQL. A third-party tool uses custom field mapping to export your data from Salesforce to a SQL database. This process can be scheduled and automated.
It’s better than no backup at all. Backing up to SQL is also easier and less time consuming than using Salesforce’s Weekly Export (if you use option #2 or #3 above). Plus, with a custom SQL script or third-party tool, you can schedule backups to run multiple times per day or in real time.
SQL allows admins to work with legacy systems and conduct advanced data analysis. Some admins at large enterprises backup to SQL as a part of a legacy system because it allows them to run reporting or other BI tools (business intelligence) and/or ETL tools (Extract, Transform, Load) the company already uses. This is absolutely fine, but it doesn’t mean SQL is the best solution for backing up and recovering your data.
While backing up to SQL is an option, it may not be the most appropriate solution for your organization.
You risk losing your backup data. If a transfer of data to your SQL backup is scheduled, you have the potential to overwrite good data with bad data. For instance, if an integration runs into your Salesforce org and incorrectly overwrites a number of records with incorrect values. This information would then replicate out to your SQL backup and also corrupt the same records there. This will make it extremely difficult to 1) figure out what was deleted, and 2) recover the lost or corrupted data.
SQL doesn’t provide alerts and offers little to no visibility into daily data changes. If you’re lucky and you know exactly when the data was lost, you could roll everything back to that point in time to recover. Unfortunately, Salesforce admins backing up with SQL must rely on end users to inform them of a data loss or corruption, which may not be reliable enough.
Metadata is not backed up when using SQL. Backing up your Salesforce instance to SQL will backup your data but not your metadata. Therefore, you will not be able to recover your custom settings, layouts, and relationships exactly as they were before.
Recovering data is difficult since most SQL solutions do not have basic recover functionality. Data loss and corruption happens more often than you’d think. Some of the causes include human error, malicious intent, integrations with external systems, and/or bad code or triggers. This means that it is essential for your company to have a backup AND recovery solution that easily helps you analyze and identify data loss or corruption and bring it back without changing other data in your environment.
When your organization moved to Salesforce, it took a huge step to modernize your CRM data management strategy. If you’re still backing up your Salesforce data to SQL, then there’s still work to be done.
I’d recommend looking into OwnBackup, which is an enterprise-ready backup and recovery solution with advanced data recovery capabilities. OwnBackup sends you alerts when a data loss happens and allows you to quickly understand the extent of data loss with visual compare and find capabilities. Then, it lets you recover that lost or corrupted data in mere minutes. Don’t take chances with your company’s data. Request an OwnBackup demo today.
Updated March 11, 2020