TwinStrata Blog » Amazon S3

How to Back Up Your Cloud Storage

Nicos Vekiarides — Tue, 08 Mar 2011 13:00:26 +0000

Protecting your data in the cloud with a perspective on the Gmail outage

Recently, Howard Marks posted an article on Network Computing entitled “Can Cloud Snapshots Replace Backup?” Howard’s key implication in the article is that cloud storage gateways, onramps or enablers that reside on-premise can replace conventional backup with snapshots for primary data stored in the cloud. However, the article leaves open a point of exposure around the reliability of the cloud storage provider if both the primary copy of data and snapshots are in the cloud. In that case, the storage provider is responsible for the safekeeping of both your primary and backup data.

Let’s take a closer look at what may possibly go wrong with a cloud storage provider and your primary data in the cloud.

For starters, a provider could experience data loss. Better providers offer redundancy and multi-datacenter replication that reduce or eliminate risk of disk or data center failures. For instance, Amazon claims 99.999999999% durability of data stored on S3. Assuming the cloud provider you choose maintains best practices around redundancy and data protection, the odds of data loss due to hardware of site failures are rather low.
The more likely scenario is that a provider suffers an outage which prevents data access. To be fair, better providers offer 99.9% or even 99.99% availability, but none offer a 100% guarantee against outages, so a cloud provider outage could range from a temporary annoyance to a painful business outage. More 9’s of availability help, but also keep in mind your network availability is also a limiting factor.
A third, though less likely, case is that the cloud storage provider goes out of business. Again this would depend highly on the quality of the storage provider, which may leave users a migration path, such as when EMC Atmos Online stopped supporting production customers. Whether or not there is a migration path, this case should be part of any risk analysis when it comes to storing business critical data in the cloud.
Finally, the world is still buzzing from thousands of Gmail users losing access to email accounts in late February, that was blamed on a bad software update. The words of Google vice president of engineering and site reliability Ben Treynor are quite telling on how Google is recovering these customers: “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.” The sobering message is that just because data is stored in the cloud, it is not exempt from software bugs or even human error, and may still require an offline storage tier for recovery.

Although snapshots in the cloud can functionally replace backup, how can we address the paranoid system administrators who are now white-knuckled at the thought of the 4 aforementioned risks? SLAs or a refund of monthly fees may be a small consolation in the face of lost data.

Is there a foolproof way to eliminate any business continuity dependency on the cloud provider? It turns out there are in fact a few:

Keep a local data copy. This is almost too simple, but some cloud storage enablers allow you to keep full local copies of your data along with snapshots in the cloud. Some, like CloudArray, even allow you to grow a local cache to ensure entire data sets reside on-premise. Additional local storage tends to be cheap, while off-site storage is very expensive, making this a compelling way to continue operations even if a cloud provider suffers an outage.
Use multiple cloud storage providers. Some cloud storage enablers support multiple cloud storage providers. If so, replicating across providers is relatively simple, albeit at double the capacity and bandwidth costs. The additional cost may be a bit much to swallow, reducing the viability of this alternative.
Periodically copy data/snapshots off-cloud. This may sound familiar to the backup administrator. Recently, Marcel van den Berg published design guidelines for Veeam backup and stated “As a number one rule I would advise to store the backup on a different storage platform than the storage platform which is being protected.” The notion of where a storage platform in the cloud begins or ends is admittedly vague. It’s not clear that storing backups in the same cloud observes this fundamental rule. Enter “off-cloud” copies or backups which can reside on-premise or on a separate cloud provider and the problem can be solved. The notion of having primary data in the cloud and backups local may sound strange at first, but is actually a very viable option that is supported by cloud storage enablers like CloudArray and provides protection against both on-premise and cloud disasters.

With these alternatives, it is viable to store primary data in the cloud while minimizing risks of cloud provider failures, software reliability and even human error.

No data center is perfect, which is what makes off-site backup and disaster recovery (DR) planning a requirement for most organizations. Likewise, storing primary data in the cloud is no exemption from proper DR planning and best practices.

Bottom line: If you are considering using a cloud storage enabler, gateway or onramp to store primary data in the cloud, consider working with a product that minimizes your risk and a company that has already thought through and addressed the possible risks and DR contingency options.

Do you use cloud snapshots for backup? Let us know…

Cloud Storage Performance: I/O Does Matter

admin — Tue, 11 Jan 2011 13:57:42 +0000

One of the first decisions you will need to make when tuning your environment for Cloud Storage I/O is what page size you will use to perform writes to your Cloud Storage Provider (CSP). This is one of the configuration parameters you will enter when configuring a new volume in CloudArray.

Page sizing is an important consideration, and represents the smallest unit of data that will be sent to your CSP from your CloudArray appliance, or read back when needed. Choose a size that is too small and you may have to do a lot more I/Os if you need to move a lot of data in bulk. Choose a size that’s too big and you will move more data than you need to.

