Learning from the Honda Ransomware Attack (Restore it All Podcast #54)

Zoë Rose (@RoseSecOps), a cyber investigator from the UK, joins us to talk about the lessons we can learn from the ransomware attack on Honda. We discuss a number of “common sense” things a company can do to protect their data.

----- Signature and Disclaimer -----

Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Evangelist at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.

GigaOm Analyst explains their latest report on data management (Restore it All Podcast #53)

GigagOm analyst Enrico Signoretti (@esignoretti) is our guest this week, and he helps us understand their latest radar report, which evaluates data management vendors.

----- Signature and Disclaimer -----

Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Evangelist at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.

One year anniversary special! (Restore it All Podcast #52)

On this first anniversary special, we are joined by Nina Hebert, the voice behind our podcast’s theme song. Fun times talking to her, and talking about our dreams for next year’s broadcast.

If you want to see the video version of the podcast’s theme song, you can see it here: https://www.youtube.com/watch?v=fPoE7nlgYe4

----- Signature and Disclaimer -----

Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Evangelist at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.

Salesforce no longer has your back (up)

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.

----- Signature and Disclaimer -----

Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Evangelist at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.

How Hollywood Picks Backup Products, Part 2 (Restore it All Podcast #51)

We continue our two-part series of how Hollywood picks backup products, discussing vendor selection and proofs of concepts. Jeff Rochlin returns as a guest, hosted by W. Curtis Preston and Prasanna Malaiyandi.

----- Signature and Disclaimer -----

Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Evangelist at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.

How Hollywood Picks Backup Products, Part 1 (Restore it All Podcast #50)

We talk to Jeff Rochlin, a veteran of many Hollywood studios and related businesses, about how he would go about picking a backup product in that environment. W. Curtis Preston and Prasanna Malaiyandi hosting.

----- Signature and Disclaimer -----

Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Evangelist at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.