Background

While IT priorities and challenges are often considered with data centers and other centralized corporate resources in mind, it is important to remember that organizations often have distributed locations that have significant and complex computing requirements. In fact, typical IT challenges are often exacerbated in these remote/branch offices due to distance and lack of onsite IT staff. ESG research found that companies face significant challenges when it comes to delivering applications over the WAN from a central location to employees at branch office locations. According to a recent ESG survey,^[1] nearly half of respondents identified improving application performance for end-users as a key initiative (see Figure 1). Improvements to application accessibility and better collaboration capabilities were also high on the list.

Riverbed Steelhead EX + Granite Overview

Riverbed Technology’s Steelhead product family is designed to provide increased application performance and data transfer speeds over the WAN. Steelhead products address four main solution areas.

• Application Acceleration—Steelhead optimizes both TCP and UDP traffic, addresses application-specific latency, delivers LAN-like performance and availability over the WAN, and enables improved collaboration, file sharing, and productivity for distributed enterprises.
• Bandwidth Optimization—enables network managers to achieve better utilization of existing WAN bandwidth by eliminating redundant WAN traffic.
• IT Infrastructure Consolidation—enables consolidation of IT infrastructure from remote offices to a centrally located facility, maintaining performance, availability, and security, as well as reducing capital expenditure and management costs.
• Backup & Replication Acceleration—enables quick and secure backup and replication from branch locations.

The Riverbed Steelhead family of products is designed to optimize WAN traffic between distributed remote and branch office locations and a central data center. Steelhead appliances run the Riverbed Optimization System (RiOS), which is the software platform that enables data-, protocol-, and application-level WAN optimization and allows a central office to consolidate the majority of its remote office server infrastructure, taking the first step toward true infrastructure consolidation. Riverbed Steelhead EX combines WAN optimization capabilities with VMware on the appliance, enabling a branch to virtualize local servers and minimize the bandwidth required by users and applications.

Granite was developed by Riverbed to deliver edge virtual server infrastructure that extends an enterprise storage area network (SAN) out to remote offices. It enables organizations to centralize and consolidate branch office storage at a primary data center. Steelhead EX + Granite combines Riverbed Steelhead and Granite software capabilities with the goal of serving write-intensive and custom applications in the branch with a global storage infrastructure projected from the data center, eliminating storage at remote branch offices previously considered too difficult to consolidate.

ESG Lab Validation

ESG Lab performed hands-on evaluation and testing of the Riverbed Steelhead EX + Granite WAN optimization and storage consolidation appliance at a Riverbed facility in San Francisco, California. Testing was designed to demonstrate how Steelhead EX + Granite improves application performance and availability, as well as delivers infrastructure consolidation and data security for branch locations in a distributed enterprise.

Getting Started with WAN Optimization

Steelhead appliances at remote locations, along with Steelhead Mobile software on remote user laptops, work together with one or more Steelhead appliances in the corporate data center to optimize traffic flowing over the WAN. Riverbed addresses three areas that affect WAN efficiency: application chattiness, data redundancy, and transport protocol inefficiency.

To speed application performance, application-specific optimizations complete transactions locally in the branch on behalf of servers in the data center, eliminating the need to wait for application responses over a WAN connection. To reduce the amount of data sent over a WAN, Steelhead appliances and software intercept and inspect WAN data to determine whether the data or a portion of it has been seen before. When a user attempts to access data already encountered by the local Steelhead datastore, the data is served locally, eliminating the delay of pulling data over the WAN. With this capability, Steelhead appliances allow users and applications to read and manipulate data, while only requesting or sending unique blocks across the WAN. To overcome transport protocol limitations, Steelhead appliances more intelligently scale and pack TCP payloads, significantly reducing round trips and more efficiently transmitting data across the WAN.

Figure 4 shows the test bed used by ESG Lab, which consisted of a simulated data center and remote office. A Network Nightmare WAN simulation device was used to limit bandwidth and inject latency, simulating a transcontinental T1 link. The data center was configured with one NetApp FAS 2050 connected to both Steelhead and Granite core appliances. The remote office had a Steelhead EX + Granite appliance running Steelhead WAN optimization software, Granite block-storage acceleration, and the Riverbed VSP. The connection between the two environments was limited to 1.5 Mbps (T1 equivalent) and had 100 milliseconds of round-trip latency injected to simulate a remote office connecting to a data center up to 3,000 miles away.

ESG Lab Testing

