Start following us @vembustoregrid as you might be missing some updates already!

The above post was written by Lenin Srinivasan of Vembu Technologies. Vembu Technologies is a backup software vendor whose product, StoreGrid, powers the online backup services of a large number of service providers across the globe. Besides remote backup, StoreGrid is also used for on premise backups of workstations and servers at various companies & universities.

Vembu Pro Online Backup Service allows Value Added Resellers and Managed Service Providers to offer online backup service to their customers without worrying about storage or hardware infrastructure.

If you are in the web hosting industry you probably would have heard ‘cPanel’ very frequently. We had some active developments with the cPanel team and now we have a complete integrated solution with cPanel / WHM for managing domain backup and restore.

So, here we are at the cPanel automation bootcamp to showcase StoreGrid Hosting Provider Edition, designed for Hosting and Cloud Service Providers to deliver full and self-managed backup and recovery services. With extended support for cPanel/WHM integration and effortless bare-metal recoveries with P2V migrations.

We came to Austin yesterday and had a tiring flight from SFO. I woke up early today, got ready for event and took a cab to the Sheraton Hotel to check-in and registrations. Wait a minute! isn’t the event starting only at 3 PM central? yeah!, we realized that after we reached the venue. To our surprise there were people already buzzing on the lobby wearing T-shirts with some technical names on it (just like us). We had some really good conversations with some of the folks attending the bootcamp.

I have my cPanel TV Live session tomorrow Tuesday 11am CST. I plan to walk through StoreGrid Hosting Edition overview and competitive advantage. I’m joined by Srivatsan Venkatesan from Vembu (Vice-President, Product Management).

As we get in to the final stretch of preparation – I’m really hoping to see many of our partners, cPanel users and of course with our competitive brothers and sisters!

The above post was written by Lenin Srinivasan of Vembu Technologies. Vembu Technologies is a backup software vendor whose product, StoreGrid, powers the online backup services of a large number of service providers across the globe. Besides remote backup, StoreGrid is also used for on premise backups of workstations and servers at various companies & universities.

Vembu Pro Online Backup Service allows Value Added Resellers and Managed Service Providers to offer online backup service to their customers without worrying about storage or hardware infrastructure.

Addition of CloudNucleus strengthens our current Vembu offerings in the areas of Failover virtualization, P2V (Physical to Virtual Migration), P2P (Dis-similar hardware migration), Disk Imaging and Bare Metal Restore. Our partners have always been asking us for improvised support for offering enterprise class Disaster Recovery services and by this acquisition we proved our commitment to the channel one more time. Here’s what our CEO, Sekar Vembu said regarding this acquisition, “This combination is all about accelerating our ability to bring key functionality to our MSP and MHP partners. We’re combining best-of-breed storage technologies, two winning employee populations with similar reputations for customer focus, and two experienced management teams with highly complementary visions for the future of information management. This represents a significant win for the companies, our collective customers, employees and partners”

We intend to integrate the CloudNucleus technology offering into StoreGrid and deliver a unified Data Protection and Disaster Recovery software. We expect to have the first release of the integrated solution available during the end of October 2011.

“CloudNucleus’ employees, customers, and partners will see tremendous benefits from Vembu’s extensive partner community, expertise in data protection solutions for the MSP market, global presence and overall financial strength,” said Srivatsan Venkatesan, CloudNucleus’ founder and CEO.  We will now have additional resources to further accelerate the development of solutions that fulfill our mission of delivering technology that enables our partners to deliver truly differentiated services to their customers.” added Venkatesan

Srivatsan Venkatesan will be joining the Vembu team as VP – Product Management and drive the Vembu’s product development initiatives and enhance StoreGrid’s support in the areas of Virtualization backup, Continuous Data Protection and instant failover virtualization during disaster recovery.

“This would add a great tool to our company’s present Backup and Disaster Recovery Offerings” said Ed Monacelli, president of EMCS, “We are upgrading all our clients over to Business Continuity and Disaster Recovery plans and are confident to see an increased revenue from this integrated solution of Vembu and CloudNucleus”

We are confident that this acquisition will add more value to our existing channel partner base of both Vembu and CloudNucleus and enhance our core competencies to go after new set of customers. In case you have any questions regarding this acquisition, please feel free to mail us at storegrid-partner AT vembu DOT com

