backup data

When it comes to evaluating technology, nothing speaks louder than the voice of the customer. Vendors can say what they want about a product, but what matters is how it works in the day-to-day world of IT, where everything that can go wrong sooner or later does.

Recently, Syncsort and NetApp jointly sponsored a webinar that featured a user of the NetApp Syncsort Integrated Backup (NSB) solution.  Fernando Mejia is the Senior Manager of IT Infrastructure for IPC, which is a Franchisee Purchasing Cooperative for the SUBWAY restaurant stores. IPC helps the 28,000 SUBWAY restaurants in the U.S. and Canada reduce costs by leveraging their collective purchasing power. IPC supplies everything from food to paper goods to IT processes.

Mr. Mejia was kind enough to join us on a webinar that you can view here. A brief registration is required, but it’s well worth it.  And here’s a tip: the first part of the webinar is me talking. If you’re familiar with the NSB story then you can jump to the 25 minute mark where Mejia begins speaking.  It takes a minute or two for the webinar to load up.

I want to give you a sense of what IPC gained by moving to NSB.  Their environment is about 350 servers and 70 TBs of primary storage, most on NetApp FAS 6280 systems. They use NSB to back up that data to a clustered FAS 3160, which is dedicated to backup.  Prior to NSB they were using Symantec NetBackup and having major headaches. Nightly incrementals started at 6:00 p.m. and finished up around 6:00 a.m. Weekend fulls started Friday night at 6:00 p.m. and lasted until Monday morning.

This led to problems, as Mejia said:

“It was always a challenge hoping and praying there weren’t any kind of gotchas, like there always are with backups, that would cause that window to extend. And often it did extend beyond the window and ran into standard business hours. And often times depending on which systems were affected we did have an impact on the performance of our systems, and users had a problem with productivity.”

Not only that, but management was a burden.

“We did have one full-time resource dedicated to just managing backups. That person’s sole purpose was to, in essence, babysit the backup process and make sure we were getting successful backups. It was a very labor intensive process.”

Some new applications that were coming on-line and would significantly extend production hours pushed IPC to look for a solution “to meet our needs, particularly the one need of being able to potentially completely eliminate a backup window.”

They got it with NSB.  The average backup time for their servers is now between 1 and 15 minutes! The backup window is a non-issue. In addition, they gained a significant benefit from the NSB Instant Virtualization capability.  It’s not only useful for recovering systems, but it has dramatically enhanced IPC’s application development efforts.

We have an in-house development staff and we do develop a good majority of the applications we use…  We’re able to leverage Instant Virtualization to bring entire applications, that are composed of multiple servers, from production into our development and staging environment. This minimizes the drift between development staging and production, in turn resulting in much quicker time to develop applications, much more streamlined testing and QA processes, and in the end a lot less issues and problems that make it out into production.”

That’s how NSB leverages the power of snapshots – launch entire applications in minutes using your most recent backup data. And because it’s using NetApp FlexClone to do it, there’s no additional storage required other than new writes to the system.  

Maybe the best part of the new solution, however, was the management relief. Rather than the full-time IT resource required before, with NSB:

“It takes barely an hour a day to go over, manage and maintain the entire solution…  That was a great win, because I can re-assign those resources that were basically just doing maintenance and operational type work and put them into more important tasks and projects that are more crucial to the organization.”

How is this achieved?  Partly it’s how easy the solution is to use.

“NSB’s capabilities of leveraging NetApp technologies as well as being entirely integrated into virtualization technologies allowed us to collapse the amount of administration interfaces into one. That’s one great benefit of the solution. The second great benefit is that it’s extremely intuitive. It’s very easy to get in front of the interface and through a very short learning curve understand how the backup jobs are configured, understand how to perform recovery operations, understand how to generate reports. In the end that resulted in really lowering our operations overhead.”

The other key is reliability. A great deal of backup management ends up being trouble-shooting and scrambling to recover from failed backup jobs. Not with NSB.

“I must say that our job failure rate is extremely low. If I get maybe one or two a week that’s a lot. And usually when we get a job failure it’s a problem with a particular server that was getting backed up. So over time we ended up not having a lot of focus on the backup solution because it just works so well… I remember in our NetBackup days I was hyper-focused on all kinds of detailed information on the backup because it was critical that you were on top of it all the time to make sure it was functioning correctly. With the Syncsort solution that really has changed.”

There’s more I could write, but I’ll leave you to listen to the webinar where you can hear it for yourself. If you have follow-up questions, the webinar will explain how you can get them to me, or just post a comment here.

{ 0 comments }

ESG’s Steve Duplessie has a great new blog post this week titled IT Chasms, Gaps and A New World Order.  Featuring Steve’s classic, straight shooting style, it is well worth your while to give it a read. It focuses mostly on networking (the kind with routers, not meeting people for a drink), but he makes a very interesting point about storage that I think are important and want to explore further.