For the first round of tests, Steelhead WAN optimization was used to optimize typical knowledge worker operating tasks. Data reduction and optimization-related metrics were captured using the Steelhead management console as well as wall-clock timing of certain operations. As shown in Figure 5, simple file transfers, Microsoft Exchange messages with attachments, and Microsoft SharePoint transaction performance were measured with and without Riverbed Steelhead WAN optimization enabled. The corresponding results show performance improvements of anywhere from 5X to 50X, depending on the type of transaction.

The data in Table 1 includes the sizes of the objects used in performance testing and the number of seconds to completely execute each operation. The largest time reduction was seen with the transfer of a 65.3 MB file from a remote client to the corporate file server.

Consolidation of Branch Services

Organizations are using server virtualization to simplify their IT infrastructures while reducing costs in their data centers through consolidation. For services required in branch offices, consolidation (minimizing infrastructure in the branches) is also a key goal. However, organizations are faced with a challenge in that certain applications require local compute and storage resources to meet performance requirements for end-users. Steelhead EX features the Riverbed Virtual Services Platform (VSP) that incorporates VMware virtualization technology to consolidate branch servers and applications onto the Steelhead EX appliance.

ESG Lab Testing

ESG Lab began testing the ease of consolidating branch office services and applications using Riverbed Steelhead + Granite technology by simulating the user experience of moving from a traditional branch office with dedicated servers, applications, and local storage to a virtualized Riverbed WAN-optimized and consolidated model, as illustrated in Figure 6.

ESG Lab first virtualized a Microsoft Windows Server 2008 system in the remote location by installing the VM onto the Riverbed VSP. This is accomplished via the Steelhead management interface. The Steelhead EX + Granite appliance can host up to five end-user virtual machines. ESG Lab connected to the Steelhead EX + Granite appliance through the Riverbed Steelhead Management Console to install the virtual server as shown in Figure 7.

Once the virtual machine was loaded and running, ESG Lab simulated a Microsoft SQL server workload using the Iometer load generation utility. SQL Server is an application that, due to the response-time sensitivity of transactional databases, is often hosted on physical servers with local storage in a branch office. In this test, a 4 KB block size was used with a 67% read, 100% random access pattern.

Figure 8 shows the Iometer results displayed during the test. The most important metric to note here is “Average I/O Response Time (ms).” While the back-end connection to the storage array was over a simulated T1 connection with 100 ms of round-trip latency, Iometer reports only 31 milliseconds of latency to disk because data is being written to the local Steelhead blockstore.

It’s important to note here that without Steelhead EX + Granite, ESG Lab was unable to obtain a usable result due to the restricted bandwidth and high latency of the WAN link. In fact, the connection to the LUN in the data center timed out, and the mount failed.

Consolidating Branch Office Storage

Riverbed Granite extends iSCSI block storage from the data center to the remote site in a way that is transparent to users and applications, and that takes advantage of Riverbed Steelhead WAN optimization technology. Granite enables organizations to maintain local servers at branch offices while actually storing and protecting their data within their data centers. Riverbed VSP provides the ability to host those servers directly on the Steelhead EX appliance.

ESG Lab Testing

ESG Lab tested Granite by mounting iSCSI LUNs from the data center on physical branch server nodes as well as within the virtual machines hosted in the Steelhead EX + Granite appliance. To verify the challenge of accessing “unoptimized” iSCSI storage over the WAN, ESG Lab first attempted to mount an iSCSI LUN directly from a traditional branch server to a data center SAN without Granite, and observed that the connection timed out and the mount failed.

Next, ESG Lab tested whether Riverbed Granite could allow the use of iSCSI over the WAN by configuring Granite appliances in both a data center and a remote office location. Figure 9 shows the basic functional design of storage extended with Granite. In effect, there are two iSCSI connections (working from right to left):

• Within the data center (right), between the actual iSCSI SAN target to the Granite core iSCSI initiator.
• Within the remote site (left), between the production server iSCSI initiator to the Steelhead EX + Granite iSCSI target.

Using the same branch server, ESG Lab was able to successfully mount with no errors or timeouts the same iSCSI LUN that had previously failed to mount in the “unoptimized” test.

The combination of Granite with Steelhead WAN optimization makes it possible for a data center LUN to be successfully mounted by a remote office production server—either a physical server located in the branch or one that is virtually hosted within the Riverbed VSP hypervisor.

Next, ESG Lab examined performance and usability. For this test, ESG Lab (working right to left in Figure 9):

