Posts Tagged ‘Zero data loss’
Data privacy has been in the news a lot lately, and reports of information compromise are frequent. Countries are getting serious about data privacy and are imposing stiff fines for failure to adequately protect personal information. According to King and Spalding, in a March 25, 2010, Corporate Practice Group Client Alert, ”The UK data protection authority, the Information Commissioner, will have powers to issue fines of up to £500,000 against companies who breach UK data protection laws from 6 April 2010.” King and Spalding go on to explain that the power to impose the fine can be exercised if “the Information Commissioner is satisfied that the breaches are ‘serious’ and of a kind likely to cause substantial damage or distress and provided the company either deliberately breached data protection laws or knew (or should have known) that there was a risk that a breach would occur but failed to take appropriate action.”
These laws are focused on the unauthorized release of personal information, not the protection of information against loss, deletion or destruction. At the same time, however, laws already exist in some industries, such as financial services, which mandate disaster recovery capabilities and disaster recovery testing. In addition, laws, such as the Safety Act, which requires the preservation of information, have been introduced in order to improve the ability of law enforcement organizations to locate individuals who are engaging in illegal activity on the internet.
What is interesting about about some of the information privacy laws is that liability can be assigned and fines assessed even when companies do not know that a risk of data compromise exists. The requirement is that they “should have known.” It’s a matter of corporate responsibility to know what is possible and take reasonable efforts to protect against bad events. It is not difficult to imagine that a similar responsibility test may be applied in disaster recovery and data retention laws. Organizations will likely be held accountable for what they “should have known,” if they failed to act. Given advances in data replication, deduplication, storage tiering, and data archiving technology, organizations should know that all data can be affordable replicated to multiple sites, all data can be protected through a wide range of disasters, and all data can be affordable archived. Consider yourself informed.
This week, as thousands of IT professionals converge at EMC World, many will be getting their first look at Axxana’s Phoenix System RP. The system, which integrates with EMC RecoverPoint and all RecoverPoint-supported platforms, forces IT professionals to change the way they think and to imagine what was previously thought impossible. Now it truly is possible for companies to protect all of their data over any distance through a wide range of disasters. It is not only possible, but it is affordable for virtually any mid-sized and large enterprise customer. And thanks to RecoverPoint’s and the Phoenix System RP’s integration with VCE Vblocks, zero data loss over any distance is also possible for smaller companies that are leveraging public cloud infrastructures based upon VCE Vblocks.
If you look at the home page of our Axxana website, you will see that we have changed our banner this week to honor other great innovators. These individuals imagined and created what was previously thought impossible. The Wright brothers proved that flight was not just for birds, bees, and bats, but that man, too could fly. Alexander Graham Bell proved that people could remain connected and communicate, hearing each others’ voices over vast distances. John Bardeen and his colleagues, who developed commercially available transistors proved that electronics could be made affordable for the masses, and Albert Einstein, well, he changed just about everything we thought about the physical world.
In his book, The Black Swan, The Impact of the Highly Improbable, Nassim Taleb explains how Europeans could not imagine black swans until they actually saw them. Just like black swans, many will not believe that they can recover their data from the ashes, until they see the Phoenix System RP. No one today denies the existence of black swans, and everyone can imagine them. Soon, no one will doubt the ability to protect all data and recover it from the ashes, from the floods, from an earthquake, or from a building collapse. If you are at EMC World, please stop by and see for yourself. We are at Booth 605.
Amazon has built a fantastic reputation as a provider of cloud services. With multiple data centers, service availability levels at 99.9% and integrated data backup services, Amazon’s EC2 makes perfect sense for new companies that want to build software applications and deliver them as a service. By delivering applications as a service, emerging companies can be a disruptive force competing against established packaged-application vendors. And Amazon EC2 enables these Application-as-a-Service suppliers to avoid the up-front capital costs associated with building multiple, redundant data centers. It doesn’t mean, however, that Amazon EC2 is perfect and without risk.
A look at the Amazon Web Services Service Health Dashboard today showed a number of service interruptions and performance issues in Amazon’s Northern Virginia facility on April 21 – 24. Henry Blodget of Business Insider reported that Amazon had a cloud crash and the “cloud crash destroyed many customers’ data.”
It would take a lot of digging to get to the bottom of why data was lost. The Business Insider article refers to a letter from Amazon to a customer that discusses “an inconsistent data snapshot” and Amazon’s inability to recover the data. Unfortunately, corrupted data which has been carefully copied to another location is still corrupted. That’s why it is important to keep a series of application-consistent snapshots together with transaction journals, so that application-data can be restored to its last known good state and updates can be applied to bring the data back to RPO=0. This is precisely what is done with the EMC RecoverPoint/Axxana Phoenix System RP solution. RecoverPoint maintains application-consistent snapshots, and Axxana stores the changed data, protected from fire, smoke, flood, shock, earthquakes, and building collapse.
As the cloud services become increasingly adopted for mission critical applications, perhaps it is time to consider a zero-data-loss solution.
This post isn’t being written to be critical of Google. They have a tremendous platform. I know many people who use Google, not only for advertising and searching, but for blogging, for collaboration applications, and for email. But I’ve been watching the continuing problems with Google’s Gmail service. On Sunday, February 27th, a software bug caused some Gmail user data to be deleted. As reported by Google, only .02% of users were affected by the data loss, down from earlier estimates that were .08%. Turns out, though, that .02% of the Gmail user base is still a big number. By some estimates, it’s about 35,000 people. It’s now five days later. The latest update from Google, which is from yesterday, reports that:
We have restored the majority of the affected accounts, and will continue to restore the remaining accounts as quickly as possible. Accounts with more mail are taking more time.
Why would it take Google so long to restore data? Because, Google has to restore the data from tape. Google has an interesting perspective on tape:
To protect your information from these unusual bugs, we also back it up to tape. Since the tapes are offline, they’re protected from such software bugs. But restoring data from them also takes longer than transferring your requests to another data center, which is why it’s taken us hours to get the email back instead of milliseconds.
Hours instead of milliseconds? Actually, for some users, it’s days instead of milliseconds. Read the rest of this entry »
About thirty years ago, IBM announced the IBM 3380 Direct Access Storage Device. It had a capacity of 2.52GB and a price that began at $81,000 without the controller. At the time, successful storage solution providers like IBM made their storage systems out of high-quality, high-cost components and charged a premium. The design goal was to prevent failures, because there weren’t a lot of ways to survive failures.
Given the volume of data now created, today’s storage systems are by necessity very different. They are designed with the expectation that components will fail and fail frequently, but that the data will survive. In order to achieve acceptable levels of data availability and data protection, storage system suppliers overcome the component failures through software, through redundant components, and through redundant copies.
What’s the chance that you will be hit on the head with a hammer? What’s the probability that your data center will be hit by a major fire, a major flood, a hurricane, or an earthquake? Both are pretty low, right? If you are a disaster recovery professional, you’ve probably been asked at last once, “Why are you budgeting so much for disaster recovery, when these events are unlikely to happen?” Wouldn’t it be better to spend money on preventing or surviving things that happen frequently? Or better yet, wouldn’t it be better to spend money on things that will help the company grow? But just like a hammer to the head, big disasters can be very costly when they do happen. So we, as businesses, somewhat reluctantly, spend money trying to prevent those disasters that we can prevent and survive those that we can not prevent.
I was looking at some articles on the severity and frequency of accidents and found an interesting blog post by Bill Wilson who has worked in the nuclear power industry and writes about the prevention of industrial accidents. He wrote about Herbert William Heinrich, who worked for an American insurance company and published a book on the prevention of industrial accidents. His research found that for every fatal or severe accident, there were 29 minor injuries and 300 accidents that resulted in no injuries. He suggested that by eliminating the root cause of accidents that caused no injuries, companies could prevent most fatal accidents. The article shows how a dropped hammer can produce a wide range of results, from no injury to fatality, depending upon other circumstances around the dropped hammer, like whether someone was walking beneath the hammer and how high the hammer was when it dropped. But what is common to all of these events is that all injuries could be prevented by eliminating the dropping of the hammer. It’s possible to imagine that all hammer dropping could be eliminated by tethering the hammer to the person carrying it. When it comes to accident prevention, however, the problem with that approach is that the tether that prevents the dropped hammer does nothing to prevent the falling brick. Read the rest of this entry »
If all of the leaks and rumors reported by industry press are to be believed, EMC will soon announce the company’s latest unified storage offering. In fact, by the time you read this, it will probably already have been announced. Dave Raffo at SearchStorage says it will be named the VNX and will combine the CLARiiON CX4 and the Celerra NS into one unified storage platform. This isn’t EMC’s first unified storage offering, and it’s not the only one on the market. NetApp has been offering a unified storage solution for a while, and claims over 150,000 installations. Oracle has been shipping unified storage, ever since they purchased Sun Microsystems, and, of course, there are several startups shipping solutions.
Unified storage has been loosely defined as a storage system that provides both block and file services. After that, arguments over what constitutes “true” unified storage devolve into a discussion of whether the so-called “unified storage” has common management, automated tiering, integrated de-duplication, thin-provisioning capabilities, common replication, and common snapshot features. Regardless of the specific features, what is common to all unified storage is that they enable the consolidation of more data of different types (block and file) into one scalable storage system at one location. This helps customers drive greater efficiency in management, increased flexibility, and improved storage utilization. However, what’s missing, or at least pushed to the back, in the drive to unified storage, is an honest discussion over the need for superior data protection, truly superior data protection, when all data is stored in a single unified storage system.
It is an unfortunate fact that high bandwidth communication lines are required for metropolitan-area synchronous replication. They are also needed for frequent asynchronous transmissions of snapshots to a remote disaster recovery center. When we meet with companies in the U.S., the U.K. or Central Europe, they may complain about the cost of bandwidth for replication, but at least the bandwidth is available at a price. Anyone with enough money can get as many 1 Gb/sec lines as they need, which will do nicely to protect the data for most applications. And they can take those lines and use them with their favorite storage-controller based, triple-site replication software.
In Johannesburg, South Africa, a company might be lucky to get a pair of 40 Mb/sec lines, which in most cases won’t be enough to protect all of the company’s data. And the cost will be outrageous. So triple-site replication approaches are almost unheard of there. The world may be getting increasingly flat, but it’s a mistake to believe that every region of the world has equal access to an affordable, abundant supply of communications resources. Read the rest of this entry »
Maybe all data should have RPO=0.
I was thinking today about a conversation I had a few years ago with the storage administrator of a major financial services company. I wanted to understand his perspective on when zero data loss was important and when it wasn’t. He told me that his team spent a lot of time with the application developers and the business unit executives discussing the various recovery point objective (RPO) requirements and the cost of the various approaches. We’ve all been told that RPO should be tied to the business value of the application, and that we shouldn’t over-insure or under-insure our data. Over-insure and you waste money. Under-insure and you increase risk.
But then he told me the challenge wasn’t in determining the RPO requirements when an application was developed. The challenge was determining RPO requirements of applications that are part of a business process that is constantly changing. “I’m fine with the RPO requirements until some developer takes an application that used to be non-critical and puts it into the critical path,” he said.
According to an article by Peter Judge in eWeek Europe, storage consumes from 20-45% of the power used by a data center. Naturally, storage suppliers are all looking for ways to make their storage more energy efficient. And, as Peter says in the article, when it comes to energy efficiency, “the storage world seems to be ahead of its server brethren.”
In order to think about the energy efficiency of a storage system, you have to think about more than how much energy a storage system consumes per GB of stored data or how much energy is required to retrieve a block of data. Approaches such as automated storage tiering, which move infrequently accessed data to lower-cost and more energy-efficient media, can have an impact on energy consumption. Data compression and de-duplication can also have an impact, since you don’t pay energy bills for data that you don’t store. Automated data retention and data destruction policies can also have an impact, though the flood of new data typically dwarfs historical data, and almost all data is important to someone, so users are naturally resistant to destroying old data.