Nasuni Reviews

The use case specifically is to allow our engineering staff in different offices to be able to work collaboratively on the same projects at the same time. Also, another important feature for us is the ability to recover or restore data from any point in time in its history.

We have Nasuni Filers deployed at each of our offices in the US and another location in India. Nasuni is used by our engineering staff and where production engineering data is stored.

The cloud is used for synchronization from site to site as well as for backup and storing all our snapshot historical data.

We use different cloud providers for different things. Currently, hard Nasuni data is in AWS.

We use it for VDI. VDI is the direction that we are going throughout the company for consistency and user experience for DR and DC capabilities. Having the Nasuni Filers be a central element supporting the VDI solution has enabled us to have all our engineers work collaboratively in a very tightly integrated total solution.

It is very rare that we need to make significant changes to the Nasuni infrastructure to support organizational changes. On a day-to-day basis, there are new projects added across various design teams in the company. Those can be set up in seconds in Nasuni. It is just very easy to work with it. In essence, setting up the basic file structures just looks like another volume that has been shared on the network. Through the console, we can configure Global File Lock permissions for how those files can be accessed from site to site.

One of its most valuable features would be the Global File Lock capability, which is what enables our engineers to be able to work on projects collaboratively from site to site.

Nasuni offers us a single platform with a 360-degree view of our file data, which is definitely important to us. It simplifies IT operations tremendously. Because it is taking continuous snapshots, it eliminates a lot of work that was previously done when trying to manage backing up and restoring data files.

It is far less labor intensive than our previous processes. There is a console interface that is used for managing all the data repositories, what is in the cache of each appliance, the Global File Lock parameters and settings, the ability to recover files, etc. The single pane of glass interface manages all those capabilities. Things can be done in minutes through the Nasuni Management Console, which previously would have been a more labor-intensive effort with more manual processes.

Nasuni enables us to provide file storage capacity anywhere it is needed, on-demand, and without limits. We have it deployed on Nasuni appliances at our offices, but we also have the ability to create virtual Nasuni Filers that potentially could be deployed anywhere in our infrastructure.

Nasuni provides Continuous File Versioning down to the granularity of the snapshots, which occur about every 15 minutes. If there was a ransomware or other disaster type of event, only the data in the cache on the local appliance would be affected. The entire snapshot history of every file is backed up in the cloud. We can, on a file-by-file, directory-by-directory, or volume basis, recover any or all files from that snapshot history back into the local appliance. The only impact would be the time to copy the data back from the cloud snapshot back into the local appliance.

Because these snapshots occur so frequently, we can recover data to a point very shortly before the time a person wants to recover that data, e.g., within 15 minutes of when whatever happened. If somebody deletes a file or accidentally moves/loses it, then we are able to recover it within 15 minutes of that point in time. Very little data, if any, is lost with this type of operation. This has greatly relieved any concerns about IT backups and restores to the point where it is a very minimal concern. 

It frees up IT staff to work on other initiatives, because these are automated processes that occur in the background and require minimal attention, if any at all, from IT staff.

One area where Nasuni has made huge strides over the last year and a half is the time required to synchronize data from site to site. This has gone down quite a lot, but we always would like it to occur faster. 

I would like to see Nasuni provide the ability to mirror a Nasuni appliance from one site to another. They could maybe have a standby appliance that is mirrored in a different location for disaster recovery purposes. We can recover if data and a Filer are lost because of a possible ransomware event, but even that takes time to recover. If we had the ability to have a mirrored appliance, we could flip over to that mirrored device and resume instantly rather than repopulate the local appliance with data from the snapshot history in the cloud. This is another feature that we would really like to see, if possible.

I would like the ability to roll back to a prior version of the firmware, e.g., if you had a problem when you were upgrading to a newer version. They do not have this capability. This is less of a concern than it used to be. It is a much more mature product, but this would always be a very nice feature to have.

We have been using it longer than I have been in the IT management role here. I can estimate it at eight or nine years in total.

For the last several years, it has been very stable. There have been no issues.

Deployment and maintenance need a very tiny fraction of an FTE. With everything that we are doing with the appliance, it is probably a couple of hours a week.

Scalability is seemingly limitless in terms of the number of places where appliances could be deployed as well as the amount of data that can be handled. The only limitation is the amount of cache memory that is on the local appliance. So, if you needed to keep a very large amount of current data in the local cache memory, you might need to deploy multiple appliances at a site. However, it basically uses a first-in, first-out methodology for what data is kept in the cache. Any data that has been accessed or modified recently is in the cache. If it is not in the cache, it will pull it into the appliance from the snapshot history and replace the data that was accessed the longest time ago which is remaining in the local cache. However, any data can be brought into the local cache to the appliance. Therefore, we have been able to completely work within the bounds of an appliance at a given site.

All of our engineering staff are using it: designers, engineers, project managers, building information modeling (BIM) staff, and technicians. That is around 240 people in our firm.

It is being about as extensive used as it can get. It is used across all our engineering staff, covering all active project-related files. That is the extent to which we tend to deploy it. There are other file systems being used for other purposes, but we don't have the same kind of needs that would warrant using a Nasuni appliance for something like that, like we do for this. So, the Nasuni infrastructure is used really for the most business-critical applications.

Previously, the company used traditional file storage systems and big tape backup systems.

Nasuni replaced multiple older file systems and manual tape backup solutions. This has been absolutely business-critical because of the type of data that is stored on there, e.g., all our engineering client project information is stored there. Also, it is extremely resilient. It allows us to recover files if there was ever either accidental or malicious loss of data. For loss of data of any type, we have the ability to recover that data from the entire snapshot history on any file. So, Nasuni is important for day-to-day activities as well as providing disaster recovery capability on any data stored on it.

Before having the solution, it just would not have been possible to have staff in multiple offices be able to work collaboratively in some of these design applications at the same time. So, Nasuni was critical to enabling that capability, which increased productivity, allowing us to share resources more effectively across offices. Also, prior to having the Nasuni solution, if engineers wished to restore data to a prior point in time, we were limited by the capabilities of our previous tape backup solutions. This means they were not as granular as Nasuni. Our granularity is down to about 15-minute increments in time, where it might have been daily with the old tape backup solution. Nasuni is quicker when recovering data from any point in time than was ever possible with prior tape backup solutions.

Nasuni has replaced other on-premise infrastructure. It has replaced traditional file storage and tape backup solutions with a simple 2U appliance that has storage integrated into it and is connected back to the cloud for all the snapshot data.

We did have assistance from Nasuni to get the devices configured initially. It wasn't an enormously complex process. 

We did have Nasuni Professional Services help with the initial setup.

Nasuni certainly has reduced labor costs associated with managing all the data and how we manage client project data. It has greatly reduced the labor efforts and costs associated with that. It has also turned out to be a very reliable solution. As site-to-site sync performances have improved, that has enhanced the productivity for all our engineers as well.

Before Nasuni, the time investment was critical and a daily activity. It took a fair bit of time to prepare, load tapes, catalogue items, and run backups every day. Now, with Nasuni, the only time spent is when we have to customize the Global File Lock permissions for certain folders (for the engineers) so the Global File Lock mechanisms work correctly. This is a one-time activity that occurs when a project is set up and completed in minutes.

Nasuni has decreased capital costs because you don’t need to buy as much excess capacity. The CapEx cost is definitely lower with Nasuni. It is only when we either need to upgrade an appliance in an office or if we need to purchase appliances for new offices that there are CapEx costs. The rest of it is an OpEx cost.