1. Configured multiple LUNs within the data center SAN, which is completely unaware of the Steelhead EX + Granite extended storage scenario.
2. Configured the Granite core iSCSI initiator to mount the LUNs that are to be extended.
3. Assigned a specific Steelhead EX + Granite edge device from the Granite core at the data center to extend each LUN. By doing so, the Steelhead EX + Granite device became an iSCSI target and offered the LUN to devices within the remote site.
4. Connected the LUN to the production Windows server using its iSCSI initiator, with the server being completely unaware that the LUN is not within the remote site but actually extended from the data center.

From there, the LUN behaved like any other iSCSI-attached device and could be mounted and utilized. A common concern about remote storage is that the latency associated with initial use or access requests will have an impact on the end-user experience. To observe the behavior, ESG Lab configured an extended LUN within Steelhead EX + Granite that contained a known data set and requested various randomly selected files.

Figure 10 shows the Steelhead EX + Granite Blockstore Metrics report, which measures the amount of “hits” (requested blocks that were already available at the branch) and “misses” (blocks that needed to be sent from the data center) in megabytes. This, in effect, measures the effectiveness of the Granite technology to pre-fetch and/or quickly transmit the necessary blocks, such that the branch server experiences the storage as though it is local.

ESG Lab used AutoCAD software to open a 33.5 MB file (cifs.dwg). The first time the file was accessed across the WAN, the file-open process took 27.7 seconds. The file was closed and the workstation was rebooted to clear client cache. When the workstation was restarted, the same file was opened using AutoCAD, and the file opened in 5 seconds, the same as baseline testing over the LAN.

While Figure 10 shows the Granite technology’s effectiveness in pulling data from the data center to the branch, Figure 11 shows the behavior of data written at the branch being committed to the data center.

• The dark blue line tracks the amount of data being written to the Granite blockstore.
• The light blue areas show data received but not yet written back to the data center storage array, implying minimal latency in transmitting those blocks to the data center.
• The grey areas show data that has been committed to the data center.

Overall, ESG Lab found the Riverbed Granite extended storage solution to be surprisingly easy to configure and utilize. Neither the production server at the remote site nor the data center SAN felt any impact from the extended distance. The iSCSI implementation was intuitive and performed well over a simulated 3,000-mile WAN connection. The combination of Granite with Steelhead technology dramatically accelerated data transfers over low-bandwidth, high-latency connections.

Remote Office Scenarios and Implications

After the servers were virtualized and the SAN storage was extended from the central data center, ESG Lab was ready to explore the performance and resilience of a Riverbed-enhanced remote office when a WAN link goes down and is restored.

ESG Lab Testing

First, ESG Lab set a baseline by opening several large files that resided on an extended iSCSI SAN volume shared on the remote office LAN by a virtual server hosted in the Steelhead EX + Granite appliance without Granite acceleration. ESG Lab opened a 39.4 MB AutoCAD file named “http.dwg” using a client on the remote office LAN. Without Steelhead and Granite optimization, the file opened in 721 seconds, or just over 12 minutes. The AutoCAD application was completely unresponsive while the file was pulled across the WAN.

Next, the same file-open test was performed with Steelhead WAN optimization and Granite active. The first time the file was accessed, the operation completed in 39.1 seconds. After closing the file and opening it a second time, the file opened in 5.0 seconds. As expected, the second open was much faster, being serviced by the blockstore cache on the Steelhead EX + Granite appliance. Saving the file to a new name took 3.1 seconds.

As seen in Figure 12, at 18:07, ESG Lab disconnected the simulated WAN between the remote office and data center, and attempted to open the same file. The file opened successfully, in 5.6 seconds. Next, the file was saved to a new name, which completed in 3.1 seconds. This is comparable to the performance observed when the WAN was connected.

ESG Lab repeated these procedures multiple times, opening files and saving them to new names. Performance was consistent. Figure 12 shows the data writes/commits report from the Steelhead EX appliance.

As shown in Figure 12, as data was written to the network share, the uncommitted bytes that had been accepted by the Steelhead appliance but not yet transmitted to the data center increased. Note that the entire time that the volume was disconnected, the client and server at the remote site remained connected, and the volume remained online.

After approximately 30 minutes, more than 40 MB had been written to the shared volume. ESG Lab then reconnected the WAN and monitored the data writes/commits report. As can be seen in Figure 13, the Steelhead appliance committed the 43.6 MB of data to the NetApp FAS in the data center in about 45 seconds.

The resynchronization was automatic and completely transparent. Users and applications saw no change in connectivity or access when the WAN link was down, nor when it came back up. Figure 14 shows a network traffic summary report for the time period that the resynchronization was executing.

