Aidan Finn commented recently on a Microsoft infographic about How to Kill Your Business in 5 Simple Steps—and they are very good steps to consider. (Thank you to @gilwood_cs for pointing this out to me.) However, regardless of those issues, there is one, just one, simple way to destroy your business these days. Five is a nice number of items to consider, but one item was missing from the list: one item that has already destroyed one business overnight and put countless others at serious risk. That one item can be addressed with one simple question:
Are you satisfied with your offsite backup?
Yes, it really is that simple. If your organization uses the cloud—and all organizations use the cloud today—for anything, how do you back up your data from that cloud so that you could recover your business as needed? Or do you have the feeling your cloud is doing your backups for you? If so, can you request a restore at any time?
Countless times, I have run across people who believe clouds are doing their backups for them, but when a disaster strikes, they are at a loss. The cloud did not do the backup, or they did not pay for that sort of backup, or something went wrong, or testing was never done—as such, all data is corrupt, etc. The list of reasons why backups fail goes on.
Backups are there to protect your data, to keep your cloud-based business running, but do you have control over those backups? Can you relaunch your business without your cloud-based CRM, web presences, and data stored on file sync and share? Do you even know where all your data resides? Do you have offsite, off-cloud backups that your organization manages?
Simply having an offsite backup will save your business, but offsite backup is handled quite a bit differently than in-cloud or onsite backups. In essence, if there is a management interface that can be used to delete your current instance of your cloud environment, that interface should not also have the ability to delete your offsite backup. Offsite backups are archives; they are write once and eventually may be deleted after a number of years, months, weeks, or even days. For example, the fact that I can log in to my Amazon Web Portal does not mean that same login can delete my offsite backup. But wait, you say—you use multiple EBS zones and that protects you? Or you use a cloud gateway to do backups?
Neither of these ways actually protects you from that one step that will destroy your business. They still allow the deletion of files via a single user interface with a single login. Once your Amazon or EBS zones are deleted—well, they are gone, and so is all your data. If you use a cloud gateway and that gateway can delete files from within Amazon, those files are still deleted.
Disaster recovery requires you to have an offsite backup. That offsite backup needs to be off-cloud as well as offsite. It could, however, be placed within a separate cloud via an API that is restricted to just write. If you can delete through the API, so can the bad guys.
I call this the “there and back again” data protection strategy. Get your data to the cloud, but get it back again so you can place it in another cloud, or even go cloud to cloud. Do not rely on any one cloud to fully back up your data, unless you are paying them to do so, but even then, have an offsite backup. It is, after all, your data. If you use SaaS tools, then you can look into using Asigra or Datto products. If you use IaaS, there is a multitude of tools available from Veeam, CloudVelox, HotLink, etc. For the latter, the list is fairly large.
Do not allow one mistake (or a bad guy) to be the one step to destroy your business.