It has reduced capital costs by over 80%.

There are annual costs that we pay for maintaining all of the snapshot history in the cloud. That is the primary cost that we pay. We occasionally buy newer Nasuni appliances or deploy them to new offices when the need occurs. That capital equipment expenses is less than the cost of buying new file storage systems. For the most part, you are trading a CapEx cost of storage equipment for an OpEx cost for management of all the snapshot data in the cloud. There are CapEx and OpEx elements to both solutions: 

• With the old school solution, you have an OpEx expense for tapes, which is relatively small. With Nasuni, you have an OpEX cost for the data in the cloud, which is larger. 
• With the old school solution, you have CapEx costs for storage equipment, which are large. With Nasuni, you have a CapEx expense when you need to purchase new appliances for offices, which is relatively small. 

It is kind of a trade off with similar costs either way.

The snapshot history backed up in the cloud is an annual OpEX expense. Occasionally we have to bump it up because the amount of storage required for all our snapshot history increases over time, but the infrastructure purchasing and support requirements are definitely simpler.

We do hardware refreshes on Nasuni appliances. So, that is not a buy it once and you're done forever kind of thing. The majority of the cost with the Nasuni is an OpEx cost for storage of all the snapshot history.

I think the pricing on the appliances is completely reasonable and fair. I have had no issues with it. 

Keep in mind that Nasuni allows their clients to choose what cloud platform all the snapchat history is saved on. Depending on the cloud platforms that your company uses, or if there are standards on such things, there may be some benefits to looking at alternative cloud providers for storing the snapshot history, because there may be some savings to be had there. At the same time, because they have that flexibility and support several different cloud platform vendors, if your company is standardized on a particular cloud vendor, then odds are Nasuni is already supported in it.

The costs are the standard licensing fees and subscription for the total size of the data repository (for the snapshot history in the cloud).

We looked at Panzura too.

The cloud piece is almost transparent to the user. Because you are interacting through the Nasuni Management Console, you are not really working directly with that cloud provider solution to access files. You could, if you wish, but you can do everything that you need to do directly through the Nasuni Management Console. The cloud happens to be the place where the data is stored and you don't necessarily need to interact with it directly.

Keep in mind the amount of data that you need to keep in your cache. So, sizing your appliance for the local cache storage needs to meet your day-to-day needs, but your actual needs are probably less than what you think they might be. If you had the ability to store 30-days worth of data in the local cache appliance, you are probably in pretty good shape. I definitely would try to understand exactly what the needs of your business are. If you have site-to-site replication needs, carefully consider the capabilities of any particular solution to make sure that the vendors that you are considering can deliver on that as well as how easy it is to work with those vendors for restoring data, if you ever needed to do that.

We haven't tried going back to a more traditional solution. This solution has done a fantastic job of meeting all our needs. Overall, we are just very happy with Nasuni.

I would rate Nasuni as nine out of 10, but I am a tough grader. It is hard to get a 10.

We use Nasuni to provide storage at various locations. It is for office-type files that they would use for day-to-day office work, such as spreadsheets. None of it is critical data.

Each group at each site has its own data store. For example, HR has its own, and finance has its own. All of these different groups at different locations use this data, and they use these filers to store it.

The Nasuni filers are on-site, and we have virtual edge appliances on ESX servers at about 35 sites globally. The data stored at these sites is then fed up into Azure and we have all of our data stored there.

The OR and DR capabilities have been a very big help for us. Previously, with the solutions we had, it would have taken weeks sometimes to get things fixed and back up and running for people. Now, it only takes a matter of minutes.

It used to be a lot of trouble to bring data back up and a lot of the time, it was read-only, so the people couldn't use it very well. Now, with Nasuni, we're able to pretty much keep their experience seamless, no matter how much trouble the hardware is in at the site.

The Nasuni filers are easy to manage, although the process is similar to what we had before. We have a report that comes out three times a day that gives us the amount of data that's in the queue to be uploaded to Azure on each individual filer. We keep track of that to make sure nothing is getting out of hand. It also tells us if the filer has been restarted and how long ago that happened. It gives us a quick view of everything and how much total we're using within Nasuni. This report is something we created on our own to keep track of things.

If a user deletes a file or a file becomes corrupted, it's easy for them to get it restored. There is very little chance that the data is going to be done. We've had a few people delete things, or they have become corrupted, and we were able to get that file back to them in the states that it was in about five minutes before they had a problem. We were able to do this without any issues. Overall, the continuous file versioning is really helpful.

The biggest and most impressive thing for us is the operational recovery (OR) and disaster recovery (DR) capabilities that Nasuni has. If a filer goes down, or an ESX server goes down, then we can quickly recover. For example, we lost a controller the other day and all of the drives were corrupted. We were able to quickly repoint all of the users to a backup filer that we have at our data center, they were back up and running within minutes, and they still have read-write capabilities. Once that ESX server was fixed, we were able to repoint everything back to it in a matter of minutes. People were then again using their local filer to connect.

Nasuni provides continuous file versioning and we take snapshots on a regular basis. Right now, we have them stored forever, but we're trying to reign that in a little bit and keep them only for a period of time. Certainly, at this point, we have a lot of file versions.

We have not had a problem with ransomware but if we did, we would be able to restore the data pretty quickly by going back to an older version of the file before the ransomware took over. It is a similar process to the DR, although a little bit different. For us, OR and DR are pretty much the same thing. We haven't had any disasters that we've had to recover from but we've had three or four hardware failures a year that we've had to deal with. The continuous file versioning has helped to fix these problems pretty quickly.

Continuous file versioning also makes it easier for our operations group. The support team is able to restore files quickly, 24/7, and it is less work for them. They have more time to focus on other problems. The end-user also has access to shadow copies through Windows, and they've used that extensively at the sites.

Nasuni has helped to eliminate our on-premises infrastructure. When we moved to Nasuni, we moved to Azure. Before that, we had a large SAN storage that we were using, and we were able to get rid of it. That was a big difference for us.

We were definitely able to save some money because we've eliminated those expensive SAN disks completely. There were some servers at our old data center that we were able to get rid of, as well. There are some new expenses with Azure because we have to pay for the space taken by the snapshots, which is why we're going to put a retention limit in place. Overall, I don't have an exact number but we were able to save money.

Nasuni is transparent to our end-users. We have it all set up as a file server through Microsoft DFS. If you were to ask one of our end-users how they like Nasuni, they would have no idea what you're talking about.

One issue that we have is related to copying data out of Nasuni. We just sold a site and it was split into two pieces. One part of it was sold to another company and we kept the other part. At the site, they have a Nasuni filer with about eight terabytes of data. Now, we have to split that data and the problem stems from the fact that the other company doesn't have Nasuni.

This means that we have to copy all of that data back to the site and into a format that they can use, which is probably just a Windows file server, and then we have to split it somehow. I'm not really sure that there's an easy way to do that. It's going to take us a little bit longer to separate this other location, and we're having to invent things as we go along.  

In these areas, it's not as simple as it could be, but it doesn't happen very often. As such, we haven't had to worry about it too often. Although it's not affecting us too much at this point, if there's a problem such that we have trouble getting data out of Nasuni, then that could be an issue. However, for the time being, it seems fine.

