System administrators are seeing more and more business processes becoming reliant on SaaS solutions. Salesforce is; to many organisations the lifeblood of their CRM & Sales lifecycle, providing efficiencies of customer management essential to an effective organisation.
The mistake many companies make is to assume that just because a solution is “in the cloud” it has the same level of protection as their on-premise systems. In many cases this assumption is false; data is very often replicated (such as the multi-zone replication of AWS S3), but rarely has any sort of historical recovery points. Salesforce for example at the time of writing only holds 2 weeks worth of restore points; any changes or deletions not spotted within this time are likely permanent. Other considerations are the fees charged by Salesforce in the event you do have to roll-back. This will easily run into thousands of dollars ($10k is what i’ve read), money that could be saved through the configuration of a Salesforce agent.
This capability is still relatively new and may be simplified in later releases. This guide is written with Commvault v11 SP11 in mind. The configuration presently is made up of the following components:
- Salesforce Virtual Client (pseudoclient)
- Cloud Connector (Linux)
- SQL Server (Optional but required for restoration to Salesforce instance)
Not everything is protected as the data protection is limited to what is made available via the Salesforce API. For a list of items that are not protected check out books online here. The high level steps required to implement the Salesforce backup are as follows:
- Ensure you have a supported version of Salesforce
- Ensure you have sufficient capacity license available on your Commcell
- Configure a Connected App in Salesforce (click here for a guide).
- Install the cloud connector on a linux VM
- Create a MSSQL database on a seperate DB server for use by the cloud connector
- Create the Salesforce pseudoclient.
Obviously this guide is no substitute for the official documentation, however hopefully it will aide in testing out the Salesforce backup functionality for yourself. During my testing I used a free salesforce developer account available here.
During the configuration of the Commvault Salesforce pseudoclient you will need to complete the following fields:
- Client Name: The name which appears in the Commvault Console
- Instance Name: Usually the same as the client name.
- Backup Client: The linux proxy with “Cloud Apps” installed
- Storage Policy: The storage policy through which data will be stored.
- Number of Data Backup Streams: Start with 1 and scale if required.
- Salesforce login URL: https://login.salesforce.com (You may use a custom URL here if configured)
- Username: Your salesforce service account
- Password: As described
- API Token: The salesforce security token, this can be reset once the service account has been created.
- Consumer Key: Associated with the Salesforce connected App
- Consumer Secret: Associated with the Salesforce connected App
- Download to Cache Path: This should be a folder on the Cloud Connector, plan for 120% of the total salesforce data.
- Database Type: SQL Server (You can also use PostGreSQL)
- Database Host: The database server containing the database preconfigured for use by the Commvault salesforce agent. I had difficulty when using DNS names here, try IP if DNS doesn’t work.
- Server Instance Name: As described
- DB Name: Name of the SQL database set up on the SQL Server
- Database Port: 1433
- Username:sysadmin user for the configured database
- Password: As described.
As described above; you will need to plan for both the Cloud Connector cache and SQL server storage. Required storage is as follows:
- Cloud Connector: 120% of the Salesforce used space.
- MSSQL Server: At least double the Salesfore used space.
In addition to this you should consider the amount of back-end storage required. This should be planned in the same way planning for any additional client is performed.
Creating a Connected App
- Login to Salesforce using your administrator account
- Click Setup
- On the left select Build then Create –> Apps
- Scroll down to Connected Apps and click New
- Completed the required fields, ensure “Enabled OAuth Settings” is enabled.
- OAuth Scope should be “Full Access”
- Callback URL should be “https://test.salesforce.com/services/oauth2/token” if you are using a test account. If this is a production config it would be “https://login.salesforce.com/services/oauth2/token”
- Click Save and then click the connected app name, note the following fields:
- Consumer Key
- Consumer Secret
- Callback URL
- Commvault requires this during setup, minus the /services/oauth2/token
Generating the API Key
The API key is associated with the administration account (service account) used by Commvault to connect to Salesforce. To generate it:
- Login as the service account.
- Click the username at the top of the screen, select “My Settings”
- On the left of the screen, select “Reset My Security Token”
- Click the button to reset the token, it will be sent to the email address registered to the service account.
Configure the Pseudoclient
You should now have all the components and details required to create a Salesforce pseudoclient (also described as a virtual client). In addition to the items configured above you should have a Linux client installed with the Cloud Apps package, sufficient space on that client for the cached salesforce data & a SQL server with a preconfigured SQL database (and associated credentials).
Steps are as follows:
- From the CommCell console, Create a new Salesforce client.
- Complete the details on each tab, use the “Required Information” section above if you need clarification on any of the fields. Be sure to Test Connection on the “Connection Details” and “Backup Options” tabs.
- Your new client will appear as displayed below. Right click on the default subclient to adjust what is to be protected. You’ll notice the defaultbackupset reflects the name of the service account used.
- In the Contents page of the default subclient you have the option to include metadata, selecting this option will give you access to the metadata view when performing a “browse & restore”.
Standard vs Metadata views
Not being a Salesforce administrator I cant provide much insight into the significance of these two views, I can however provide screenshots of the different browse and restore results:
Now it’s time to run a backup operation which can be performed by right clicking on the default subclient and choosing backup. You’ll notice an incremental backup is automatically performed following the completion of the full backup. Once this has completed you can test the solution by deleting accounts/opportunities etc and testing the restoration process.
If you are restoring directly to Salesforce you’ll notice the requirement for a configured database. The screenshot below shows the restore options window when restoring directly from the most recent database sync.
If you are restoring from another restore point, you may need to restore from Media, as shown in the screenshot below:
You’ll notice this clears the database details. All restores to Salesforce require a staging database (be that MSSQL or PostGreSQL). You would need to create and specify a SQL database to restore to (from media), prior to that data being restored to your Salesforce instance.