Cloud Backup/Recovery: The Same, Only Different
This blog post is the second in a series on Data Protection issues and practical solutions.
Backup and Restore, the most basic form of data protection, has been a standard IT practice since teams or Operators managed racks and rows of tape drives and tapes for early mainframe computers. Borrowing from proven audio technologies, tape backups protected programs and data from the fickle failings of early disk drives.
As computers became more interactive, and more personal, the need for backup and restores services expanded. Yes, your hardware might fail. More likely, however, an assistant would “save as” over the boss’ most recent masterpiece. Computers were new, and human error was inevitable. Then came viruses, poorly written applications, spyware, bots, and the Internet (the ying and yang of all things good and evil).
As we move into the cloud, some of the reasons for backup/restore remain, and some new ones emerge.
For those of us running Google Apps for Business, Education, and Government, Google’s highly redundant, multi-tenant infrastructure protects us from nearly all risk of data loss or corruption due to hardware or system failure. Understanding the other risks to our data lets us decide when and how to better protect ourselves.
Third Party Applications
While domain-level access for applications is usually restricted to administrators, users often have the ability to run and connect third party applications to accounts. Whether global or individual, poorly written third party applications can wreak havoc with your data. Applications that need write access to docs, email, calendars, or contacts, can overwrite or delete content. Determining the scope of a problem, and recovery, can be nearly impossible without reviewing all of your data.
User Error
Recent research shows that data loss within Google Apps is due to user error 63% of the time (0% is caused by Google). As with any new system, unfamiliarity can bring unintended harm. Ill-placed pastes, mistaken deletions, and save instead of “save as” are some of the ways data may be lost. Even more complex, mistakes using Manage Revision settings, and permanently deleting items, can make recovery impossible.
Willful Misconduct
Protecting your data from the employee (or soon to be ex-employee) intent on doing harm is nothing new. In Google Apps, as well as any other system, employees with access to sensitive information often have the ability to damage or destroy that information in ways intended to harm your business.
Security Breach
Google Apps is one of the most secure public cloud services in the world. Even so, no system is ever completely safe from user identity theft or corrupt systems with access. A mal-ware infected computer running Google Drive can allow damage to data in Google Apps as easily as with a computer connected to a Windows server down the hall. If a user — knowingly or as a result of social engineering — shares his or her identity, hackers and others can damage your data.
Google Error
While Google has never had errors resulting in permanent data loss, and Google’s systems are designed to withstand multiple points of failure, a very, very small chance still exists that a software or hardware error could corrupt data.
All of these cases are, and have been, reasons to run a backup/recovery service. But at what point do you add backup/recovery to your? For most, the answer is as simple as the answer to the following question:
If you had this data on a server in your computer room, would you back it up?
If the answer is “Yes”, than you should protect the data where it lives — even in Google Apps.
For others, it is one of critical mass. When the cloud is considered a secondary data store, some wait for usage to reach a level “significant” enough to warrant the additional cost of backup/recovery services. Unfortunately for some who “wait and see”, the significance is often measured by the pain of a data loss event.
—–
