When your cloud vendor dies, your backup plan dies with it
A US public TV station lost access to 50TB of archives when its cloud storage vendor went out of business. Here is why vendor bankruptcy is the backup failure mode nobody drills for.
A cloud storage vendor going out of business is not a scenario most backup plans have a page for, and that is exactly the hole a US public television station just fell into. Per Tom's Hardware, Nine PBS lost access to roughly 50TB covering 70 years of television history after the vendor it contracted with went defunct. The station has sued Iron Mountain, which hosts the data centre holding the material, to make sure it is preserved.
Read that again. The disks are probably fine. The bytes are probably sitting there right now. Nobody can get to them.
🔍 Durability, availability, and custody are three different things ⚙️
Every storage provider sells you a durability number. Eleven nines, thirteen nines, whatever the marketing deck says this quarter. That number describes the probability of a disk or a replica failing. It says nothing about the probability of the company failing.
There are at least three separate things that can break, and your provider only insures one of them:
| Layer | What breaks | Who covers it | Recovery time |
|---|---|---|---|
| Durability | Disk, rack, region loses your bytes | Provider SLA, replication | Usually invisible to you |
| Availability | API down, network partition, billing lockout | Provider SLA, credits | Minutes to hours |
| Custody | Vendor goes bankrupt, gets acquired, gets seized | Nobody. Possibly a court. | Months, or never |
The Nine PBS situation is a custody failure. The archive did not rot. Access to it became a legal question instead of a technical one, which is a much worse kind of question because you cannot fix it with a script at 2am.
Key takeaway: Your replication factor protects you from hardware failure. Nothing in your storage bucket protects you from your vendor's balance sheet.
💰 If it can happen to a broadcaster, free tiers are wide open 🚪
Here is the part that should worry anyone building on a student or startup budget. Nine PBS is an institution with lawyers, contracts, and standing to sue. It still lost access. Now compare that with how most of us in Sri Lanka actually store things: a free tier, a personal card on a hobby plan, or a service somebody recommended on Reddit two years ago.
What recourse do you have when each of these goes away?
| How you store it | What happens when the vendor dies | Your recourse |
|---|---|---|
| Enterprise contract | Access frozen, assets contested | Litigation, eventually |
| Paid consumer plan | Wind-down email, short export window | Email support, then nothing |
| Free tier | Service off, often with little notice | None. You are not a customer. |
| Someone else's account | Gone the day they stop paying | None |
A free tier is not a business relationship. It is a marketing expense that can be cancelled in a board meeting. Fine for a demo or a college assignment; not fine for client work, a dissertation dataset, or the only copy of your company's invoices.
Bankruptcy is not the only route here either. Acquisition, a pricing change you cannot afford in LKR, a payment method your bank stops honouring, or an account suspension you cannot appeal from Sri Lanka all produce the same outcome: the bytes exist and you cannot reach them.
🛠️ The restore drill almost nobody actually runs 🔁
Most people have backups. Very few have tested restores. The gap between those two is where stories like this one live.
Run this drill once, properly, and you will learn more about your actual risk than any amount of reading:
- Pick a real target. Not a test file you uploaded yesterday. Something from a year ago that you would genuinely miss.
- Cut off the primary. Log out. Pretend the vendor is gone, not slow. No dashboard, no support ticket.
- Restore from the secondary alone, end to end, on a machine that does not already have the data.
- Verify byte-for-byte, not by eye. Generate a checksum before archiving and compare it after restore. Our hash generator does SHA-256 in the browser if you need a quick one-off check.
- Time it. Write the number down. That number is your real RTO, and it is usually much larger than the one in your head.
- Read the file. A restored file in a proprietary format you no longer have a licence for is not a restored file.
Step six catches more people than you would think. Exported data locked in a vendor-specific container is a hostage with extra steps.
🌐 A backup layout that survives a bankruptcy 🧱
The classic 3-2-1 rule (three copies, two media types, one offsite) was written for an era of tape and fire. It handles hardware and buildings. It does not explicitly handle a company disappearing, because when it was written, the copies were yours.
I would add a fourth axis: two independent legal entities. Two buckets at the same provider in two regions is one custody risk wearing a costume.
| Copy | Where | Why it survives |
|---|---|---|
| 1. Working | Local disk / laptop | You physically hold it |
| 2. Offsite A | Object storage, vendor A | Fire, theft, hardware failure |
| 3. Offsite B | Different vendor, different jurisdiction | Vendor A goes under or locks you out |
| 4. Cold | An external HDD in a drawer, updated monthly | Everything above, plus your own mistakes |
For a small team here, that fourth copy is the cheapest insurance available. A single external drive holds far more than most Sri Lankan small businesses generate in a decade. For context, the 50TB Nine PBS is fighting over would fit on a handful of consumer drives today. Scale is not the obstacle. Discipline is.
Two practical notes before you build this:
- Check egress pricing before you commit, not during a crisis. Some providers make getting data in free and getting it out expensive. Model the full cost of leaving on day one, in LKR, at a realistic exchange rate.
- Automate it or it will not happen. A monthly
rsyncorrclonejob on a schedule beats a heroic manual copy you do twice and then forget. If cron syntax is where you stall, our cron expression builder will write the line for you.
Prefer open, self-describing formats for anything you intend to keep for years. Plain text, CSV, JSON, standard video and image codecs. A format you can read with free tooling in 2040 beats a format that needs a subscription in 2027.
💡 What this means for you
I do not know how the Nine PBS case resolves. It may end well. But the lesson does not depend on the outcome, because the damage is already done: an archive that took 70 years to build is now a court matter, and every month it sits there is a month it is not being used, migrated, or maintained.
The practical version, for a student with a thesis, a freelancer with client files, or a two-person team in Colombo running on free tiers:
- Assume every vendor you use will be gone in five years. Then ask what you would do.
- Keep one copy where no company's survival is a dependency.
- Test a restore this month, not "sometime."
- Write down, in one file, where every copy lives and how to get it back. Store that file with the backups.
The cheapest disaster recovery plan is the one you rehearse before you need it. The most expensive one is a lawsuit.