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.