An opinionated review of the OVH Cloud Archive Service
Reviewing a cold storage offering while gaining some perspective on a data protection strategy.
Some perspective
So you need to store your data somewhere safe and you are looking for a cost-effective solution. You can find online a lot of benchmarks of the different cloud providers for their cold storage offering, but this is not my point today.
In a recent article published here (in french), I showed that one should not trust the reliability marketed by cloud providers because the consequences of a failure are not acceptable. To summarize : Even if cloud providers are offering a really low probability of data loss, they have virtually nothing to loose from such a loss, this is a perfect example of an asymetric payoff (a negative one here, See Nassim Nicholas Taleb essays to dig further).
My first take as a business owner of a company offering digital transformation services is the following : When you have to store and protect data from loss, one shall use several services from different providers, the more important the data, the more providers. In a (buzz)word, one shall be multi-cloud.
The OVH Cloud Archive service
OVHCloud is a leader in Europe and they offer a wide range of services. Although they are behind AWS in terms of features and geographic coverage, their offering is way cheaper (watercooling helps keep costs down).
At Netsach we have been using their cold storage offering for more than 3 years in conjunction of other services for backups and hybrid storage configurations.
The service pricing is composed of a monthly fee, ingress and egress costs :
- Data at rest costs 0.002 € / GB / month
- Ingress is billed 0.01 € / GB (ingress = data going to be archived or frozen)
- Egress is billed 0.01 € / GB (egress = data coming from the archives, unfrozen)
As their competitors, the restoration process is restricted to ensure infrequent use : you will have to unfreeze your files to be able to retrieve them. The process takes as low as 10 minutes and can take up to 12 hours.
Once unfrozen, the files are available for 24 hours before they are frozen again. As this process is somehow an industry-standard now, there are a few details that are worth noting.
The good
The ingesting process of files is really simple : all you have to do is to upload the files using one of the available protocols (rsync, sftp, and openstack swift). So you can use tools like cyberduck or winscp from your desktop. We use the swift API in our applications as we can automate things a bit more.
If you already use the swift object storage API in your application, this is great because the integration is simplified.
The performances are good : each time we archived or unarchived we maxed-out our bandwidth (1 Gbps).
From my point of view, the price is a bargain and as we all need several backup solutions, having cheap ones is a must.
The less good
The retrieval process is somehow clunky when you are not using the swift API, the unfreezing process is the following :
- Access the file to be unarchived as-if you want to download it
- Experience a cryptic error that tells you that the file is not available or some other error (this is expected)
- Wait a few hours (4h)
- Try downloading again the file : it works
This behavior is explained by the fact that only the swift API will tell you when the files will be unfrozen. Even if you use a desktop client like cyberduck, the error message containing the ETA of the unfreezing process is not displayed because the error code is not implemented in desktop clients. You will have to wait 4 hours before retrying.
The developer documentation details this process for the swift API and it works as documented.
The bad
As part of the service, you have access to an integrated user interface. You can see the content of the archives. However when you have a lot of files the interface is useless as you cannot unfreeze multiple files at the same time. You have to manually click twice to unfreeze one file !
The unfreezing process should be done using the rsync or the swift protocol.
Some more technical details
What about the reliability of the solution ? As I wrote before, the reliability data should be read with caution. However, there are industry standards to add redundancy to a storage system known as RAID-1, RAID-5 and RAID-6. The technical details behind these systems is the implementation of erasure coding. Basically more information than needed is stored on drives. In case of partial data loss, information can be rebuilt.
What is interesting here is that OVHCloud give us the configuration of their erasure coding in the developer docs :
For 12 dataframes, they add 3 parity frames. So 20% of the storage is dedicated to the protection against failures.
So for one file, we can guess that it may be spread across 15 drives (erasure coding may be implemented per file and not per volume) and the service will keep your data safe as long as no more than 3 drives fail at the same time.
This is safe, but not bullet-proof safe.
Key takeways
Data storage and data protection may become one of the key challenge as we keep creating content. What we tend to forget is that our data has never been so fragile : a failure of fire extinguisher systems or AC in a datacenter can wipeout billions of dollars worth of data.
We built datacenters like nuclear power plants, centralized and secured as much as possible. Still, we did not have a Fukushima or a Tchernobyl incident yet. Hopefully we won’t. Just use more than one service for your data protection ensuring that you know which is the underlying the cloud provider.
In the mean time, OVH offers a decent archival service that comes with an industry standard safety level while keeping costs low.
