Restore Day

Today is the day the Manus data comes back. Or doesn't.

If you missed the setup: Manus got acquired by Meta for around two billion dollars in December of 2025, Chinese regulators ordered the deal unwound in April, and the unwinding required deleting user data generated while the wrong corporate parent was in charge. Affected accounts had until the twenty third to back up. Deletion ran through the twenty fourth. Restoration opens today.

I wrote about the exit side of this last week, the part where you build a way out of any platform before you need one. That was the fire drill. Today is the fire.

Because here's the thing about backups that nobody enjoys hearing: a backup you have never restored is not a backup. It's a folder you feel good about.

Most people running a small business have never once restored anything. They've made backups. They've paid for backup tools. They've checked the little green status indicator. But actually taking the archive, putting it somewhere, and confirming the business could run on it? Almost nobody. And today a chunk of people are about to find out the hard way, which is the only way anybody ever finds out.

So let's use somebody else's bad week productively.

This works whether or not you touch Manus. Pick any platform your business would genuinely hurt without. Your CRM, your email tool, your project system, your file storage. The one where you'd say "oh no" out loud.

Go get your most recent export. Not make a new one. The one you already have, sitting wherever you left it. That's the point of the test.

First, can you open it. Sounds stupid. It isn't. Exports come out as JSON, as CSV with encoding that mangles anything not English, as proprietary archives that need the vendor's own tool, as a zip of ten thousand HTML files with hashed names. I have watched a very smart operations person discover her three years of backups were a format only the platform she was leaving could read.

Open it. Actually look inside. Right now.

Second, is the thing you care about actually in there. This is where most exports fail and where the failure is expensive.

Exports are usually built for compliance, not continuity. They contain what the vendor is legally obliged to give you, which is often the records but not the relationships between records. You get contacts. You don't get which contact belongs to which deal. You get files. You don't get the folder structure. You get messages. You don't get the threading.

Pick five real things from the last month and go find them in the export. A specific customer and their history. A project and its attachments. An invoice and what it was for. If you can find all five with their context intact, you're in better shape than most.

Third, how long would rebuilding take. Not a guess, a number. If the platform vanished this afternoon, how many hours to be operational somewhere else. Include re authenticating everything downstream, which is the part everyone forgets and which is always the biggest chunk.

Write the number down. That number is your actual risk, expressed honestly, probably for the first time.

Fourth, what breaks quietly. This is the one that gets people.

Your automations point at that platform. Your invoicing might pull from it. Your scheduling links might live in it. Somewhere in your business is a webhook firing into a system that is about to stop existing, and it will fail silently for eleven days before you notice the follow up emails stopped going out.

List every integration touching that platform. Most people find between four and nine and are surprised by at least two.

Forty minutes. You now know something true about your business that you did not know this morning.

The lesson people are taking from this is "back up your data," which is fine but it's the small lesson.

The bigger one is about the shape of the risk. Look at what actually happened here.

This deletion wasn't triggered by a security incident. Manus was explicit about that. It wasn't triggered by inactivity, or by storage tiers, or by anything that would show up in a normal risk assessment. The data was deleted because of who owned the company while the data was being made.

That's a category of risk most small businesses have no model for. You can evaluate a vendor's uptime, their security posture, their pricing trajectory, their funding. There is no field in anybody's vendor checklist for "will a foreign regulator order this company's ownership unwound in a way that requires erasing my Tuesday."

And it's not rare anymore, it's just new. Acquisitions get blocked. Companies get split. Platforms change jurisdiction. Terms change because a law changed somewhere you don't operate. The EU AI Act is reshaping products for users who have never been to Europe, which we saw two weeks ago with watermarking going global to satisfy Brussels.

You cannot forecast any of this. So stop trying. Build for the general case instead: any platform can become unavailable for reasons that have nothing to do with you, with about ten days notice, and your job is to make that annoying instead of fatal.

Before you build anything, you need to know which platform actually deserves the work, and most people rank this wrong.

The instinct is to rank by how often you log in. That's the wrong axis. Daily use means the platform is convenient. It doesn't mean it's load bearing.

Rank by two questions instead.

How much of this is irreplaceable? Not the software, the accumulated stuff inside it. Your automation platform is replaceable in a week because the scenarios are logic you could rebuild. Your customer records are not, because they took four years to accumulate and no amount of effort recreates a history of who bought what and when they stopped replying.

That's the real distinction. Tools that hold configuration are annoying to lose. Tools that hold history are expensive to lose. Sort your stack on that line and the picture usually rearranges itself.

How many other things point at it? Count the arrows. If your file storage is where six other systems drop things, it's more critical than its own function suggests, because losing it breaks six things you weren't thinking about.

