They never really did, IMO, but at least now they’re being open about it. As of July 31, 2020, Salesforce will discontinue its “recovery service,” which was a last-resort backup that I always advised against anyway.
I retract what I once said about Salesforce
Last year, Salesforce corrupted their own customers’ data and then told them to fix it. And their instructions for doing so never even suggested a real backup, such as what my employer (and many of our competitors) provide. They talked about using a recent (but not too recent) sandbox copy or manually fixing it yourself. This created an outage that lasted more than a day for may customers, leading me to write a blog post that said they proved they do not understand backups.
While I still cannot fathom what happened last year, they clearly have their act together now. They are basically saying that the “recovery service” was a horrible service that no one wanted to buy and they didn’t like selling it – it not so many words. OK, here’s what they actually said:
“At Salesforce, customer Trust is our number one priority. The data recovery process does not meet our high standards for customer experience due to the length of time and reliability of the process. This process takes a minimum of 6 – 8 weeks to complete and we cannot guarantee 100% data recovery. Due to these issues, we are no longer offering this service as of July 31, 2020.”
You need to start backing up Salesforce
You should have been doing it already, but at least you could say there was a method of last resort. That method is about to disappear. You need to use some mechanism for getting your Salesforce data out of that world and into some other world. Here are some suggestions on how to do that.
Automated
Please make sure however you do it is automated. This precludes the use of the built-in free tool, because it is a very manual process.
Ensure referential integrity
The Salesforce database consists of dozens of related tables (or objects, in Salesforce terminology) that contain data that reference each other. When you use bare-minimum backup methods like the old data recovery service and the built-in free tool, each CSV file you get knows nothing about the other ones. (Each object is represented by a separate CSV.) This means you can easily create records that aren’t linked to each other. Use a backup method that understands these tables are related, and will restore them that way.
Conform to the 3-2-1 rule
Three versions of your data on two media, one of which is somewhere else. This means a Sandbox copy doesn’t cut it, as it conforms to none of that. If you use the built-in tool (which I don’t recommend), make sure to not overwrite last night’s backup file with tonight’s file. Keep three versions – at least. And don’t store all your backup in one place (like the laptop you downloaded them to). Keep at least one copy somewhere else. Like the cloud. You can easily conform to all of these rules using a cloud backup service, of course.
Microsoft and Google don’t have your back (up) either
At least Salesforce is upfront about it. Neither Microsoft or Google offer anything like a data recovery service. (Extended retention is NOT backup.) So if you’re using one of them, you should be following all of the same advice above. If you don’t believe me, please go read your service agreement. Let me know when you find the words “backup,” “restore,” or “recovery.” I can wait.
Written by W. Curtis Preston (@wcpreston), four-time O'Reilly author, and host of The Backup Wrap-up podcast. I am now the Technology Evangelist at Sullivan Strickler, which helps companies manage their legacy data
