There is just no good place to put your data
Every option for storing data has a fundamental flaw. NAS fails. Cloud concentrates trust. Encryption doesn't fix the trust problem. That problem deserves a real solution.
No good place for your data
Most people store their data in one place or with one provider, be it a NAS or a cloud vendor. Your data may be replicated internally, but it's still all eggs in one basket. And speaking of vendors: Do you really trust them? There are many reasons not to, or at least to minimize the required trust. You can mitigate with backups and encryption, but that either doesn't solve the problem or trades it for new problems.
For as long as I can remember, I have not been satisfied with the options of storing my personal data. It started when I was a teenager worrying about my personal files, pictures, documents and so on and it continues to this day. Fundamentally, corporations are facing the same problems, just with higher stakes.
To be clear here: I know that I'm a bit unusual in these regards. Most people will use Dropbox and not think much about it. I have an itch most people don't have, but it actually maps closely to how a security-conscious company thinks.
What I discuss here especially applies to your most important and sensitive data. The kind where you do not want to settle for "good enough".
Now in 2026, these problems are still not solved, and they become even more pressing as geopolitics becomes more threatening.
Currently these are your options - and each one is not good enough
There are basically two main options: either you hold the data or someone else does (on-prem vs. cloud). Then there are two common strategies to mitigate the risks: backups and encryption. Let's go through them.
Your own storage
Back when I was a teenager, you stored your personal data on some disk, and many people do this to this day. Of course, disks sometimes die, or you mishandle your data and lose some. Some people upgrade to a NAS, maybe put some RAID into the mix. That improves the situation, but if your house burns down, again, your data is lost. The same applies to businesses storing their data on their premises.
Cloud storage
Realizing that I wouldn't be able to maintain my data on disks as well as serious cloud vendors, I considered Dropbox, but I never actually used it due to the lack of encryption; they could look at all my data, which I really don't appreciate. You can roll your own encryption (e.g., Cryptomator), but setting it up is a hassle and it felt fragile.
Eventually I stumbled upon Tresorit, a small Swiss storage vendor, which in the meantime was acquired by the Swiss postal service. It has an emphasis on trust and encryption, and it is as trustworthy as it gets. I really love their service. The Swiss company Proton, likewise focused on privacy, is another great option. However, no matter how good their offer is, you are still concentrating trust in a single provider. I can just about accept it as an individual; high-stakes businesses probably can't.
For businesses, the situation is actually worse. Many rely on hyperscalers based in the US, where the Cloud Act is looming and where a different culture of privacy is present. Of course, cloud storage is the status quo which works well in many cases, but for your most important data an uneasy feeling remains.
Backups
You might want to mitigate that concentration of risk with backups. While it might help, you now have to handle a second data location. You should not lose it and you have to maintain steady backups. How to keep everything in sync? And what do you need in case a backup is actually needed? Only then do you really find out whether your backup strategy works. Backups are good and should be done, but they shift the trust and operational problem rather than fully removing it.
Encryption
Encryption is essential, but it has to be done right. Many offers promoting encryption don't do end-to-end encryption. If the vendor has the keys, what's the point?
Even if encryption is set up well, there is still the risk that you don't know who might be able to crack it. Agencies are sitting on older encrypted data, just waiting for means to decipher it. It is a cat-and-mouse game: Quantum computers threaten older encryption schemes, now there is post-quantum cryptography, and who knows how this game will continue.
If encryption is done really well, I trust that it is secure. However, how can you be sure that you did everything right? I want a safety net - a second layer of defense. Ideally, no one except you has a view of the complete ciphertext in the first place.
Threats arising from these options
As you can see, the different options come with different challenges and trust requirements. And this is all not just theoretical. In October 2025, an AWS outage "took down the internet". If your data was stored in the affected region US-East-1, you would have lost access. That such a thing can happen even to the best - in that case, AWS - is exactly what makes this risk worth taking seriously.
So, there are different categories of threats, like single-point-of-failure, privacy/protection, operational risks, and so on. I will expand on these in later posts.
A better storage
The state of affairs felt unsatisfying. However, in a desire to not accept that, I got the idea to just distribute my data over several cloud storages. The first idea was to get accounts for Dropbox and some others and then build a virtual filesystem on top. So the program would offer a mounted folder and in the background operate on the mounted folders of the base cloud storages. It would then basically do RAID5 over clouds, which gives you two major benefits: each cloud only receives parts of your data, and no single cloud can take you down.
As I thought about it, I realized that this would be hard to pull off. As a local program, obtaining safe concurrent operations seemed impossible. Also, implementing a full-fledged POSIX filesystem is daunting. I mulled over the idea repeatedly and also started a few attempts but could never actually make it work.
Then, last year, it suddenly clicked! Not POSIX but actually S3 is the right abstraction. Instead of implementing a large API with many guarantees that do not come naturally to high-latency distributed storage, I could use one that is limited in just the right ways. First, S3 has a smaller API surface and it is more naturally aligned with the cloud, which made implementation less daunting. Also, it has become something of a standard - perfect for me to use it for diverse backend storages. Today, it's used for literally all kinds of data: It is where you can put your unstructured data, but also structured data goes more and more into object stores (think Delta), so if I build on it, I can implicitly cover a lot of applications. Since it is such a standard, there are many object store vendors other than AWS using the S3 interface. Open-source systems like MinIO and Ceph implement S3. Slight exceptions are Azure and Google Cloud Platform, but even though they do not literally use the S3 interface, it can easily be "translated". All in all, offering the system with an S3 interface makes it the perfect drop-in replacement for existing applications.
That way you would get very versatile storage and can connect to many cloud storage vendors. If you wanted you could use it as a personal storage, e.g., by using Nextcloud, but the general concept would lend itself even more to businesses. That realization is what started Fragmenta. I want to address the storage problems and implement a multi-cloud storage based on S3.
While I now focus on IaaS and B2B, I'm still building this for myself too, to solve my long-running storage concern. By the way, I was very happy to hear Martin Kleppmann (known for his book Designing Data-Intensive Applications) argue for S3 as a storage layer in his local-first software approach (this topic deserves an article in itself).
Fragmenta
Now, I'm building the storage system and I call it Fragmenta: Data is split into fragments spread across clouds, so no single party ever holds the whole picture. Even the best storage provider is still just one provider, with all the implications discussed above. The only real way out is to stop relying on a single one. That is what Fragmenta is built for. And even Fragmenta itself is not in your trust chain. Concretely:
- Each cloud provider gets only fragments. Those fragments are pieces of ciphertext: useless on their own and impossible to reconstruct into your data.
- Your data is stored redundantly, so no cloud vendor can pull the plug on you, or blackmail you on cost
- Fragmenta itself will not be in your trust chain for data custody: The base storage clouds run under your name and Fragmenta itself runs on a cloud account that you own, so even if Fragmenta disappeared tomorrow, your infrastructure stays up and your data stays where it is. You lose maintenance, not your data.
As you can see, Fragmenta operates the system but never holds the data in a durable way itself. To be precise: data passes through the Fragmenta-managed infrastructure purely in RAM and is never written to disk there; your data at rest lives exclusively in the backend clouds you choose.
That being said, it is only fair to also talk about what you're trading off for these benefits:
- Cost: This system is built for your crown jewels. Of course, involving multiple clouds for redundant storage incurs cost. Reads also come with egress fees. For example, you wouldn't put large amounts of disposable log files there.
- Performance: This storage is not built for very hot data. You wouldn't use it for your chatty microservice architecture. There is more latency involved (queries go over the internet instead of staying within a datacenter), but for warm to cold data applications, that's usually fine.
Conclusion
That's where this obsession with perfect storage has brought me, and how I'm finally solving this problem myself.
The system is currently in development. I will call it an MVP as soon as I'm confident enough to trust it with my own personal data.
If you're working through the same concerns, I'd love to hear from you. This blog is where I'll document the journey: I will write about threat vectors of data, how to mitigate them, how to use multiple clouds to your advantage and, of course, about the progress of Fragmenta.