When we have to rebuild a filer or put a new one at a site, one of the things that I would like to be able to do is just repoint the data from Azure to it. As it is now, you need to copy it using a method like Robocopy. To me, this seems counterintuitive or like we're going backward a little bit. I would like to see a way to be able to switch them around without any problem. That said, I'm not sure if it would then cause other issues because of how Nasuni works, so it may not be possible.

We started using Nasuni in 2018 and it's been running ever since.

Up until about a week ago, the stability has been rock solid. We've actually had a few issues after upgrading to version 9.3 that we're trying to deal with. We have a couple of sites that we're still not sure if Nasuni is the problem, or if it's VMware ESX, and we're working on that. At this point, we're not thinking about rolling back because of all of our sites, only two of them have problems. As such, we think that something else may be going on.

For the most part, it's been extremely stable, with no issues whatsoever. With Nasuni, there has been very little downtime, if any. Most of the sites have never gone down and with the sites that have, there's usually some other external problem.

Overall, it's been very stable for us.

We are limited to the amount of space that we have purchased from Nasuni. If we get close to running out then we just buy more. We still have to pay for the storage within Azure, so we're trying to make sure that it doesn't get out of control. In general, we don't need to add any on demand.

Scalability is not a problem and we can add as many servers and as many filers as we need to, which is really nice. For example, instead of buying tape drives and using that type of backup system, we decided to take a few sites where we have some smaller servers and we use Nasuni to back them up. We use a separate filer to back up all of that data. It's been nice in that way, where we've been able to do things with it that we hadn't originally thought of.

If it should happen that we make a large acquisition, and we bought 10 sites, we could easily put in 10 more filers. It wouldn't be a problem.

Amongst our 35 sites, we have between 10,000 and 12,000 users. A lot of them are office-type people such as those from HR and finance. All of us, including administrators and developers, use it for this kind of thing. The developers wouldn't store code on these because that's not what it's used for. Our Nasuni environment is specifically for data to help the business run, which isn't critical to producing goods or shipping them or anything like that. That is a completely different system. Anybody who works for the company that needs to access simple office data is going to be going through Nasuni.

We have approximately 210 terabytes stored in Nasuni right now. That continues to grow at perhaps a terabyte or two per month. I don't think we'll be moving it anywhere else at this point. Down the road, we do have a very large file system at our data center that we're considering moving, but it's going to take a lot of time to do that one because it's 400 terabytes and it's a lot of old data that we have to clean up first. But that's pretty much the only area that I would see us doing something.

Later this year, we're going to start refreshing some of the hardware because we're approaching five years on some of the older stuff. As we replace it, we'll do another rollout, but it's not going to be like before. We're just going to put a new server in and put a new filer and connect to the data.

Up until recently, I would have rated the technical support a seven out of ten. We had to open a case in Australia for a problem with one of the Nasuni filers, and I haven't got a response for it yet. We had one of the support people answer a question at about three in the morning, US East Coast time, and he said something to the effect that he would send an email giving an update. After that, we didn't hear back from him until about 25 hours later, which was a little concerning for me.

Part of the problem seems to be that Nasuni currently is not set up to do 24/7 support. They said that they were going to do that, so that was a little disappointing. Typically when we call in a problem, they jump all over it and they get it fixed in no time.

From the perspective of our end-users, the servers function the same way when they're working. We had Windows filers before and now they're Nasuni, so it's basically the same thing to them.

Although we mostly used Microsoft, we did use a backup solution called Double-Take, which is now owned by Carbonite. It did the job but it had a lot of idiosyncrasies that were very difficult to deal with at times. That was the only non-Microsoft thing that we used for the data before Nasuni, and we have since stopped using it.

In the beginning, the setup was kind of complex. We did have help from Nasuni, which was great. They were with us the whole time. We had some growing pains at the beginning, but once we figured out the first three or four sites, we were able to get everything done very quickly and efficiently, with very few problems moving to Nasuni.

When we first started with Nasuni, we had never used it before, and we had never used anything like that. We were used to using Windows servers, and there was a learning curve there to figure out the best way to set up the Nasuni filers. We really had to rely a lot on Nasuni for that. Some of it was trial and error, seeing what worked best as we started rolling it out.

We were replacing a single server that was responsible for doing everything. It was a file server, a domain controller, a print server, and an SCCM distribution point. It was all of these different things and we replaced that with one ESX server, which had multiple guest servers on it, doing all those functions separately. It is much better security-wise and much better operationally.

We started with a very slow implementation. We implemented one site, and then we waited two months before moving to the second site. We tried to start with some of the smaller sites first, with the least amount of data, to get our feet wet. Also, the first site we did was the one that I sit at. The team was all there and it was our site, so we figured we should do our site first. We staggered deployment, so it was not very quick. Then, once we had three or four completed, we did three a week for three months and we were done.

After completing the first site, choosing the next sites had to do with the hardware. We had some old hardware that we repurposed, so we did those sites next. After that, we moved to the sites that necessitated purchasing new hardware. 

From beginning to end, our implementation took a little more than a year. It began in August of 2018 and finished at the end of Q3 in 2019. The time it took was not because of Nasuni. Rather, it revolved around different ordering cycles in our company. Buying the new hardware was what stretched out the deployment time.

I was in charge of the team that did the implementation.

For purchasing and the initial negotiations with Nasuni, we used CDW. We still interact with them when it's time to do renewals, and they are great to deal with. They really help out quite a bit. They were the ones that brought us Nasuni in the first place and suggested that we take a look at it.

We're very happy with CDW. We use them for all of our hardware orders, and a couple of different infrastructure tools. We use them quite extensively.

We had four people responsible for the deployments, with one guy who was in charge of the group as the lead architect. Once it was deployed, we turned it over to our operations group, which is outsourced to TCS. Although they have supported us since then, they come to us if there's anything that's still an issue. We have a couple of guys that still work with Nasuni a little bit, but that's basically how the maintenance is done.

For the most part, there is little maintenance to do. There are situations such as when a controller card goes down, or like the issues we have been having since the upgrade. Otherwise, it's very hands-off and you really don't have to do a lot.

We don't plan on calculating a return on investment with this solution. In the grand scheme of things, it's really not very much money for what we're doing. We spend more money on the hardware, for example.

Our agreement is set up such that we pay annually per terabyte, and we buy a chunk of it at a time. Then if we run out of space, we go back to them and buy another chunk.

We thought about an agreement with a three-year plan, where we would get a small increase every year, but we decided not to take that approach at this time. We go through CDW for these agreements and they help us get all of the quotes together.

In addition to what we pay Nasuni, there is the cost of storage in Azure or whatever cloud service you're using. It can get pretty pricey if you have a lot of snapshots, which is something we've found and we're now trying to scale back on. That's the biggest thing that is extra and you may not think of right at the beginning.

We looked at a few different products that year, and we decided that Nasuni was the best way to go. It has really worked well for us.

One of the products that we looked at was Veeam, the backup software, but it would have been used a little bit differently. We also looked at Backup Exec and a tool from Microsoft. We didn't look at anything that was exactly like Nasuni. We looked at these other things that would create backups of the primary data, which would have stayed at the site. Nasuni was a completely different way of looking at it.

The difference with Nasuni is that rather than having a backup in the cloud, the primary copy of the data is what's in the cloud. For us, it's stored in Azure, whereas with the other tools, the primary copy stays at the site. If you had a major problem, for instance, this issue with the controller card, the problem with these other solutions or the way it was before was that you're down and out at least until you can get the controller card replaced.