The port number indicates the type of traffic: Port 7951 is traffic flowing between the Steelhead EX + Granite edge device and Steelhead and Granite core devices in the data center. The actual data transmitted across the WAN link was highly optimized, and, of the 43.9 MB of iSCSI data transmitted by the virtual server, only 3 MB was actually transmitted across the WAN, a reduction of 93%.

Data Protection Scenarios and Implications

When extending storage from the data center to the remote office, data protection becomes multifaceted, incorporating not only backup and recovery of production data, but also protection of remote office data from loss or theft.

Securing Data in the Appliance

Riverbed appliances utilize integrated storage to hold cached data in remote locations, designed to enhance the remote user’s experience by providing local access to frequently used data. The Riverbed Steelhead + Granite appliance offers AES encryption (up to and including AES-256) to securely encrypt the data on disk. The AES key for the Granite blockstore is kept in a secure vault area, which is also encrypted using AES-256.

The default key to each appliance vault is unique, derived from a unique identifier of each appliance. The vault key can be changed by organizations to comply with their own security standards. When an appliance boots, the vault key must be provided, or the contents of the blockstore are not accessible. A visual representation of Riverbed encryption is shown in Figure 15.

Backup and Recovery

When considering backup and recovery, multiple data protection scenarios are either enabled or enhanced, including:

• File/application-based protection of the remote data, from the data center
• Block-based protection of the LUNs used by the branch platforms, from the data center

In principle, because server-centric storage utilized at the branch is in fact extended from the data center via Granite (and user-centric data from the branch is stored locally on Granite-extended volumes), Riverbed suggests that data protection can be done entirely from the data center instance of the data.

ESG Lab audited the operating methods that Riverbed uses for storing its data to understand the viability for customers to use their current data-protection methods within a Steelhead EX + Granite deployed configuration.

Traditional File/Application Backups from Guest-VM Branch Servers

For production servers running at the branch, presumably as virtual machines within the Steelhead EX + Granite (VMware Virtual Server) host environment, traditional file- and/or application-centric backups are still achievable.

ESG Lab looked at how a typical backup agent can be installed within a virtualized production OS to send backup data to the requesting backup server located at the data center, as shown in Figure 16. In this configuration, as files are queued to be sent from the production VM to the backup server, Steelhead WAN optimization is designed to recognize the data that already exists at the data center from previous synchronizations. In this case, while both the remote backup agent and the data center backup server believe that the data is being sent across the WAN, only truly unique data segments and reference “pointers” to previously encountered data actually traverse the network.

Based on how ESG Lab tested file transfers with Steelhead EX + Granite, file-centric data movement during backups should be nearly eliminated. Similarly, application-centric backups that generate storage IO as part of the backup process (such as SQL Server log files) will benefit. In those cases, as the data files are prepared for backup, their corresponding blocks within Granite will be committed to the data center and therefore may not need to traverse the WAN during the actual backup.

SAN-based Backup of the Branch from the Data Center

Perhaps the most intuitive and yet subtle method ESG Lab observed was the ability to back up the extended LUN from within the data center. Because the SAN is unaware of the Steelhead/Granite solution, LUNs can be backed up directly using storage-based snapshots and clones—traditional “serverless” backup solutions.

As seen in Figure 17, ESG Lab observed that by backing up the original LUNs from the SAN, all of the production data could be protected in the data center, including virtualized server-centric data and client-specific data that are Granite-extended.

As shown in Figure 17, ESG Lab found serverless backups of remote office volumes to be potentially ideal choices for those customers who already utilize them within their data centers. The IO burden is removed not only from the production resources, but also from the Steelhead and Granite appliances, freeing them up for production IO exclusively. Like any serverless backup, an understanding of the applications in use and the need for consistency and post-backup processing are keys to success.

Riverbed SAN Hardware Snapshot Integration

Along with extending and potentially enhancing customers’ existing backup methodologies, Riverbed has also developed a Riverbed Hardware Snapshot Provider (RHSP) mechanism to directly integrate its storage-extending capabilities with both the Microsoft Volume Shadow Copy Service (VSS) and SAN arrays from EMC, Dell EqualLogic, and NetApp.

Although RHSP was not tested by ESG Lab, a discussion with Riverbed highlighted RHSP capabilities that directly address the need for application consistency with backup. RHSP installs as a plug-in on Windows clients in the branch office. It is used within the VSS process to place a point-in-time marker into the Granite blockstore. This enables a backup agent to quiesce an application to indicate an application-consistent restore point. In turn, this indicator triggers a snapshot on the data center SAN storage array that can then be used for any required restores or subsequent secondary backups to disk or tape in the data center.

