When the cloud can't give your work back
We have learned how to wait for a cloud outage to end. Refresh the status page. Put off the meeting. Try again after lunch. Somewhere, people who understand the machinery are fixing it. Eventually the dashboard turns green, and work resumes.
In September, AWS published an update with a different ending.
After months of disruption and damage to its Middle East infrastructure, the company said it could not restore access to data held only in its Bahrain Region or in one affected zone of its UAE Region. In the AWS Health Dashboard, the words that mattered were "hosted exclusively".
Customers with copies elsewhere had something to recover from. For data held only in those locations, AWS had exhausted its recovery options.
There is a question in that announcement for anyone whose working day happens inside a browser: if the service cannot give your work back, where else would you look?
Someone else's cloud is still somewhere
The cloud is an excellent name for something we would rather not think about. It puts the buildings, power supplies and cables out of sight. We pay for a service and get on with our jobs.
The buildings are still there.
AWS spreads services across separate facilities so that trouble in one does not have to stop the others. In Bahrain, the damage reached across several availability zones. It exceeded what those regional protections were designed to withstand.
That is an exceptional event. The assumption it exposed is much more ordinary: somewhere in the system, surely, there must be another copy.
There may be several. They may also share the same fate.
Your team's work lives in those tabs
A project tool holds more than a list of tasks. It holds the explanation somebody wrote before leaving the company. The comment that settled an argument. The attachment nobody saved anywhere else. Months later, those scraps can be the only record of why a decision made sense.
We entrust all of that to services that are usually very good at keeping it available. It is easy to let usually become always.
Take Linear. It was not part of the AWS incident described here; its stated data regions are the EU and the US. But it has published its own account of a very different kind of loss.
In January 2024, a faulty database migration deleted production data. Linear restored a daily backup and worked through later changes, recovering over 99% of the lost data within 36 hours. Some changes conflicted and could not be recovered. Workspaces created during the affected window had to be recreated.
The post-mortem is a candid account of a serious recovery effort. It also shows how much a customer has to leave in the provider's hands: the recovery process, the waiting, and what can ultimately be brought back.
Your own crisis could be quieter. An integration overwrites a set of descriptions. A project disappears, and nobody notices for five weeks. The service is working perfectly when you discover that the thing you need is gone.
A copy you can actually reach
Imagine your usual tool is unavailable tomorrow morning. You still have a deadline. Someone asks for the notes from last month's project.
A useful backup gives you somewhere to look.
It needs to be far enough away from the original problem to survive it. It needs access you can still use. And it needs to open into something you can read. A download you already have can be more useful at that moment than a reassuring promise behind a login screen you cannot reach.
Age matters too. You need a copy from before things went wrong. A mistake discovered six weeks later needs an older copy that has survived six weeks of cleanup.
There is a practical way to find out whether you have this covered: download a copy, open it, and look for a piece of work you recognise. Try the recovery process while you still have the original in front of you. That is a much easier afternoon than learning it during an outage.
Where we fit into this
We build BackupLatte because we want Linear teams to have that second place to look. It saves daily snapshots outside Linear, in private Cloudflare R2 storage under EU jurisdiction. You access them through your BackupLatte account and can download a ZIP containing saved data and copied files. Once downloaded, it can be read without either service.
We also want to be clear about what you are relying on. BackupLatte is another service, with its own dependencies. Keep an occasional download in storage your team controls. A restore into Linear needs Linear to be available; during an outage, the downloaded copy is what you can read.
And snapshots expire. Cleanup does not preserve a last copy when new backups stop. Choose retention that gives you time to notice a problem and act, and download important snapshots before they expire. Our backup and restore guide explains what you can save and bring back.
The AWS announcement is unsettling because it closes off the ending we expect from an outage. We are used to waiting for our work to come back.
It is worth spending one quiet afternoon making sure we have somewhere else to find it.
AWS Health Dashboard and Linear documentation checked on 20 October 2026.