Disasters Aren't Always System Failures

When people think of disaster recovery and backups, they tend to think of catastrophic events like system failures or data breaches. And yes, you need to have those things in mind, but you also need to expand your view a bit. It's extremely unlikely that Salesforce will suffer a catastrophic failure that causes loss of customer data. 

Think about worst-case scenarios: What if you forget to disable the account of a user who leaves your organization under unpleasant circumstances and they intentionally corrupt your data? What if an integration with another system causes significant data loss? What if you build a Flow that accidentally deletes a bunch of records instead of one record?

Even well-meaning users make mistakes. What if one of your users accidentally bulk updates a field on a significant number of records, writing over important data? What if an admin runs a data load to bulk update thousands of records and mis-maps the email field into the phone number field, wiping out all your phone numbers? What if you use a duplicate merge tool like DemandTools or Duplicate Check and accidentally merge together a bunch of records that aren't, in fact, duplicates? Having a backup in moments like these can make recovery from data mishaps like this far easier (or possible at all).

Disaster Recovery Starts with Preventing Disasters!

First off, you should have processes for onboarding and off-boarding users to ensure system access is limited to those who need it. Even better, your Salesforce permission model should ensure that users only have access to the data they need to do their jobs, reducing the amount of potential issues they can cause. Think very carefully about which users should be trusted to perform actions like importing records or making bulk updates using tools like Data Loader, or who are trusted to merge records. For those users, you should have comprehensive internal training and guides to ensure they know how to use the features correctly. 

And finally, no matter what, it should be clear to your users who to report problems to in the event that a mistake affecting your database occurs!

Using Salesforce Data Export

Salesforce offers an internal Data Export process in all editions of the product. Here is quick video walkthrough of how to set this up. To use Data Export, you'll need to be an Admin in your Salesforce instance. 

First, start by clicking the gear icon and select Setup.

In the Quick Find box, enter Data Export.

To schedule a repeating export, click the "Schedule Export" button.

You'll then get options for when and how to run your data export. Here's a quick summary of what each of these means:

1. Export File Encoding: in the beginning, computers used a text encoding called ASCII, which evolved to include a few hundred characters common to English and 29 other languages like Spanish and Italian [https://en.wikipedia.org/wiki/ISO/IEC_8859-1]. As more languages and characters needed to be represented (think non-Roman script languages like Chinese, Japanese, Russian, Arabic and the ever-popular emoji 🔥🏡) encodings that could support far more individual characters were developed. Those are called Unicode. 

   So, what does that mean for you? Think about your data–if you have a significant amount of data that you expect to have non-Roman characters in it (like emoji!) you'll probably want to select UTF-8. Otherwise, data exported from Salesforce might not be re-importable (you don't want to lose your 🔥🔥🔥🔥🔥). Of course, this need varies from org-to-org. The best path may be to try one export type and test.

2. Include images, documents, and attachments & Include Salesforce Files and Salesforce CRM Content document versions: these are related options. By default, Data Export only includes record values, not files that are attached to those records. If your org uses the newer Salesforce Files integration, Salesforce can also keep track of versions of those attached files. Check one or both of these boxes to include this data in your export, but be warned that this can make the export take significantly longer to run (and make the resulting file significantly bigger). 
3. Replace carriage returns with spaces: CSV files don't handle returns in fields–think of long text fields that might exist on your records (like notes fields) where users might manually enter line breaks–very well–it can make them difficult to open and re-import to Salesforce. Leaving this option checked will automatically replace these line breaks with spaces, making it easier to work with the resulting files. 
4. Frequency and start/end dates: If you are using Enterprise edition or above, you can schedule an export weekly. Otherwise, you can schedule monthly. Pick a day and a preferred start time.

Video Walkthrough of setting up the Salesforce Data Export Weekly Backup

Tip: Don't schedule exports for times that you expect to be busy (for example, the first or last day of the month), as your request will be queued with all other customers running data exports at that time, which may mean your requests will be delayed.

Another Tip: Want to run your backup effectively forever? Simply set the end date to a far distant future date like 12/31/2099. Salesforce won't show you a year option that far in the future in the drop-down menu, but you can type it into the box.

Below the Save button, you can select the objects to include–Salesforce includes all objects by default. After you've made your selections, click Save.

Great, you've scheduled your download. But remember: Scheduling the export does not automatically save it for you! When Salesforce completes the scheduled export, it will send the user who scheduled it an email notification. From that point, Salesforce preserves the export file for 48 hours, giving you the chance to download it and store it somewhere convenient. After you get the notification email, you'll need to sign into Salesforce and manually download the file.

You can click here for a quick video walkthrough of setting up the Data Export Weekly Backup.

More Advanced Options

Data Export is a great tool that's available out of the box in all Salesforce orgs, but it is limited. Because it generates CSV copies of all of your object data, it would be very labor intensive to use the results to reconstruct changes to your database. That's why there are a number of third-party backup and disaster recovery tools that offer additional features like bulk restore on multiple objects, granular restoration of data down to the field level, or allow restorations to a different Salesforce account (which can also be helpful for migration to a new org). Many third-party tools can also backup metadata–the definitions for objects, fields, and reports and dashboards–in addition to your actual data. Here are just a few:

Skyvia Backup and Restore is great for small Salesforce instances, as its pricing starts at only $9 per month/$84 per year for up to 20 GB of record data. It gets many of the features listed above at a low price point, although the data storage caps may make it difficult to retain backups for long periods of time.

OwnBackup is a more expensive but also very popular product. It is priced per-user, tied to the size of your Salesforce instance and has no data limits. OwnBackup allows retention of daily backups for at least a year, but comes with a minimum listed price of $6,000 per year, no matter how small your userbase is. But for larger databases that may need to retain multiple backups, it may be a better choice. 

Salesforce also offers its own native Backup and Restore product–pricing depends on many factors. Your Account Executive can help with pricing.

As always, Prolocity is here to help you navigate your backup and disaster recovery needs–please reach out if you need further guidance!