Comparison between cloud backups and on-premise backups

There are several options for Google Apps backup: Spanning and Backupify can backup Google Apps data to another cloud, while CubeBackup can backup your Google Apps data to a local storage inside your company. When you are looking for a backup solution for your Google Apps domain, you might not sure which backup solution is more suitable for your company. So, the comparison of these two different backup strategies might be helpful to you.


Cloud-to-Cloud backup solutions:


1. Easy configuration
Cloud-to-Cloud backups employ web interface which is pretty easy to be integrated with Google Apps marketplace.  Only a few steps are required to setup the backup process.
2. Less administration work
All backup jobs are running on backup vendor’s servers. As a Google Apps domain administrator, you can relax with ease in most of the times.
3. A more natural choice
Google Apps is a cloud collaboration platform, with all data stored online. Backing up cloud data to another cloud sounds to be a more natural choice for most companies.


1. Higher cost

The pricing for Backupify and Spanning is about $40-50 USD/user/year, which is not so affordable.
2. No physical files accessible
With a cloud-to-cloud backup solution, all backup data are stored in another cloud with a vendor-specific format. Except restoring from the backup, you can almost do nothing with the backup data.  For example, migrating email message backups to another mail system is just impossible.

On-premise  backup solutions:


1. More affordable
Comparing to cloud-to-cloud backup solutions, the cost of local backups solutions are much lower.
2. Keep your data in your own hands
All backups are stored in a local storage (a hard disk or a NAS) inside your company’s firewall, totally under your control.
3. Get physical backup files
Backup data are stored locally as physical files, which means that you can easily export these files into another system.  For example, open docs backup files with Microsoft word/OpenOffice, read email messages using Outlook, etc.
4. Keep data from being exposed to any third party
Cloud-to-cloud backups open your data instance onto another cloud vendor which create privacy concerns. Cloud-to-local backups, which only preserve a copy of your data locally, keep you from this security concern.


1. Initial configuration is not easy
Local backup solutions require a desktop app to access the local storage. Due to the limitation of Google Apps Marketplace, desktop apps cannot be easily integrated into Google Apps marketplace as web apps do.  To setup a local backup, domain administrators need to create a Google cloud project in Google Developers console and authorize data access to GDrive, Gmail, Contacts and Calendar.
2. A reliable physical server and a local storage are needed
Unlike cloud-to-cloud backup solutions, which are completely disk-free, on-premise backup solutions require a reliable server as well as a large and robust local storage.


If you do not have enough budget, or you’d like to fully control your backup data, or there is any possibility that your company might migrate your cloud platform from Google Apps to Office 365, an on-premise backup solution, such as CubeBackup, should be your best choice.

If you want an easier and effortless backup solution, you might consider a cloud-to-cloud backup solution.

Initial Configuration Details for CubeBackup

Some customers have been concerned that the initial configuration of CubeBackup is too complicated, and they cannot understand why a simple authorization requires so many operations. In this post, I’d like to discuss OAuth 2.0 Service account and present a more detailed explanation of CubeBackup’s initial configuration.


Although it may seem complicated at first,  the initial authorization process (described here) only consists of two steps:

1.  Create a Service Account in Google Developers Console.

A Google OAuth 2.0 service account allows the administrator of the Google Apps domain to authorize an application to access user data on behalf of users in that domain. This authorization is also referred as “domain-wide authorization” or ” 2 Legged OAuth”. To create a service account, you need to login Google Developer Console with a personal account (e.g.: or  For the purposes of this step, you may consider yourself a developer of Google APIs.

2. Authorize Access to your Google Apps Domain for the Created Service Account.

Next, the Google Apps administrator should enable the service account created in the previous step to access the data in your Google Apps domain.

Q1. What is an OAuth 2.0 Service Account?

OAuth 2.0 enables a third-party application to obtain limited access to an HTTP service. Through OAuth 2.0, the application requests an access token from the specific HTTP service and then attach the token to the subsequent requests to that service. It is a modern, safe authorization standard which protects your credentials from being leaked to anyone else. OAuth 2.0 is the Google’s recommended login method for all third party applications.

A Google OAuth 2.0 service account is a variant of the standard OAuth 2.0, which enables data access to an entire Google Apps domain, not just a single Google account. This is also called 2-Legged OAuth 2.0. More detailed information is available at

Q2. Why are CubeBackup users required to create a service account themselves? Shouldn’t this be done automatically?

Service accounts could, of course, be created automatically, or even embedded within CubeBackup itself, but this would negate some very powerful advantages:

I)  By manually creating a service account, users can tailor the account to their own needs by enabling/disabling Google APIs, setting up the request quotas, etc.  They can also monitor API requests statistics in real time using Google Developer Console.

