About Jim Zhai

iOS & OSX developer

Expected features in CubeBackup version 3.x

We are currently working on the next major update of CubeBackup, Version 3.0. A lot of improvements will be added in the new version.

1. Parallel backup
CubeBackup will allow you to choose how many accounts can be backed up in parallel. This will greatly improve the backup speed for large organizations who have fast Internet connections.

2. Bandwidth throttling
Users can limit the backup speed in office hours, which can prevent CubeBackup consuming too much network bandwidth in the day time.

3. Run as a service
Most users run CubeBackup on server operating systems, like Windows Server 2012. Making CubeBackup running as a service provides users more flexibilities and convenience.

4. Administrator email notification
Daily/weekly backup statistics, error reports, and other notifications will be sent to G Suite Domain administrators via email. Administrators will get the latest information for the backup without checking logs.

5. Team drive support
Team drive is a new feature in Google Drive and is very useful for collaboration. New version of CubeBackup will support team drive backup.

6. Improved log
More information will be added to backup/restore/error logs.

7. Bug fixes
Many bugs will be fixed in the new version.

8. Restoring the whole account
Currently, CubeBackup allows you to restore any files/data for a user when you selected the files and click the “Restore” button. In future versions, Google Apps administrators can restore a whole account with just one click, or even restore all data from one account to another account. This feature might not be available in version 3.0, but should be added to a later release, like version 3.1 or 3.2.

9. Linux version
We got a lot of requests asking for the Linux version. It is still under development and is expected to be released in a few months. The good news is: CubeBackup’s first Linux Version will have all the features as its Windows version.

We are always happy to hear feedbacks from our users, so please feel free to contact us (support@cubebackup.com) if you have any questions.

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.

Automatic backup plan for Linux servers using rsync and crontab

Linux servers are widely used by lots of companies for hosting their websites, databases, or other services.  I personally likes Linux system much more than Windows Server, not only because Linux is free, but you get better performance and more powerful tools on Linux.  To set up a Linux server, sometime you don’t actually need a physical server,  subscribing a VPS from Linode, DigitalOcean or Amazon could be a better choice.  Though most cloud server providers have  backup or snapshot services (usually not free), it’s better to have your own backup plan.

The rsync command is a ideal tool for copying and synchronizing files and directories to a remote computer, while the crontab command is used to schedule jobs to be executed periodically.  Combinding these two commands, we can setup a light-weight and effective backup solution.

Due to the difference of Linux distributions, in this article, we use CentOS/Redhat system as an example to introduce how to setup up the backup plan.  However, before that, here are several questions to think about:

First,  what data should be backed up?

Generally, we only need to backup data important to us, like website pages, databases, configuration files and personal data.  It is generally not necessary to backup data such as Linux system files, installed software.

Here  are several directories that need to be taken care of:

  • /etc directory:  Though some files in this directory don’t need to backup, I wouldn’t bother to pick them out.  And since the total size of this directory is usually no more than 50 Megabyte, it would not hurt to back up the whole directory.
  • /home directory: This is the location for personal user data of all accounts (except root),  and obviously, the backup plan should cover this directory.  However, there is a problem: There are lots of cache data, log files, download software, or history records located in this directory. It is just meaningless to backup these data.  Rather than backing up the whole /home directory,  putting only specific sub-directories, such as /home/someone/gitdata, /home/anotherone/documents into your backup list would be a better choice.
  • /var/www directory:  This is the default directory for website files. (If your web files are located in other directories, find them out and put into your backup list ).
  • /var/spool/mail:  This is where the mail data is located, and definitely should be  backed up.
  • /var/lib/mysql:  This is the directory for holding the database data.  Include this directory in your backup list.

You may have other utilities or service data scattered in other directories which need to be backed up,  think carefully and find them out before you take action.

Second, fully backup or incremental backup?

If you want to fully backup all data listed above every time, you can compose a bash script to archive all files using Linux tar command and then send (scp) the tarball to the backup location. This method works well for backup in a local area network, but might not feasible for backing up data from a remote VPS to a local computer because hundreds or even thousands of megabytes are transferred between the two remote computers each time. It is a waste of bandwidth and disk storage.

Incremental backup, which employs the rsync utility in Linux, backs up only modified data each time. For most cases, this is a right choice due to its efficiency and cost-saving.

Where to store the backup data?

Generally, backup data should be stored on a remote computer, either another Linux VPS, or a Linux computer inside your company.

How to schedule an automatic backup plan?

Cron job is the best choice to schedule command to be executed periodically, for example, a backup script can be scheduled at midnight each day.

The following are the detailed instructions for making an automatic and incremental backup:

Host A: the active server with CentOS/Redhat system.

Host B: the backup service with CentOS/Redhat system.

I.)  Make sure rsync is installed on both Host A and Host B.  If it is not installed, install it using command:

yum install rsync.

II.) Login to host B using root account (Crontab requires a root user permission, though theoretically it can be done using a non-root account, but not easy) ,  and create a directory to hold the backup data:

mkdir -p  /var/ServerBackup

III.) Generate the SSH key pair :


Two files are generated in the /root/.ssh directory: id_rsa is a private key file, while id_rsa.pub is a public key file, which must to be copied to Host A:

scp /root/.ssh/id_rsa.pub  root@A.com:/root/id_rsa.pub

IV.)  Login to host A using root account, and attach the content in id_rsa.pub file to the authorized_keys file.  If /root/.ssh/authorized_keys file doesn’t exist in host A, execute the following commands to create it first:

 mkdir -p /root/.ssh
 chmod 700 /root/.ssh
 touch /root/.ssh/authorized_keys
 chmod 600 /root/.ssh/authorized_keys

To attach the public key generated in host B to authorized_keys file:

cat /root/id_rsa.pub >> /root/.ssh/authorized_keys

Now we can use scp or rsync to transfer data from host A to host B without password required.

V.)  Modify /etc/crontab file to schedule the execution of backup script.  Add this line to the end of the crontab file:

0 2 * * * root bash backup.sh     # the script file backup.sh is scheduled to be executed every day at 2:00AM.

The content of the backup.sh script is something like this:


/usr/bin/rsync -avz -e "ssh -i /root/.ssh/id_rsa.pub"  root@A.com:/etc  /var/ServerBackup
/usr/bin/rsync -avz -e "ssh -i /root/.ssh/id_rsa.pub"  --exclude mysite/updraft  --exclude mysite/.cache    root@A.com:/var/www   /var/ServerBackup
........  (other similar commands)
/usr/bin/rsync -avz -e "ssh -i /root/.ssh/id_rsa.pub"  root@A.com:/var/lib/mysql   /var/ServerBackup

This script is just a sample and you can modify it based on your need.  You can use Linux man pages to get more usage of rsync.

Now you can rest easy without worrying about the data loss.