Then, once you're back up, you're going to have to copy all of the data back. For that, it would probably need at least a week. Some of these sites have very poor connections. For example, we have a site that's in the Amazon jungle in Brazil and they are notorious for being very slow, yet we've used Nasuni there and it works fine. Some of these other solutions probably wouldn't have worked. In fact, we probably would have had to buy a tape drive and back up the servers that way.

We have a hosted data center where we don't pay for individual items, such as servers. Instead, we pay for a service. The service might include a server or storage, and Nasuni has not eliminated that because we still need our physical servers at the locations. We debated on whether or not to put the filer in Azure for each site, but we decided that it was better to have something local at this point.

For our company, we were a little ahead of the curve. We didn't have internet connections directly from each site, and they all routed through a central internet connection. Because of that, it was difficult to eliminate any hardware at the site. We needed something there physically. But, having the virtual appliance for Nasuni really helps out quite a bit, because then we only have to have one piece of hardware and we can put all of the other servers that we need for infrastructure on the same ESX server. We have five or six different servers that are doing different functions that at one point, would maybe have been three or four different physical servers. Now we've reduced it to one.

We use Microsoft SCOM as a monitoring tool to keep track of all of the filers and make sure that they are running. 

We don't use the Nasuni dashboard because we don't have to. Everything is working the way it is. We do have a management console set up and we do go into that occasionally, but it's not something that's a regular thing that our support people use.

If I had a colleague at another company with concerns about migration to the cloud and Nasuni's performance, I would talk about the fact that the OR capabilities are so different than anything else that I've seen. The performance has actually not been too bad. You would think that there would be an issue with the cloud stores, but we set up a local cache on each filer that allows it to store up to a terabyte or two of regularly used data. That gets probably 80% of what people use, which means that they're accessing a local copy that's synced with what's in the cloud. This means that they don't really have to go to the cloud to get a lot of it. But when they do, it's pretty quick. It may not be as fast as if it were a local copy, but it's not too bad.

My advice for anybody who is considering Nasuni is that they definitely want to look at all of the options, but that Nasuni does have the best setup at this point. It offers the ability to recover things and provides data security. Especially with ransomware and all of these other new things that are causing lots of problems out there, it really helps mitigate some of that.

The biggest thing that I have learned from using Nasuni is that you shouldn't be afraid of the cloud.

I would rate this solution an eight out of ten.

We have multiple physical locations and we had to find an alternative data repository so that we could transition from some legacy technology like Microsoft StorSimple. We needed a cloud-native solution that would be more cost-effective than some of the other vendors out there. We ended up going with Nasuni primarily for file server access for three locations within Australia.

Nasuni is helping us replace multiple data silos and toolsets with a single global file system. We are still in the transition stage for some of our locations. We're doing away with the Microsoft StorSimple services, which is being retired at the end of the year. We have an HPE Unity SAN at one of our locations, and because that used to store all the data, we have had to have backup technology to replicate it. We're doing away with both of them and simplifying our infrastructure in that location to accommodate just a small caching appliance. And there's an FTP capability that we're looking to investigate for some of our infrastructure components.

Also, we have reduced the IT risk in our recovery point objectives and recovery time objectives. In the event of a disaster, we're able to bring up the infrastructure in a different location very quickly. In addition, we can have access to this data in a site-survivability mode in our manufacturing area. That means that for a period of time, the data that's cached on those appliances will happily be used by that office, should the network become isolated from the internet.

Another benefit is that, compared to what we had before, from a dashboarding perspective, we get really good visibility within the Nasuni console. We also have much better assurances around the backups and the mechanisms assuring that the data is actually being securely stored, based on our rules, with various tools and backup solutions. There were many different places where we used to get that information and that just wasn't efficient.

One of our guiding principles, when it comes to architecture, is to ensure that we have immutable backups of all of our data. Historically, we were able to do that for everything except for our file servers. We still leveraged legacy capabilities for that. By moving to Nasuni, we were able to ensure that the backups are immutable and retained for a period of time without being impacted. That gives us assurance that, in the event of a ransomware attack, we're able not only to restore the data or make it accessible, but we're also able to provide a different mechanism for users to access the data in a disaster recovery scenario. That can be done by using the web interface rather than having to establish network connectivity.

Nasuni has also helped to eliminate on-premises infrastructure. We're simplifying the infrastructure we deploy and, as part of that process, we're able to then repurpose it. For example, we currently have SAN storage attached to the network and we had a couple of NAS appliances. We consolidated all of that into a virtualization stack that only has to store a minimal amount of caching data. That saves us hours a week from managing the backups and ensuring that they work. When we do restore testing, we only have to test a finite amount of data because it's one system working for many different areas. It's considerably easier. There was a little bit of a learning curve to understand how the new technology works, but the implementer helped us with that.

It has also decreased capital costs in the sense that we don't have to renew the purchasing of additional specific hardware for it. The last SAN storage appliance that we purchased cost $180,000 four and a half years ago, and it is coming up for retirement and decommissioning. Nasuni is not a complete replacement, as we'll be replacing that SAN with some virtualization infrastructure, but that will be co-shared and used by a number of different systems and applications. We're taking away a storage appliance, but adding more capacity and more processing power for use with more systems.

We effectively subscribe to the storage where that is saved. As a result, from a cash flow perspective, we're clearer. We're not having a large capital investment for the storage appliance. And we also have the assurance that it is considerably more redundant than what we used previously.

The disaster recovery capabilities are very easy because their virtual appliances are just like OVFs or images. You put in a code and it collects all the configuration from the cloud and then builds up the cache. But that doesn't preclude the device from easily being restored or recovered at short notice. It also means, from a security-patching perspective, that we don't have to add any additional processes like managing a Windows Server or having agents on it. We can simply rebuild those or upgrade those agents.

The storage that we're deploying it to is in Azure, but one of the key features of Nasuni is the fact that we can actually change the location of that storage when it becomes cost-prohibited to have it in Azure, and we can find equally reliable but cost-effective places. A good example would be Wasabi storage services. They don't have regions in Australia, but should they get regions in Australia, they are considerably cheaper than what Azure, AWS, and GCP offer. We have that flexibility.

Nasuni also provides file storage capacity anywhere it's needed on-demand and without any limits. What we've found is that a lot of our storage is dormant and not actively used. Nasuni gives us really good insights into the usage of the data and enables us to store that data in an immutable secured location. The flexibility is there and the level of data that we can send to it is exceptionally high. The importance of this feature is about a six out of 10 for us. That's because our volume of data is actually decreasing year-on-year, specifically in those types of data repositories. We are exponentially growing on data stored in cloud services, like Dropbox, OneDrive, SharePoint, and Teams, but that's a different technology stack.

Migration from existing systems, specifically StorSimple, could be improved, but that solution will be end-of-life by the end of the year. 

Also, the documentation could be more accessible.

It's a pretty good product, overall. It's hard to find something specific that they really have to focus on.

I have been using Nasuni for a couple of months.

So far, we've had no problems with its stability.

We're assessing whether we're going to deploy it throughout Asia as well. But strategically, we're moving away from this type of storage. We're looking to leverage more cloud-based collaborative storage. The primary reason is that we don't have the necessary use cases for really large storage connectivity, like CAD or design drawings. Our usage of Nasuni will actually become lower and lower over time as we transition business processes.