II)  A single service account shared by multiple users might overrun quota limitations. For example, the default Google Drive API quota is 1,000,000,000 requests per day, which should be sufficient for a single organization in most cases. But if this service account is shared by hundreds of organizations, the quota could easily be reached.

III)  Leaving the creation of service account to a third-party is always a potential security risk. The service account owner can monitor your requests, set request quota, and generally interfere with your business.

Q3. Why is CubeBackup’s configuration more complicated, when other web-based apps on Google Apps marketplace seem to easily integrate with Google Apps?

The situation with web-based apps is a little different. They need service account authorization to access Google Apps data, just like desktop apps, but most web-based apps/addons for Google Apps are installed through Google Apps marketplace, as explained by Google:  “When you use Google Apps Marketplace to install an application for your domain, the required permissions are automatically granted to the application. You do not need to manually authorize the service accounts that the application uses.”  

Unfortunately, this straightforward app integration is only available for web-based Google Apps tools, and not for desktop apps.  One of the strengths of CubeBackup is its ability to backup all Google Apps data to local storage, which is simply impossible with web-based approaches, due to the security limitation of web browsers.  The trade-off for this flexibility and power is that service account configuration and authorization must be done manually.

Hotfix for CubeBackup

The new version of CubeBackup, version 2.6.8, has just been released. This is a hotfix version to solve the problems caused by recent changes in Google Drive APIs. We strongly suggest all CubeBackup users upgrade to this version as soon as possible.  We are sorry for the inconvenience, but this upgrade is not optional.

What’s the problem in older versions?

A few days ago, Google made several modifications on its Drive APIs and caused some file-downloading operations in CubeBackup to fail. CubeBackup users might see lots of errors in the log files, such as “Failed on backup of Google Document entry: … Error message: One or more errors occurred. A task was canceled.”, or “Object reference not set to an instance of an object”, etc.  As a result, some Google Drive files were not successfully backed up locally. This problem happened randomly and just started a few days ago.

What’ new in CubeBackup 2.6.8?

This version is just an emergency hotfix for recent Google Drive backup problems. There are no new features added to this version. Due to the changes in Google Drive APIs, every CubeBackup users should upgrade to the new version as soon as possible.  We are sorry for all the trouble. However, as a client app completely based on Google APIs, CubeBackup must be adjusted to even minor changes in Google APIs.

Upgrade instructions:

  • To upgrade to the latest version, please select the “Check for updates” menu item in CubeBackup, then click the “Update” button. You need to exit CubeBackup and restart it for the new version to take effect.    NOTE: Simply closing the main window will not exit the application. To quit CubeBackup, please select “Exit CubeBackup” from the system tray in the right-bottom corner of the screen.
  • Or, you can quit and restart CubeBackup. CubeBackup will check for new versions every time it starts.

What if the upgrade failed?

There are possibilities the upgrade may fail and “Upgrade failed. You can try it again later.” message is given. To solve this problem, you can:

  • Download the CubeBackup hotfix file manually and unzip it into the installation directory for CubeBackup, like “C:\Program Files (x86)\CubeBackup“, to replace the old files.
  • Or, download the new version from  and reinstall it. All the application settings, configurations and user selections in old versions will be kept after the new installation, but you will be asked for the license key again to activate CubeBackup.

For some users, their Drive files backups were incomplete due to the errors in the last few days, how do I fix it?

To retry the backup for a specific user, you can open the local backup folder in Windows Explorer, then delete the folder for that user. For example, if the folder named “” is deleted, CubeBackup will backup‘s data completely from the beginning in the next backup cycle.

If you have any problems with this upgrade, please don’t hesitate to contact us.