After discussing how important it is for vendors to help customers develop applications faster, Duplessie says this:

The bigger truth is telling a storage buyer that your stuff is awesome because he can go faster running VMware is cool, but telling the App owner that your storage features will enable them to cut test and Q/A time by 30% is where the money is.

Hats off to that!  Steve is dead-on here. And one of the ways to do this – I would argue the best way – is by using your backup storage.

Let’s step back a bit.  Normally, when you hear vendors talking about using storage for test/dev tasks they start talking about snapshots and clones, and that usually means doing this with your primary storage.  Does it work? It does, but there’s a price to pay. 

First, primary storage is expensive, and using up high-speed disk resources for tasks that do not require high-performance is spending money you’d rather not spend. Second, it impacts performance.  Many disk array snapshots create quite a bit of impact on performance because the copy-on-write model means two writes and one read every time a block is written. To provide a hypothetical example, if “Barry the Unruly Developer” wants to do a lot of test/dev work off your primary disk, you risk serious impact to production performance.  

If you happen to use NetApp for your primary storage, you happily avoid this performance penalty because not all snapshots are created equal. But what if you don’t have NetApp primary storage?

That’s where NetApp Syncsort Integrated Backup (NSB) can help.  NSB lets you back up from any primary storage environment to a NetApp FAS device.  When NSB captures data, it stores it using NetApp Snapshots. And guess what? You have full access to cloning capabilities. The benefits of this are many.

1.  Everything is running on secondary storage. That means low-cost SATA drives with loads of capacity.

2. Everything is running on secondary storage. That means that no matter how many clones you spin up, no matter how hard “Barry the Unruly Developer” bashes away at the system, the impact to your production environment is zero, as in none whatsoever!

3. Everything is running on secondary storage.  That means it’s all consolidated onto a single hardware platform, no matter what mix of primary disk you have. It even protects boot drive data that’s not on a SAN, so Barry has access to all the application information, not just the data volumes.

4. Everything can also run on tertiary storage. Just use SnapMirror replication to send your backups to a DR site, and you can do all your test/dev over there.

5. It’s all super easy. NSB overlays the NetApp Snapshot and FlexClone features with super-simple workflows.  That means the person dishing out the storage to the test/dev folks doesn’t have to know how a NetApp FAS works.  How many steps does it take to provision a 2 TB SQL database volume clone to a dev?  A couple of mouse clicks. You can see how it’s done here

6. It’s physical. It’s virtual. It’s virtu-physical!  NSB can take any backup from any server and boot it from a FlexClone into a new VM in about ten minutes start to finish. That’s right.  When “Barry the Unruly Developer” demands a SQL Server instance to work on, you can say “Ten minutes Barry!”  And ten minutes later Barry has a brand new VM running he can play with all he likes. All running off a FlexClone, using zero extra storage footprint. And running – did I mention this? – from secondary storage or even tertiary, if you’d rather have Barry as far away as possible! To see how this works, click here

I could go on, but I think you get the idea. We have users doing this every day, leveraging their backup data for tasks beyond recovery: development, testing, data mining, reporting, even virus scanning. Anything you want to do that requires copies of your data and you would prefer to off-load from production hardware.

Saves time. Saves money. So easy that your most inexperienced IT person can be designated as “the guy that Barry gets his data from.”  (And not to worry inexperienced IT person – you can schedule NSB to deliver Barry his data every day, automatically).

It makes you smile. It makes Barry smile. What’s not to love?

{ 0 comments }

Earlier this week, Syncsort hosted a  Customer Advisory Board (CAB) meeting at the wonderful Four Seasons Resort in Dallas, Texas, with a select group of our NetApp Syncsort Integrated Backup users (to respect the participants’ privacy, I won’t mention specific names of people or organizations).  We did this to get an unfettered, no-holds-barred view of what we’re doing right and where we can improve.

As part of the event, we went around the room to gain insight into key priority areas and what people were doing. The organizations represented ranged in size from small enterprise to medium enterprise, with a couple service providers thrown into the mix. To nobody’s surprise, one word came up again and again: virtualization. One of the service providers was already 100% virtualized while the rest of the group were at different stages, but most of them quite far along. Everyone agreed that any new servers being deployed were likely to be virtual with a few exceptions (things like clustered SQL seem to be hanging on to physical platforms, as well as some vertical apps that require a unique piece of hardware like a FAX card).

One thing I found particularly interesting was the level of virtual machine density. Almost everyone was running at between 15 to 25 VMs per physical server, higher than the 8 to 10 you usually hear as the average. One customer, amazingly, is now deploying at the rate of 80-100 VMs per box (using 32-core servers). Wow! That’s some serious density. Imagine the ROI on that.  I’m pleased to report that NSB’s low-impact backup is helping to make that possible. In fact, that same user said that before switching to NSB, they had “hit the wall of backups on VMs” at about a 15 to 1 ratio with their previous solution. They were choking on backup data and it was holding back their business. Makes me think of a new catchphrase: “NSB sets your VMs free”! (Clearly a comment like that shows why I’m not working for an advertising firm on Madison Avenue).

