Why Salesforce needs third party apps for safe backup and restore

The unwritten rule for Salesforce users is: ‘Backup your own data’.

Without a dedicated backup app, customers could risk losing their data because Salesforce does not offer complete dataset backups on a daily basis.

Salesforce’s built-in data protection facilities include:

  • Weekly export – this does not include full data set and you could lose up to a week’s worth of data
  • Export to data warehouse – needs a script and API knowledge
  • Sandbox refresh – 30-day refresh period
  • Data recovery service – six-eight weeks needed plus $10,000 fee

None of the above options meet what an enterprise IT department would regard as a satisfactory backup service for important data. For the enterprise, the acceptable data loss period is measured in seconds or minutes rather than hours, days or weeks. And restore needs to be fast – ideally measured in minutes.

Chart showing Salesforce recovery options

The data custodian

SaaS applications such as Salesforce do not regard themselves as custodians of the tenants’ data in their multi-tenant SaaS environment. You the customer are the custodian of your data – just like you are when running applications in your own data centre.

Of course, the enterprise could roll its own backup app; to do the job it would need to set up a scripting routine to use the Salesforce API calls or write its own application code. But this is option is not feasible for most users.

That is why additional SaaS applications such as OwnBackup for Salesforce provide a backup, restore, archive data protection service for Salesforce customers. Competing Salesforce backup applications include CopyStorm, Druva, Reflection Enterprise and Kaseya’s Spanning.

OwnBackup set up in 2015 and has raised $49.8m in four funding rounds. It has offices in Tel-Aviv, New Jersey and London. The company offers automated complete and daily dataset (data and metadata) backup plus archiving and sandbox seeding for test and dev. OwnBackup’s technology was initially developed as a sideline from 2012 onwards by CTO Ariel Berkman, while working at Recover Information Technologies, an Israeli firm that recovers data from crashed storage drives and media.

Multi-tenancy problem

Why can’t customers use their existing backup applications to do the job?

OwnBackup co-founder Ori Yankelev told us in a press briefing last week that traditional relational database backups require customer access to the underlying infrastructure. “They need an agent on the machine. With multi-tenant [SaaS] applications this is not possible. The customer doesn’t have access to the infrastructure.”

A customer cannot run a backup agent on Salesforce infrastructure: only Salesforce could do that. However, Salesforce provides access to its infrastructure through API calls only – which OwnBackup uses to provide its service.

Data that is input into Salesforce is visible to customers when they operate the app. But this is not necessarily the case for the metadata that Salesforce uses, as API calls are required to access that information. A backup application has to access this data to be able to backup and restore customer data.

SaaS backup silos

The upshot is that the Salesforce customer needs a dedicated backup silo and backup software for Salesforce data, even if they operate on-premises backup facilities.

Also, note that OwnBackup and other backup apps tend to specialise in one SaaS app target. This means customers likely need different third-party backup apps for each SaaS application they use.

Yankelev said OwnBackup is considering adding Workday to its coverage. But he noted: “Its APIs don’t deliver the flexibility needed for us to deliver our services. Hopefully it will change.” Subject to this caveat, the company could announce OwnBackup for Workday by the end of 2020.

Our impression is that a SaaS app’s API set is not necessarily designed to enable a third-party backup application to backup and restore a customer’s complete dataset with minimal or no data loss.