ESG Lab Validation Highlights

• ESG Lab used Steelhead appliances to optimize WAN performance and reduced data by up to 50 times, enabling more productive collaboration between remote and central offices.
• When running an OLTP database workload in a Riverbed appliance-hosted virtual machine, ESG Lab observed latency to storage over the WAN decreased by more than 67%, enabling a remote server to mount an iSCSI volume hosted in a distant data center, and making it possible to consolidate business-critical branch services over the WAN.
• ESG Lab found Granite-extended block-storage performance over a simulated transcontinental WAN link to be remarkably viable, rivaling local-attached storage in both throughput and latency.
• ESG Lab validated that Riverbed improved performance by a factor of 18 to 26 times when opening and editing large CAD files across a high-latency, low-bandwidth T1 link, providing WAN access to centralized project files at LAN-like speeds.
• ESG found that customers’ existing backup methodologies were all potentially viable options for remote offices—in ways not achievable without the combination of WAN optimization and storage extension. Without changing their backup mechanisms, customers may find their solutions enhanced because of how Steelhead optimizes the data streams that Granite has already synchronized between sites.

Issues to Consider

• It should be noted that one key to the performance of the extended storage is the built-in blockstore within the Steelhead EX + Granite appliance itself. When designing the storage to be used at the branch, customers should be aware that the Granite solution does not change normal design considerations around capacity or IO performance. Those aspects should still be considered when determining the size of the Granite edge device to place at a particular branch location.
• While many data-protection scenarios are enhanced through this configuration, for SAN-based backup of the branch from the data center, a minimal amount of effort is still required to ensure the boot volumes of the virtualized VMs on VSP within each branch appliance are protected and recoverable. ESG Lab hopes that Riverbed will address this in future releases, so that even in the VSP scenario, an entire VM can be protected at the data center.
• While many backup processes may potentially gain benefit from a Riverbed Steelhead solution with Granite technology, they do so without any awareness of Riverbed’s changes to infrastructure or topology.

The Bigger Truth

Riverbed provides comprehensive WAN optimization solutions, helping organizations share applications and data across global wide-area networks. Riverbed WAN optimization solutions have been proven in the field to give businesses order-of-magnitude increases in the performance and value of their existing IT infrastructure and mission-critical applications, including file sharing, e-mail, backup, document management systems, IT tools, and ERP and CRM solutions.

Riverbed has applied its field-proven WAN optimization technology to provide similar performance gains for SAN-based block data extended to remote offices. Achieving a data reduction of more than 26 to 1 in ESG Lab testing, Steelhead Granite technology not only reduces the amount of bandwidth needed to connect to data center SAN storage, but also provides access to remote users at local speeds, maximizing the productivity of those remote workers. Steelhead EX + Granite also enables organizations to utilize existing investments in data protection hardware and software and secures that data in the data center.

In a truly fluid enterprise, all data and storage resources will be centralized in the data center. When that occurs, organizations will gain the ability to provide desired performance in the branch and the ability to quickly provision systems and storage wherever or whenever they wish. In addition, data protection becomes much easier and more secure for remote offices—it is executed centrally along with all valuable corporate data in the data center.

ESG Lab confirmed, through hands-on testing, that Riverbed’s Steelhead EX + Granite solution is able to reduce remote office network traffic while extending data center SANs with little impact on remote office servers and clients. The solution integrated well with Microsoft Exchange and SharePoint business applications as well as basic file system services and iSCSI block storage, long considered all but impossible to extend over long-distance, low-bandwidth WAN links. Organizations interested in improving the remote user experience while bringing data-center-class performance and protection to their remote offices should seriously consider Riverbed Steelhead EX + Granite.

Appendix

[2] Source: ESG Research Report, 2011 IT Spending Intentions Survey, January 2011.

[3] Source: ESG Research Report, 2011 Remote Office/Branch Office Technology Trends, July 2011.

[4] ESG Research Report, Remote Office/Branch Office Technology Trends, July 2011.

[5] Source: ESG Research Report, 2011 Remote Office/Branch Office Technology Trends, July 2011.

[6] ESG Research Report, Remote Office/Branch Office Technology Trends, July 2011.

This announcement coincides with the publishing of ESG’s whitepaper on “DR in the Cloud” using AWS.

All things being considered, I am very excited about the AWS Storage gateway (AWS SG), mostly because it reminds me in some ways of Microsoft’s for-sale backup product, System Center Data Protection Manager that I used to manage.  DPM wasn’t the most full-featured backup software on the market, but it did at least two very good things:

