The Storj Platform distinguishes between two types of object storage: remote and inline. Remote objects are large enough to erasure code and store the pieces of the file on storage nodes. Inline objects are smaller than the metadata associated with the actual object. In the case of objects that are smaller than the associated metadata, it is more efficient to store the object inline in the satellite metadata database
My question is do inline files have the same durability and uptime guarantees as normal remote / larger files? And if the guarantees are different then what are they?
The SLA is the same, just inline segments stored in the metadata distributed database, running in our facilities across the globe.
See our Terms of service and Terms of Use.
The SLA is the same, just inline segments stored in the metadata distributed database, running in our facilities across the globe.
Hi Alexey,
Could you elaborate on that statement, please? Specifically in the context of durability for inline segments.
I’ve read through the TOS and TOU and the SLA applies for availability, not durability. In fact, the TOS clearly states that Storj is not responsible for any loss or damage to storage materials (i.e., user data).
The whitepaper seems to indicate that erasure coding only occurs with remote segments, not inline segments. Is my understanding correct, or are inline segments also stored with erasure coding?
I ask because my backup software generates larger files (encrypted blobs of backed-up data that are sufficiently large enough to be remote segments) and smaller index files (which would be inline segments). Both are needed to restore data, and I’d like to ensure that both are sufficiently durable to not be at risk of damage or loss.
For this purposes it does not matter – satellite losing data means data loss for the customer, and it does not matter whether this is inline segment or metadata. the TOS and SLA apply to the whole service, regardless of implementation details.
On the contrary, that’s precisely why it does matter.
The documentation goes into substantial detail about the mathematics of Reed Solomon erasure coding and how remote segments are protected from loss or damage.
It’s a bit more sparse and much less quantitative as to what protections exist for metadata and inline segments. That’s what I’m curious about.
And there’s many conditions where some data could be corrupted but not have a total, catastrophic data loss. For example, a bit of metadata or inline segment suffering a bit flip.
Put simply, my question is are metadata and inline segments protected to the same degree as remote segments?
For clarity, that’s the TOS that says there’s no guarantee against data loss and the SLA that only covers service availability with several exceptions, correct?
To rephrase: the whole storage is no more reliable/durable/available than a satellite. All the agreements are written with respect to the service as a whole. The whitepaper is an explainer at how larger segment work, because it’s unique to storj, and how can claimed reliability be achieved while storing bits and pieces on an untrusted, even Byzantine nodes.
This is a valid question, and the logical answer is “obviously, they have to be, to roughly the same degree”, but I can’t point out the specific docs on how it is achieved. Perhaps because it’s not that important. They may be using third party compute services that provide desired data durability and availability, like Google cloud. I remember reading that satellite is a redundant cluster, and because metadata is small, it’s inexpensive to store it with sufficient redundancy for any specified desired target durability. See more in chapter 4.9
No service can provide 100% guarantee. Storj claims to provide 11 9’s of durability — so the satellite by necessity has to stores data with durability is no lower than that.
Of course not. But their TOS and SLA provide no statement I could find regarding any standard for data durability or data loss. On the contrary, their Terms of Service explicitly states, “Company does not guarantee the maintenance of any Storage Materials and is not responsible for any loss, misuse, or deletion of Storage Materials or any failure of any Storage Materials to be stored or encrypted.”
Storj claims to provide 11 9’s of durability — so the satellite by necessity has to stores data with durability is no lower than that.
As far as I’ve been able to see, Storj’s marketing text makes that claim, but I’ve not seen anything in the actual Terms of Service, SLA, or Terms of Use that make such a claim in a formal, binding sense. It’s possible I’ve missed something, which is one of the reasons I’m asking.
As @arrogantrabbit said, it’s doesn’t matter, how they are stored, SLA is covering the whole service.
Yes, the inline segments are stored together with their encrypted metadata, there is no need to use erasure codes. The database is a distributed service across several locations, as everything in Storj. We have a regular backups and other procedures which also compliance with SOC2.
This is because the remote segments are stored on untrusted devices across the world, likely without any monitoring or on unreliable hardware without 24/7 NOC, etc.
On contrary the inline segments are stored in the trusted SOC2 Type II environments, which have 24/7 NOC, reservations and high availability, it is a distributed service too but much more reliable than nodes in the network, thus the erasure coding is not needed, there is an integrated durability of the used certified database software and hardware.
The durability itself is a part of availability, if the segment is lost, the file will not be available, this is how the Storj network works.
As @arrogantrabbit said, it’s doesn’t matter, how they are stored, SLA is covering the whole service.
[…]
The durability itself is a part of availability, if the segment is lost, the file will not be available, this is how the Storj network works.
That’s good to hear. Out of curiosity, could you please point me to the SLA you’re referring to? The only one I’ve seen is in the Terms of Service (section 9) and refers to the availability of the service (and the maximum 10% service credit if that availability doesn’t meet the SLA) but made no statements as to the durability of files stored in the system:
(i) Storage Services SLA: except for scheduled maintenance, the Storage Services will be available 99.95% of the time. We calculate availability based upon the service records we maintain. We will use reasonable efforts to notify you in advance of any scheduled maintenance.
(ii) Edge Services SLA: except for scheduled maintenance, the Edge Services will be available 99.9% of the time. We calculate availability based upon the service records we maintain. We will use reasonable efforts to notify you in advance of any scheduled maintenance.
Is there some SLA or other explicit statement regarding file durability for files stored both in remote and inline storage? Even though they’re stored in proper datacenters in managed databases, do inline segments and metadata undergo auditing or other verification to ensure their integrity? Is there some means of detecting and correcting errors that may arise (e.g. random bit flips) in such data?
I ask because I feel like I’m missing something and I’m trying to reconcile several different statements: specifically, the marketing text on the Storj website refers to “eleven 9s” durability and links to information about the erasure coding, the SLA refers to availability of the service not file durability (and explicitly disclaims responsibility for loss of or damage to files being stored), and you stated that inline segments are stored without the erasure coding the documentation describes as the method by which the durability is achieved.
Sorry for all the questions, and thank you for your patience in helping me better understand.
It’s not in SLA documents and will not be, no one cloud provider include it.
SLA is a final document when you use the service, nobody can provide you 100% guarantee on the Earth.
You may contact sales to conclude a contract, including special requirements to responsibility for damage, etc. It is a premium service.
Thanks again for your response. I’m afraid I’m still a bit puzzled: both yourself and @arrogantrabbit have made statements that the “SLA is covering the whole service” and that “the SLA is the same” in reference to @rhodey’s and my own questions regarding file durability.
But the SLA doesn’t make any reference at all to durability, just the availability of certain parts of the service itself.
What exactly do you mean when you refer to the SLA in the context of durability?
I completely understand. I’m not asking for a 100% guarantee, nor am I expecting one. I’m just trying to reconcile the statements I referenced above and understand what level of durability is offered.
No one SLA in the world of cloud services includes durability. You may Google for it.
You have a SLA, which has statements regarding availability because it’s usually more important for the client.
If you want to include a responsibility for the potential damage, you need to conclude a contract, which would include these conditions. I cannot offer anything better.
I’ll take your word for it. But why mention it in the context of @rhodey’s question about durability without mentioning that the SLA refers to availability only?
That’s fair.
I just find it confusing for the website to state “eleven 9s” of durability, that it is “architected using zero-trust and zero-knowledge principles that yield the highest levels of durability”, the Storj Product Overview state that “Storj makes that storage and bandwidth available as a distributed cloud object storage service for developers, with an enterprise-grade 99.95% availability, eleven 9s of durability, and S3 compatibility under the Storj brand.”, etc., but the actual Terms of Service make no claims at all to the durability at all and make it clear that even if a user’s data was completely wiped out or corrupted through no fault of the user then that’s just a risk the user takes.
I’m not demanding perfection – things happen, after all – and I like the service from a technical perspective, but just saying it’d be nice if the Terms of Service (as opposed to just other pages on the site) said something to the effect of “Although the Storj is designed and engineered to provide eleven 9s of durability and [XYZ]% availability for all data stored, including metadata, inline segments, and remote segments, Storj is not responsible for any loss of customer data…” since that’d make it clear in the actual contract that that entire system is designed to provide that level of durability even if there’s no liability for not providing it.
I may be splitting hairs, hope you take this as the friendly constructive feedback it’s intended as, and again I thank you for your patience.
You will find this confusing on every Cloud Storages, all mentioning that their solution is designed to have 11 nines durability, but no one includes this to their SLA.
This is a current normal.
The inline segments have not worse durability than the underlaying environment, our providers doesn’t include a durability to their SLA, why shall we? How we can guarantee something which is not guaranteed to us?
But yes, Storj Cloud Storage is designed to have durability of 11 nines as well, as stated in the mentioned article.
Since you are talking not about a durability but responsibility for damage - it’s a different story, this is a part of the individual agreement (contract) and shall be discussed when you would conclude such an agreement.