The above post was written by Lenin Srinivasan of Vembu Technologies. Vembu Technologies is a backup software vendor whose product, StoreGrid, powers the online backup services of a large number of service providers across the globe. Besides remote backup, StoreGrid is also used for on premise backups of workstations and servers at various companies & universities.

Vembu Pro Online Backup Service allows Value Added Resellers and Managed Service Providers to offer online backup service to their customers without worrying about storage or hardware infrastructure.

Two days ago,  Amazon announced Amazon Web Services (AWS) calculator on their blog. I can see this becoming quite useful, and am, in fact, surprised that they didn’t do this earlier.

You can access the AWS Simple Monthly Calculator here. The calculator, currently in Beta, allows you to get an idea of the kind of costs you can expect for different services that you might use. They’ve even had a stab at typical figures you might be seeing for some ‘typical use cases’.

Don’t see the use cases? You need to scroll to the right if your resolution is 1024 x 768 (or lower)  – see the screenshot above.

The five use cases they have are (comments in brackets are my own):

• A marketing website (bandwidth intensive; requests from visitors)
• A Web App (would use more of computing resources, including DB)
• A Media application (storage & bandwidth intensive)
• HPC Cluster (CPU intensive)
• Disaster Recovery & Backup (storage intensive and computing to a lesser degree)

Take the numbers with a pinch of salt (an ounce, in the case of DR & Backup). But that’s not the point – I think it is pretty bold of them to hazard a guess knowing fully well that one size won’t fit all…

Rather than take the numbers at face value, you should focus on the AWS services in the ‘mix’, i.e. the different services that AWS assume you will use for each scenario. It serves to give you a good idea of the services you should be looking at.

We’ll take a more detailed look and provide some data that’s more relevant to StoreGrid + AWS deployments. Stay tuned.

The above post was written by Lakshmanan (Lux) Narayan of Vembu Technologies. Vembu Technologies is a backup software vendor whose product, StoreGrid, powers the online backup services of a large number of service providers across the globe. Besides remote backup, StoreGrid is also used for on premise backups of workstations and servers at various companies & universities.

Vembu Home is the only FREE consumer backup solution for free local backups and optional Amazon Cloud backups. Get your FREE COPY now.

Besides this affinity for many things ‘Google’, three other events inspired this post:

a) Google announced its quarterly results earlier this month. Though revenues were almost stagnant, Google managed to deliver a higher net income of $ 1.48 bn (Qtr ending June 30, 2009)

b) Techcrunch says Bing users are twice as likely to click on ads than Google users.

c) I clicked on the ‘I’m feeling lucky’ button on Google today – more out of curiosity than out of habit! This got me thinking…

Who clicks the ‘I’m feeling Lucky’ button anyway?

So, I googled it up (note the subtle irony here) and came across a very interesting article from Nov 2007 ; here’s an excerpt:

Google cofounder Sergey Brin told public radio’s Marketplace that around one percent of all Google searches go through the “I’m Feeling Lucky” button. Because the button takes users directly to the top search result, Google doesn’t get to show search ads on one percent of all its searches. That costs the company around $110 million in annual revenue, according to Rapt’s Tom Chavez. So why does Google keep such a costly button around? “It’s possible to become too dry, too corporate, too much about making money. I think what’s delightful about ‘I’m Feeling Lucky’ is that it reminds you there are real people here,” Google exec Marissa Mayer explained, or at least tried to.

So Google left $110 million on the table two years ago! Let’s try and recalculate the figure now…

a) Google’s annual revenue in 2008 was $22 billion – about twice its revenues in 2006. 66% of Google’s revenues are from Google owned sites. I’m simply assuming that Google.com (and other country sites) account for about 50%, and properties like Gmail and other Google sites account for the balance 16%. In effect, I’m assuming that search from Google homepage(s) contributes to $11bn of the total $22bn revenue.

b) Lets assume that the ‘1% of people click on I’m Feeling Lucky’ still holds. In fact, I suspect that this number would be higher considering the increasing number of newbie net users especially in developing countries! You’d expect the people who click on “I’m Feling Lucky” to be net newbies and unable to really differentiate between organic and paid results. Those well crafted & well placed ads (like ours!) would attract their attention a lot more.