Their tech support is quite busy at the moment with everyone trying to outsource storage. We can give them a little bit of leniency on that.

Positive

We had a risk around an end-of-life technology and we brought in Nasuni and we transitioned to it within a week and a half.

The initial setup was straightforward. The biggest thing that we had to focus on was transitioning our existing snapshot backups. They definitely had some guidance on how to do that and that helped. The technology side was straightforward. Some of the business decisions that we had to make were more complex. For example, how comfortable were we in keeping some of the data that we had in our old system and getting rid of some of the other data?

Compared to what we used to have, this solution is significantly simpler. The deployment of the caching appliances is very easy, as is redeploying them. From an infrastructure perspective, that's quite straightforward. We don't have the hardware appliances, but I believe they are equally easy to manage.

Our deployment is a combination. In one location it's on-premises, but it's in a virtualized environment. We are deploying components in our core data center, which is a co-lo with our virtualization infrastructure.

While a 360-degree view is going to be a stretch, it does allow us to have all of our file repositories centrally managed in one administrative console. It doesn't cater to data classifications and data loss prevention, but from an object storage point of view and a management perspective, it definitely works.

We use the Nasuni Filers and Nasuni Management Console (NMC) to manage those Filers.

We have four offices in Los Angeles, Singapore, Hong Kong, and Shanghai. In each office, we have a Nasuni Cloud Storage Gateway that allows end users in each office to access their data in the cloud. However, that data is cached locally.

It is an excellent solution for collaboration. We are an architecture firm. For example, we may be working on a set of architectural drawings files here in Los Angeles. We save those drawings at 17:00, then those drawings will sync to other offices. When other offices, e.g., China and Shanghai, come online, the data is there and on the network drive. They can continue working on those drawings or meet with clients. They can also access them on an iPad if they are at a job site. So, it is very useful for collaboration on a global scale.

The product integrates with industry standard platforms, like Active Directory. So, it is very straightforward to apply changes to the organization.

If we were hit with ransomware, we would have to know the time of the ransomware, then we can easily recover files using Nasuni Management Console.

It is much simpler to upgrade a solution because the data is in the cloud. You are just upgrading your gateway and pointing it to the cloud. So, it is much simpler to upgrade.

The bread and butter of what it does is the ability to sync data. Because in architecture, we are using unstructured data with a lot of big files and large file structures going from one place to another. Nasuni does that very quickly.

I can see who is logging in on files from all over the globe. For example, if a file is locked, maybe a user in Shanghai has locked files or something, I can see that from the Management Console, then unlock the file. I would rate the importance of this feature as nine out of 10.

Nasuni enables us to provide file storage capacity anywhere it is needed and on-demand. I would rate this feature as nine out of 10 because of the nature of our business. We can look at identical data for all our locations at the same time, which is very useful.

The tools are very good, and I learned them. They are relatively straightforward.

The end user has the ability (on his own computer) to recover a file.

I would like to see them improve their tools in regards to accessing data using smartphones, tablets, and iPads. I think the Nasuni app could be improved to make access to the data cleaner and more efficient.

I have been using Nasuni for four and a half years.

It is a stable product. I wouldn't be using it if it wasn't stable.

Its strength is that it is extremely scalable. It is very quick to spin up a new Filer. We have opened and closed offices in the last four-and-a-half years. So, I have had to spin up a gateway, then I have to shut it down and move it. In that sense, because the data is in the cloud, that has been a huge strength of the product.

We are limited by the subscription that we have. We have incrementally increased our data. We have increased our data by probably five percent a year. So, I suspect we will continue to add about five percent per year to our subscription.

Everybody uses it, which is about 110 employees and consultants.

I would rate the technical support as seven out of 10. 

Before Nasuni, I would use more conventional storage arrays from larger vendors, like Dell EMC and HPE. We switched because Dell EMC didn't offer a cloud option or the ability to quickly sync data to our other offices.

Nasuni has replaced multiple data silos and toolsets with a single global file system. We still have separate storage in our offices. However, that storage is really for less critical data, libraries, etc., where the most critical data is on the Nasuni platform.

Replacing multiple data silos has been extremely important for us. The alternative is the way that we did business in the old days. Previously, we worked on a storage array here in Los Angeles, then we would have to transfer the files in some way (from one place to another) to a separate storage array. With the amount of collaboration that we do globally, that is very difficult.

In the old days, we would have an architect fly to China and meet with a client about a drawing or design, maybe at a job site. We are not able to do that anymore due to COVID-19. Instead, we now can have our staff in China pull up the same drawing on an iPad and mark up the drawing using a web conference. This solution provides us reach to our clients, which is very important.

The initial setup was not simple, but not complex.

Our deployment took 30 days.

I worked with Nasuni Professional Services. Over one weekend, we migrated the data.

We also worked with Consiliant Technologies for the deployment. Our experience with them was excellent.

I do the maintenance and upgrades of the product. This takes one person (me).

I see ROI qualitatively from people in our global offices. After I made the change, their workflow definitely improved.

Continuous File Versioning definitely saves me money on purchasing expensive backup solutions.

We still use on-premise infrastructure, but it does eliminate part of our infrastructure. It is about a 20% savings versus conventional storage arrays and backup solutions.

Because you are paying for a subscription, there is less of a CapEx cost. It has reduced our capital cost by about 40%, but we are paying for a subscription as well.

It has a license fee as well as hardware costs, which we would incur if we want to use Nasuni Cloud Storage Gateway for upgrades.

We pay for a subscription.

We looked at keeping our Dell EMC storage arrays. I also looked at Panzura and Nasuni. Both Panzura and Nasuni fulfilled our requirement of syncing the data. However, I preferred Nasuni's architecture and the way that they did it.

Nasuni is the preferred solution of our CFO because the business agility and cash flow are more predictable.

Investigate the cloud provider that you want to use, whether it is Microsoft Azure, AWS, or whatever Nasuni supports. Do that research first, then investigate with Nasuni regarding pricing.

You need to determine what data you are willing to put up in the cloud, then what data you deem critical to be cached locally in your location. For example, if you have 20 terabytes in the cloud, how much of that do you really need cached in each location? Is it five terabytes? Is it seven terabytes? This information will help with the migration.

If you have a requirement where you have multiple locations that need to look at identical data because of collaboration, that is Nasuni's strength. If that is not a big requirement, then you would probably look elsewhere.

A big advantage is having the data exist in the cloud. This has certainly relieved a lot of pressure from our IT department in regards to having a backup as well as preventing some ransomware in all of our offices. That has definitely been a big plus.

I would rate it as nine out of 10.

It's mostly for internal users. We use it for internal file sharing. We have moved our various departments, such as marketing, finance, and HR, to Nasuni. We started using it because of the StorSimple devices coming to an end of life. Microsoft announced that, so we considered Nasuni as the first option for internal file sharing of users.

It's on the cloud, but we started on-prem. We borrowed the filer from Nasuni themselves and completed the migration just to speed up the process, and then we sent the filer back. We are now completely on the cloud backed up by AWS.

We are using its latest version. We did the update two weeks ago to the latest version that we received from them.

Snapshot backup has been a lifesaver. It sometimes used to take us close to five hours to back up one spreadsheet for users because we were using physical file servers. We have not received any complaints from users regarding the performance or a connection or network not being available. It has been good so far.