The AWS Storage Gateway is a credible offering for what its initial release is designed to do.  And like most cloud-based offerings, one can expect it to be enhanced in months, not years, as customers give feedback and operational lessons are learned.  As Terri points out, the AWS Storage Gateway may not be taking over the world of cloud-based storage enablement quite yet.  But the AWS Storage Gateway, when seen alongside all of the other AWS offerings, shows how Amazon is continuing to evolve its Platform-as-a-Service (PaaS) and infrastructure-as-a-Service (IaaS) offerings.   And those evolutions are good not only to Amazon and its ever-growing AWS direct customer base, but also to the partners that will develop even more solutions based on them for the rest of us.

ESG recently authored a white paper on “DR in the Cloud“, based on where we see companies struggling with home-grown DR solutions — and how the AWS offerings can help.

To read the ESG Whitepaper on “DR in the Cloud” using AWS, click here.

Thanks for reading.

In my earlier post, I talked about the 10 professional practices of Business Continuity Planning.

Practices 2 and 3 include “Risk Evaluation and Control” and “Business Impact Analysis.” They are essentially about gathering an understanding of what each of your core business processes are, the IT infrastructure that supports them, and a qualitative and quantitative assessment of what would happen if those operations were impacted. Folks, this is a very healthy thing that isn’t done enough in corporations. Too often, companies grow their business processes and the supporting IT functions over time and incrementally–but fail to step back and re-assess where they are.

Some of the quantitative math for a BIA and RA, as well as TCO/ROI, RPO/RTO and metrics, are available in a sample chapter from my book, which is available as a free download — Chapter 2 of Data Protection for Virtual Data Centers.

When you start BC/DR planning, here is what you’ll get:

Along with reassessing where you are, BCP process 4, “Business Continuity Strategies” starts to look at what kinds of mitigating technologies could be applied to resolve the potential IT faults in your environment:

• Invariably, you will end up putting in replication and failover technologies, where standalone servers used to be.
• You’ll discover new protection and recovery methods, such as cloud-based backup, that originally seemed unattainable and now appear more cost-effective and reasonable.
• You’ll almost definitely become much more aware of the business processes that can be improved.
• And, you’ll discover aspects of your infrastructure that could be consolidated or optimized.

Read those words again — optimized, improved, more cost-effective. Of course, you’ll also be ‘prepared,‘ but the lesson is that while BC/DR preparedness may be the cause, business optimization is the effect.

The server and storage virtualization that enables booting up an alternative data center during a crisis will also reduce your hardware, power, cooling, and space costs now.

The replicated data and resilient applications that ensures continuous operations of your business during a crisis will also assure productivity during a server-level issue or planned migration — and in many cases, improve performance through load balancing throughout the rest of the day and during peak usage hours.

The conversations that you’ll have with your business stakeholders will not only prepare you to be ensure their service during a crisis, they will also almost definitely create conversations where some of those operational processes and procedures can be optimized now. They will also create new dialogues of understanding between the business stakeholders and their IT counterparts which will yield big benefits of empathy and cooperation.

Some of these BC/DR benefits are covered in Chapter 12 of my book — but hopefully, this gets you thinking about BC/DR planning in a new way. While your preparedness and company survival may be the destination, you’ll be amazed how much that you’ll gain during the journey.

As always, thanks for reading.

Every week during the spring and summer, my lawn gets mowed. Specifically, it happens every Thursday morning, while I am working. Some guys come by my home and pick up the check from my wife, and then my lawn magically gets mowed. It’s not that I particularly mind mowing the lawn or think it is hard to do, it’s just that I have constraints on my time and it is easier to simply cut a check. In organizations that my kids are in, we have some parents that would prefer not to hold car washes or run fundraising programs, but they are happy to cut a check to solve the problem. We all have things that in a perfect world we might do, but we are happy to simply write a check and focus on other things.

Some folks look at cloud-based services the same way. For IT tasks that they don’t want to deal with–perhaps due to complexity, competing for resources, or just operational costs–they would prefer they just go away. To do so, they are willing to “cut a check.” Backup can be one of those mundane tasks, and cloud-based backup sounds ideal (and sometimes it is).

Here is the difference

When I pay for my lawn to be cut, the outcome that I want is immediate: a better looking lawn. And other than an accidental cut in an inflatable pool or hose, the risks are minimal. With a small amount of prudence and some proactive selection criteria for picking the service provider, my desired outcome is assured for about $30 per week. To me, I am buying back 3 hours with my kids at $10/hour, which is an easy choice for me.