c) If the average Bing user is twice as likely as the average Google user to click on an ad, I’d argue that the average ‘I’m feeling lucky’ clicker, had he clicked on the money making ‘Google Search’ button instead, would be at least thrice as likely to click on an ad. Hence the ‘I’m feeling Lucky’ guys could account for (almost) 3% of ‘opportunity’ revenues

So, let’s do the math…

$11bn in annual revenues x a conservative 3% =

$ 330mn in increased revenues – simply by removing the ‘I’m feeling lucky’ button!

What does this do for the bottom-line?

There is no direct cost (of revenue/goods sold) for this ad inventory – unlike the ad inventory from the content network where about 75% of the revenues are paid out to the content network partner. Hence this is $330mn of PURE Gross Profit! Google typically spends 30% of its revenues in R&D & G&A expenses. Assuming this ratio applies for the incremental revenues, and taking that expense figure of 30% out ($100mn) , you’d expect them to add a whopping $230mn annually to their net income – simply by removing the ‘I’m feeling lucky’ button!

This $230mn translates to an increase (in net income) of over 5%

I believe this is too tempting an opportunity for Google to pass up! When the going is good, its easy to say stuff like “It’s possible to become too dry, too corporate, too much about making money… “ . In the current economic climate, you can expect Google to milk every opportunity they have. After all, they still ‘answer’ to Wall Street!

Considering all this, the “I’m Feeling Lucky” opportunity is too much of a potential cash cow (or sitting duck, or low hanging fruit – pick your metaphor) to pass by. Remember, it translates into a direct increase of 5% in net income!

Of course, when it happens, Google won’t tell you the real reason! Expect to hear something like…

“…extensive research conducted by Google showed that the absence of the I’m Feeling Lucky button translated to a user taking 6 milliseconds less – to reach the results page he was looking for. As much as the ‘I’m Feeling Lucky’ is a part of Google history, removing it makes for an enhanced user experience, and finally, Google is all about the user’s experience. So, with a heavy heart…”

As some people say, It’s all about the Money, Honey!

Remember, you saw it here first!

The above post was written by Lakshmanan (Lux) Narayan of Vembu Technologies. Vembu Technologies is a backup software vendor whose product, StoreGrid, powers the online backup services of a large number of service providers across the globe. Besides remote backup, StoreGrid is also used for on premise backups of workstations and servers at various companies & universities.

Credit : Wikimedia Commons

Ah, the price of fame!

Tim McGuire of  “The Backup Plan” has been offering his customers ‘Vembu powered’ online backup services since January 2007. His company’s website is http://thebackupplan.com

All’s been well, and Tim has been steadily signing up new customers and backing them up!

However, in recent times, in spite of more business, and a huge traffic surge, a smaller proportion of his website visitors are really keen on his backup services!What happened? Well, Hollywood happened…

I have Google Alerts set up for various terms, and ‘backup’ is obviously one of them. As a consequence, I get snippets on everything from generator backups to data backups. Last month, I noticed a couple of alerts for ‘The Backup Plan’. I clicked on the link expecting to see something about Tim’s firm, but was surprised to see JLo’s smiling face instead! Apparently, “The Backup Plan” is the title of a new movie starring JLo. The movie is scheduled for a 2010 release but the spin doctors are already hard at work, and legions of crazed fans are typing thebackupplan into their browsers & search engines – hoping to see more on Jlo!

Not one to disappoint, Tim has even created a link for fans – that takes them to another site that focuses on the movie!

I’d emailed Tim last month asking him if he was being wooed by Hollywood, and this is what he had to say…

“…I am actually getting a brisk amount of traffic coming from people searching for J-Lo.  Unfortunately, not a lot of them are interested in backing up.  I did get a call from the movie people themselves, but they are mostly interested in seeing if I can link to their site, but they actually do not have one set up yet.  thebackupplanmovie.com is actually my site also; I started that when the traffic was spiking to my main site.  I wanted to try to divert the movie traffic to a site just for the movie, and leave my customers, prospects, and partners as the ones hitting my server.  So, on that site, I just started blogging about the movie and actors, and giving the fans of the actors a place to chat about the movie….”

In fact, when I last checked, Tim has even written an ode to The Backup Plan & JLo! He also blogged about the launch of the movie’s website and called it ‘cute’. He almost seems to be enjoying his new role; it certainly looks like Tim’s crossing over to the dark side! You could help avoid this by visiting his site; it would be great for him to get more people looking for the real backup plan!