Nasuni has also helped with data consolidation. It has improved our compliance and risk management with data consolidation. We have all our data in one place.

Nasuni has replaced multiple data silos and toolsets with a single global file system. We are only using a single, global file system instead of the five physical servers that we had previously. It's really good. We started with this project because we wanted to do data migration because of the StorSimple issue, but then we found out that we could do data consolidation at the same time because it did support multi-site access. We now have all our data centralized in one place, which is very helpful and useful. At the time of considering and doing data redundancy, we will only have to do it on one site instead of multiple sites.

Nasuni has helped to eliminate on-premises infrastructure. We were using five physical servers before. Instead of them advising us to buy a physical server to do the migration, they lent us one for free. We did our migration, and we sent it back to them, so that was a great call from them. We didn't even know that option was available. It was their sales team that suggested this. Otherwise, we would have ended up with one file server that we would not have been using. It would have been just on commission if we had to buy it ourselves.

Nasuni offers a single platform with a 360-degree view of our file data. We call it Nasuni Management Console. They do provide their own console for us to manage our data, which is a shift from the old way of managing our data. We used to have to physically log into the server and manage our data, but now, we manage it all in one place. It's quite an easy and straightforward process.

Nasuni doesn't provide file storage capacity anywhere it’s needed, on-demand, and without limits. You would have to sign up with them, but you can always request or demand a capacity increase. You have to go through a process with them, but the customer support is quite fast, so you can request it and then get it applied within the same day. I'm not sure about unlimited, but I know that we're using 20 terabytes, and we're able to expand it if we want to. It's $850 per terabyte. We do need this capability to be able to expand because it's an internal file system. At some point, our security team might decide to do a backup of the data, and that will just double the size. We need to have on-demand storage capacity support because the company data is growing day by day, so we would always need it. We would need to request more storage from Nasuni in the next couple of months.

With the support that was provided for us, it was easy to configure the solution to support organizational changes. It wasn't very easy, but it was easy. They were with us every step of the way. With their support, it got quite easy for us. We expected it to be way more complicated than this. It did not affect our business in a bad way. There was hardly any downtime. We completed the data migration, and then we did the switch within five minutes to Nasuni filer. It affected our business in a good way that the users did not even feel the change. A lot of users did not even notice the changes until we told them. We had to tell them to change the path they were accessing or the directories they were accessing. That was the only way it affected users, but that's not just with Nasuni. It would have been with any other vendor.

Nasuni has also simplified infrastructure purchasing and support requirements. We no longer have to worry about buying physical equipment. In terms of its effect on the time and effort spent on infrastructure support, we will be able to measure that only after a year. Next year, we don't have to worry about backup. We don't have to worry about maintaining the devices or upgrading them to the physical ones or buying or renewing a license. Overall, it has helped a lot. It would be a great shift next year once we do the infrastructure budget again.

Snapshot backup is most valuable. It's quick and easy to use. It's controlled only by an administrator, which is very good. It takes 10 seconds to back up a spreadsheet of three or four megabytes.

It can be improved in terms of retention policy or data retention for the volumes. We found this quite frustrating because different departments in our organization require different retention policies. For instance, the finance team wants their data to be kept for seven years. It's a legal requirement, whereas the HR team needs it to be kept for 10 years. The marketing team only wants it for the next two years. Nasuni does not support different retention policies within the same volume, so you have to keep creating volumes for retention policies. When you create a new volume, it means you're starting from zero all over again. You can't move data between two volumes. You have to move them from your physical device to Nasuni or your cloud device to Nasuni. That has added a lot of time for us because we were not aware of that feature, but when we shared this with Nasuni, they said it's something they'll be working on in the next quarter.

We started with it in November. We have been actively using it since November, but we started the process of migration in late August. It has been less than a year. 

So far, we haven't had any issues with them. It has been good so far. The stability has been good and on point.

Currently, we have around 400 internal users.

Their support is very good. I'd rate them a nine out of ten. When we send an email, we get a response from them within the next three hours. 

Positive

We had StorSimple from Microsoft. We switched to Nasuni because StorSimple devices were coming to an end of life.

It was straightforward because we got support from Nasuni every step of the way. There were two people involved in its deployment: myself and someone else.

It took us about two weeks between meetings and having an initial deployment. It would have taken one week if we were properly organized from our end as well because a lot of the staff were not available.

It has been a pleasure working with them. They have been one of the best vendors so far. They are quite good, and I just hope we can continue this with them.

It's too soon for that. In one year's time, we will be able to give a full financial overview of how much is saved in terms of costs.

When it comes to business agility and cash flow compared to buying fixed assets through a hardware refresh, with Nasuni, it's the way forward. It's not just Nasuni, it's with everything. It's the way forward for the infrastructure of any IT department to buy everything on the cloud.

We are trying to move everything to the cloud. It has saved us about five grand in the total overall project cost. In the long run, it's going to reduce the carbon footprint as well. At this time, it's hard to say whether it has decreased capital costs. This kind of feedback would be possible in about a year's time because we've paid for the initial project. We paid for the S3 bucket on AWS, so our cost is quite high, but we will be able to evaluate the cost next year. We had to pay for everything at once, and we have been using it for less than a year. Next year, the cost will be very, very low because we don't have to renew the S3 bucket anymore. We've already bought a few years of reservation with them.

We did evaluate Azure Files and AWS as well, but the costs were quite high for both of them. They did not meet the security requirements, whereas Nasuni met the security requirements we had.

Do a cleanup before you get the initial cost. Do the data cleanup. Because we didn't clean our data properly, it came out to be 20 terabytes. We ended up using about 12 terabytes, but we had already signed the contract with Nasuni. This is no fault from Nasuni's end; it's from our end. So, organize your data, clean it up, and then request the quotation from Nasuni.

Any infrastructure team that wants to move to this solution should clean their data and consider retention policies. These are the two lessons we've learned from using this solution. Check with different departments because apparently, every department has its own retention policy. We found this the hard way.

To someone who has concerns about migration to the cloud and about the solution’s performance, I would say that we had the same concern, but four months in with Nasuni, we did not receive a single complaint from the users, whereas with our previous solution, we had filers at the same physical location where the users were based, but we used to get a lot of complaints about the performance and stability. I would recommend testing it out and reading the reviews about it.

In terms of our cloud strategy, we only have snapshots and backups. We have an active backup, which was advised by Nasuni anyway, and we applied a few retention policies as well on some of the files. This is the strategy we currently have. We will be considering redundancy, but because of the cost, we will just put that on hold until next year.

We have not used Nasuni for data protection. It was just a budget issue from our security team. They already had data protection with other vendors, and they will wait for that contract to finish.

We have not used the Access Anywhere feature, but we are considering it. We had a meeting with them last week regarding Access Anywhere. We haven't yet had an in-depth conversation with them. We have also not used the Continuous File Versioning feature or add-on services.

Overall, I'd rate Nasuni an eight out of ten.

We use the solution for file sharing, redundancy, and restore features. 

Regarding cloud strategy, we use a bucket in the cloud, but it's all private, so nothing public hits it. We have elements including the bucket, a filer, and an MC component; it's all there but only accessible from within. Part of our strategy when deploying filers and locations is to ensure firewalls are set so that traffic never exits; it's technically the internet, but we use a private IP, so no data travels over.  

