The first step was to create a new volume just for the production data. We are going to continue on the original volume to hold backup copies of our data. As you can see from the video below we were able to create a new volume without reading the manual or trying it out first. We just started recording and everything worked as expected.

Lab Report

George Crump, Senior Analyst

Adding a Volume and Another Cloud Provider

One of the key capabilities we wanted to take advantage of during the Nasuni test was to select a different cloud supplier than our original. Our plan is to copy data between the cloud suppliers, that way if the primary cloud supplier fails we have a backup. Redundant clouds at a click of a button. From a business perspective this presents a nice option, our cache, leveraging continuous data protection, is protected and then where the data is stored in the cloud is redundant. In the case of a failure locally we can also restore data entirely from the cloud. Access to data is assured.

In a future test segment we will work through the process of restoring a failed local cache and how to recover that. The goal will be to simulate a site or server disaster and how to recover the local cache. We almost had to do that today, as our VMware Fusion server crashed (not a Nasuni issue) and the VMDK associated with the Nasuni Filer became corrupted. There is an issue with how the current version of VMware Fusion handles corrupted VMDKs. We will break this out in an upcoming entry next week.


With all that work complete we have our Windows, Linux and Macintosh (remember that Nasuni only officially supports Windows) systems now ready to start storing live data on the Nasuni Filer.

Nasuni is a client of Storage Switzerland