For example, if your application needs to read a lot of small chunks of data that don’t already reside in your CloudArray cache, then CloudArray will have to issue read requests to the CSP for each of those chunks. If each chunk was 64K in length, and they weren’t contiguous, then CloudArray might have to issue 4 separate read requests for that data. If the data were contiguous, then only 1 read request would need to be made.

Larger Page Sizes will result in more data being read than is needed for the current operation, but it may help performance if that data is needed at any point while it is still in cache. In CloudArray, you can choose variable page sizes from 128 KB (default) all the way to 2 MB. 512 KB is the recommended value for backups and in cases where there is a lot of sequential I/O.

If you do a lot of random small block I/O, you should choose the smaller default page size. This will prevent having to move a lot of empty data between your CSP and the CloudArray appliance. A large page size here will cause slower overall performance since a lot more pages will have to be written to accommodate the data requirements. Likewise, if you are doing backups, you will want the 512 KB (or larger) page size. This will result in fewer overall writes compared to a smaller block size and performance will increase.

This can have an impact in your cost model as well, but nowhere nearly as much as some vendors selling file system-based appliances would have you believe. Some CSP’s will charge a small per transaction fee for each read or write request you make. For Amazon S3 for example, the charge is $0.00001 per write transaction. And so for a 1TB backup, that amounts to 8,388,608 x 128KB transactions, or $83. If you used a 512KB page size, that would amount to 2,097,152 write transactions, or $20 for the write transaction costs. Reads are cheaper by an order of ten. That’s a far cry from the $1K+ figure for a 100GB write that another vendor would cost you.

Visit www.TwinStrata.comfor more info about CloudArray.

Amazon S3 RRS Cloud Storage — Secondary storage tiers at 33% savings

Nicos Vekiarides — Thu, 27 May 2010 02:08:55 +0000

Amazon recently announced S3 RRS starting at $0.10/GB per month, a very palatable 33% less than S3 standard storage. What’s the catch? RRS means reduced redundancy storage, a tier of storage that maintains fewer copies of data than Amazon S3 standard service. According to Amazon, S3 standard storage provides “99.999999999% durability and 99.99% availability of objects over a given year” and can sustain “the concurrent loss of data in two facilities.” RRS storage provides “99.99% durability and 99.99% availability of objects over a given year” and can “sustain the loss of data in a single facility.”

Why is this interesting to CloudArray customers? Because many CloudArray solutions involve secondary tiers of storage in the cloud with full copies of primary data on-premise. In these cases, RRS is a great cost-saving tradeoff for the secondary storage tier in the cloud with very little impact on overall data availability thanks to the full on-premise copy.

It is important to use this new tier of storage wisely. For those solutions using primary tiers of storage in the cloud without full onsite copies, it may make sense to stick with the standard S3 service.

Because CloudArray makes storage providers and policies flexible and transparent, our customers now have the benefit of a more cost-effective tier of storage for backup, data replication and business continuity solutions to Amazon.

A Move to Cloud Storage, Companies Re-Think Data Protection Strategies

Robert Infantino — Tue, 01 Dec 2009 19:50:48 +0000

Ongoing discussions with customers on their challenges with existing data protection solutions are leading to changes within their data center. Customers are frustrated with the current data protection process. More specifically, storing information off-site on tape where it can take anywhere from a few hours to as much as a week to restore information. “This is just plain unacceptable and costly”. Human intervention, misappropriation of data, special security transports for tapes that contain certain types of information are all adding to the latency and cost of storing and retrieving data off-site and on tape.

New technologies and solutions with ROI measured in months are driving the need for change. Once such technology is Cloud storage. One of the many uses for Cloud storage is as a target device for data protection applications. Meaning, as opposed to pointing a data protection application to a tape device or even a disk system, point it to the Cloud. Easily accessible from anywhere around the globe, companies [applications] can securely store and access data in real time, cost effectively and with ease. Tape management and off-site tape storage challenges are mitigated or eliminated.

In the Solutions section of TwinStrata.com and on their respective blog we provide a list of data protection solutions and Cloud storage providers that are qualified to operate with CloudArray software. The list of data protection applications are from well established companies such as Oracle (RMAN), Symantec (Backup Exec), Vizioncore (VRanger Pro) and younger companies such as Veeam, PHD Virtual (esXpress). Cloud storage providers include Amazon.com (S3), EMC Atmos, AT&T and others. These applications and providers work together with CloudArray software to protect data and quickly retrieve information at a moments notice.

Check back from time to time, we will be adding more applications to the list of CloudArray supported applications and Cloud storage providers.

Also, Twinstrata is offering a free 30-day trial of CloudArray software. Click here for link.