Moving from Vembu Storegrid to RBS RBackup Online Backup


If you’re moving from Vembu Storegrid to RBackup, there are some differences between our software and theirs that you should be aware of. This article will help make the transition easier.

Note: This article changes often. You might want to subscribe to it by email.

For those who are comparing RBackup to Storegrid, these are some points to consider. We have important reasons why we wrote RBackup to work the way it does, and we want to set your expectations and correct some widespread misconceptions.


  • RBackup’s backups and restores are slower than Storegrid – sometimes much slower.   Read More
  • You will not have direct access to the endpoint software except at the endpoint’s console using controls on the RBackup endpoint software.   Read More
  • If you use RBackup’s BitBackup technology to back up just the changed parts of large files, RBackup will require at least as much local cache space as the native size of the files for which BitBackup is used.   Read More
  • Currently RBackup runs on Windows only. It has no support for Linux and Mac except through mapped drives and Windows virtual machines running on Linux or Mac.   Read More
  • Licensing models are different. Although you can buy RBackup for as little as $350 on our Subscription Licensing model (similar to MCALS), most Partners buy the Permanent Licensing model.   Read More
  • If you benchmark test RBackup against Storegrid, you are comparing apples to oranges. Read More


Licensing Models

In Storegrid’s licensing model most Partners just “rented” the software. You bought monthly licenses that expired with use, called MCALs. You had to continue to buy these expiring MCALs to keep your software running. Some features in the software used up MCALs quicker than expected, causing problems. It was difficult to control costs and estimate your exact costs of doing business.

At RBS we sell software under three licensing models – Permanent Licenses with no mandatory recurring fees, Subscription Licenses on a per endpoint basis (similar to MCALS), and Subscription Licenses on a per gigabyte basis.

Permanent Licensing – By far the most popular model, Permanent Licenses never expire. When you buy 200 Licenses, they are yours forever and do not have to be renewed or bought again. Permanent Licenses are based on the number of endpoints serviced, and on the features the endpoints need.

Permanent Licenses recycle automatically. If you take an endpoint out of service, its licenses automatically recycle back into your available license pool and you can reuse them with new endpoints.

Permanent Licensing like this: You first buy one of our base packages at this link:

All of these packages include a Maintenance Subscription. After your Maintenance Subscription expires you may renew it if you like, at prices listed here:

Permanently Licensed software will not stop working if you don’t renew Maintenance. You just won’t have access to the Partner’s Portal, Tech Support, the Hot Site, the Server Locator, software upgrades, or the other goodies that go along with having an active Maintenance Subscription.

Subscription Licensing – An alternative to buying your software outright, under our Subscription Licensing Models you can pay only for what you use, and start for as little as $350.

There are two options for subscription licensing. You can pay for the number of licenses you use (like Storegrid), or for the number of gigabytes stored on your RBS Server (like some other vendors – Novastor, Asigra, etc.)

Under the Subscription Licensing model for licenses you buy blocks of Monthly Licenses in advance and use them as you add end user accounts to your RBS Server. Once a month your License Balance is charged for the number of Monthly Licenses you have used during the previous month. When your balance starts to get low, you will get an email and can top off your balance online, with your purchase credited immediately.

If you opt to pay per gigabyte you will be billed monthly for the amount of storage space (compressed) that your endpoints use on your RBS Server.

Here is a fuller explanation of how our licenses work:

A different basic approach to online backups.

You’re used to Storegrid doing things the way Storegrid does. Here at RBS we have different opinions about the correct way to do online backups. We wrote our software around Industry Best Practices, with widely used protocols in place. Vembu did not.

That apache web server! – No IT guy in his right mind would agree to install an old, unpatched Apache web server on a customer’s server. Vembu’s reasons for using an Apache web server included allowing them to write simpler Client software in PHP and Java, using Apache to run the Client’s user interface, and to allow you to manage your endpoints remotely.

It also allowed Vembu to use as many as fifteen Public Domain and Open Source modules instead of writing their software from scratch like RBS does. Why go to all the trouble to write your own software when you can just download it free from the Internet, change it up a bit, and then sell it as your own?

This solved an immediate problem (getting cheap software to the market quickly and making a little money fast) but it eventually crumbled under the weight of increasingly outdated software that Vembu couldn’t maintain because they didn’t own the source code.

So, it just got older and older, developing more problems as newer operating systems and databases hit the market, until it was just too old to be profitable for them doing an increasing amount of tech support.

Security – Then there was that major security exploit published back in August 2014, that Vembu publically denied and refused to try to fix, even in the face of published evidence and an exact methodology for hacking Storegrid and compromising customer data.

Here’s an article discussing it:

RBackup’s security is state of the art, and since we own our technology and source code, we can upgrade quickly when a new exploit hits the Internet – usually overnight.

Local Queue Space – Storegrid uses an old protocol called RSync to sync changes made to files at the local level with the “backup” files on the Storegrid server. RSync was never intended to be used as an online backup protocol. It was intended to distribute patches to software applications back when modems ran at 300 baud over telephone lines, and eight inch floppy disks only had 250KB of space.

RSync was great at what it was intended to do, and not good at doing online backups EXCEPT that it requires very little local cache space. That’s a good thing if you have limited drive space on an endpoint, but it’s a bad thing if you need to comply with HIPAA or any other security and privacy regulations, or if you just like to keep your data secure.

RSync works by comparing (in real time) the source file (locally) with the target file (on the storage server) and transmitting only the changed parts of the file to the server, where they can be “patched” into the target file. It’s GREAT for patching 1980s software.

