Classically, backup for the unforeseen event comprises a resource remote from the primary information that can be used to support the business operations in the event of the non-availability of the primary source. Analysis of risk and impact of losses can be used to determine how long that you are able to do without the primary source and how much you should be prepared to pay for recovery within that time. Generally, only broad classifications of risk to the primary information is considered (destruction of data centre; denial of service etc).
In “cloud” services, we are buying a measure of protection of our information assets from the provider whether that is Google, Microsoft or Waikikamukau Data Services. The trust we can place in these organisations is related to their competence and also the size of the pain that the organisation will feel when your primary information is unavailable. For example, if Google reported that it could not recover from a failure of just one of its data centres, there would be a massive loss of confidence affecting the viability of the multibillion dollar company.
So we might safely assume that Google will be able to restore your account in event of a catastrophe in their domain, but user mishandling of information is another matter and firmly in the user’s court. For this the user needs a strategy to suit their needs for information assurance.
Implementing some form of backup for Google Apps will require one or more of
- Maintaining an inhouse backup storage server to backup cloud based documents to local hard disk or another storage supplier like Amazon.
- Use a 3rd party service like Backupify or Spanning to copy and restore Google Apps documents/files.
- Something to confirm that your backup policy is adhered to
In the case of Spanning Backup there are a few issues to be aware of.
- When a document is recovered it is a new Google Apps document. Any references to the original will not be replaced by the restore operation. This will affect Sites that link to Apps documents, shares of the original, and published documents.
- When a shared document is recovered, the new document is retains the shares of the original but the ownership changes to the user that performed the restore.
- When a restore is performed, a folder is created to contain the restored documents. This folder is treated like any other, including taking part in subsequent backup cycles. There are opportunities for confusion about which version of a document is which.
- The backup can only be used to recover to Google Apps and not as a path to another service
There will be good reasons for these issues and the design fits well with organisations where the individual user is responsible for their own environment (like with a personal computer). However, those familiar with IT-managed filestore could be surprised, unpleasantly.
2 comments:
Hi Dave-
Thanks for the post. I'm interested to know if three three limitations you describe with Spanning Backup are unique, or if they apply to other solutions as well.
I'm not sure it's technically possible to retain links to restored documents, since by definition they really are new docs. Do you have an idea as to how this can be done?
Similarly, with the ownership issue, I'm not sure it's possible to create a document on behalf of one user and then make another user the owner. I'm happy to be proven wrong though.
Your third point is intriguing. I can certainly see how it could become confusing to have backups of restored folders. The typical workflow we recommend is to restore docs/folders, move them into their proper location, then deleted the "Restored from..." temporary folder. Should we disable backups for "Restored from..." folders? Or is there a different design that might work better?
Your last point, that Spanning Backup only backs up Google Apps, is absolutely correct. But with the launch of Google Drive, Google Apps can contain a lot more data than before. We're seeing customers storing hundreds of times as much data in Google Drive as they did in Google Docs, and we back up and restore all of that, with unlimited storage.
Again, thanks for your analysis. I look forward to hearing your ideas.
Cheers,
Charlie
Founder & CEO
Spanning
Thanks for your interest and taking the time to respond, Charlie.
I agree that retaining the uri of the document through restore is unlikely to be possible (and certainly forbidden for a third party developer). If the original document still exists and the intent is to revert to a previous version then you could copy and paste content in its entirety ... which is probably what a user will do.
I have not checked the api but you can certainly transfer the ownership of a document but I think the new owner has to accept the transfer. Really, I am not sure that restoring a copy of someone else's document is a good idea in all circumstances ... an option perhaps? or a notification?
I think that the Spanning workflow is good and a pity that it cannot be enforced! It seems too easy to restore and then just start working in the restore folder (losing the functionality of any sharing of the original through folders).
My point about only restoring to Google Apps was directed at the issue of losing access to the apps account (maybe paranoia setting in here) because you would also lose the ability to recover (to a new account) or recover your information to another service.
Given the perhaps naive premise that in the disaster scenario (whatever it is) there is a snapshot we can recover, I do think that there are some holes in the current offerings.
I think that the case for needing a backup of GApps is well made but the current 'solutions' are at an early stage in their lifecycle and should not really give the user that they are bullet-proof.
Post a Comment