It will be interesting to see how his traffic jumps when The Backup Plan (movie) releases in 2010! I’ll save that for a new post…next year!

The above post was written by Lakshmanan (Lux) Narayan of Vembu Technologies. Vembu Technologies is a backup software vendor whose product, StoreGrid, powers the online backup services of a large number of service providers across the globe. Besides remote backup, StoreGrid is also used for on premise backups of workstations and servers at various companies & universities.

For starters, Wolfram Alpha is NOT a search engine – its (what they call) a “computational knowledge engine” – it generates output by doing computations from its own internal knowledge base, instead of searching the web and returning links.

Slight detour to StoreGrid…

StoreGrid has a feature called “Local to Remote Migration” (LtoR) wherein you can ‘seed’ a backup server with the 1st full backup and can therefore start with doing only incremental backups from day 1 itself. You’d typically take advantage of this feature for ‘first full backups’ that you think would take a long time.

How much time will the first backup take? Ask Wolfram Alpha…

For example, if you had 10GB and wanted to know how long it would take over a 1Mbps line (For asymmetric broadband plans, remember that you should need to look for the upload speed – NOT download), simply enter “data transfer time 10GB, 1Mb/s” – try it out using the box above.

See the answer, and if you don’t have the time, go the LtoR way! Go ahead, give it a spin.

Click here for more examples of “Web & Computer” stuff you can use Wolfram Alpha for. A larger list of possibilities is here – and includes things like knowing how many calories you had for breakfast and getting information about satellites.

What’s more, it even knows the meaning of life!

Have fun!

The above post was written by Lakshmanan (Lux) Narayan of Vembu Technologies. Vembu Technologies is a backup software vendor whose product, StoreGrid, powers the online backup services of a large number of service providers across the globe. Besides remote backup, StoreGrid is also used for on premise backups of workstations and servers at various companies & universities.

I am actually quite surprised by the hype around deduplication and the adoption it seems to have gained in the enterprise. The reason I am surprised is similar to the one I articulated in my previous blog post: “Synthetic Full Backup in the online backup world – Are we inviting trouble?“. The crux of my argument is that backup and archiving is about building redundancy to the data and not about eliminating redundancy in the name of efficiency of storage or network bandwidth. So it is my contention that wherever feasible we should have as much redundancy to the data (that needs backing up) and only under unavoidable circumstances should we resort to using synthetic full backup or deduplication. Actually, let me state this more strongly: “avoid falling for the synthetic full backup or deduplication hype if you can!”

But who am I to say this. I am neither an “industry expert” nor am I Steve Jobs to say “this is what is good for you; take it or leave it”. Given that we are a niche company trying to grow (and growing) in the face of industry giants, we are actually contemplating building deduplication support in our data backup software, StoreGrid. While not many of our customers/partners are asking for it, we do get the occasional prospect saying that deduplication (rather, the lack of it) is a show stopper feature for them!

As we started thinking about and designing the best way to support deduplication in StoreGrid, we encountered many options to consider and many complexities to be handled. But at the end, we were left with a fundamental question – whether a full-fledged deduplication is indeed possible in the online backup world! Before I explain some of the options and the complexities, and why we think a full-fledged de-duplication may not be feasible in a pure online backup scenario, let me first get into a broad overview of the two deduplication approaches…

Deduplication at the source (client) vs. at the target (backup server) : There are vendors who claim they do the deduplication at the source (i.e. the client system that is being backed up) as opposed to others who claim that they do deduplication at the target (i.e. at the backup server). If deduplication is done at the source then it is easy to deduplicate data at a block level across all files within the source system. If deduplication is done at the target then it is equally easy to deduplicate data at a block level across all files across all the client systems backing up to the backup server. Quite obviously doing deduplication across all files across all clients will be much more effective than doing deduplication only at a client system level. It is theoretically possible to do deduplication at the source system and still be able to deduplicate across all systems backing up to the backup server. In this case, each client (source) has to continuously update itself with the meta-data of the blocks that are being stored in the backup server. The meta-data in this case would simply be the checksums of the blocks. These checksums are looked up to identify similar blocks of data. I have not personally tested such a product myself – i.e. the ones doing deduplication at the source system and still being able to deduplicate across all systems backing up to the backup server. But this may not be as efficient in terms of performance as compared to doing the deduplication at the backup server end, especially if the backup/storage server resides at a remote data center (and the meta-data needs to be downloaded each time from the remote server).