But remember, you aren’t trying to buy the outcome of “backup,” you are trying to buy the outcome of “restore.” As I and others preach, “backup is just the tax you pay so that you can restore.” In a cloud-based solution, it’s great that you can cut the check to make your nightly operations easier. By doing so, you may avoid backup software licensing costs, tape media costs, power/cooling for disk-based backup servers, and operational costs for the folks managing backup functions. But if you can’t reliably restore, you haven’t bought anything. And no matter how much you saved, it will likely pale in comparison to the losses of unrecoverable data. The trickle of data to the cloud for backups seems nice, but have you thought through how the restore will work. Will it be a trickle, or will the data show up in a restore appliance at your doorstep the next day? If my lawn guy cuts a watering hose, I or he can pay a few bucks and all is forgiven. If I can’t get back my data, there are no easy fixes.

And just like picking a lawn guy who is cost effective but also professional and careful, one should look for a cloud backup provider that protects a wide variety of the platforms supporting my data using software that doesn’t tax my users via complexity or (worse) actually impacting performance or stability of my devices, from server agents that walk the file system too often to smart device agents that routinely crash my device. My neighbors don’t care how my lawn gets mowed, but they care if a trailer is parked in front of their house for too long or if their water hose gets cut by my (guy’s) mower. Your users hold you accountable for backups and restores and their experience for both, regardless of whether you run it or manage it through a cloud service.

First backup, now DR?

And now, we are starting to see cloud-based disaster recovery providers. Again, it is a cool idea and I am very eager to continue watching as the offerings develop, but the same caution applies. Focus not on offloading your DR to someone else. First, because real BC/DR is about people and process, not just remote copies of your data, and secondly because no one is as invested in your company’s recovery as you are. Most folks who manage their own DR planning don’t test their recovery capabilities thoroughly or frequently enough, so it is hard for me to imagine someone who outsources it being more diligent (maybe).

So, is cloud-based backup or DR bad? NO, absolutely not.

I am a long-time advocate of D2D. And more often, D2D2D = from production disk … to secondary disks at the same location … to offsite disks, whereby long-term tape-based retention might occur offsite (D2D2D2T). These days, I am just as much, or more, a fan of D2D2C, where the cloud is your offsite copy and long term retention is managed by them (go ahead, cut the check).

Is cloud-based backup or DR too new to try? NO.

In fact, ESG recently released some validations of Asigra’s v11 cloud-backup technologies.  That’s eleven generations of technology and a huge partner provider network, with over 25 years of experience in cloud-based backup and 400,000 sites being backed up. Those numbers are not typos. Here are links to the ESG reports:

Asigra Public Cloud Backup v11 - delivered by service providers near you

Asigra Private Cloud Backup v11  - using the same technologies in your own infrastructure

Most cloud-based solutions can’t boast a quarter century of experience, but there are certainly other providers and technologies that offer cloud-based backups too, just like there are other folks who mow lawns in my neighborhood. In my own past, I have had positive experiences with Iron Mountain Digital when it was still part of Iron Mountain and not yet HP’s Autonomy as a repository. And I am a fan of i365’s cloud, using its EDPM appliance. Those two solutions both use Microsoft’s on-premises backup solution (DPM), but then store the tertiary copy in their respective clouds.  There are benefits to simply cutting the check (pure-play cloud-based service) and benefits for cutting a smaller check (hybrid onsite/offsite solutions).

My Advice

The other reason that I pay for my lawn to be mowed is because, frankly, they do a better job than I dot. So, not only is it cheaper (time/effort/cost) than doing myself, the quality of the outcome is better. For many folks, cloud-based backup fits the same criteria. The right combination of software and service will likely give you a better quality and cheaper (time/effort/cost) backup. But when you are picking your provider, remember that you are looking for how you will restore, not back up–and that you have a variety of platforms to protect, so be mindful of the experience and support of those applications and workloads.

And most importantly, remember: no one is as invested in your restore as you are–regardless of how you chose to make backups happen.  So, choose your cloud-based (recovery) partner carefully or you may find that your favorite hose and slip-n-slide got hit by a weed-whacker.

Thanks for reading…

via Advantages of Disaster Recovery as a Service – Data Center Knowledge.

“You have to make sure all the connective tissues are reattached when an application goes down,” said Chapa. “Everything rolls into VOM. VBS is the construct that touches all these products. They are simplifying management for availability of applications by focusing on the business problem. Those interdependent servers collectively define a business service.”

via Symantec launches high availability software for virtual, physical servers – SearchDisasterRecovery.com.

