Contact Us  |  Blog  |  Account  |  Support  |  DEMO

Nasuni and Google Cloud Part 3: No More Tape Trucks

For the third and final installment of my Q&A series with Brian Schwarz, the Director of Product Management at Google Cloud, we’re going to focus on file backup and recovery. The series is part of the launch of our exciting new partnership with Google Cloud Storage. We already discussed the problem of NAS sprawl, and some of the technology that makes Google Cloud Storage such an exciting player in the object storage world. Yet one theme that Brian and I kept coming back to in our conversation was the challenge of backup and disaster recovery 

Here at Nasuni, we help enterprises move file storage and backup to the cloud with a SaaS platform that gives customers unlimited capacity on-demand, file sharing across an unlimited numbers of locations, and built-in backup and DR. Often, this last use case is what brings customers to us in the first place. They’re tired of managing complex backup systems across dozens or even hundreds of global locations. Some of their sites won’t even have a DR solution in place.  

We try to simplify all that, and it was fascinating to talk to Brian about how Google Cloud Storage supports the simplification of data protection as well. Here’s the final edited excerpt of our conversation: 

Brian: Some of these data protection solutions are stuck in the past. I live in Silicon Valley and I still see the tape truck driving around!  

Russ: It seems like a really antiquated idea, sending physical tapes on a truck to some warehouse.  

Brian: And then, if you want it back, it’s literally going to take a day or two to get it back. 

Russ: That’s if you can find it.  

Brian: Right. It makes more sense to use cloud object storage and have good software like Nasuni on top of thatThat way, people don’t have to worry about these recovery processes and how the process is going to work, or how long it’s going to take. People sometimes forget about the hassle involved until disaster strikes.  

Russ: But when they need it, they really need it, and it absolutely has to work. That’s the key. That’s one of the reasons we made sure our recovery processes are all testable, so customers can practice those restores and DR events and know it’s going to work. 

Brian: Another really underappreciated capability that factors in here is how Google Cloud Storage can cover multiple or dual region configurations. You can create a single bucket that spans different regions, say, U.S. East and U.S. West, and you can put things into the bucket from either side. You can read from either side, and it’s all got appropriate strong consistency in terms of how the reads and writes work.  

Russ: It hasn’t always worked that way, right? Copying storage around used to be really complicated. 

Brian: You had to set up two sites. You had to set up some kind of replication connection between them, synchronous, or asynchronous, or periodic. And then you had to manage the fact that there were two namespaces, and they may or may not be in-sync with each other. The Google Cloud Storage technology has fundamentally changed that. You can literally create a bucket that’s a continent-sized bucket, and you get a namespace. So, if one of the sites were to disappear, you’re still whole. 

Russ: That’s a huge advantage in terms of disaster recovery, which is something we’ve focused on from the start here at NasuniWhen our customers switch over to Nasuni, they don’t need to worry about file data backup or DR anymore. All their file data is continuously versioned to the cloud and they have access to cloud-based disaster recovery as well. This protects them against local or even regional events.  

Brian: This works well with Google Cloud Storage, because you have the option for dual or multi-region. If a customer were to activate one of those options, their underlying file data would be copied to multiple regions, which is great for DR. If they wanted to protect themselves from the loss of an entire cloud region for some reason, it’s super simple to turn on the multi-region option. And yet they’d still have this one namespace. They wouldn’t have to manage the second bucket. 

The other thing that’s killer about it is you get implicit automatic failover. One of the hardest things in DR has always been managing the failover. When you only have one namespace, the failover is a nonevent. You just continue to read and write to the same bucket. Your network path may change. You may end up in U.S. Central instead of U.S. East, but you’re still reading from and writing to the same bucket. This concept of a single namespace that can span regions makes things much easier.  

Russ: Sure, because one of the challenges with DR and data protection in general is that it’s costly to have smart people go set this up and manage it and configure it globally. That’s one of the reasons we strive for simplicity in all aspects of our product. We know how much IT has on its plate today. The more we can do to simplify life for IT, the better, whether that relates to automatic DR that extends to all your locations, or a more powerful management console.  

Brian: Overall, this cloud-based approach to data protection and DR definitely simplifies the IT administration aspect of it, which is, as you know, one of the more complex and costly parts of IT. A modern, cloud-friendly or cloud-centric approach to data protection is just better. Not the tape truck. 

I’d have to agree. In general, I hope you enjoyed these excerpts from our conversation. We also delved into some exciting technical details about Google Cloud Storage that got my product management wheels spinning, and I’ve already begun talking to our engineers about how we can leverage some of the features of Google’s technology to make our software platform even more powerful for our customers.  

Needless to say, we’re very excited about this partnership, and what it’s going to do for our customers in the years to come. To find out more about enterprise file storage with Google Cloud and Nasuniregister for our upcoming webinar.  

Leave a Reply