Instead, RBackup uses a very secure protocol that encrypts, compresses, deduplicates, and digitally signs backups before they are sent offsite. Our process is far more secure and reliable (and MUCH newer,) but it requires more local drive space to be used as temporary space during preparation.

RBackup may appear slower than Storegrid.

If you compare RBackup and Storegrid side by side you may see that Storegrid backs up data faster, sometimes much faster. However, this speed comes with some extremely critical risks that you should be aware of.

RBackup is not Storegrid. RBackup does things right, and sometimes doing it right takes longer than doing it wrong. Storegrid cut many corners to improve “apparent” performance while sacrificing reliability, security, privacy, maintainability, and stability.

RBS will never trade security for speed, any more than we will ever require installing an out of date Apache web server missing many critical security patches inside your clients’ networks – as Storegrid does.

RBackup has many controls that can be tweaked to speed up or slow down its operation. As examples, changing the encryption method, using archive bits to select files, increasing CPU utilization, or giving RBackup more bandwidth through its throttling controls.

The following article has some information on speed, and another link to even more info on speed. Be sure to read the other link. It explains the complicated, exhaustive process RBackup goes through to work its magic, and explains why it needs to do all this to assure compliance.

Storegrid, instead, uses an outdated protocol called “Rsync” which is not compliant and was never intended to be used for online backups. While it is faster than our high security protocol, it is dangerous and insecure, and should never be used to back up critical files any more than xcopy should.

Support for Mac and Linux – Because we use Microsoft tools to write RBackup, our software will not run on Linux or Mac. RBackup runs only on Windows. However, our Server can use a Linux storage array by mapping it to Windows, and our Client can back up Linux and Mac by mapping drives.

Our Client can also back up Macs and Linux if you run our software in a Windows VM that has access to the files you need to back up.

We are currently working on projects that will eventually give us native Mac and Linux clients and a native Linux Server.

Benchmark Testing

While comparing RBackup to Storegrid please keep in mind that RBackup is not Storegrid. We do things right, and therefor the two platforms are quite different. If you demand Storegrid’s speed and outside direct access to your endpoint software through an on-endpoint web server, then you are willing to sacrifice your users’ network security and the integrity of their backups, so please just keep using Storegrid. RBackup will seem like a dinosaur to you, and we don’t want any responsibility for the liability you are taking upon yourself.

Do not test the RBackup and Storegrid endpoint agents on the same computer. They will interfere with one another with unusual results.

RBackup installs a website on its Server that is used to control its server and manage its clients. (RBackup does not install a web server on the Endpoint.) It uses Microsoft’s IIS web server, which it will download and install if necessary. RBackup uses port 80 by default for its web service. If you install RBackup on the same server as your Storegrid server, and your Storegrid server also uses port 80, change the Storegrid server to some other port.


No on-site server required. – The Storegrid software started out life as peer-to-peer software. Every Client was also a Server. You’re probably used to installing a Server out at some of your customers’ sites, where all the local workstations back up to the on-site server, and then that server “replicates” offsite.

This is very different from our approach, which uses a true client/server architecture. So, we have pure Clients (the endpoint software) and Servers (the data center computer that receives and stores backups).

Each of our Clients backs up directly to the offsite Server. Our Clients can also mirror their backups to three locations simultaneously – the offsite RBS Server, any local device like a shared drive, and also to cloud services like Google Drive and DropBox.

Restores can be done by any Client from the local shared drive at full local network speed. If the local device is not available, restores are done from any of the other offsite locations, automatically.

With our RBackup you will no longer need a local server.

Replicating the Offsite Server – You are used to being able to replicate your main storage server to another location, but not with full automatic failover and recovery.

We call it Server Mirroring. RBackup can maintain two or more Servers in sync, in the same data center or geographically separated. If one server goes offline, backups can automatically switch to other available Servers, no matter where they are. When the offline Server comes back online, the other Servers will sync their data with it and backups will resume to it. Your end users will never see a service outage.

Your Free Automatic Hotsite – You can have an automatic failover server even if you don’t have two servers! With your Maintenance Subscription, you have a free Hotsite Server in the RBS data center in Memphis, Tennessee. Just log into your Partner Portal account and turn it on. When you do, we start to monitor your RBS Server.

If your Server goes offline, we immediately switch on your Hotsite Server here and your backups will come here to Memphis. Your users will see no service outage. When your Server comes back online, your backups will automatically switch back to your Server, and you can then download the backups that were sent to your Hotsite.

Programming Methods and Tools – Storegrid is a hodgepodge of fifteen Public Domain and free Open Source projects originally written for Linux, that Vembu simply downloaded from SourceForge and cobbled together with PHP and Javascript.

RBackup was written from scratch using all Microsoft Visual Studio tools, at a very low level. We fully comply with all Microsoft’s Best Practices for handling all of its products the correct way. So, we do things with Windows products exactly the way Microsoft recommends.

Starting with software originally written for Linux, and then porting it to Windows, the Storegrid software has never handled Windows correctly because it was never intended to run on Windows.



Please contact us if we can answer further questions about all of this. Our phone number is in the USA – 901-405-1234. Our email is: You can also reach us through the Live Chat on our website at



About The Author

Rob Cosgrove /

Rob Cosgrove is President of Remote Backup Systems, developers of the fully brandable RBackup Online Backup software platform, powering more than 9,500 Service Providers, MSPs and VARs wordwide since 1987. He is the founder of the Online Backup industry and author of several books, the most recent, "The Online Backup Guide for Service Providers", available at and bookstores.