Another strong trend was a movement to 10 Gigabit Ethernet. Folks were either there or planning to go there. Deploying VMs on NFS also seemed universal, which certainly helps explain the 10 Gig Ethernet. This was a very NetApp friendly group, so the emphasis on NFS is not that surprising. We asked about “why NetApp?”, and the responses were many: great support; ease of use; a deep partner channel with a lot of expertise. My favorite quote: “NetApp is one box that does everything.”  At Syncsort, we agree!  And that’s just what we leverage to bring data protection to non-NetApp environments (if you can’t have your primary data on NetApp, you can at least protect it on NetApp).

We learned a lot from our users over the course of the CAB meeting and bring back to our labs a lot of great feedback. I also came up with some good ideas for future blog posts (which makes me happy), so stay tuned!  But mainly, we got to develop deeper relationships with some of our users in a setting that didn’t involve any selling. It is amazing the productive dialogue that can be stimulated by just talking about the current solution and our plans for the future. It is always a great sign when customers are just as passionate as we are about the solution.

Finally (disclaimer and warning about shameless self-congratulating), I can’t resist passing along one last comment. That evening after dinner as we sat around talking, having a few relaxing beverages, and watching the Yankees lose (boo!), one of our users who manages a number of data centers across the world made the following comment. “If I ever left my position and went somewhere else, the one technology I would definitely recommend at my new company would be NSB.”

{ 2 comments }

Last week I got involved in a little back and forth with blogger Mark Twomey , who blogs under the title of Storagezilla. Mark is an EMC employee, but the blog represents his opinions, not EMC’s.

Storagezilla is a good name for him.  He’s a feisty partisan who likes to stomp on cars, especially if those cars say “NetApp” on the side, or the name of other EMC competitors. I really enjoy his blog, but that’s not to say I always agree with his point of view.

Last week in a post called “Snapshots are not Backup,” he put up some comments on NetApp’s recent SnapProtect announcement and the notion of whether snapshots alone are valid as a backup mechanism.  I responded from the point of view of NetApp Syncsort Integrated Backup (NSB), which works differently.  You can read the back and forth, but I wanted to just state a few general points about using snapshots for backup.  (Side note: there is another interesting back-and-forth going on between ‘Zilla and industry guru Curtis Preston, which you can read here.

There are a few common objections that people make when arguing that “Snapshots don’t work as backups.”  Let’s look at a few.

Objection: Because the snapshot depends on the primary storage, if the primary fails the snap fails, so it’s not a backup.

True enough for primary-based snapshots. But NSB does something very different: it uses snapshots on secondary storage without the need to even have primary snapshots. That’s why it can support any primary storage (doesn’t have to be NetApp) and still store backup jobs as NetApp snaps, with all the great speed of recovery advantages snaps give you. Your primary storage can melt into a slag heap and it won’t affect your backup data.

Objection: Backups take up disk space and if you run out of space unexpectedly, your applications will fail. Too risky!

Again, true enough if you are doing snaps on primary, but NSB doesn’t.  If an NSB volume filled up, the worst that could happen is a backup job would fail.

Objection: Snapshot are very large objects and they don’t have good restore granularity.

Could be true in some cases, but with NSB your snapshots are cataloged and searchable, so if you need to find every version of filexyz.doc across dozens or hundreds of snaps, you can do it in seconds. You can use wildcards, file size and date ranges, etc.  Or, if you just want to browse the data, you can mount up a snap in about a minute to whatever server you want (assuming the same OS) and just poke around in the file system. And because everything is on secondary storage, none of this impacts your production in any way.

Objection: Even if you move the snap to secondary disk, that disk could fail or you could lose the site and lose all your backup data.

Well yes. But that’s not an objection so much as a design goal.  Anything can fail. And if you only keep one instance of a backup on one disk array, of course you could lose the backup (or lose all your backups in the event of a site disaster).  That is why NSB includes both disk-to-disk replication as well as tape output. Ideally, you want that third copy of data somewhere else to avoid loss if a site goes down.   

You could present more objections (feel free to drop any in the comments, and I’ll respond to them), but to sum it up, the simple but powerful fact that makes NSB different is that we take the data from any primary storage and store it as snapshots without any dependency on that primary.  As soon as you break that link between the primary storage and the snapshot, you eliminate most of the core objections around using snapshots as backups.

So can you use snapshots as backups?  With NSB you can. If anybody knows of a reason why it’s not perfectly feasible, I’d like to know.

{ 0 comments }