Armed with this background, lets dive deeper into the implications of these ‘approaches’ in the online backup context…

Option 1: Deduplication at target
One of the most important requirements in the online backup domain is that the data that is backed up is encrypted before the data leaves the source system and is sent over the internet to the remote data center (where the data is stored). Deduplication works by finding similar blocks across all the files and physically storing only one copy of the block in the storage system. And encryption works by destroying all patterns in a given data and making the data random. Because of the way encryption eliminates all patterns, trying to do deduplication on a set of encrypted files will have no effect – i.e. finding similar blocks of data across encrypted data will not be of much use as encryption would have eliminated all patterns. That means doing deduplication at the remote storage end, where all the data from different clients systems are encrypted and stored, is technically not possible. The option of not encrypting the data that is being backed up to the remote data center is not really an option in the online backup world.  Another point to note is that deduplication at target doesn’t really help much in the case of an online backup scenario – clients still send all data across and hence don’t save anything on bandwidth! Of course, you save on ‘server side storage’ but optimizing this, I’d assume, comes a distant second to optimizing bandwidth utilization – for online backups!

Option 2: Deduplication at source – with a common encryption key
As I said before it is theoretically possible to do deduplication at source and still be able to deduplicate across all client systems in an organization. In order to do that, either the data should not be encrypted during backup or all the client systems will have to use a common encryption key to encrypt the data. Not encrypting the data is not really an option with online backups. Using a common encryption key would mean that for each block of data that is backed up the checksum signature of the unencrypted block is also sent to the backup server where it is stored. Every client that is backed up should look up this database of checksums stored in the backup server before sending a block of data to the backup server. Though this can be done efficiently, I am not really fond of this option, because of the performance penalty, considering that the backup server is at a remote location in the case of online backups.

Option 3: Deduplication at local target backup server – with offsite replication
The only practical option I can think of is to have a deployment model where all clients in an organization backup to a local backup server – without encryption. The backed up data is deduplicated at the local backup server and then encrypted and sent to a remote backup or replication server. This deployment model will ensure that the deduplication is done on data from across all clients backing up to the local backup server.  Depending upon a customer’s preference, the local backup server can either keep a copy of the deduplicated backed up data (for quicker restores) or the backed up data at the local backup server can be purged (not recommended) once the data is moved to the remote backup/replication server.

In summary, we prefer the last approach, viz. doing the deduplication at the target backup server which is deployed locally at the site where clients systems are. This would allow the client to backup to the local backup server without encrypting the data – thus facilitating  deduplication at the target. And for offsite storage, the data from the local backup server would be deduplicated, encrypted and sent to the remote backup or replication server.  This would also ensure that the benefits of bandwidth savings associated with deduplication are also achieved.

I look forward to feedback & suggestions on other ‘better’ ways of implementing deduplication in the online backup domain!

The above post was written by Sekar Vembu of Vembu Technologies. Vembu Technologies is a backup software vendor whose product, StoreGrid, powers the online backup services of a large number of service providers across the globe. Besides remote backup, StoreGrid is also used for on premise backups of workstations and servers at various companies & universities.

What is Synthetic Full Backup, anyway? Synthetic Full Backup is a way to create a new full backup without actually doing a full backup. The way it is done is by combining a previous full backup and the subsequent differential/incremental backups to “synthesize” a new full backup. Note that all of these are done at the backup server and hence it does not involve actual transfer of data from the clients to the backup server. Here is a definition of synthetic full backup on the web.

The advantage of using a synthetic full backup is that the client systems (the production servers and the user desktops/laptops) do not have to do a complete full backup periodically. This would reduce the load on client systems and the time taken for periodic full backups quite significantly. This is especially much more attractive in the online backup world because synthetic full backups eliminate the need to transfer large amount of data (involved during full backups) over the internet every time a full backup needs to be done. So far so good! So why not implement this right away considering that the advantages are so obvious. Hold your horses…

During synthetic full backup, the process of “synthesizing” a full backup is done at the backup server end. In order to “combine” a previous full backup with subsequent incremental/differential backups, the backup server should have access to the encryption key used to encrypt the backup data. Note that in the online backup world the encryption is done at the client end (the production servers and the users’ desktop/laptops). One of the most debated topics in online backup is about the security of the data that is backed up – will the service providers have access to the backed up data of their customers? Almost all online backup solutions, including StoreGrid, encrypt the data before the data is sent over the internet to the service provider’s storage cloud. And during restores the encrypted data is first restored to the client and then decrypted at the client end. So unless the backup server is given access to the encryption password, temporarily at least, synthesizing a full backup from a previous full backup and subsequent incremental/differential backups would not be possible.

