twitter linkedin cross no arrow-down arrow-up arrow-right

Backup & Recovery

Posted November 7th, 2017 by in Salesforce Apps, Salesforce Best Practices

I know… This is not specific to lending & leasing… And talking about back-ups is boring when we could be talking about exciting stuff like multiple investment sinking funds and terminal rental adjustment clause leases… But, as more and more lenders are maintaining critical business data in Salesforce, it’s something we need to discuss.

When thinking about backups, it is important to understand the differences between data types that comprise your Salesforce environment. First type is the actual data, which includes accounts, contacts, leads, opportunities, cases, custom objects, file attachments and chatter posts. Second type is metadata, which refers to all of your configuration settings like custom fields, page layouts, reports, dashboards and any custom code done for your organization.

You may ask why should I backup my data? Even with best intentions, users and administrators have been in situations where they have accidentally deleted or updated large amounts of data. With tools like data loader, it is very easy to mass delete records due to a simple mistake. It is therefore recommended to keep regular backups of your data, as well as point-in-time backups before proceeding with any major data project within your Salesforce org. In addition to data, you also should backup your metadata for the same reasons. Many configuration settings are not reversible and it is best to have a copy of this metadata to restore if needed.

Beyond using Salesforce Services for restoring data and metadata, there are 2 main options for handling backup and recovery of your Salesforce data and configurations to protect against accidental deletion. First option is to manage backup & recovery on your own, which requires having a data-savvy Salesforce Administrator in your organization to manage the backup & recovery process. Second option is to sign up with a service to manage the backups for you.

Option 1 – Manage Your Own Data Backup & Recovery
To avoid paying recovery fees to Salesforce and be able to recover your data whenever needed, it is recommended to use the following backup and recovery methods if you intend to manage data backup and recovery on your own.
Native Data Backup Options: the following options are available as methods to backup data:

1. Data Export Service: manual or scheduled exports of your data via the UI. See Exporting Backup Data for more information.
2. Data Loader: manual on-demand exports of your data via the API. See Export Data documentation for more information.
3. Report Export: manual on-demand exports of your data via reports. Build a new report containing the data you want to backup. Export the report and select Comma Delimited .csv for the Export File format

Native Metadata Backup Options: the following options are available as methods to backup metadata:

1. Change Sets: copy metadata from your production org to a sandbox or developer org. See Change Sets Overview for more information.
2. Sandbox Refresh: refresh your production org to a sandbox so that your configuration metadata is refreshed automatically. See Creating or Refreshing a Sandbox for more information.
3. Migration Tool: Java/Ant-based utility for moving metadata between local directories and a Salesforce org. See Migration Tool for more information.
4. IDE: Client application for creating/modifying/deploying applications. See IDE for more information

Option 2 – Third-Party Service Manages Your Backup & Recovery
There are several options for doing this, the most well-known options are listed on the Salesforce AppExchange. Some services are more comprehensive than others. You can search for current offerings on the AppExchange, using keyword ‘backup’. Third-party services are beneficial since they remove the need for someone on your team to manage a process that can be quite complex and time-consuming. You also get peace-of-mind that you have technical experts safeguarding your critical electronic assets.