Nasuni hasn't replaced any other solutions; we use it side-by-side and implement it at new sites. We're an extensive organization, so we can't just replace tools; it would take a very long time, and the initiative would have to be of great importance. Much money and work would go into replacing products, including storage requirements, buying a filer and spooling it up, and all the associated activity across multiple sites.

It's relatively straightforward to configure the solution to support organizational changes; Nasuni provides the required TCP and UDP ports. The product has its requirements, but they're easy to meet. When we harden the tool, this gets harder, but the actual Nasuni conditions are manageable.  

The product has a lot of zero-touch operation, which is good; we don't have to intervene too much except for updates, which is somewhat annoying. 

One of Nasuni's best characteristics is its fully redundant system; we don't have to shift tapes or use other backup solutions. It's a good, full-featured product.

Nasuni enables us to provide file storage capacity anywhere it's needed, on-demand, and without limits, which is essential for a global file storage solution. 

The solution provides Continuous File Versioning, positively affecting our ability to recover from ransomware or a disaster. We can roll back using protected snapshots, and we may lose some data, but how much depends on when the snapshot was taken and what's affected by the event.  

Continuous File Versioning also positively impacts a user if they delete a file or a file becomes corrupted. We can resurrect the file any time after its creation, based on our policies. For example, every volume can have a different retention policy, with backup increments every ten minutes.  

Sometimes, there are too many updates; recently, Nasuni flagged a virus incorrectly, and there was an update to fix that. This is not good in a production environment, so the solution isn't as mature or stable as needed.

The privilege settings need to be more granular, and alerts are an excellent example. If a user doesn't have access to them, they can't see them and access information such as what they may have done wrong, what's there, and when the last sync happened. However, the ability to view alerts also comes with permission to delete them, which is not good, so we need more customization options here.  

There are a few little functions that Nasuni can do for us, but we can't do for ourselves, and it shouldn't be that way. We should be free to customize what we want, and Nasuni should provide the commands or a place in the GUI to do it.

We've been using the solution for about a year. 

The solution is stable; the S3 bucket isn't going to break down, and we're on new servers running off a Linux kernel, so they shouldn't go down either. We have yet to experience any issues with the stability. 

The product is very scalable. I do wish we could throw more master volume owners on one device, as it's limited to 16 or eight if it's user-facing.

We contact customer support weekly, and the company representative who deals with us is excellent; he knows what he's talking about. They run through details with us and regularly teach us about the product. We can ask many questions, and Nasuni is more like an automatic transmission car than a manual, which is as it's supposed to be.

Before Nasuni, we used traditional Microsoft tools and didn't necessarily switch. It's more of a slow upgrade process; we use Nasuni for all newer sites and will continue to do so going forward.

The initial deployment is relatively straightforward; the only complexity comes from our internal rules around traffic flow and quality of service, but Nasuni itself has nothing to do with that. The server comes pre-configured, we do the volume, it's without glitches, and connecting to the NNC is fine.

The last two deployments I worked on took almost six months for a full deployment. It's important to remember we are a massive company, so much waiting is involved, and things take time. If someone wants to spool up a VM here, it could take months for that to happen; this is a very controlled environment, we can't afford mistakes, security is tight, and many checks and balances exist.

We evaluated other options, but I was not involved in the process. We looked at many products, including Commvault and online tools, as there are a lot of choices when it comes to backup and recovery, incremental backup, and file-sharing solutions. Ultimately, our requirement was for a product that could be solely internal and would not go over the internet, so Nasuni fit the bill.

I rate the solution seven out of ten. 

Nasuni's analytics connector provides analytics, including what data is flowing. We can access that locally and in the cloud from wherever the filers are.

Regarding data protection, we use the solution's built-in antivirus but not exclusively; we also have other tools to scan the data. We have it as an extra layer of protection, but otherwise, secure files as we usually would.

We use Nasuni Access Anywhere, but we may not need it. As we use an SD-WAN solution, Nasuni tacked a CNAME on the device so we can access the shares. Therefore, we can use both of those.

Regarding simplicity of management, I'm not involved in the daily management, but I suspect it isn't as glitchy as Oracle ZFS. ZFS is horrible; it works, but good luck fixing it if it breaks. Nasuni is probably better because it's a newer platform built on a Linux kernel.

If we didn't have Nasuni, we would instead have some kind of file server, attached storage maybe with a RAID, and then push that to AWS in a blob or S3 bucket. We could do much of what Nasuni does in other ways, but it would be more complicated; it would be less clean and easy. Having a unified platform to handle everything is much better. Regarding hardware elimination, the solution doesn't really do that; we could eliminate the hardware, but that leads to other problems and is less cost-effective.  

In terms of cloud migration, I've done lift and shift projects, and I was more involved in the management side. I've also been involved in Azure projects, including AAD, hybrid AD, and some Intune rollouts.  

To a colleague at another company who has concerns about migration to the cloud and the solution's performance, I would say the performance is related to your WAN, hardware, and user demands; it's not the product that will limit you. Regarding the cloud concerns, your data is safer in the cloud; I've never heard of a company losing their data in an S3 bucket due to an Amazon mistake, for example.  

To those considering implementing the solution, I recommend you have your infrastructure properly set up before, depending on the security requirements. Putting the solution in a VLAN and the filer in a different VLAN is a consideration. I also recommend buying enough storage for future capacity, testing the data, and not skimping on storage; it's better to lean toward generosity here. For product-specific advice, I recommend being prepared for some learning; taking the time to learn how Nasuni works and how to support it post-deployment is essential. As with everything, it will take a little time, a few months or so, so be prepared for an investment of time and planning.

I work for a retail company. We have our users spread out geographically across the globe. We have deployed Nasuni in all our remote locations. With this service, we are catering to users across different continents, such as the EMEA, APAC, North American, and South American regions.

It is deployed on-premises through Azure appliances.

Nasuni deployment, along with its DFS capabilities, help with our SLA and RPO requirements. For example, if there is a site in Las Vegas and another site in San Francisco, and the Las Vegas site is down, then with the help of DFS, we can redirect clients to access the site from the back-end using the same path. The San Francisco site is then enabled and in an active state, but still clients will not have any issues connecting because of the Nasuni solution. So, this is an innovative solution that helps with the overall RPO requirements of our enterprise. 80% to 90% of the time, we are satisfied with its performance and with availability.

It is easy and seamless to configure Nasuni to support our organizational changes. We deployed the solution through a virtual appliance. If that particular virtual appliance is corrupted in any way, then we can deploy the OVA within no time. Within an hour, we can deploy and redirect users to the new appliance, then it can continue serving customers' requests.

There is a feature known as Global File Lock. If one of the users is accessing a file from another geographical location from where he is working, then this feature helps maintain the integrity of the file. It could be a Doc file, spreadsheet, etc.

Everything about Nasuni is easy, in terms of setup, deployment, access, and seeing the directory structure. Based on the DFS path, we are creating a directory structure, where we are pointing to multiple locations in a single directory structure. Nasuni helps with that. 

There is a minimal firewall requirement so we don't have to worry too much about the firewall.

With Nasuni Management Console (NMC), we get a single, centralized view of our entire internal structure and data center structure. This is very important because this caters to remote locations. One of the main care center teams is dependent on this solution. As it is directly connected to customers for the calls that they receive and troubleshoot, they can then help customers out in case they are not able to place an order. 

It provides file storage capacity anywhere it's needed on demand and without limits. The object storage capability helps provide storage to Nasuni.

In terms of simplicity, we have had 100% satisfaction.