But there are workarounds that can be implemented which would avoid the need to decrypt the encrypted data in the backup server for synthesizing a new full backup. Let me describe the workaround we are planning to implement and the resultant additional risks this introduces…

Firstly, for every file, StoreGrid does a full backup and then subsequently does differential backups (which is the block level differences between the current file and the content of the original file that was backed up during the full backup). This is done because if we were to do subsequent incremental backups (that is the block level differenced between the current file and the content of the file the last time it was backed up either incrementally or fully) all the time, instead of differential backups, then it is very difficult to implement versioning.

This is because for restoring the latest file we need to maintain the full backup file and every incremental backup that was done. In the case of block level differential backups, the latest file can be restored using the full backup file and the latest differential backup that was done.

So versioning is easier as we can delete the differential backups that are not required to be kept. This is illustrated in Figure 1 below.

Figure 1

Considering the way we are doing full backups and differential backups, we plan to implement synthetic full backup without actually physically combining a previous full backup and a subsequent differential backup. Instead, as illustrated in the Figure 2 below, we would simply create a reference in the database for a synthetic full backup with the information about which previous full backup and the differential backup make up the synthetic full backup in question.

Figure 2

This information would have to be used only during restores. Thus by just keeping the references of full backups and differential backups required to make up a new synthetic full backup, we can eliminate the need to have the backup server decrypt the data for combining backups to synthesize a full backup.

What are the risks introduced by the above process? If we have to follow the above approach (having just references in the database without actually physically combining different backups) forever by actually doing only periodic synthetic full backup (to avoid a normal full backup), then, as illustrated in Figure 3 below, restores can become more complex and time consuming.

Figure 3

As during restore of a latest file, the first full backup file and every subsequent synthetic full backup file have to be restored along with the latest differential backup for that file. If this involved tens or hundreds of synthetic full backups then the restore process will surely become quite inefficient. Besides a simple restore of the latest file could mean restoring data which was stored months or years before. This introduces additional risks as even if one intermediate block of data from a synthetic full that was done months before is corrupted for some reason then all the backups done after that would be invalidated and cannot be restored. This is a serious risk. This risk can be eliminated either by physically synthesizing a full backup by decrypting the data when synthetic backup is done or by actually doing periodic full backups without relying on the synthetic full backup feature. The former option would mean that the backup server should have at least temporary access to the encryption key which introduces security risk. The latter option makes the restore process inefficient in addition to increasing the risk of losing data because of a small corruption in a block of data stored months before.

What is our take? We strongly believe that the fundamental philosophy behind having a robust and foolproof backup strategy is to have as much redundancy for the data as possible. Any backup strategy that sacrifices redundancy for storage efficiency or for reducing time taken for backups should be avoided if feasible. Hence, though StoreGrid would have support for the synthetic full backup feature in a few months time, we would strongly advise our partners to thoroughly analyze it and understand the implications before using this feature. Our recommended approach will always be to do periodic full backups of all the data. Perhaps, one can reduce the frequency of complete full backups by doing frequent synthetic full backups in combination with less frequent complete full backups. We would certainly not recommend completely doing away with a normal full backup altogether.

This was exactly the sentiment expressed by some of our partners when we spoke to them about this feature. Like in many other spheres of life, ‘natural’ is better than ‘synthetic’, I guess!

The above post was written by Sekar Vembu of Vembu Technologies. Vembu Technologies is a backup software vendor whose product, StoreGrid, powers the online backup services of a large number of service providers across the globe. Besides remote backup, StoreGrid is also used for on premise backups of workstations and servers at various companies & universities.

Hope you enjoy reading it.

Note: Backupanytime does not use our product, StoreGrid, for their backup service. I believe they use our competitor’s product.

The above post was written by Sekar Vembu of Vembu Technologies. Vembu Technologies is a backup software vendor whose product, StoreGrid, powers the online backup services of a large number of service providers across the globe. Besides remote backup, StoreGrid is also used for on premise backups of workstations and servers at various companies & universities.