Do that sort and most small businesses end up with the same two at the top: the place customer records live, and the place money moves through. Everything else is a bad week. Those two are a bad quarter.

Which is useful, because it means you don't have to solve this for your whole stack. You have to solve it properly for two things, and stop.

Here's the part worth building, and it's smaller than you'd think.

Most backup automation is one directional. Export fires, file lands, everyone assumes it worked. The failure mode is silence: the export breaks in March, nobody notices until November, and the folder is full of eight kilobyte error files with the right names.

What you want is a check that makes noise.

Run it monthly in Make. The whole thing is maybe six modules and an afternoon.

Trigger on a schedule. Monthly is right for most businesses. Weekly if you're moving fast.

Pull the export. Whatever the platform offers, API or scheduled export dropped into cloud storage.

Check the size against last time. Store the previous byte count. Compare. If the new export is more than about thirty percent smaller, something is wrong. This one check catches most silent failures, because broken exports are almost always small exports.

Check the count of the thing that matters. Not file size, records. Number of contacts, number of projects, whatever your unit is. It should go up, or hold roughly steady. A sudden drop means either a real problem or a permissions change upstream, and both are things you want to know about today rather than in November.

Verify one record end to end. Pick a known record by ID, pull it from the export, confirm the fields you actually depend on are populated. One record. Takes seconds, catches schema changes, which are the sneakiest failure because everything looks fine until you need the field that quietly stopped being included.

Tell you. Green means one line in a monthly digest you barely read. Red means a message that interrupts you. Don't send yourself a success notification every month, you'll start ignoring it by March and then you'll ignore the failure too.

That's it. The whole value is in steps three through five, which almost nobody builds, because building the export feels like finishing the job.

One refinement worth adding once the basic version runs. Store the exports somewhere that isn't the same vendor family as the thing you're backing up. If your CRM, your files, and your backups all live behind one login with one company, you don't have a backup, you have a copy. A single account suspension takes all three at once, and account suspensions happen for stupid reasons: a billing card that expired while you were on holiday, a security flag on a login from a new country, a support agent making a mistake at scale.

If your operational layer runs on Make and your files sit in the same account family as everything else, that is the arrangement to break first. Different vendor, different login, different payment method. It's the cheapest resilience you can buy and it costs nothing but a decision.

And keep one export offline. Not cloud to cloud, actually on a drive, refreshed quarterly. It feels absurdly old fashioned right up until the afternoon it's the only copy anybody can reach.

There's a second category of loss that no backup catches, and it's worth naming because people build the export, feel finished, and still get hurt.

Your platform holds data. It also holds behaviour. The scoring rules, the tags that mean something specific to you, the automation that fires when a deal hits a stage, the email template with the subject line that outperformed the other four. None of that comes out in a data export, and rebuilding it is where the real weeks go.

So alongside the export, keep a plain document. One page. What the custom fields mean, what the stages are and what moves something between them, which automations exist and what fires them, and any setting you changed away from default and why.

It takes forty minutes to write and it will feel like a waste of an afternoon. It is the difference between rebuilding in three days and rebuilding in three weeks, because the data goes back in fast and the behaviour is what you'll be reconstructing from memory at 11pm.

Anyone who has migrated a business system knows this already. Everyone who hasn't thinks the export is the whole job.

If you use Manus and you're affected, go check the restore. Obviously. Confirm what came back, and specifically confirm the stuff generated after December 29 of last year, since that's the window that was deleted. Do it today, not next month. Restoration portals have a habit of being more helpful in week one than week six.

If you don't use Manus, do the forty minute test on something else. Today, while the story is in front of you and the motivation is free.

And then the one I'd actually push you on: pick your single most dangerous dependency and give it a real answer. Not the platform you use most. The one where, if it went dark on a Tuesday with no warning, you'd be genuinely stuck.

For most small businesses that's not the CRM or the automation layer. It's usually one of two things. The place customer records live, or the place the money moves through. Everything else is replaceable in a week. Those two are the ones that turn a bad month into a bad year.

Give that one a real export, a real restore test, a real number for rebuild time, and a real check that runs monthly and yells at you.

One platform. Not all of them. Doing this properly for one thing beats doing it vaguely for nine, and you'll actually finish.

The Manus users who backed up before the twenty third are fine today, or they're finding out they're not. Either way they know. That's the entire difference between them and everybody who's been meaning to get to this since March.

Knowing is cheap. It's forty minutes and a monthly check that mostly stays quiet.

Jordan

The AI Newsroom is written by Jordan Hale. This issue contains affiliate links to tools I actually use. If you sign up through them I may earn a commission at no extra cost to you.