The Nasuni file storage platform doesn't work well when there are a high number of small files. This is the case when a directory structure contains more than 10,000 or 20,000 small files, e.g., 5 KB, 10 KB, or 15 KB. When the user is accessing these files from another geographical location, they might face a slow response or timeouts when connecting to the shares, and then to the files. This is because the file size is small. There is a scope of improvement with this solution when it comes to accessing a large number of small files.

We have been using it for about five years.

Stability is at 80%. It is reliable. We get monthly newsletters from Nasuni regarding the state of the systems running on certain versions.

Scalability-wise, it is at 90%. We can easily scale the system.

There are close to 5,000 users across the globe who are using it for multiple purposes. Some of them are using it because they are part of the applications team. There are also some care center executives using it.

The technical support team doesn't have a lot of engineers to help customers. Thus, the response time can be a bit slower than with other vendor support. I would rate them as six out of 10.

Neutral

This was a new solution for us. We wanted to have Nasuni in place to increase our global footprint.

The initial setup was straightforward.

It took 30 days to deploy to all our locations. We went with the site-by-site approach.

We worked with the Nasuni account rep team. They shared portal access to all our administrators as well as the images that we need to deploy to OVAs. Before that, we took care of the firewall network and all its prerequisites. Then, we took care of the basic finances. Once that was done and based on geographical locations, we started deploying the OVA. We shared those paths with the end users and relevant teams who could also do testing. Once they were happy, we declared that the systems were in production.

The architecture team had a meeting with Nasuni. Then, within a couple of months, we decide on the solution and design. Once they approved it, the deployment was done within no time, which simplified everything.

5 to 10 people are involved in the deployment.

We have seen 100% ROI.

For some sites, it has helped us to eliminate on-premises infrastructure. For our enterprise, there are four major data center locations. We have physical data centers, which we share and a couple that we own. This solution helped us by having us avoid investing in on-premises infrastructure-related costs, saving us about 50% of the cost by just deploying the OVA through the ESX app. Instead, we are just investing in the vCenter environment, then deploying the OVA through that.

This solution has helped minimize our administration work. Because of its simplicity, you can log into NMC and get a global footprint of which files are working and which are having some issues. So, the interface helps us take a look at our infrastructure.

Nasuni has helped decrease capital costs by 66% since we don’t need to buy as much excess capacity. 

With this solution, the license renewal is pretty swift. With the virtual appliance, you just need to take care of the OS versions and patches. In a way, we don't have to struggle much with renewals because the only thing that we need to take care of are the licenses. We renew it every three years. This aspect goes with infrastructural costs because it doesn't cost us too much to maintain the solution.

There is a cost associated with vCenter maintenance.

It is a cost-effective solution. If performance is not a priority and you want to build a cost-effective solution for the remote sites, then this is a recommended solution for you.

Nasuni's file storage footprint is not that significant when it is spread out across the globe and deployed through a virtual appliance. 

If you need to deploy physical storage, then the footprint is larger and performance-intensive. Nasuni is not recommended in these cases.

It provides Continuous File Versioning, but we disabled that feature. From an administrative perspective, we disabled it because we wanted to ensure that we control the access to the previous versions for users.

We use the solution regularly. We don't have plans to increase usage since we use it for a specific use case.

I would rate this solution as eight out of 10.

It is mainly used for file storage.

I belong to the administration part of the storage team who use it to handle all the file servers and the SAN storage. I manage a team who handles the day-to-day tasks of Nasuni. We have multiple teams who take care of our work on the Nasuni. There is a separate team who works on deployment and another separate team who handles the BAU tasks. So, we have different teams who work on different parts.

Nasuni has helped to eliminate on-premises infrastructure. We were using about eight to 10 different types of vendors or small storage boxes for provisioning and shared access for users. We got rid of all those. That has eliminated the footprint and operational overhead at our data center. We don't have to worry about any hardware or monitoring particular devices, and hundreds of devices have been decommissioned. Now, for provisioning, everything is on Nasuni. I assume this has made a big difference in costs.

It is without limit. It grows per the need. In one year, I haven't seen anybody requesting any new spaces yet.

We use the Continuous File Versioning feature. Restoration is quite simple. Because of Continuous File Versioning, there are any number of snapshots available with the settings that we have chosen. There is always a backup ready, and all we have to do is find a previous one that is ready to be recovered.

Previously it was a tough job working on hardware, volumes, shares, or anything that was managed by us. Now, it is the same task, but the ease with which we do it is better with Continuous File Versioning. All we have to do is log into the console, find what needs to be recovered, and then use that for recovery.

The user-friendliness of its access needs improvement. When I log into the console, I see all the files that we handle globally. There are hundreds of Nasuni files that I can see on the console, but no way that I can filter them down. While this is a small thing, I need to scroll down and select the ones that I want. "Control F" doesn't work nor is there a dropdown menu that I can click on and select the ones that I want. 

There are some things that we are really looking forward to. For example, we recently had an issue related to the COW disk. Only the Nasuni back-end team can check and see which out of the LANs or volumes provision from ESX is exactly the COW disk. We don't have visibility into that. There are certain things that are only visible to the back-end team of Nasuni, but I feel that we should, as a user, also have visibility into it.

I have been using it for a year.

We haven't seen any kind of outages related to Nasuni. Stability-wise, it has been great.

We don't have to worry about scalability. 

At the moment, we are backing up or protecting about 10 to 15 terabytes. 

We plan to get every NAS box that we have off existing devices that are end-of-life and used for file provisioning. We plan to move those to Nasuni.

I would rate Nasuni support somewhere between eight or nine out of 10 because sometimes we face issues in getting support from Nasuni. For example, if I am running a P1, then I call up Nasuni support but don't get immediate support. We then have to wait until somebody gets back to us. When we get support, it is good, but waiting is the issue.

Before Nasuni, we had NAS file servers from different vendors, e.g., Dell EMC and NetApp. We also had small-time, consumer NAS boxes, like QNAP, Synology, etc. It was quite uncomfortable and tedious, as well as the toughest way, to monitor all these vendors with different technologies and features, just to provide a file share to the user. This is something that has been tremendously reduced since dealing with just Nasuni and nothing else.

It was a tedious process of getting a change approved, looking into the available space, whether the storage had enough space for provisioning additional space to be requested. It used to take probably a time window of anywhere between seven to 10 days, if there was space available on the existing storage. If not, then it was another task that would go for months to procure new storage to add in more capacity. Nasuni has eased our job because we don't have to worry about the user requests for additional space anymore.

When we had NetApp, we had more control of it from a hardware perspective, but there were a lot of negative aspects to it. 

With Nasuni, as an administrator, my life is easy. The only issue that we are currently dealing with is about some access or permission-related issues. There are a whole lot of issues that we do not even have to look into it anymore: 

• People are not getting back to us that they need more space. 
• People are not getting back to us to tell us if there are hardware failures that we need to fix. 
• They are not coming back to tell us that there are some hardware issues going on, which probably might affect the data, data integrity, or probably cause data loss. 

So, there are many other things that we are not even hearing about right now. It has greatly reduced the amount of issues that we have had from previous solutions.

I have heard that it is easy to configure the solution to support organizational changes.

My team doesn't get involved. We have a separate team who takes care of deployments.

Unless you know that you have something better, I would say, "Go for it," in regards to Nasuni.

I would rate this solution as nine out of 10.