Last week, I saw the latest disclosure on what is still too common: “backup tapes are lost and the amount of disclosure is under investigation.”

This time, it was 4.9 million military clinic and hospital patients. Click to read the original article.  The slightly abridged version is:

The lost data was stored on back-up tapes that contained patient health care information from 1992 until 2011. The exposed information may include names, Social Security numbers, addresses, phone numbers, diagnoses, treatment information, provider names, provider locations, and other personal health data such as clinical notes, laboratory tests and prescriptions, according to a data breach notification statement issued by the companies.  The statement claims that the tapes did not contain financial data, credit card, or banking information. It remains unknown exactly how the data went missing. It is also unclear whether the stored data was encrypted.

Let’s first quickly go through everything that is wrong with this picture:

“4.9 million military clinic patients” – our servicemen and their families deserve better.  We all do, but especially those who serve.

“may include names, SSN, addresses” – so all of the personally identifiable information (PII) that someone needs for identity theft is there.

“diagnoses, treatment info, provider names, prescriptions, lab tests” – so all of the HIPAA information that is so closely guarded is out there.

“did not contain financial data, credit card or banking info” – that is okay.  They already have names and SSNs, so they can request new credit cards and bank access.

(and my least favorite part)

“it is unclear whether the stored data was encrypted”

Folks, this is not about you “losing” data. This is about the wrong people “finding” data.

Hence, my sincere plea to the world … Stop Shipping Tapes!

Tape is not dead, nor is it dying. Yes, I am a disk-to-disk (D2) fan. More specifically, I have long been a D2D2T (to Tape) fan. Lately, I am even more of a D2D2C (to Cloud) fan.

Tape absolutely has its place: on a shelf.

Nothing else can take large amounts of data and store it indefinitely without applied power or cooling as well as tape.  Yes, you have to cool the room, but since tapes do not create their own heat or consume their own power, it isn’t linear like disk subsystems.  So, tape has its merits.

Important Key Point – the ability to be placed in a carrying case for easy shipping to an offsite location is NOT one of the merits of tape.

If you’ve read my other blog posts, you know that I tell anyone who will listen to “Get Your Data Out of the Building” (see earlier post), but please do not use tapes for transport.  Yes, there are respectable third-party providers of courier and storage services, but the bottom line is that your tapes are your responsibility and your liability.

Ok, if you absolutely believe tapes are the only way for you, then please click the simple checkbox that every respectable backup solution has for “[X] Encrypt Tapes.” But tape is almost never the only way…

There is a Better Way

Electronic data in flight is so much easier to encrypt and protect–and it is more current than nightly backup. Instead of your offsite data being at least one day old, it can be 15 minutes  or an hour old.  Now, your offsite data start to resemble the first steps in a disaster recovery plan.

Get your data offsite over a WAN or the ‘net, and THEN back it up to tape.  The result is the same “offsite, shelf-able media” but without the risk of having to announce exposed data.

• If you are a Windows environment, you likely already own ECI or System Center suite licenses and so you already own Data Protection Manager (DPM), which does D2D 2T natively, or D2D2pC to a partner’s cloud, such as i365.
• If you centrally manage your data center storage,  let your SAN get your data offsite, like the Thin Replication capabilities in a Dell Compellent Storage Center
• If you don’t have a secondary site of your own, then go straight to the cloud, like an Asigra solution, hosted by a partner near you.

Once your data is reliably and securely offsite, then do your tape backups.  Heck, even if you do your own D2D across sites, using a cloud as the tertiary location–whether it be i365, Asigra, what was Iron Mountain Digital (Autonomy), etc.–is definitely worth considering.

The vendor names above are not necessarily my endorsements as best-of-breed because I don’t do that, but the point is that you have a range of options, all of which are better than putting potentially unencrypted tapes in canisters to be picked up by some guy in a truck.

I cannot afford it

If cost is the only reason you haven’t done better with offsite data, then ask your execs and lawyers and marketing folks, “Can we afford to do a data breach disclosure?”

Use words like “resolution of identity theft for 4.9 Million claims” … “corporate reputation” … “indemnification” … and they’ll get the idea.  If you need more ideas of the hidden costs of lost data, check out the sample chapter “Data Protection by the Numbers” from my book.

So, three leave-behinds for you to consider:

YES, Get your data out of the building

PLEASE, stop shipping tapes as the transport medium

NO, you can’t afford not to

Thanks for reading …

via Actifio Reexamines Data Protection, Disaster Recovery – InformationWeek.

via Replication technology for business continuity and disaster recovery.