On 14 October, a whole season of The Challenge, a show on the Swedish channel TV4, disappeared. It was edited and due to air five weeks later. In the morning, the newspaper Aftonbladet blamed an AI agent. In the afternoon, TV4 denied it: no AI, but human error at the producer.
Everyone argued about the same question: who deleted it? TV4's head of programming gave the only useful answer. There was a backup, and it had not worked. When the files disappeared, they did not exist anywhere else.
TL;DR: after a deletion, people look for the culprit. AI agent, colleague or script, it barely matters. The real question is why no copy was left. My own backup stopped for four months without me noticing. A useful backup reports its silence, stays out of reach of whatever can delete, and has actually been restored.
This article is for developers who let AI agents work on their machine, and for business owners responsible for their data. No technical background is needed.
Who deleted it? The question saves nothing
Back to the Swedish story. According to Aftonbladet's sources, the producer Mastiff had let an AI agent onto its server. According to the same paper, TV4 answered that same day that its investigation pointed to "the human factor" at Mastiff, and not to AI.
The raw footage survived. All the editing has to be redone. The premiere, planned for 22 November, moved to 2027.
Agent or human, the result is the same. Months of work have to be redone. The difference between an outage and a disaster is not the culprit. It is the copy.
When the copy lives where the original lives
In April 2026, at the startup PocketOS, a coding agent was working on a test environment. It was Cursor, running Claude Opus 4.6. It hit a credentials error and decided to fix it on its own.
It found an access token in a file unrelated to its task. That token had been created to manage domain names. In fact, it gave full rights on the hosting provider's API. The agent deleted the production database volume in a single call. It took 9 seconds.
The backups went with it. The host, Railway, stored them in the same volume as the data. The founder summed it up: the copy was in the same blast radius as the original.
The story ends well. Railway recovered the data from its own copies, kept elsewhere. Since then, its API deletions wait 48 hours before they become final. But that rescue did not come from PocketOS. Its own latest usable backup was three months old.
My backup stopped for four months, and I did not notice
I run my coding agents without confirmation prompts. My safety net is an hourly backup of my work folders. It uses restic, and goes to a storage space I rent from Hetzner.
On 1 June, I reinstalled my machine. I wanted the new Ubuntu release, because of Nvidia driver problems. The reinstall wiped two small things: the systemd timer that started the backup, and the file that held its password.
No backup ran from 1 June to 2 October. Nothing warned me.
A backup that fails makes noise: an error, an email, a red message. A backup that no longer runs makes no noise at all. That is the one you need to watch.
I noticed by looking at my storage space at Hetzner. It had not changed in a long time.
Then I had to open the old repository. The passphrase was nowhere to be found. I had typed it by hand when I created it. I was sure I had written it down somewhere. It was nowhere, not even in my password manager. And restic's documentation is clear: without the password, the data cannot be accessed. I had to start again with a new repository.
What I set up since
- A record of every success. After each successful backup, the script writes the time to a file.
- An alert on silence. Every time my agent starts a session, a hook reads that file. If the last success is more than 48 hours old, it warns me.
- A real restore. I restored a full folder somewhere else, then compared. All 4,495 files were identical.
- A regular re-read. Every week, restic re-reads a different part of the backed-up data. In a year, the whole repository gets read.
- A layer out of reach. Hetzner takes a daily snapshot of my space, kept for about ten days. My laptop's SSH key can delete the restic repository. It cannot delete those snapshots, which are only managed from Hetzner's console or API.
That last layer has two limits, and I would rather say them.
First, snapshots rotate. Each new one pushes out the oldest. If nobody notices a deletion within ten days, there is nothing left to recover. With four months of silence, they would not have saved me. That is why the 48-hour alert matters so much.
Second, they live on the same space, at the same provider. Hetzner says it itself: a snapshot is not a full backup. It protects against a deletion from my laptop. Not against losing the account. So I still lack a copy somewhere else, and offline.
A useful backup answers four questions
Is it still running? Do not watch for errors. Watch for missing successes. A last-success date and an alert past a deadline are enough.
Who can delete it? If your laptop, your agent or one of its tokens can delete the backup, it is not a backup. It is a second folder waiting to be deleted. restic offers an append-only mode with its dedicated server: the client can add backups, not remove them.
Is it in the same place as the original? ANSSI, the French cybersecurity agency, recommends the 3-2-1 rule. That means three copies of the data: the original and two backups on different media, one of them offline. Attackers target the copies too. According to Sophos, 94% of organizations hit by ransomware say the attackers tried to compromise their backups.
Have you ever restored it? A backup that was never restored is only a hope. ANSSI puts it simply: backups must be tested regularly. The passphrase is part of that. Store it where you will find it on the day things break.
The checklist
Who deletes does not matter. What is left afterwards does.
- [ ] Record the time of the last success, and alert if it is more than 48 hours old
- [ ] Check who can delete the backup: not your laptop, not your agent, not its tokens
- [ ] Keep one copy away from the original, and one copy offline
- [ ] Store the passphrase in your password manager, then check that it opens the repository
- [ ] Restore a real folder, compare the files, write down the date of the test
- [ ] Re-read part of the backed-up data every week
- [ ] After a reinstall, check that your scheduled tasks still run
- [ ] Give your agents tokens limited to their task
What to remember
One day, something will delete your data. An AI agent, a colleague, a script, or you. You do not control who. You control the copy.
A useful backup is watched for its silence. It lives out of reach of whatever can delete. And it has been restored at least once.
Want to check that your team's backups would hold the day an agent gets it wrong? Let's talk.
Sources: TV4, The Challenge season deleted (14/10/2026) · Aftonbladet, same story · Cybernews, in English · Decrypt, PocketOS (28/04/2026) · Railway, recovery and guardrails · restic, repository password · restic rest-server, append-only mode · Hetzner, Storage Box snapshots · ANSSI, backup fundamentals (2025, French) · Sophos, compromised backups (2024)
Top comments (0)